upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 4 months
Self-Introduction: Denis Ovsienko and /etc/net project
by Denis Ovsienko
Denis Ovsienko
Russia, Moscow
Linux system administrator and developer
ValueCommerce/Russia
I develop /etc/net project (http://etcnet.org) and my goal is to integrate it
into Fedora Core.
I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux
development tree and should soon be seen in 3.0 version.
I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too,
but i haven't heard from them for last months.
My skills include 6 years Linux experience, several programming
languages, 5 years of mixed software development and system/network
administration and so on, but I guess it's not related much to my goal now.
I have reviewed current initscripts buglist.
Some bugs are not bugs in /etc/net:
#65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop...
#75390 it would be nice to tie bandwidth shaping into the networ...
#129820 initscripts maclist patch
#132252 Request for addition of routing rule config file
#132912 No additional IP addresses at ethX without aliased devices
#132925 initscripts use old ifconfig instead of iproute2
#154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup...
#168990 No ifup-gre/ifdown-gre scripts.
#170884 MTU of ethernet card can't be set before interface is up
#171763 Enhancement to initscripts
Some bugs gave me ideas how to improve /etc/net:
#59114 .d-style scripts for ifup/ifdown
#119952 RFE: Add hook for "local" network initialization
#124045 Support setting a metric on interface routes
The whole process, if we don't face some unexpected problems, should take
3 to 6 months. What I need:
1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages.
2. Probably some help with documentation.
How can we start?
pub 1024D/6D1844F2 2002-11-11
Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2
uid Denis Ovsienko <linux(a)pilot.org.ua>
uid Denis Ovsienko (http://pilot.org.ua) <pilot(a)altlinux.ru>
sub 2048g/57B7ACBE 2002-11-11
--
DO4-UANIC
15 years, 7 months
[offtopic] Ignacio Vazquez-Abrams
by Arthur Pemberton
Hi guys,
I apologize ahead of time for the offtopic nature of this thread, and
if desired, I will cease any continuation. Threads over on
fedora-extras-list have brought my attention to the e-dissappearance
of one "Ignacio Vazquez-Abrams".
This guy has helped me out many times over of #fedora, and was always
online, despite me changing time zone twice - to the point where I
asked if he was a bot. He seemed to have also had a large load in
package maintaince. Fedora being partly about the community, I have to
ask: does anyone know what happened to this guy? His online presence
seems to have simply ceased as of May-2006. I searched Gmail for
emails from him, the last was in May. His blog
(http://www.ivazquez.net) seems also to have gone quiet as of May.
Just felt that the guy has helped me enough to at least care if he
suddenly died or something.
Peace.
--
To be updated...
16 years, 4 months
Move Evolution to Extras?
by David Woodhouse
Evolution is fairly much broken in FC5, and there's little movement even
on the 'this mail crashes Evolution' bugs, let alone the "Evolution is
totally unusable with IMAP" bugs.
What are we going to do about it? One option might be to move it to
Extras in the hope that someone will actually start to look after it
there. Or perhaps just drop it entirely? Any better ideas? Volunteers?
--
dwmw2
16 years, 5 months
Re: gstreamer and selinux issue
by Louis Garcia
On Fri, 2006-08-11 at 08:01 -0100, Paul Howarth wrote:
> On Thu, 2006-08-10 at 16:31 -0400, Louis Garcia II wrote:
> > On Thu, 2006-08-10 at 10:15 -0400, Daniel J Walsh wrote:
> > > On Wed, 2006-08-09 at 20:31 -0400, Louis Garcia II wrote:
> > > > On Wed, 2006-08-09 at 18:12 -0400, Louis Garcia II wrote:
> > > > > I was able to setup the pitfdll plugin for gstreamer and use the win32
> > > > > codecs under fc5 with selinux enabled. The pitfdll plugin needed to be
> > > > > marked textrel_shlib_t and the codecs under /usr/lib/win32 marked lib_t.
> > > > > > This worked for FC5 under selinux and FC6 with selinux disabled. But
> > > > > selinux under FC6 seems to have changed. Is their another lable I
> > > > > should use, how can I debug this?
> > > > >
> > > > > -Thanks
> > > >
> > > > This is what I get:
> > > >
> > > > Aug 9 19:12:34 soncomputer kernel: audit(1155165152.723:10): avc:
> > > > denied { execstack } for pid=9530 comm="totem"
> > > > scontext=user_u:system_r:unconfined_t:s0
> > > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process
> > > >
> > > > -Louis
> > >
> > > you can turn on allow_execstack or change the context of totem to
> > unconfined_execmen_exec_t
> > > chcon -t unconfined_execmem_exec_t /usr/bin/totem
> >
> > if I turn on allow_execstack would that be for everything
>
> Yes.
>
> > or just for totem?
> > What would be the most secure of these two options?
>
> Just changing the context type of totem.
>
> Paul.
Ok, I chaged the context type of totem and now it's:
-rwxr-xr-x root root system_u:object_r:unconfined_execmem_exec_t /usr/bin/totem
This seems to fix my problem. However I get a slightly different message now:
Aug 11 15:09:41 soncomputer kernel: audit(1155323379.605:36): avc: denied { execheap } for pid=3094 comm="totem" scontext=user_u:system_r:unconfined_execmem_t:s0 tcontext=user_u:system_r:unconfined_execmem_t:s0 tclass=process
what does it mean?
-Louis
16 years, 7 months
Firefox trademark shenanigans (Re: Any chance of getting Firefox 2.0 into rawhide/FC6?)
by Konstantin Ryabitsev
On 9/28/06, Stephen John Smoogen <smooge(a)gmail.com> wrote:
> > Besides, GNOME and gaim are applications designed and written for you
> > the Linux user in mind (GNOME arguably is done with the Fedora user in
> > mind), and we have sway with what goes in to that codebase. Firefox is
> > written with the Windows user in mind and if you find bugs, I am not
> > guaranteed to be able to fix them because I (on behalf of Fedora or Red
> > Hat) can't make changes to the source code without getting approval from
> > the Mozilla Corporation pursuant to their trademarking guidelines.
> >
>
> IceWeasel!
Honestly, we may consider doing the same thing as Debian guys, to show
our support and to prevent future possibility of a similar situation,
in case/when MozCo decides to change their marketing rules again.
Besides, it is my understanding (from reading the Debian bug
discussion and generally from being roommates with the Debian Firefox
maintainer in question), that MozCo is enforcing the "if you use the
name, you must use the logo" rule. In theory, since the logo is
copyrighted (and not sensibly licensed), Fedora should NOT be able to
use the name with a generic logo, unless Red Hat has an agreement with
MozCo about this specific case. Even in the case when such agreement
exists, it's still not acceptable, because it interferes with any
third-party repackaging of the Fedora tree. This restriction is
already true for current releases of Fedora.
If Red Hat and Debian both pick a name for a non-restricted version of
Firefox, then that would help lessen the potential confusion. It would
suck if every distro has Firefox under a different name. If someone
wants to cooperate with the Debian Firefox maintainer, he's open to
such dialogue with Red Hat/Fedora (FESCO?). Interested parties may get
in touch with him via eric(a)debian.org (he's cc'd on this message).
I think "IceWeasel" is very silly and creates unnecessary tension with
upstream, but "Freefox" sounds like a winner, unless it is decided by
IAALs that it's too close to "Firefox" and thus can be found
infringing.
It's definitely late for such change to happen in the FC6 timeframe,
but we have to look further, and if we are to stick to the motto of
providing a distribution that is "free to infinity," then we can't
continue to ship Firefox under the name that limits what we can and
cannot do with the software.
Regards,
--
Konstantin Ryabitsev
Montréal, Québec
16 years, 7 months
where have some X bitmaps gone?
by Patrice Dumas
Hello,
In the lesstif tests, there is a test with references to some bitmap
that used to be shipped with X:
#include <X11/bitmaps/Excl>
#include <X11/bitmaps/FlipHoriz>
#include <X11/bitmaps/FlipVert>
#include <X11/bitmaps/Left>
#include <X11/bitmaps/Right>
#include <X11/bitmaps/Up>
#include <X11/bitmaps/Down>
#include <X11/bitmaps/Fold>
#include <X11/bitmaps/Term>
#include <X11/bitmaps/woman>
I tried to find them, but I didn't succeed. Am I missing something?
--
Pat
16 years, 7 months
rpmbuild with target i386 on x86_64 sets %{_libdir} to lib64.
by Rob Andrews
Hi,
Since I don't have an i386 installation of Fedora, I am trying to build a
set of i386 RPMs on my x86_64 machine using:
rpmbuild --target=i386 --rebuild foo.src.rpm
or
rpmbuild --target=i386 -bb foo.spec
However, it is expanding %{_libdir} to /usr/lib64.
Am I doing something wrong? I'm tempted to use --define="_libdir /usr/lib"
for a quick fix, but I was under the impression that building i386 packages
would have adjusted the path definitions accordingly.
Thanks,
rob.
--
rob andrews :: pgp 0x01e00563 :: rob(a)choralone.org
16 years, 8 months
Re: FC5 "rpmbuild -ta" problems
by Marcio Oliveira
>
>
>
> >> Hi there,
> >>
> >> I got many error messages on FC5 fully updated trying to compile tar
> >> packages using "rpmbuild -ta tar_package.tar.gz" command.
>
> >This is already filed:
> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206841
thank you...
>> I solved this problem adding "-" before tar options and "--wildcards"v
> >> to tar command in build.c file. (see attached patch).
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >> --- rpm-4.4.2/build.c.orig 2006-09-29 09:17:25.000000000 -0300
> >> +++ rpm-4.4.2/build.c 2006-09-29 09:18:01.000000000 -0300
> >> @@ -144,7 +144,7 @@
> >> (void) isCompressed(arg, &res);
> >>
> >> cmd = alloca(strlen(arg) + 50 + strlen(tmpSpecFile));
> >> - sprintf(cmd, "%s < %s | tar xOvf - Specfile 2>&1 > %s",
> >> + sprintf(cmd, "%s < %s | tar -xOvf - Specfile 2>&1 > %s",
> >> zcmds[res & 0x3], arg, tmpSpecFile);
> >> if (!(fp = popen(cmd, "r"))) {
> >> rpmError(RPMERR_POPEN, _("Failed to open tar pipe: %m\n"));
> >> @@ -156,7 +156,7 @@
> >> /* Try again */
> >> (void) pclose(fp);
> >>
> >> - sprintf(cmd, "%s < %s | tar xOvf - \\*.spec 2>&1 > %s",
> >> + sprintf(cmd, "%s < %s | tar --wildcards -xOvf - \\*.spec 2>&1
> > %s",
> >> zcmds[res & 0x3], arg, tmpSpecFile);
> >> if (!(fp = popen(cmd, "r"))) {
> >> rpmError(RPMERR_POPEN, _("Failed to open tar pipe:
> %m\n"));
> >>
>
> >Posting this patch to bugzilla would highly appreciated, I think.
> >
> >Mamoru Tasaka
Patch and info posted!
Thank you!
Márcio Oliveira
16 years, 8 months
