From perbj at stanford.edu  Wed Dec  1 00:25:54 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Tue, 30 Nov 2004 16:25:54 -0800
Subject: Elektrified X.org released (was: X configuration paradigm, and
	a proposal)
In-Reply-To: <1101843846.25617.116.camel@localhost.localdomain>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
	<1101839022.3783.25.camel@localhost.localdomain>
	<1101843846.25617.116.camel@localhost.localdomain>
Message-ID: <1101860754.3434.11.camel@localhost.localdomain>

On Tue, 2004-11-30 at 19:44 +0000, Alan Cox wrote:
> Mobility Electronics have been shipping cardbus hotplug video for about
> 5 or 6 years now (E1000V). They make fun toys for this sort of testing
> and are cheap on ebay generally 8)

Hotplug of displays is way more common than that; consider the laptop
case, where you want to sometimes plug in a projector and just mirror
the main display (which mostly works now) but sometimes you want to plug
in a second monitor for extra screen real estate and expand your desktop
onto it, and most of the time you just have the laptop display. At least
I haven't found a way to do the switch without an X restart but I guess
I might have missed something (can RandR help with this simple case)?

Of course, if the general hotplug case is taken care of, reconfiguration
of a graphics card on the fly will probably basically be solved
automatically as part of that so that's definitely the real solution;
however, some work and testing might be possible even without somewhat
exotic hardware.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From alan at redhat.com  Wed Dec  1 01:16:31 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 30 Nov 2004 20:16:31 -0500
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <1101860754.3434.11.camel@localhost.localdomain>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
	<1101839022.3783.25.camel@localhost.localdomain>
	<1101843846.25617.116.camel@localhost.localdomain>
	<1101860754.3434.11.camel@localhost.localdomain>
Message-ID: <20041201011631.GB19687@devserv.devel.redhat.com>

On Tue, Nov 30, 2004 at 04:25:54PM -0800, Per Bjornsson wrote:
> Hotplug of displays is way more common than that; consider the laptop
> case, where you want to sometimes plug in a projector and just mirror
> the main display (which mostly works now) but sometimes you want to plug

This is a hotplug video card rather than hotplug video ports. Its a cardbus
bridge with an ATI rage based device behind it.

Alan



From quarlewm at jmu.edu  Wed Dec  1 02:56:23 2004
From: quarlewm at jmu.edu (William M. Quarles)
Date: Tue, 30 Nov 2004 21:56:23 -0500
Subject: i486 base architecture
In-Reply-To: <1101835626.2640.65.camel@laptop.fenrus.org>
References: <codhib$pg2$1@sea.gmane.org>	<Pine.LNX.4.58.0411281657220.19060@devserv.devel.redhat.com>	<codki5$ls0$3@sea.gmane.org>	<604aa7910411281454a3a118a@mail.gmail.com>	<20041128234650.GA13367@ee.oulu.fi>
	<codrhv$4fd$1@sea.gmane.org>	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
Message-ID: <cojbso$fce$1@sea.gmane.org>

Arjan van de Ven wrote:
> On Tue, 2004-11-30 at 12:05 -0500, William M. Quarles wrote:
> 
>>performance difference.  Now were you saying that this cmov is part of 
>>i486 or i686?
> 
> 
> i686

What differences between i386 and i486 would become a benefit if the 
base architecture was changed from i386 to i486?

----
Thanks,
William



From alan at redhat.com  Wed Dec  1 03:00:26 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 30 Nov 2004 22:00:26 -0500
Subject: i486 base architecture
In-Reply-To: <cojbso$fce$1@sea.gmane.org>
References: <codki5$ls0$3@sea.gmane.org>
	<604aa7910411281454a3a118a@mail.gmail.com>
	<20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>
	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
Message-ID: <20041201030026.GA26613@devserv.devel.redhat.com>

On Tue, Nov 30, 2004 at 09:56:23PM -0500, William M. Quarles wrote:
> What differences between i386 and i486 would become a benefit if the 
> base architecture was changed from i386 to i486?

The only thing 486 might give is the ability to consign the old linuxthread 
stuff to the dustbin of back compatibility.



From ziga.mahkovec at klika.si  Wed Dec  1 02:59:58 2004
From: ziga.mahkovec at klika.si (Ziga Mahkovec)
Date: Wed, 01 Dec 2004 03:59:58 +0100
Subject: adventures in booting
In-Reply-To: <1101692986.2025.22.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
Message-ID: <1101869999.3544.65.camel@serenity.klika.si>

On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> So, I've looked a bit more into the booting process and how to optimize
> it.

Great work!

> The results are pretty good I think, here is the general time line made
> with a wallclock
> 
> 00: exit grub; start booting the kernel
> 04: kernel prints audit()
> 11: initrd is mounted; Red Hat nash visible
>      mount / ro (normal initrd procedure)
> 13: start bootchart logging; start readahead of approx 193MB files
>      sleep until readahead is complete
> 24: readahead done; now
>      create /dev and modprobe (in background)
>      mount / rw, enable swap
>      start xfs
>      startx as user davidz in background
>      start messagebus
>      start hald
>      start acpid
>      start NetworkManager

Do you have an idea of how much kudzu, cups and syslogd would add to
these times?  rhgb too probably, or would it make sense to dump it
completely?

> 7. A number of things was started in parallel - I found that doing
>    readahead while running modprobe wasn't helping anything; in fact
>    it contributed negatively to performance (a bit to my surprise, I
>    guess because the kernel was busy).

You think it might make sense to try running readahead in background,
but after the modules are loaded?  Especially if the readahead list
could somehow coincide with the order of services started, to further
reduce seeking.
Or is readahead best left running alone?

> So, I think these numbers are good and there's still some room for
> improvement; e.g. it takes ten seconds from grub to when the initrd is
> mounted - surely the kernel can boot faster? It's after all 25% of the
> time spent from grub until I have usable desktop.

I did some experiments with bootchart logging in the initrd phase.
Packed the initrd image with bash, ps and a bunch of libraries and
started logging early in the nash script... only to find out that the
whole phase flies by in less than a second :)

I would like to visualize the kernel boot though.  But I'd need pointers
on what kind of data to collect, and how.

> Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
> very useful.

BTW, I've had loads of fun with SVG lately, so you might want to try
regenerating these charts.  Makes them scalable and about 15x smaller in
file size.  Have a look at the SVG samples (rsvg does a pretty good
job):
http://www.klika.si/ziga/bootchart/#Samples

-- 
Ziga



From paul at dishone.st  Wed Dec  1 03:44:33 2004
From: paul at dishone.st (Paul Jakma)
Date: Wed, 1 Dec 2004 03:44:33 +0000 (GMT)
Subject: Suggestion for some network parameter defaults
In-Reply-To: <20041129124014.11380474@nausicaa.camperquake.de>
References: <20041129124014.11380474@nausicaa.camperquake.de>
Message-ID: <Pine.LNX.4.61.0412010343160.18143@hibernia.jakma.org>

On Mon, 29 Nov 2004, Ralf Ertzinger wrote:

> Hi.
>
> net.ipv4.conf.all.accept_redirects         (current: 1, proposed: 0)

This will break on networks with logical subnets.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Sattinger's Law:
 	It works better if you plug it in.



From quarlewm at jmu.edu  Wed Dec  1 04:06:21 2004
From: quarlewm at jmu.edu (William M. Quarles)
Date: Tue, 30 Nov 2004 23:06:21 -0500
Subject: i486 base architecture
In-Reply-To: <20041201030026.GA26613@devserv.devel.redhat.com>
References: <codki5$ls0$3@sea.gmane.org>	<604aa7910411281454a3a118a@mail.gmail.com>	<20041128234650.GA13367@ee.oulu.fi>
	<codrhv$4fd$1@sea.gmane.org>	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>	<1101835626.2640.65.camel@laptop.fenrus.org>	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
Message-ID: <cojfvm$nid$1@sea.gmane.org>

Alan Cox wrote:
> On Tue, Nov 30, 2004 at 09:56:23PM -0500, William M. Quarles wrote:
> 
>>What differences between i386 and i486 would become a benefit if the 
>>base architecture was changed from i386 to i486?
> 
> The only thing 486 might give is the ability to consign the old linuxthread 
> stuff to the dustbin of back compatibility.

I'm guessing that's supposed to be a joke?

----
Peace,
William



From nmiell at comcast.net  Wed Dec  1 06:22:54 2004
From: nmiell at comcast.net (Nicholas Miell)
Date: Tue, 30 Nov 2004 22:22:54 -0800
Subject: i486 base architecture
In-Reply-To: <cojfvm$nid$1@sea.gmane.org>
References: <codki5$ls0$3@sea.gmane.org>
	<604aa7910411281454a3a118a@mail.gmail.com>
	<20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
Message-ID: <1101882174.3522.7.camel@localhost.localdomain>

On Tue, 2004-11-30 at 23:06 -0500, William M. Quarles wrote:
> Alan Cox wrote:
> > On Tue, Nov 30, 2004 at 09:56:23PM -0500, William M. Quarles wrote:
> > 
> >>What differences between i386 and i486 would become a benefit if the 
> >>base architecture was changed from i386 to i486?
> > 
> > The only thing 486 might give is the ability to consign the old linuxthread 
> > stuff to the dustbin of back compatibility.
> 
> I'm guessing that's supposed to be a joke?

No, the x86 NPTL implementation requires the CMPXCHG instruction, which
was introduced in the i486.
-- 
Nicholas Miell <nmiell at comcast.net>



From buildsys at redhat.com  Wed Dec  1 12:46:04 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 1 Dec 2004 07:46:04 -0500
Subject: rawhide report: 20041201 changes
Message-ID: <200412011246.iB1Ck4C32511@porkchop.devel.redhat.com>



From alan at redhat.com  Wed Dec  1 13:12:36 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 1 Dec 2004 08:12:36 -0500
Subject: i486 base architecture
In-Reply-To: <cojfvm$nid$1@sea.gmane.org>
References: <20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>
	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
Message-ID: <20041201131236.GA6851@devserv.devel.redhat.com>

On Tue, Nov 30, 2004 at 11:06:21PM -0500, William M. Quarles wrote:
> >The only thing 486 might give is the ability to consign the old 
> >linuxthread stuff to the dustbin of back compatibility.
> 
> I'm guessing that's supposed to be a joke?

No its quite serious. 486 adds a lot of the SMP instructions like XADD that
good threading in user space wants.



From tmraz at redhat.com  Wed Dec  1 13:58:32 2004
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 01 Dec 2004 14:58:32 +0100
Subject: i486 base architecture
In-Reply-To: <20041201131236.GA6851@devserv.devel.redhat.com>
References: <20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>
	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
Message-ID: <1101909512.4123.7.camel@localhost.localdomain>

On Wed, 2004-12-01 at 08:12 -0500, Alan Cox wrote:
> On Tue, Nov 30, 2004 at 11:06:21PM -0500, William M. Quarles wrote:
> > >The only thing 486 might give is the ability to consign the old 
> > >linuxthread stuff to the dustbin of back compatibility.
> > 
> > I'm guessing that's supposed to be a joke?
> 
> No its quite serious. 486 adds a lot of the SMP instructions like XADD that
> good threading in user space wants.

So actually that could be a good reason why we should switch over to
i486 as base arch?

-- 
Tomas Mraz <tmraz at redhat.com>



From arjanv at redhat.com  Wed Dec  1 14:02:17 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 01 Dec 2004 15:02:17 +0100
Subject: i486 base architecture
In-Reply-To: <1101909512.4123.7.camel@localhost.localdomain>
References: <20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>
	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
Message-ID: <1101909736.2640.27.camel@laptop.fenrus.org>


> So actually that could be a good reason why we should switch over to
> i486 as base arch?

for the glibc package... sure ;)

for all other packages... none will use the new instructions afaics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041201/81867d27/attachment.sig>

From P at draigBrady.com  Wed Dec  1 14:17:44 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Wed, 01 Dec 2004 14:17:44 +0000
Subject: i486 base architecture
In-Reply-To: <20041201131236.GA6851@devserv.devel.redhat.com>
References: <20041128234650.GA13367@ee.oulu.fi>
	<codrhv$4fd$1@sea.gmane.org>	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>	<1101835626.2640.65.camel@laptop.fenrus.org>	<cojbso$fce$1@sea.gmane.org>	<20041201030026.GA26613@devserv.devel.redhat.com>	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
Message-ID: <41ADD288.1060507@draigBrady.com>

Alan Cox wrote:
> On Tue, Nov 30, 2004 at 11:06:21PM -0500, William M. Quarles wrote:
> 
>>>The only thing 486 might give is the ability to consign the old 
>>>linuxthread stuff to the dustbin of back compatibility.
>>
>>I'm guessing that's supposed to be a joke?
> 
> 
> No its quite serious. 486 adds a lot of the SMP instructions like XADD that
> good threading in user space wants.

True. However they could be emulated inefficiently on 386.
I remember seeing a patch (I think from Andi Kleen) that
added 386 suport to NPTL.

Also note that http://cobind.com/ supports 386

P?draig.



From n3npq at nc.rr.com  Wed Dec  1 14:18:08 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Wed, 01 Dec 2004 09:18:08 -0500
Subject: i486 base architecture
In-Reply-To: <1101909736.2640.27.camel@laptop.fenrus.org>
References: <20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>
	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
Message-ID: <41ADD2A0.6050703@nc.rr.com>

Arjan van de Ven wrote:

>>So actually that could be a good reason why we should switch over to
>>i486 as base arch?
>>    
>>
>
>for the glibc package... sure ;)
>
>for all other packages... none will use the new instructions afaics
>  
>

Absolutely agreed, more pain that gain for s/i386/i486/ everywhere.

However -- as always -- the problem is one of perception, and '*.i386.rpm'
signifies something quite different than '*.i486.rpm' no matter what 
instructions
are actually used within the package.

Perhaps we need to change the perception in order to lose linux threads 
forever.

Again, I know quite well more pain than gain, fixing all the bleeping 
scripts
that have embedded i386/* and/or *.i386.rpm, to know 'i486' is gonna break
a whole lot of process.

But perhaps it's time to signify Something Else Instead.

73 de Jeff



From arjanv at redhat.com  Wed Dec  1 14:19:33 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 1 Dec 2004 15:19:33 +0100
Subject: i486 base architecture
In-Reply-To: <41ADD2A0.6050703@nc.rr.com>
References: <1101799715.2640.19.camel@laptop.fenrus.org>
	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
Message-ID: <20041201141933.GA8641@devserv.devel.redhat.com>

On Wed, Dec 01, 2004 at 09:18:08AM -0500, Jeff Johnson wrote:
> scripts
> that have embedded i386/* and/or *.i386.rpm, to know 'i486' is gonna break
> a whole lot of process.

yeah just make the i686 rpms be i386 ones with a Require: cpu(cmov)



From pp at ee.oulu.fi  Wed Dec  1 14:26:47 2004
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Wed, 1 Dec 2004 16:26:47 +0200
Subject: i486 base architecture
In-Reply-To: <20041201141933.GA8641@devserv.devel.redhat.com>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
Message-ID: <20041201142647.GA8785@ee.oulu.fi>

On Wed, Dec 01, 2004 at 03:19:33PM +0100, Arjan van de Ven wrote:
> On Wed, Dec 01, 2004 at 09:18:08AM -0500, Jeff Johnson wrote:
> > scripts
> > that have embedded i386/* and/or *.i386.rpm, to know 'i486' is gonna break
> > a whole lot of process.
> 
> yeah just make the i686 rpms be i386 ones with a Require: cpu(cmov)
Ignoring the severe technical problems that it would create (It'd
break _everything_ and be way too much work to implement), how about
.ia32.rpm for everything that is .i386 now and use i?86.rpm for stuff
that requires a specific cpu?

Too much work for just ending some FAQ's for no technical benefit, certainly ;)

-- 
Pekka Pietikainen



From n3npq at nc.rr.com  Wed Dec  1 14:37:34 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Wed, 01 Dec 2004 09:37:34 -0500
Subject: i486 base architecture
In-Reply-To: <20041201142647.GA8785@ee.oulu.fi>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi>
Message-ID: <41ADD72E.3040000@nc.rr.com>

Pekka Pietikainen wrote:

>On Wed, Dec 01, 2004 at 03:19:33PM +0100, Arjan van de Ven wrote:
>  
>
>>On Wed, Dec 01, 2004 at 09:18:08AM -0500, Jeff Johnson wrote:
>>    
>>
>>>scripts
>>>that have embedded i386/* and/or *.i386.rpm, to know 'i486' is gonna break
>>>a whole lot of process.
>>>      
>>>
>>yeah just make the i686 rpms be i386 ones with a Require: cpu(cmov)
>>    
>>
>Ignoring the severe technical problems that it would create (It'd
>break _everything_ and be way too much work to implement), how about
>.ia32.rpm for everything that is .i386 now and use i?86.rpm for stuff
>that requires a specific cpu?
>  
>

No, Requires: cpu(cmov) breaks nothing, it's just another strcmp to rpm. 
Your expectations
are what is confusing you. Yes, there would be a lot of confusion for a 
short period of time,
but as Arjan has pointed out, there are only a handful of packages that 
need to carry the
dependency.

s/i386/ia32/ is marketing hype and fluff, much like s/x86_64/amd64/, 
vendors need to
signify Newer! better! Bestest! somehow.

>Too much work for just ending some FAQ's for no technical benefit, certainly ;)
>  
>

The real reason for doing
    Requires: cpu(cmov)
is that it identifies the reason for the dependency quite clearly, 
narrowly, and objectively,
which will be easier to support, maintain, and adjusts expectations to 
what is needed, rather
than endless learned discussions of what an 'i686' actually means these 
days.

73 de Jeff




From pjones at redhat.com  Wed Dec  1 16:09:34 2004
From: pjones at redhat.com (Peter Jones)
Date: Wed, 01 Dec 2004 11:09:34 -0500
Subject: i486 base architecture
In-Reply-To: <41ADD72E.3040000@nc.rr.com>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi>  <41ADD72E.3040000@nc.rr.com>
Message-ID: <1101917374.13895.3.camel@localhost.localdomain>

> >>yeah just make the i686 rpms be i386 ones with a Require: cpu(cmov)
> >>    
> >>
> >Ignoring the severe technical problems that it would create (It'd
> >break _everything_ and be way too much work to implement), how about
> >.ia32.rpm for everything that is .i386 now and use i?86.rpm for stuff
> >that requires a specific cpu?
>
> No, Requires: cpu(cmov) breaks nothing, it's just another strcmp to rpm. 
> Your expectations are what is confusing you. Yes, there would be a lot
> of confusion for a short period of time, but as Arjan has pointed out, 
> there are only a handful of packages that need to carry the dependency.

RPM isn't the only thing that touches files though.  Lots of stuff
doesn't expect that it'll find 2 i386 packages, so it'll dump them to
the same filename.  I know it sounds silly, but having the arch
difference means it's easy to generate non-colliding filenames.

That's not to say we shouldn't do the "Requires: cpu(cmov)" as _well_,
since it could obviously be helpful in many situations.

-- 
        Peter



From avibrazil at gmail.com  Wed Dec  1 16:41:01 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Wed, 1 Dec 2004 13:41:01 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <1101838973.6103.103.camel@localhost.localdomain>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101837905.2684.4.camel@kyrre>
	<1101838973.6103.103.camel@localhost.localdomain>
Message-ID: <ed0efd31041201084170ecdacc@mail.gmail.com>

On Tue, 30 Nov 2004 13:22:53 -0500, Darrin Thompson <darrint at progeny.com> wrote:
> On Tue, 2004-11-30 at 19:05 +0100, Kyrre Ness Sjobak wrote:
> 
> 
> > While i am all for the *idea*, what happens if your X11 server breaks
> > down and you *have* to use VIM to "save" it? While i am not opposed to
> > creating an easily learned api for config-file configuration, i am
> > *strongly* opposed to not be able to hack into that xorg.conf file from
> > a crude command line (hell, i have vim'ed config files with /bin/bash as
> > my init process and a half borked kernel that would boot 1/5 times...).
> >
> > I don't want my config's to be put all in the hands of some program, to
> > *have* to use a config program (with all the odds and ends it migth
> > have...) in order to fix a broken config. Now imagine that program
> > needed another program, which needed a service wich needed ... the thing
> > you where just trying to fix.
> >
> 
> You don't *have* to use a config program, the keys are all vim hackable.
> It might be a royal pain, however, to add a bunch of keys with an
> editor. Tweaks would be easy enough though.
> 
> http://elektra.sourceforge.net/#rgfacts (third bullet, also seventh)

Also this screenshot: http://elektra.sourceforge.net/#edit
Which shows using any text editor (including vi) to edit an export of a subtree.

The idea is to create such a level of integration between
applications, that you probably won't need to edit configuration by
hand. Software will do this for you.
How many times per year you edit modern windows registry by hand? How
many times per year you edit GConf keys by hand ?

Regards,
Avi



From kyrre at solution-forge.net  Wed Dec  1 16:41:20 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 01 Dec 2004 17:41:20 +0100
Subject: Elektrified X.org released (was: X configuration paradigm, and
	a proposal)
In-Reply-To: <1101836596.1676.31.camel@davidz>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
Message-ID: <1101919279.2675.16.camel@kyrre>

tir, 30.11.2004 kl. 18.43 skrev David Zeuthen:
> Hey,
> 
> I'm all for improving the situation with around auto configuration of
> hardware, but with all due respect, I think you guys are trying to solve
> the symptom, not the real problem. In my view you really want the X
> server to be able to export an API for software higher up the stack
> (GNOME, KDE, etc.) to configure the X server. You also want to
> reconfigure it while it's running. It seems to me, that putting in an
> mediator, for basically writing out configuration files, is not the best
> API for doing this. I could be wrong though. Ideally the X server
> wouldn't even touch hardware before someone used that API to say "Add
> monitor, Add input device, blah blah".
> 
> Anyway, with the right API in the X server (which would probably be
> exported through D-BUS), I should be able to write a daemon, let's call
> it gnome-input-manager, that runs in the desktop session as user davidz.
> This would also allow said daemon to disable the touchpad when I connect
> an external mouse or, for more fun, to disable it around intervals where
> I'm punching the keys. The reason you want this in the desktop session
> is that you want to query the locally logged in users preferences from
> e.g. gconf or whatever.
> 
> Just what I personally think.

Hmm... Would it be possible to restart *X11* without killing the current
session? So that the user would only se a "blink" and then whatever was
working?



From avibrazil at gmail.com  Wed Dec  1 16:45:48 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Wed, 1 Dec 2004 13:45:48 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <20041130185654.GA15322@devserv.devel.redhat.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
	<20041130185654.GA15322@devserv.devel.redhat.com>
Message-ID: <ed0efd31041201084574fdd591@mail.gmail.com>

On Tue, 30 Nov 2004 13:56:54 -0500, Alan Cox <alan at redhat.com> wrote:
> On Tue, Nov 30, 2004 at 12:43:16PM -0500, David Zeuthen wrote:
> > exported through D-BUS), I should be able to write a daemon, let's call
> > it gnome-input-manager, that runs in the desktop session as user davidz.
> > This would also allow said daemon to disable the touchpad when I connect
> > an external mouse or, for more fun, to disable it around intervals where
> > I'm punching the keys. The reason you want this in the desktop session
> 
> You pretty much have to. I've got a hotplug video card here for example.
> That really ruins the current configuration system. OTOH you have to start
> somewhere and if the goal is to unify configuration then you want to let
> someone else rewrite X. However as you and Havoc both point out it has
> to handle notifiers
> 

Good. Elektra has call to get notification. Check the kdbMonitorKey()
and kdbMonitorKeys() methods in the Doxygen:
http://elektra.sourceforge.net/elektra-api/html/



From kyrre at solution-forge.net  Wed Dec  1 16:48:10 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 01 Dec 2004 17:48:10 +0100
Subject: i486 base architecture
In-Reply-To: <cojbso$fce$1@sea.gmane.org>
References: <codhib$pg2$1@sea.gmane.org>
	<Pine.LNX.4.58.0411281657220.19060@devserv.devel.redhat.com>
	<codki5$ls0$3@sea.gmane.org>	<604aa7910411281454a3a118a@mail.gmail.com>
	<20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
Message-ID: <1101919690.2675.19.camel@kyrre>

ons, 01.12.2004 kl. 03.56 skrev William M. Quarles:
> Arjan van de Ven wrote:
> > On Tue, 2004-11-30 at 12:05 -0500, William M. Quarles wrote:
> > 
> >>performance difference.  Now were you saying that this cmov is part of 
> >>i486 or i686?
> > 
> > 
> > i686
> 
> What differences between i386 and i486 would become a benefit if the 
> base architecture was changed from i386 to i486?

Or to i586? Who are running newish fedora/redhat things on anything
older than a pentium 1 anyway?

Sorry if am sounding stupid... But really...

Kyrre



From n3npq at nc.rr.com  Wed Dec  1 17:07:02 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Wed, 01 Dec 2004 12:07:02 -0500
Subject: i486 base architecture
In-Reply-To: <1101917374.13895.3.camel@localhost.localdomain>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
Message-ID: <41ADFA36.4060703@nc.rr.com>

Peter Jones wrote:

>>>>yeah just make the i686 rpms be i386 ones with a Require: cpu(cmov)
>>>>   
>>>>
>>>>        
>>>>
>>>Ignoring the severe technical problems that it would create (It'd
>>>break _everything_ and be way too much work to implement), how about
>>>.ia32.rpm for everything that is .i386 now and use i?86.rpm for stuff
>>>that requires a specific cpu?
>>>      
>>>
>>No, Requires: cpu(cmov) breaks nothing, it's just another strcmp to rpm. 
>>Your expectations are what is confusing you. Yes, there would be a lot
>>of confusion for a short period of time, but as Arjan has pointed out, 
>>there are only a handful of packages that need to carry the dependency.
>>    
>>
>
>RPM isn't the only thing that touches files though.  Lots of stuff
>doesn't expect that it'll find 2 i386 packages, so it'll dump them to
>the same filename.  I know it sounds silly, but having the arch
>difference means it's easy to generate non-colliding filenames.
>
>That's not to say we shouldn't do the "Requires: cpu(cmov)" as _well_,
>since it could obviously be helpful in many situations.
>
>  
>
OK, to summarize:

    a) There's a whole lot of pain and not much gain messing with 
package file names (and file paths and scripts and ... )
    b) The dependency
            Requires: cpu(cmov)
         (or equivalent token) might (*will* imho) be useful identifying 
packages that actually use, say, cmov.
        (Note: there's more than cmov that needs marking, generalizing 
the cpu(...) name space is quite straightforward.)
    c) Users want a clear call on what package file name to install, as 
some *.i386.rpm will not run on arch i386, very confusing.
    d) linuxthreads needs to die! die! die! (but that's just me ;-)

Name your poison (if any) please.

73 de Jeff



From elanthis at awesomeplay.com  Wed Dec  1 17:19:10 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 01 Dec 2004 12:19:10 -0500
Subject: Elektrified X.org released (was: X configuration paradigm, and
	a proposal)
In-Reply-To: <ed0efd31041201084574fdd591@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
	<20041130185654.GA15322@devserv.devel.redhat.com>
	<ed0efd31041201084574fdd591@mail.gmail.com>
Message-ID: <1101921550.11887.19.camel@support02.civic.twp.ypsilanti.mi.us>

Is the cross posting to four lists *really* necessary for this
discussion?

On Wed, 2004-12-01 at 13:45 -0300, Avi Alkalay wrote:
> On Tue, 30 Nov 2004 13:56:54 -0500, Alan Cox <alan at redhat.com> wrote:
> > On Tue, Nov 30, 2004 at 12:43:16PM -0500, David Zeuthen wrote:
> > > exported through D-BUS), I should be able to write a daemon, let's call
> > > it gnome-input-manager, that runs in the desktop session as user davidz.
> > > This would also allow said daemon to disable the touchpad when I connect
> > > an external mouse or, for more fun, to disable it around intervals where
> > > I'm punching the keys. The reason you want this in the desktop session
> > 
> > You pretty much have to. I've got a hotplug video card here for example.
> > That really ruins the current configuration system. OTOH you have to start
> > somewhere and if the goal is to unify configuration then you want to let
> > someone else rewrite X. However as you and Havoc both point out it has
> > to handle notifiers
> > 
> 
> Good. Elektra has call to get notification. Check the kdbMonitorKey()
> and kdbMonitorKeys() methods in the Doxygen:
> http://elektra.sourceforge.net/elektra-api/html/

>From the docs: "This method will block your program until one of the
folowing happens:"

I'm imaging it works by just re-reading the DB on each iteration.
kdbMonitorKeys has to be a performance monster... Especially if you want
to get notified about a key change in a reasonable period of time.
Let's not even get into the disk seek implications we have here.

This API needs to be efficient and reasonably easy to integrate with
existing applications main loops.

Seriously - suck it up and write a kdbd daemon for this kind of stuff.
There's no good reason not to have one.  For times when the daemon isn't
around (and there's no reason why this should ever be the case, even
during early early bootup, but I have the feeling you'll make that
argument anyhow) you can have the client library access the kdb in read-
only mode and disable features like key notification.

Take a look at how the GConf client interface is structured.  You get a
socket to the configuration server.  If you have a custom main loop, you
can poll/select/epoll/whatever the socket to wait for updates (while in
the meantime blocking on other important file descriptors or running
various timeouts).  When the descriptor has data available, you tell the
library to read as much as it can - if the library gets a complete
notification message, it invokes your callback(s).  This is the absolute
best you can get.  It makes the API *easy* to integrate with Qt, glib,
or any other custom mainloop.



> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From avibrazil at gmail.com  Wed Dec  1 17:33:27 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Wed, 1 Dec 2004 14:33:27 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <1101841021.11035.27.camel@support02.civic.twp.ypsilanti.mi.us>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<20041130144913.GA15676@devserv.devel.redhat.com>
	<ed0efd31041130071879fbf19d@mail.gmail.com>
	<20041130162338.GA10244@devserv.devel.redhat.com>
	<ed0efd3104113008349b0c47@mail.gmail.com>
	<20041130171728.GB10115@devserv.devel.redhat.com>
	<1101841021.11035.27.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <ed0efd3104120109333920bd2f@mail.gmail.com>

On Tue, 30 Nov 2004 13:57:01 -0500, Sean Middleditch
<elanthis at awesomeplay.com> wrote:
> Getting intricate behaviour with shell scripts is also quite possible.
> You would probably need some kind of service daemon.  So you'd write
> something like:
> 
> #!/bin/sh
> 
> # this would print out code to set an  environment variable, so the code
> # gets executed by eval, setting the variable
> eval(kdb begin)
> 
> # set some keys - the command would check for the environment variable
> # defined by the shell service daemon, and communicate with the daemon
> kdb set "key1" "value"
> kdb set "key2" "value"
> 
> # do some other stuff, including checking values of keys, which would
> # also communicate with the daemon if the env-var is set
> if [ `kdb get 'key2'` = 'value' ] ; then
>   do-some-stuff
>   set-some-other-keys
> fi
> 
> # commit/rollback/whatever - again, checks env var, daemon, etc
> kdb commit
> 
> #eof

Instead of doing a lot of 'kdb set', you can generate an XML file with
the keys you want changed, and do 'kdb import keys.xml'. It will be
more atomic, and will use the kdbSetKeys() call which wraps
transaction support.



> The daemon would take some work to get working robustly (i.e., noticing
> when its parent exists without shutting it down, and thus shutting
> itself down cleanly after doing a rollback op, etc.) but its certainly
> possible.
> 
> >
> > > About storage, 1 file per key or 1 file per folder uses almost the
> > > same amount of disk space. Do a 'du -sk' in gconf storage folders to
> > > see that.
> >
> > In a db4 hash overhead seems to be percentage points. In flat file its
> > about 3.5K per key for single key per file. It is implementation detail
> > compared to the fundamental goal.
> 
> The author has this unfortunate tendency to use ReiserFS and other non-
> mainstream file-systems and claim everyone else should too (Linux
> Registry, the previous name for Elektra, was shot down repeatedly due to
> his disregard for real-life systems) so he probably doesn't see any of
> the over-head for small files.

I don't have a tendency to use ReiserFS, but it showed to be more
performatic and less space consuming then any other FS. And I do see
the overhead for small files.
The point is: only discussing ideas is very different that writing
code. In this last case you'll find issues that destroy entire
architectures you built in your head.
A single DB file and a deamon was obviously the first reasonable thing
to think and to implement, so read bellow.



> A db4-baed system certainly has technical advantages in terms of
> efficiency, but stop and think - you're basically now running the
> WIndows Registry.  The Registry's *largest* problem is that it's a
> binary format that easily gets corrupted - a lot like Berkeley DB (hell,
> I wonder if that's what the Windows Registry's code is based off of
> ~_^ )

Yes, this is one problem with BDB. BDB was the first thing used, and
droped in version 0.0.9. See the changelog:
http://www.germane-software.com/repositories/elektra/trunk/ChangeLog

The major problems with BDB or a daemon (that was also the paradigm
for the old old old versions) are:
- It is very difficult to implement hierarchy in a consistent way inside a BDB
- Elektra is system-wide by definition. So with a global daemon,
security has to be handled in the user-space daemon. And security is a
little thing that you may require this: is the best (kernel space) and
you have it, or you simply don't have it.
- Besides, you can't authenticate against a system daemon.
Authentication means to have a user to *type* a password or *read* it
from a file. Think about how authentication works in HTTP sessions,
LDAP, DB servers, etc. I'm open to hear ideas on this point.
- A daemon is a single point of failure.

These were the reasons why daemon and a single file (binary or text)
is accepted only in non-critical, desktopish, single user environment
(read GConf, that really makes its job!). Not systemwide.


> The best format is probably something like XML, or something very XML-
> ish, because it can easily store a hierarchy in a single file, is "safe"
> in terms of value escaping (many custom formats are not), and there are
> tons of libraries to read/write it efficiently.  It isn't *easily*
> edited by hand, but if it's "pretty-printed" it can be easy enough.

Read/write in memory, not on the disk. On the disk you have to rewrite
the entire file, so bye bye transactions.


> > Overall I'm glad to see this work being done. I'm not convinced the format is
> > right but the essential goals of unifying configuration spaces, improving
> > tools and also just going out and doing it are all good things.
> 
> Definitely.  Elektra still has major short comings (no transactional
> guarantees, no notification, no real access control, no temporary
> keys... mostly things Elektra can never do since it refuses to use a
> daemon), but it's at least a tiny step in teh right direction that might
> open some peoples' eyes.

Notifications is there already. Check the code. Transactions needs
some stabilization, yes.
What do you mean with "no real access control"? This is completelly
delegated to the best guy that can do it: the Kernel.
And what do you mean about "temporary keys" ?



> Sean Middleditch <elanthis at awesomeplay.com>
> AwesomePlay Productions, Inc.

Thank you,
Avi



From kyrre at solution-forge.net  Wed Dec  1 16:35:58 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 01 Dec 2004 17:35:58 +0100
Subject: print configuration
In-Reply-To: <1101845309.2798.9.camel@localhost.localdomain>
References: <1101844214.2798.4.camel@localhost.localdomain>
	<1101844175.2684.19.camel@kyrre>
	<1101845309.2798.9.camel@localhost.localdomain>
Message-ID: <1101918958.2675.14.camel@kyrre>

tir, 30.11.2004 kl. 21.08 skrev Trever L. Adams:
> On Tue, 2004-11-30 at 20:49 +0100, Kyrre Ness Sjobak wrote:
> > To share it using cups, make sure your other computers actually could
> > lookup your dns name to your IP.
> > 
> 
> That is done. Do I actually need to set one in the cupsd.conf or does it
> automatically grab one?
> 

the cups server automathically grabs the box'es current hostname.
The clients got to be able to look whatever that is (look in
http://localhost:631 on the client to see) up back to the IP of the box
sharing.

Try to run "host dns-to-server" on client. try to ping it as well (as
the resolver refuses to resolv anything else that fqdn-names.

Funny if the client is not able to look up the server, even funnyer if
the server claim's it has the name "localhost" :) Try it, print
something to it from the client. But have a terminal ready to do a
/etc/init.d/cups stop and then a rm -rf /var/spool/cups/*

;)

> > Also drill a hole for port 631:udp in the client's firewall.
> > 
> 
> Right now, silly, I know, there is no firewall within my network. There
> is one on the route to the outside world. This will probably be
> changing, but it isn't right now.
> 

If you are behind NAT and firewall, you should not need it...

> > To have it shared via samba, i think installing and starting it is
> > enough.
> 
> Hmm, you are correct. I wasn't seeing printers where I looked. Ooops,
> wrong location.
> 
> So the question is, how can I tell if cupsd is allowing the browsing. I
> am watching with Ethereal and I see nothing. In my apps I see nothing.
> 

If cupsd is running, it should be advertising its printers (via udp:631
broadcast) pretty often.

> Also, I noticed that in the printer definitions in cupsd.conf (defs is
> wrong, more like acl) I see that the order is deny,allow and the first
> line is deny all even though a few lines later it says allow everyone.
> Is this accurate?
> 

Hmm... I *know* it is in Norwegian, but the config files are pretty
standard. Had to use some vendor-supplied drivers for a Lexmark
laserprinter....

http://forum.hardware.no/index.php?showtopic=238474&view=findpost&p=2134794

> Trever
> --
> "C++ is to C as Lung Cancer is to Lung." -- A.C. on Slashdot



From camilo at mesias.co.uk  Wed Dec  1 18:00:56 2004
From: camilo at mesias.co.uk (Cam)
Date: Wed, 01 Dec 2004 18:00:56 +0000
Subject: Elektrified X.org released
In-Reply-To: <1101921550.11887.19.camel@support02.civic.twp.ypsilanti.mi.us>
References: <ed0efd310411300525669cd21b@mail.gmail.com>	<1101836596.1676.31.camel@davidz>	<20041130185654.GA15322@devserv.devel.redhat.com>	<ed0efd31041201084574fdd591@mail.gmail.com>
	<1101921550.11887.19.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <41AE06D8.8030909@mesias.co.uk>

Sean

>>From the docs: "This method will block your program until one of the
> folowing happens:"
> 
> I'm imaging it works by just re-reading the DB on each iteration.
> kdbMonitorKeys has to be a performance monster... 

 From looking at the sources, I think it does. But that's not the point. 
And it's a bit harsh to judge the API on it's first implementation.

I think it's useful work to try and port apps to a common config API, so 
long as the API is capable. Elektra seems to be written with the 
assumption that the back end will be reimplemented, so maybe one day it 
will. Until then, poor performance of some less-used parts of the API 
shouldn't be a problem.

-Cam
-- 
camilo at mesias.co.uk                                                 <--



From elanthis at awesomeplay.com  Wed Dec  1 18:12:21 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 01 Dec 2004 13:12:21 -0500
Subject: Elektrified X.org released
In-Reply-To: <41AE06D8.8030909@mesias.co.uk>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101836596.1676.31.camel@davidz>
	<20041130185654.GA15322@devserv.devel.redhat.com>
	<ed0efd31041201084574fdd591@mail.gmail.com>
	<1101921550.11887.19.camel@support02.civic.twp.ypsilanti.mi.us>
	<41AE06D8.8030909@mesias.co.uk>
Message-ID: <1101924742.11887.26.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-01 at 18:00 +0000, Cam wrote:
> Sean
> 
> >>From the docs: "This method will block your program until one of the
> > folowing happens:"
> > 
> > I'm imaging it works by just re-reading the DB on each iteration.
> > kdbMonitorKeys has to be a performance monster... 
> 
>  From looking at the sources, I think it does. But that's not the point. 
> And it's a bit harsh to judge the API on it's first implementation.
> 
> I think it's useful work to try and port apps to a common config API, so 
> long as the API is capable. Elektra seems to be written with the 
> assumption that the back end will be reimplemented, so maybe one day it 
> will. Until then, poor performance of some less-used parts of the API 
> shouldn't be a problem.

Having seen the first few incarnations of Elektra (then "Linux
Registry") and the initial community discussions with the author, I'll
have to disagree.  Applications' needs came second, after the initial
design.  Elektra is several iterations into the design.  The goal needs
to stop being "get all applications to share a config database" and
become "how can we make configuring applications easier and more
consistent."  A shared key-based configuration database is simply a
means to that end, and an implementation choice, not the end goal
itself.  If it is made the end goal then you end up with, well, Elektra.

The API needs to be designed first and then the backend needs to be made
to fit.  Currently, the API is built entirely around the idea of the
flat text key files.  The KeyMonitor API is a perfect example of that
fact.

> 
> -Cam
> -- 
> camilo at mesias.co.uk                                                 <--
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From console at spray.se  Wed Dec  1 18:19:51 2004
From: console at spray.se (Daniel)
Date: Wed, 01 Dec 2004 19:19:51 +0100
Subject: openoffice.org-i18n size
In-Reply-To: <20041128142459.GO11949@viasys.com>
References: <20041128142459.GO11949@viasys.com>
Message-ID: <41AE0B47.30903@spray.se>

One other pretty uncool thing about the openoffice is that the spelling 
dict loads all the languages avail. Right clicking to get a spelling 
suggestion ends up with memory exhausted. This is on a 512MB machine. 
But cleaning the dict-file fixes the problem, but I don't think thats an 
appropriate solution.

/Daniel

Ville Herva wrote:

>>rpm -qi openoffice.org-i18n
>>    
>>
>Name        : openoffice.org-i18n          Relocations: (not relocatable)
>Version     : 1.1.2                             Vendor: Red Hat, Inc.
>Release     : 12.7                          Build Date: Tue Nov 23 23:38:11
>2004
>Install Date: Sat Nov 27 10:46:07 2004      Build Host:
>tweety.build.redhat.com
>Group       : Applications/Productivity     Source RPM:
>openoffice.org-1.1.2-12.7.src.rpm
>Size        : 645925614                        License: LGPL
>              ^^^^^^^^^
>
>Would it make sense to split openoffice.org-i18n up somewhat? For example,
>I'm only interested in Finnish and not about Africaans, Catalan, Arabian and
>what not. 650MB is pretty much for stuff that is not needed at all; it's a
>huge download (although it compresses well), but also takes up disk space
>quite much.
>
>Or is it just infeasible idea to split it in smaller parts?
>
>BTW: Anyone tried openoffice 2.0 beta yet? I don't suppose there are fedora
>rawhide compatible rpm's for it somewhere?
>
>
>-- v --
>
>v at iki.fi
>
>  
>



From florin at andrei.myip.org  Wed Dec  1 19:17:48 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 01 Dec 2004 11:17:48 -0800
Subject: Configuring NFS under Linux for Firewall control
Message-ID: <1101928668.31463.17.camel@stantz.corp.sgi.com>

Please have a look at this document:

http://www.lowth.com/LinWiz/nfs_help.html

It describes a method to configure the components of a Linux-based NFS
server so that NFS access can be controlled via a simple firewall that
does not "understand" NFS.
As an engineer using various firewall platforms, i often saw the need
for a similar solution, in situations when the firewalls being used
could not control complex protocols such as NFS. Sometimes the firewall
helps you and gives you a way to manage such protocols, some other times
it doesn't.

The document seems to be geared towards older Red Hat versions, but
perhaps it is still actual for recent Fedora distributions.
The techniques described require editing scripts in /etc/init.d and so
on. That it typically considered something to avoid in production
environments.

I think it would be great to add "hooks" to the init.d scripts (or
something like that) so that such a change can be made in a cleaner
fashion. Say, add stuff in /etc/sysconfig for the sysadmin to modify in
order to achieve the same effect.
For example, add some variables, containing the port numbers for the
various portmap/nfs components, in a file in /etc/sysconfig:

STATD_PORT="4000"
LOCKD_PORT="4001"
MOUNTD_PORT="4002"
RQUOTAD_PORT="4003"
# set this to 1 to enforce using the unique NFS ports
FORCE_NFS_UNIQUE_PORTS="0"

Or something along these lines - it does not have to be
in /etc/sysconfig. Any mechanism that will allow the sysadmin to "flip a
switch" and make NFS play well with firewalls would be great.

Thank you,

-- 
Florin Andrei

http://florin.myip.org/



From roland at redhat.com  Wed Dec  1 19:27:02 2004
From: roland at redhat.com (Roland McGrath)
Date: Wed, 1 Dec 2004 11:27:02 -0800
Subject: http://fedora.redhat.com/participate/schedule/
Message-ID: <200412011927.iB1JR23w004561@magilla.sf.frob.com>

This page now contains only past dates.  How will we know what to do next?



From tibbs at math.uh.edu  Wed Dec  1 19:31:11 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Wed, 01 Dec 2004 13:31:11 -0600
Subject: Configuring NFS under Linux for Firewall control
In-Reply-To: <1101928668.31463.17.camel@stantz.corp.sgi.com> (Florin
	Andrei's message of "Wed, 01 Dec 2004 11:17:48 -0800")
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
Message-ID: <ufaoehd3jeo.fsf@epithumia.math.uh.edu>

>>>>> "FA" == Florin Andrei <florin at andrei.myip.org> writes:

FA> For example, add
FA> some variables, containing the port numbers for the various
FA> portmap/nfs components, in a file in /etc/sysconfig:

/etc/sysconfig/nfs is checked.  You can things like:

RPCNFSDCOUNT
MOUNTD_PORT
STATD_PORT
STATD_OUTGOING_PORT

You have to set the NLM ports in modprobe.conf or on the kernel
command line.

 - J<



From walters at redhat.com  Wed Dec  1 19:37:30 2004
From: walters at redhat.com (Colin Walters)
Date: Wed, 01 Dec 2004 14:37:30 -0500
Subject: http://fedora.redhat.com/participate/schedule/
In-Reply-To: <200412011927.iB1JR23w004561@magilla.sf.frob.com>
References: <200412011927.iB1JR23w004561@magilla.sf.frob.com>
Message-ID: <1101929850.19971.2.camel@nexus.verbum.private>

On Wed, 2004-12-01 at 11:27 -0800, Roland McGrath wrote:
> This page now contains only past dates.  How will we know what to do next?

Unit #4579, you are malfunctioning.  Until given direction by the Fedora
Collective, you must return to State 0: drool at desk.



From kyrre at solution-forge.net  Wed Dec  1 20:09:14 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 01 Dec 2004 21:09:14 +0100
Subject: openoffice.org-i18n size
In-Reply-To: <41AE0B47.30903@spray.se>
References: <20041128142459.GO11949@viasys.com>  <41AE0B47.30903@spray.se>
Message-ID: <1101931754.2675.196.camel@kyrre>

ons, 01.12.2004 kl. 19.19 skrev Daniel:
> One other pretty uncool thing about the openoffice is that the spelling 
> dict loads all the languages avail. Right clicking to get a spelling 
> suggestion ends up with memory exhausted. This is on a 512MB machine. 
> But cleaning the dict-file fixes the problem, but I don't think thats an 
> appropriate solution.
> 
> /Daniel

Then you imagine a 128 MB machine...



From florin at andrei.myip.org  Wed Dec  1 20:13:24 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 01 Dec 2004 12:13:24 -0800
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <ufaoehd3jeo.fsf@epithumia.math.uh.edu>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
Message-ID: <1101932004.31463.48.camel@stantz.corp.sgi.com>

On Wed, 2004-12-01 at 13:31 -0600, Jason L Tibbitts III wrote:
> >>>>> "FA" == Florin Andrei <florin at andrei.myip.org> writes:
> 
> FA> For example, add
> FA> some variables, containing the port numbers for the various
> FA> portmap/nfs components, in a file in /etc/sysconfig:
> 
> /etc/sysconfig/nfs is checked.  You can things like:
> 
> RPCNFSDCOUNT
> MOUNTD_PORT
> STATD_PORT
> STATD_OUTGOING_PORT
> 
> You have to set the NLM ports in modprobe.conf or on the kernel
> command line.

D'oh! :-(

Ok, so then here's my not-so-pet peeve:
There are all kinds of clever and remarkable things that the rc.d system
is performing, but they are useless if a sysadmin cannot figure them out
without either reading up acres of large shell scripts in /etc or
chancing upon a bit of documentation that has the relevant info (not
that i've seen anything in the docs related to the issue i was
describing).

I already noticed that there are all kinds of arcane config bits in
places such as /etc/sysconfig/network-scripts/ifcfg-eth* that can be
very handy, but there's no way to unearth them other than printing out
all essential system scripts in /etc and reading them line by line.
Honestly, i hate to do that. Not because i'm lazy, but because i'm busy.
I assume i'm not the only one in this situation.

If /etc/sysconfig/nfs is checked by a system script, then please by all
means _create_ that file, add some generic content (put in all variables
that _could_ be present in that file, but comment out those that are not
typically used) and include it in a Fedora Core package.

Same for ifcfg-eth* - now i know that ESSID is a valid variable and i
know how to use it, but only after stumbling upon it by chance, when
reading some system scripts in /etc.

I would say, whenever a config file in /etc/sysconfig (or wherever)
_might_ contain a variable, then it _should_ contain it. Comment it out
if it's not used. Add an explanation above. Comments are good - like
chicken soup for the sysadmin's brain. Look at /etc/syslog.conf - ain't
that thing pretty?

I was initially a Slackware user and migrated later to Red Hat and
fought all those SysV-style versus BSD-style wars. I still think the
SysV style is better, but i ended up being wary of the Fedora /etc
directory, precisely because of the massive obfuscation i'm describing.
Sure, you guys at Red Hat must know /etc by heart, but how about us poor
mortals?

Please, not everyone is doing 100% of their homework beforehand -
indeed, it's impossible to do so in the real world. Many people learn
the system on the fly. Give them a helping hand.

Thanks!

Now i'm going back to fight looming deadlines. Sorry for rambling, i
still think y'all are cool. :-)

-- 
Florin Andrei

http://florin.myip.org/



From dhollis at davehollis.com  Wed Dec  1 21:10:38 2004
From: dhollis at davehollis.com (David Hollis)
Date: Wed, 01 Dec 2004 16:10:38 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101932004.31463.48.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
Message-ID: <1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>

On Wed, 2004-12-01 at 12:13 -0800, Florin Andrei wrote:

> Ok, so then here's my not-so-pet peeve:
> There are all kinds of clever and remarkable things that the rc.d system
> is performing, but they are useless if a sysadmin cannot figure them out
> without either reading up acres of large shell scripts in /etc or
> chancing upon a bit of documentation that has the relevant info (not
> that i've seen anything in the docs related to the issue i was
> describing).
> 
> I already noticed that there are all kinds of arcane config bits in
> places such as /etc/sysconfig/network-scripts/ifcfg-eth* that can be
> very handy, but there's no way to unearth them other than printing out
> all essential system scripts in /etc and reading them line by line.
> Honestly, i hate to do that. Not because i'm lazy, but because i'm busy.
> I assume i'm not the only one in this situation.

Try checking out the files in /usr/share/doc/initscripts-*.

Particularly, sysconfig.txt.  


-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041201/8ba165ad/attachment.sig>

From hhoffman at ip-solutions.net  Wed Dec  1 21:16:20 2004
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Wed, 01 Dec 2004 16:16:20 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
 Firewall control]
In-Reply-To: <1101932004.31463.48.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
Message-ID: <41AE34A4.3080802@ip-solutions.net>

how about /usr/share/doc/initscripts/* ?

Florin Andrei wrote:
> 
> D'oh! :-(
> 
> Ok, so then here's my not-so-pet peeve:
> There are all kinds of clever and remarkable things that the rc.d system
> is performing, but they are useless if a sysadmin cannot figure them out
> without either reading up acres of large shell scripts in /etc or
> chancing upon a bit of documentation that has the relevant info (not
> that i've seen anything in the docs related to the issue i was
> describing).
> Thanks!
[snip]



From paul at frields.com  Wed Dec  1 21:22:08 2004
From: paul at frields.com (Paul W. Frields)
Date: Wed, 01 Dec 2004 16:22:08 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101932004.31463.48.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
Message-ID: <1101936128.14817.8.camel@berlin.east.gov>

On Wed, 2004-12-01 at 12:13 -0800, Florin Andrei wrote:
> Ok, so then here's my not-so-pet peeve:
> There are all kinds of clever and remarkable things that the rc.d system
> is performing, but they are useless if a sysadmin cannot figure them out
> without either reading up acres of large shell scripts in /etc or
> chancing upon a bit of documentation that has the relevant info (not
> that i've seen anything in the docs related to the issue i was
> describing).
[...snip...]

A lot does appear in /usr/share/doc/initscripts-*/sysconfig.txt, but...

> If /etc/sysconfig/nfs is checked by a system script, then please by all
> means _create_ that file, add some generic content (put in all variables
> that _could_ be present in that file, but comment out those that are not
> typically used) and include it in a Fedora Core package.
> 
> Same for ifcfg-eth* - now i know that ESSID is a valid variable and i
> know how to use it, but only after stumbling upon it by chance, when
> reading some system scripts in /etc.
> 
> I would say, whenever a config file in /etc/sysconfig (or wherever)
> _might_ contain a variable, then it _should_ contain it. Comment it out
> if it's not used. Add an explanation above. Comments are good - like
> chicken soup for the sysadmin's brain. Look at /etc/syslog.conf - ain't
> that thing pretty?
[...snip...]

...this is a great idea regardless. Cf. also /etc/samba/smb.conf, I
believe. Start the ball rolling by reading the /etc/rc.d/init.d/???
script, parsing it for variable names, and reading the code to comment
it. Generate an example and Bugzilla the result. 

Perhaps a good idea would be a tracking bug for this issue and then a
bug for each file. Here's what I drew up for NFS, but I will gladly
suffer accusations of carelessness if something here is stupid:

# -------------
# Sysconfig default file for nfs
#
# All variable names appear next to their assigned defaults.
# To change the default, uncomment the line and change the value.

# NFS version 2 will be used unless MOUNTD_NFS_V2 is set to 'no'
# MOUNTD_NFS_V2=default

# NFS version 3 will be used unless MOUNTD_NFS_V3 is set to 'no'
# MOUNTD_NFS_V3=default

# Number of nfsd servers to launch
# RPCNFSDCOUNT=8

# Location of rpc.rquotad, or set to 'no' to disable
# RQUOTAD=`type -path rpc.rquotad`

# Extra options, other than the above
# RPCRQUOTAOPTS=

# Default is to use portmap
# LOCKD_TCPPORT=
# LOCKD_UDPPORT=
# RQUOTAD_PORT=
# MOUNTD_PORT=
# -------------------

I haven't BZ'd this since I wasn't sure if anyone agreed with my
suggestion, but will do so if I can get a second on the motion.

-- 
Paul W. Frields, RHCE



From florin at andrei.myip.org  Wed Dec  1 21:54:49 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 01 Dec 2004 13:54:49 -0800
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <1101938089.31463.64.camel@stantz.corp.sgi.com>

On Wed, 2004-12-01 at 16:10 -0500, David Hollis wrote:
> On Wed, 2004-12-01 at 12:13 -0800, Florin Andrei wrote:

> > I already noticed that there are all kinds of arcane config bits in
> > places such as /etc/sysconfig/network-scripts/ifcfg-eth* that can be
> > very handy, but there's no way to unearth them other than printing out
> > all essential system scripts in /etc and reading them line by line.
> > Honestly, i hate to do that. Not because i'm lazy, but because i'm busy.
> > I assume i'm not the only one in this situation.
> 
> Try checking out the files in /usr/share/doc/initscripts-*.
> 
> Particularly, sysconfig.txt.  

Cool, that's really useful, but it does not seem to be complete. E.g.,
where are the NFS-related bits? (my original request)

It still seems that self-documented files are a better idea, at least
from the sysadmin's perspective.

-- 
Florin Andrei

http://florin.myip.org/



From florin at andrei.myip.org  Wed Dec  1 22:02:54 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 01 Dec 2004 14:02:54 -0800
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101936128.14817.8.camel@berlin.east.gov>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
Message-ID: <1101938575.31463.67.camel@stantz.corp.sgi.com>

On Wed, 2004-12-01 at 16:22 -0500, Paul W. Frields wrote:

> # -------------
> # Sysconfig default file for nfs
> #
> # All variable names appear next to their assigned defaults.
> # To change the default, uncomment the line and change the value.
> 
> # NFS version 2 will be used unless MOUNTD_NFS_V2 is set to 'no'
> # MOUNTD_NFS_V2=default
> 
> # NFS version 3 will be used unless MOUNTD_NFS_V3 is set to 'no'
> # MOUNTD_NFS_V3=default
> 
> # Number of nfsd servers to launch
> # RPCNFSDCOUNT=8
> 
> # Location of rpc.rquotad, or set to 'no' to disable
> # RQUOTAD=`type -path rpc.rquotad`
> 
> # Extra options, other than the above
> # RPCRQUOTAOPTS=
> 
> # Default is to use portmap
> # LOCKD_TCPPORT=
> # LOCKD_UDPPORT=
> # RQUOTAD_PORT=
> # MOUNTD_PORT=
> # -------------------
> 
> I haven't BZ'd this since I wasn't sure if anyone agreed with my
> suggestion, but will do so if I can get a second on the motion.

I'm not sure about the details either, but overall this is what i was
talking about.
Perhaps don't leave the *PORT variables empty, but add sensible values?

-- 
Florin Andrei

http://florin.myip.org/



From notting at redhat.com  Wed Dec  1 23:19:53 2004
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 1 Dec 2004 18:19:53 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101938089.31463.64.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>
	<1101938089.31463.64.camel@stantz.corp.sgi.com>
Message-ID: <20041201231952.GA6168@nostromo.devel.redhat.com>

Florin Andrei (florin at andrei.myip.org) said: 
> Cool, that's really useful, but it does not seem to be complete. E.g.,
> where are the NFS-related bits? (my original request)
> 
> It still seems that self-documented files are a better idea, at least
> from the sysadmin's perspective.

Generally, it only contains stuff for parameters used by things
in the initscripts package. At least, that's the only way it
really can be without maintainers for other packages adding their
own changes. :)

Bill



From florin at andrei.myip.org  Wed Dec  1 23:23:12 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 01 Dec 2004 15:23:12 -0800
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <20041201231952.GA6168@nostromo.devel.redhat.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>
	<1101938089.31463.64.camel@stantz.corp.sgi.com>
	<20041201231952.GA6168@nostromo.devel.redhat.com>
Message-ID: <1101943392.31463.69.camel@stantz.corp.sgi.com>

On Wed, 2004-12-01 at 18:19 -0500, Bill Nottingham wrote:
> Florin Andrei (florin at andrei.myip.org) said: 
> > Cool, that's really useful, but it does not seem to be complete. E.g.,
> > where are the NFS-related bits? (my original request)
> > 
> > It still seems that self-documented files are a better idea, at least
> > from the sysadmin's perspective.
> 
> Generally, it only contains stuff for parameters used by things
> in the initscripts package. At least, that's the only way it
> really can be without maintainers for other packages adding their
> own changes. :)

Yup, makes sense, that's why i mentioned the self-documented files.

-- 
Florin Andrei

http://florin.myip.org/



From paul at frields.com  Wed Dec  1 22:42:50 2004
From: paul at frields.com (Paul W. Frields)
Date: Wed, 01 Dec 2004 17:42:50 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101938575.31463.67.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
Message-ID: <1101940970.7811.2.camel@berlin.east.gov>

On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
[...snip...]
> > # Default is to use portmap
> > # LOCKD_TCPPORT=
> > # LOCKD_UDPPORT=
> > # RQUOTAD_PORT=
> > # MOUNTD_PORT=
> > # -------------------
> > 
> > I haven't BZ'd this since I wasn't sure if anyone agreed with my
> > suggestion, but will do so if I can get a second on the motion.
> 
> I'm not sure about the details either, but overall this is what i was
> talking about.
> Perhaps don't leave the *PORT variables empty, but add sensible values?

Sensible values will be widely variant from one location to the next. A
"sensible value" is one that gets through *your* firewall. What's there
should be good enough for even the laziest admin, IMHO, and yes, I
resemble that remark too. :-)

-- 
Paul W. Frields, RHCE



From shiva at sewingwitch.com  Wed Dec  1 22:34:07 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 01 Dec 2004 14:34:07 -0800
Subject: Elektrified X.org released (was: X configuration paradigm, and
 a proposal)
In-Reply-To: <ed0efd31041201084170ecdacc@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101837905.2684.4.camel@kyrre>
	<1101838973.6103.103.camel@localhost.localdomain>
	<ed0efd31041201084170ecdacc@mail.gmail.com>
Message-ID: <DF80FEC365A6AC8A22BBD597@[10.0.0.4]>

--On Wednesday, December 01, 2004 1:41 PM -0300 Avi Alkalay 
<avibrazil at gmail.com> wrote:

> How many times per year you edit modern windows registry by hand?

Quite a lot. The ability to grep the registry would be really nice, but no 
built-in tool offers that. One has to buy commercial add-ons for that. 
Backing up the whole registry is also a PITA.

But I don't think Elektra suffers these problems. As long as it's all text 
files and state isn't held in memory, unavailable to backup programs, I'm 
fine with it.



From cra at WPI.EDU  Thu Dec  2 00:25:49 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 1 Dec 2004 19:25:49 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101940970.7811.2.camel@berlin.east.gov>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
	<1101940970.7811.2.camel@berlin.east.gov>
Message-ID: <20041202002549.GS27024@angus.ind.WPI.EDU>

On Wed, Dec 01, 2004 at 05:42:50PM -0500, Paul W. Frields wrote:
> On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> > Perhaps don't leave the *PORT variables empty, but add sensible values?
> 
> Sensible values will be widely variant from one location to the next. A
> "sensible value" is one that gets through *your* firewall. What's there
> should be good enough for even the laziest admin, IMHO, and yes, I
> resemble that remark too. :-)

There are "standard" port numbers for some of these:

MOUNTD_PORT=635
NFSD_PORT=2049



From toshio at tiki-lounge.com  Thu Dec  2 02:50:26 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Wed, 01 Dec 2004 21:50:26 -0500
Subject: i486 base architecture
In-Reply-To: <1101919690.2675.19.camel@kyrre>
References: <codhib$pg2$1@sea.gmane.org>
	<Pine.LNX.4.58.0411281657220.19060@devserv.devel.redhat.com>
	<codki5$ls0$3@sea.gmane.org>	<604aa7910411281454a3a118a@mail.gmail.com>
	<20041128234650.GA13367@ee.oulu.fi> <codrhv$4fd$1@sea.gmane.org>
	<1101715873.2814.33.camel@laptop.fenrus.org>	<coh476$rhb$2@sea.gmane.org>
	<1101799715.2640.19.camel@laptop.fenrus.org>	<coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org> <1101919690.2675.19.camel@kyrre>
Message-ID: <1101955827.7436.75.camel@Madison.badger.com>

On Wed, 2004-12-01 at 17:48 +0100, Kyrre Ness Sjobak wrote:
> ons, 01.12.2004 kl. 03.56 skrev William M. Quarles:
> > What differences between i386 and i486 would become a benefit if the 
> > base architecture was changed from i386 to i486?
> 
> Or to i586? Who are running newish fedora/redhat things on anything
> older than a pentium 1 anyway?
> 
> Sorry if am sounding stupid... But really...

There were several long threads on this in May and June of this year.
Perhaps the entry point most relevant to your question is here:
http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00011.html

Read the whole discussion so you know which pieces information were
factual and which were later corrected.

-Toshio
-- 
Toshio <toshio at tiki-lounge.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041201/1c9b758e/attachment.sig>

From toshio at tiki-lounge.com  Thu Dec  2 02:43:24 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Wed, 01 Dec 2004 21:43:24 -0500
Subject: Elektrified X.org released (was: X configuration paradigm, and
	a proposal)
In-Reply-To: <ed0efd3104120109333920bd2f@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<20041130144913.GA15676@devserv.devel.redhat.com>
	<ed0efd31041130071879fbf19d@mail.gmail.com>
	<20041130162338.GA10244@devserv.devel.redhat.com>
	<ed0efd3104113008349b0c47@mail.gmail.com>
	<20041130171728.GB10115@devserv.devel.redhat.com>
	<1101841021.11035.27.camel@support02.civic.twp.ypsilanti.mi.us>
	<ed0efd3104120109333920bd2f@mail.gmail.com>
Message-ID: <1101955405.7436.69.camel@Madison.badger.com>

On Wed, 2004-12-01 at 14:33 -0300, Avi Alkalay wrote:
> > Definitely.  Elektra still has major short comings (no transactional
> > guarantees, no notification, no real access control, no temporary
> > keys... mostly things Elektra can never do since it refuses to use a
> > daemon), but it's at least a tiny step in teh right direction that might
> > open some peoples' eyes.
> 
> Notifications is there already. Check the code. 

Avi, correct me if I'm misinterpretting, but the API docs seem to say
that Elektra has "monitoring" rather than true notification.
Notification as it exists in GConf is event driven (which is easy for a
programmer to use) and reasonably performant.  The monitoring of keys
that Elektra's API implements places a much higher burden on the
programmer and seems like it would consume more system resources
(scanning for changes instead of being notified when a change occurs.)

If the goal of Elektra truly is every program should use it to config,
then this is going to need some rethinking because few programmers who
need notification  (at minimum, desktop apps) will choose the extra work
involved in Elektra over GConf.  If Elektra is only aiming at the
current system services which don't change state dynamically (The app
"resyncs" with its config via restart or reload of all config info
rather than changing on the fly as each key is modified.)  then it might
not need true notification... although I think there are system services
could benefit from notification; it's just that the capablitity to do it
isn't attractive with the current /etc files scheme.

-Toshio
-- 
Toshio <toshio at tiki-lounge.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041201/bd7c1111/attachment.sig>

From nmiell at comcast.net  Thu Dec  2 03:37:46 2004
From: nmiell at comcast.net (Nicholas Miell)
Date: Wed, 01 Dec 2004 19:37:46 -0800
Subject: i486 base architecture
In-Reply-To: <41ADFA36.4060703@nc.rr.com>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
Message-ID: <1101958666.3585.2.camel@localhost.localdomain>

On Wed, 2004-12-01 at 12:07 -0500, Jeff Johnson wrote:
> OK, to summarize:
> 
>     a) There's a whole lot of pain and not much gain messing with 
> package file names (and file paths and scripts and ... )
>     b) The dependency
>             Requires: cpu(cmov)
>          (or equivalent token) might (*will* imho) be useful identifying 
> packages that actually use, say, cmov.
>         (Note: there's more than cmov that needs marking, generalizing 
> the cpu(...) name space is quite straightforward.)
>     c) Users want a clear call on what package file name to install, as 
> some *.i386.rpm will not run on arch i386, very confusing.
>     d) linuxthreads needs to die! die! die! (but that's just me ;-)
> 
> Name your poison (if any) please.

What's going to Provide: cpu(cmov)?
-- 
Nicholas Miell <nmiell at comcast.net>



From n3npq at nc.rr.com  Thu Dec  2 04:10:04 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Wed, 01 Dec 2004 23:10:04 -0500
Subject: i486 base architecture
In-Reply-To: <1101958666.3585.2.camel@localhost.localdomain>
References: <coi99b$fpm$1@sea.gmane.org>
	<1101835626.2640.65.camel@laptop.fenrus.org>
	<cojbso$fce$1@sea.gmane.org>
	<20041201030026.GA26613@devserv.devel.redhat.com>
	<cojfvm$nid$1@sea.gmane.org>
	<20041201131236.GA6851@devserv.devel.redhat.com>
	<1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
Message-ID: <41AE959C.7050903@nc.rr.com>

Nicholas Miell wrote:

>On Wed, 2004-12-01 at 12:07 -0500, Jeff Johnson wrote:
>  
>
>>OK, to summarize:
>>
>>    a) There's a whole lot of pain and not much gain messing with 
>>package file names (and file paths and scripts and ... )
>>    b) The dependency
>>            Requires: cpu(cmov)
>>         (or equivalent token) might (*will* imho) be useful identifying 
>>packages that actually use, say, cmov.
>>        (Note: there's more than cmov that needs marking, generalizing 
>>the cpu(...) name space is quite straightforward.)
>>    c) Users want a clear call on what package file name to install, as 
>>some *.i386.rpm will not run on arch i386, very confusing.
>>    d) linuxthreads needs to die! die! die! (but that's just me ;-)
>>
>>Name your poison (if any) please.
>>    
>>
>
>What's going to Provide: cpu(cmov)?
>  
>

Can be done by simple string in per-arch kernel package right now, although
that doesn't really solve the problem adequately, as dependencies in 
packages
are static content. But even a static dependency would be as good as, say
    Provides: kernel-abi = 2.6

Prolly the strongest mechanism is to attach a run-time probe dependency 
to the "cpu(...)"
name space and parse /proc/cpuinfo for the relevant info. That mostly 
works, but
will have problems in chroot's w/o /proc mounted, and will be kinda 
weird if/when, say,
the mobo or disk is moved amongst machines, to mention just 2 possible 
problems off
the top of my head.

I suspect those deficiencies can be lived with, and are no worse than 
existing arch based tests.

It's not like a missing dependency is gonna explode somebody's monitor 
or anything
really seriously deadly or risky ... NPTL was far far riskier than what 
I am humbly proposing ;-)

73 de Jeff



From pp at ee.oulu.fi  Thu Dec  2 09:17:30 2004
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Thu, 2 Dec 2004 11:17:30 +0200
Subject: i486 base architecture
In-Reply-To: <41AE959C.7050903@nc.rr.com>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com>
Message-ID: <20041202091730.GA5806@ee.oulu.fi>

On Wed, Dec 01, 2004 at 11:10:04PM -0500, Jeff Johnson wrote:
> Prolly the strongest mechanism is to attach a run-time probe dependency to
> the "cpu(...)" name space and parse /proc/cpuinfo for the relevant info.
> That mostly works, but will have problems in chroot's w/o /proc mounted,
> and will be kinda weird if/when, say, the mobo or disk is moved amongst
> machines, to mention just 2 possible problems off the top of my head.
> 
> I suspect those deficiencies can be lived with, and are no worse than 
> existing arch based tests.
Would there be any compilications if the thing was generalized and
you could do Requires-Return-Code: /usr/lib/rpm/check-x86-cpu-flags cmov
(or whatever the syntax would be, basic idea is that there's some
external thing that exits with 0 or 1). 

In any case, such a thing should be easy to override, even when
using a frontend like yum.

-- 
Pekka Pietikainen



From mpeters at mac.com  Thu Dec  2 09:35:25 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Thu, 02 Dec 2004 09:35:25 +0000
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101938089.31463.64.camel@stantz.corp.sgi.com> (from
	florin@andrei.myip.org on Wed Dec  1 13:54:49 2004)
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101935438.3712.40.camel@dhollis-lnx.centricconsulting.com>
	<1101938089.31463.64.camel@stantz.corp.sgi.com>
Message-ID: <1101980125l.2118l.0l@devel.mpeters.us>

On 12/01/2004 01:54:49 PM, Florin Andrei wrote:

> 
> It still seems that self-documented files are a better idea, at least
> from the sysadmin's perspective.

Or at least a man 5 page for the file (I'm of the view that  
documentation does not belong in the file, comments in file should be  
written by sysadmins or to indicate new sections)




From j.w.r.degoede at hhs.nl  Thu Dec  2 10:10:57 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 02 Dec 2004 11:10:57 +0100
Subject: OT: automating gui apps
Message-ID: <41AEEA31.3080602@hhs.nl>

Hi,

Sorry for posting OT, but I'm hoping that with the acumulated wisdom on 
this list someone can help me.

I've got this propietary motif application which uses a propietary 
database from which I want to export some data. I can export this data 
from the motif gui by selecting the right item from the menu, entering a 
filename, etc.

So my question is is there aay way to record mouse movements and 
mousebutton/key presses under X and replay those automaticly, the replay 
preferrably under Xvfb?

Thanks,

Hans



From nphilipp at redhat.com  Thu Dec  2 12:24:17 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 02 Dec 2004 13:24:17 +0100
Subject: [Fwd: Kudos, Congratulation and Many Thanks]
Message-ID: <1101990257.12076.10.camel@wombat.tiptoe.de>

Hi everybody,

I got a very encouraging mail praising Fedora and I'd like to share it
with you because I think the praise belongs to all the developers,
testers and other contributors, not just to those who can't keep their
mouths shut like me ;-).

Nils

-------- Forwarded Message --------
1 December 2004

Mr. Nils Phillippsen

Red Hat.com

Dear Mr. Phillippsen:

I apologize for making you the victim of this message, but you seem to
be relatively high profile in the Red Hat Linux development community.

I believe that many thank yous, plaudits and congratulations are due
your team. Fedora Core simply keeps improving and improving.

I am a relative neophyte to Linux. I came in through the back door, if
you will. A friend of mine is in the hospitality business and the
franchisor imposed upon the franchisees a DOS software system written in
1986 and running in Caldera Linux. The problem is that the franchisees
had no control over any program matters and the franchisor was
constantly downloading private information and selling this to any
buyer. The information included credit card information and cases of
fraud arose.

I asked my friend to send me a complete image of his fixed disk. While
awaiting the arrival of this, I purchased the Red Hat Linux Bible, which
came with Fedora Core 1. This was my introduction to Linux.

I loaded the image on one fixed disk and Fedora on another. I was able
to, ?look-in,? on the Caldera system to obtain the information I needed.
I was able to change the root password on the Caldera system and lock
the franchisor out of my friend's system. The, because of the fraudulent
activities, I was able to supply system logs, find dead end dialing
numbers for the purpose of elevating toll charges and remove the auto-
dialer.

After this experience, I upgraded to Linux. I have five computers, plus
one business computer. These I networked, some on wireless (11.02g) and
some by cable with T1 access. I knew Windows had problems, but it was
not until I became familiar with the never-ending features of Linux,
that I realized the extent of Windows shortcomings (I am being nice). I
had converted to Mozilla as soon as it was available for Windows, so I
eliminated the problems of IE6. The most amazing Linus surprise was in
the transfer of files. My business program is in DOS. To transfer 700
files via the Windows network, takes 14 minutes. Linux transfers the
same data in less than a minute. So, I run both SAMBA and NFS.

The GIMP is every bit the equal of Photoshop and Corel PhotoPaint, both
of which I have. OpenOffice is a great word processor. The only program
I miss from Windows is MAGIX Samplitude and Audio Studio. These have
superb sound manipulation and equalizers. I am not aware of any such
equalizers available for Linux.

I have three HP Photosmart printers which I hope to send aboard the next
NASA deep space exploration vehicle. I hope aliens do not find these
printers. They will think we are not as advance a society as they may
have presumed. Linux and CUPS actually make the HP printers function in
an acceptable manner, so I am considering a reprieve for the HP's,
thanks to Linux.

I will not bore you with other details. I merely thank you again for the
fine work you and your team is doing with FC 2 And FC 3, both of which I
use. The only issue is with ?eggcups.? 

Sincerely,

John MacEwan

-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From buildsys at redhat.com  Thu Dec  2 12:54:47 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 2 Dec 2004 07:54:47 -0500
Subject: rawhide report: 20041202 changes
Message-ID: <200412021254.iB2CslM11341@porkchop.devel.redhat.com>

New package dcraw
	A tool for decoding raw image data from digital cameras.

New package ufraw
	A GIMP plugin to retreive raw image data from digital cameras.


 
Updated Packages:

bluez-utils-2.10-3
------------------
* Wed Dec 01 2004 Phil Knirsch <pknirsch at redhat.com> 2.10-3
- Minor dependancy fix (missing initscripts for post stuff)
- Switch Copyright to License

boost-1.32.0-2
--------------
* Wed Dec 01 2004 Benjamin Kosnik <bkoz at redhat.com> 1.32.0-2
- Remove bogus Obsoletes.

cscope-15.5-9
-------------
* Tue Nov 30 2004 Neil Horman <nhorman at redhat.com>
- added tempsec patch to fix bz140764/140765

* Mon Nov 29 2004 Neil Horman <nhorman at redhat.com>
- updated cscope resize patch to do less work in
  signal handler and synced version nr. on dist.

* Mon Nov 22 2004 Neil Horman <nhorman at redhat.com>
- added cscope-1.5.-resize patch to allow terminal
  resizing while cscope is running

eject-2.0.13-13
---------------
* Wed Dec 01 2004 Than Ngo <than at redhat.com> 2.0.13-13
- add patch to remove deprecated SCSI ioctl

emacspeak-21.0-1
----------------
* Thu Dec 02 2004 Jens Petersen <petersen at redhat.com> - 21.0-1
- update to latest version

evolution-2.0.2-6
-----------------
* Wed Dec 01 2004 David Malcolm <dmalcolm at redhat.com> - 2.0.2-6
- Fix broken properties dialog for "Unmatched" vfolder (#141458)

* Wed Oct 27 2004 Christopher Aillon <caillon at redhat.com> - 2.0.2-4
- Re-enable s390(x)

* Fri Oct 22 2004 David Malcolm <dmalcolm at redhat.com> - 2.0.2-3
- added requirement on gnutls/gnutls-devel

expat-1.95.8-4
--------------
* Thu Nov 25 2004 Ivana Varekova <varekova at redhat.com> 1.95.8
- update to 1.95.8

gdm-1:2.6.0.5-9
---------------
* Wed Dec 01 2004 Ray Strode  <rstrode at redhat.com> 1:2.6.0.5-9 
- Look up and use username instead of assuming that user entered 
  login is cannonical.  Patch from
  Mike Patnode <mike.patnode at centrify.com> (fixes bug 141380).

gtksourceview-1.1.0-4.fc3
-------------------------
* Wed Dec 01 2004 Matthias Clasen <mclasen at redhat.com> - 1.1.0-4.fc3
- Rebuild (#151450)

im-sdk-1:12.1-10
----------------
* Wed Dec 01 2004 Akira TAGOH <tagoh at redhat.com> - 1:12.1-10
- iiimsf-fix-auth-with-unixdomain-r2088-141468.patch: applied to fix
  the denied access issue. (#141468)

* Tue Nov 30 2004 Jens Petersen <petersen at redhat.com>
- add leif-unit-latin-fixes-r2060.patch to help fix deadkeys in European layout
  of unitle (130851)

* Tue Nov 30 2004 Akira TAGOH <tagoh at redhat.com>
- iiimp-fix-missing-prototype-r2084-140818.patch: fixed not activating on ia64
  due to the lacking of some prototype declaration. (#140818)

isdn4k-utils-3.2-21
-------------------
* Wed Dec 01 2004 Than Ngo <than at redhat.com> 3.2-21
- fix some minor build problems #140941

* Sat Nov 20 2004 Miloslav Trmac <mitr at redhat.com> 3.2-20
- Convert imontty.8 to UTF-8

* Thu Nov 18 2004 Than Ngo <than at redhat.com> 3.2-19
- update cvs snapshot
- workaround, add capi devices

jpackage-utils-0:1.6.0-2jpp_2rh
-------------------------------
* Wed Dec 01 2004 Thomas Fitzsimmons <fitzsim at redhat.com> 0:1.6.0-2jpp_2rh
- Import version 0:1.6.0-2jpp from jpackage.org.

* Tue Nov 02 2004 Nicolas Mailhot <nim at jpackage.org> - 0:1.6.0-2jpp
- fix missing /usr/lib/java in file list

* Thu Oct 28 2004 Thomas Fitzsimmons <fitzsim at redhat.com> 0:1.5.38-1jpp_6rh
- Add "package-list" blank file to java-javadoc.

kernel-2.6.9-1.1009_FC4
-----------------------
* Wed Dec 01 2004 Rik van Riel <riel at redhat.com>
- replace VM hack with the upstream version
- more Xen bugfixes

mc-1:4.6.1-0.11
---------------
* Wed Dec 01 2004 Jindrich Novy <jnovy at redhat.com> 4.6.1-0.11
- update from CVS
  - fix #141095 - extraction of symlinks from tarfs is now fine
- add growbuf patch from Roland Illig #141422 to view files
  in /proc and /sys properly

perl-3:5.8.5-13
---------------
* Wed Dec 01 2004 Chip Turner <cturner at redhat.com> 3:5.8.5-13
- rebuild

* Wed Dec 01 2004 Chip Turner <cturner at redhat.com> 3:5.8.5-11
- bugzilla: 140563, nptl doesn't act like linuxthreads; threads have no PIDs

* Thu Nov 11 2004 Jeff Johnson <jbj at jbj.org> 3:5.8.5-10
- rebuild against db-4.3.21.

procps-3.2.4-1
--------------
* Wed Dec 01 2004 Karl Zak <kzak at redhat.com> 3.2.4-1
- update to new upstream release

qt-1:3.3.3-16
-------------
* Tue Nov 30 2004 Than Ngo <than at redhat.com> 1:3.3.3-16
- add sql macro

rpmdb-fedora-1:4-0.20041202
---------------------------

selinux-policy-strict-1.19.9-1
------------------------------
* Thu Dec 02 2004 Dan Walsh <dwalsh at redhat.com> 1.19-9-1
- Update to add execmem and execmod

* Wed Dec 01 2004 Dan Walsh <dwalsh at redhat.com> 1.19-8-4
- Allow boolloader to can_exec_any

* Wed Dec 01 2004 Dan Walsh <dwalsh at redhat.com> 1.19-8-3
- Add ipx support
- Fix portmap

selinux-policy-targeted-1.19.8-4
--------------------------------
* Wed Dec 01 2004 Dan Walsh <dwalsh at redhat.com> 1.19-8-4
- Allow boolloader to can_exec_any

* Wed Dec 01 2004 Dan Walsh <dwalsh at redhat.com> 1.19-8-3
- Add ipx support
- Fix portmap

swig-1.3.23-2
-------------
* Wed Dec 01 2004 Phil Knirsch <pknirsch at redhat.com> 1.3.23-2
- rebuild

transfig-1:3.2.4-10
-------------------
* Tue Nov 30 2004 Than Ngo <than at redhat.com> 1:3.2.4-10
- fix compiler warnings #111394
- fix broken language selection #114849

up2date-4.3.69-1
----------------
* Wed Dec 01 2004 Adrian Likins <alikins at redhat.com> 4.3.69-1
- better fix for #139537
- better fix for #140505
- fix #141511

* Mon Nov 29 2004 Adrian Likins <alikins at redhat.com> 4.3.68-1
- fix #140775
- update translations #139495
- fix #140505

* Thu Nov 25 2004 Adrian Likins <alikins at redhat.com> 4.3.67-3
- rev release to rebuild in right dist

vim-1:6.3.035-1
---------------
* Wed Dec 01 2004 Karsten Hopp <karsten at redhat.de> 6.3.035-1 
- patchlevel 35
- allow remapping of 'g' (#140747)

xorg-x11-6.8.1-22
-----------------
* Wed Dec 01 2004 Kristian H??gsberg <krh at redhat.com> 6.8.1-22
- Update xorg-x11-6.8.1-battle-libc-wrapper.patch to not break when
  some module also includes stdio.h.

xscreensaver-1:4.18-14
----------------------
* Wed Dec 01 2004 Ray Strode <rstrode at redhat.com> 1:4.18-14
- Add utility xscreensaver-config-tool to make changing settings
  easier (replaces the short lived xscreensaver-register-hack
  program).  Use xscreensaver-config-tool to set default settings
  instead of using patches. 
- Split up xscreensaver (fixes 121693).
- Make preferences dialog slightly more pretty
- Make lock dialog slightly more pretty



From paul at frields.com  Thu Dec  2 13:14:49 2004
From: paul at frields.com (Paul W. Frields)
Date: Thu, 02 Dec 2004 08:14:49 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <20041202002549.GS27024@angus.ind.WPI.EDU>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
	<1101940970.7811.2.camel@berlin.east.gov>
	<20041202002549.GS27024@angus.ind.WPI.EDU>
Message-ID: <1101993289.6751.0.camel@berlin.east.gov>

On Wed, 2004-12-01 at 19:25 -0500, Charles R. Anderson wrote:
> On Wed, Dec 01, 2004 at 05:42:50PM -0500, Paul W. Frields wrote:
> > On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> > > Perhaps don't leave the *PORT variables empty, but add sensible values?
> > 
> > Sensible values will be widely variant from one location to the next. A
> > "sensible value" is one that gets through *your* firewall. What's there
> > should be good enough for even the laziest admin, IMHO, and yes, I
> > resemble that remark too. :-)
> 
> There are "standard" port numbers for some of these:
> 
> MOUNTD_PORT=635
> NFSD_PORT=2049
> 



From paul at frields.com  Thu Dec  2 13:21:04 2004
From: paul at frields.com (Paul W. Frields)
Date: Thu, 02 Dec 2004 08:21:04 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <20041202002549.GS27024@angus.ind.WPI.EDU>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
	<1101940970.7811.2.camel@berlin.east.gov>
	<20041202002549.GS27024@angus.ind.WPI.EDU>
Message-ID: <1101993665.6751.5.camel@berlin.east.gov>

On Wed, 2004-12-01 at 19:25 -0500, Charles R. Anderson wrote:
> On Wed, Dec 01, 2004 at 05:42:50PM -0500, Paul W. Frields wrote:
> > On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> > > Perhaps don't leave the *PORT variables empty, but add sensible values?
> > 
> > Sensible values will be widely variant from one location to the next. A
> > "sensible value" is one that gets through *your* firewall. What's there
> > should be good enough for even the laziest admin, IMHO, and yes, I
> > resemble that remark too. :-)
> 
> There are "standard" port numbers for some of these:
> 
> MOUNTD_PORT=635
> NFSD_PORT=2049

For rpc.nfsd, you're right on. Sorry about that. For rpc.mountd and
rpc.statd, the man pages show that ports are assigned randomly by
portmap. Is that not correct?

-- 
Paul W. Frields, RHCE



From n3npq at nc.rr.com  Thu Dec  2 13:42:48 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Thu, 02 Dec 2004 08:42:48 -0500
Subject: i486 base architecture
In-Reply-To: <20041202091730.GA5806@ee.oulu.fi>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
Message-ID: <41AF1BD8.6080305@nc.rr.com>

Pekka Pietikainen wrote:

>On Wed, Dec 01, 2004 at 11:10:04PM -0500, Jeff Johnson wrote:
>  
>
>>Prolly the strongest mechanism is to attach a run-time probe dependency to
>>the "cpu(...)" name space and parse /proc/cpuinfo for the relevant info.
>>That mostly works, but will have problems in chroot's w/o /proc mounted,
>>and will be kinda weird if/when, say, the mobo or disk is moved amongst
>>machines, to mention just 2 possible problems off the top of my head.
>>
>>I suspect those deficiencies can be lived with, and are no worse than 
>>existing arch based tests.
>>    
>>
>Would there be any compilications if the thing was generalized and
>you could do Requires-Return-Code: /usr/lib/rpm/check-x86-cpu-flags cmov
>(or whatever the syntax would be, basic idea is that there's some
>external thing that exits with 0 or 1). 
>  
>

Well, not a script please, scripts break way too often to be reliable.

But yes, return codes like
     0 == condition is TRUE
     1 == condition is FALSE
from a function that is passed the {N,EVR,FLAGS} dependency triple which
is dispatched iff the 'cpu(...)' name space wrapper is detected.

Kinda like 'rpmlib(...)' tracking dependencies, which are also a 
run-time probe dependency
wrapped in a name space.

>In any case, such a thing should be easy to override, even when
>using a frontend like yum.
>
Yep.

73 de Jeff




From nphilipp at redhat.com  Thu Dec  2 14:10:43 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 02 Dec 2004 15:10:43 +0100
Subject: Configuring NFS under Linux for Firewall control
In-Reply-To: <ufaoehd3jeo.fsf@epithumia.math.uh.edu>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
Message-ID: <1101996643.21680.30.camel@wombat.tiptoe.de>

On Wed, 2004-12-01 at 13:31 -0600, Jason L Tibbitts III wrote:
> >>>>> "FA" == Florin Andrei <florin at andrei.myip.org> writes:
> 
> FA> For example, add
> FA> some variables, containing the port numbers for the various
> FA> portmap/nfs components, in a file in /etc/sysconfig:
> 
> /etc/sysconfig/nfs is checked.  You can things like:
> 
> RPCNFSDCOUNT
> MOUNTD_PORT
> STATD_PORT
> STATD_OUTGOING_PORT
> 
> You have to set the NLM ports in modprobe.conf or on the kernel
> command line.

Can you tell us the module options needed for that?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From peter.backlund at home.se  Thu Dec  2 14:51:15 2004
From: peter.backlund at home.se (Peter Backlund)
Date: Thu, 02 Dec 2004 15:51:15 +0100
Subject: Icon suggestion
Message-ID: <1101999075.9155.5.camel@localhost.localdomain>

Hi.

I would like to see the current Bluecurve Home-icon changed into one
that uses the same angle/perspective as the rest of the BC icons. I've
cropped the /usr/share/icons/Bluecurve/48x48/emblems/emblem-home.png
icon to 24x24 pixels, which unfortunately cuts one pixel vertically so
that the front edge of the house is at a slightly wrong angle.

Here's what it would look like in Firefox, Nautilus browse mode and
Konqueror: 

http://mozer.nailed.org/misc/gtk-home.png

(~300k, 1400x1050 pixels)

Comments?

(Related to that, the Computer icon in Nautilus is too small as you can
see)

/Peter Backlund



From Philip.R.Schaffner at nasa.gov  Thu Dec  2 15:01:21 2004
From: Philip.R.Schaffner at nasa.gov (Phil Schaffner)
Date: Thu, 02 Dec 2004 10:01:21 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101938575.31463.67.camel@stantz.corp.sgi.com>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
Message-ID: <1101999681.5631.274.camel@wx1.larc.nasa.gov>

On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> On Wed, 2004-12-01 at 16:22 -0500, Paul W. Frields wrote:
> > I haven't BZ'd this since I wasn't sure if anyone agreed with my
> > suggestion, but will do so if I can get a second on the motion.
> 
> I'm not sure about the details either, but overall this is what i was
> talking about.
> Perhaps don't leave the *PORT variables empty, but add sensible
> values?
> 
> -- 
> Florin Andrei

Sounded like a second to me.  Consider this an "All in favor say aye.
Aye!" response.  Very nice start.  Have wished for other files commented
as well as smb.conf, and agree that every config file should at least
have a commented template.

Perhaps a new thread, noting your BZ RFE, and soliciting suggestions (or
submitting more good examples) for other /etc/... files that deserve
this treatment is in order.

Phil




From alan at redhat.com  Thu Dec  2 15:12:30 2004
From: alan at redhat.com (Alan Cox)
Date: Thu, 2 Dec 2004 10:12:30 -0500
Subject: Eina - gtk2 replacement for xmms
In-Reply-To: <1101752376l.4582l.0l@devel.mpeters.us>
References: <1101681765.28290.76.camel@tux.lan>
	<1101684566.3297.1.camel@cutter>
	<41AA628A.3080905@silverorange.com>
	<1101686177.25046.3.camel@localhost.localdomain>
	<1101687292l.25496l.4l@devel.mpeters.us>
	<41AA73D7.6030704@silverorange.com>
	<1101703472l.25496l.5l@devel.mpeters.us>
	<ed0efd31041129013136069abd@mail.gmail.com>
	<1101724342.28290.83.camel@tux.lan>
	<1101752376l.4582l.0l@devel.mpeters.us>
Message-ID: <20041202151230.GA13321@devserv.devel.redhat.com>

On Mon, Nov 29, 2004 at 06:19:36PM +0000, Michael A. Peters wrote:
> I like the iTMS music store, I'm not a huge customer, but I've spent  
> about $200 there since the Windows launch, and I would buy more if I  
> could play the songs in Linux (the OS I use 95+% of the time) without  
> needing a burn/re-rip.

There's always folks like magnatune.com who do provide unencumbered ogg
and have some interesting stuff. 



From paul at frields.com  Thu Dec  2 15:38:57 2004
From: paul at frields.com (Paul W. Frields)
Date: Thu, 02 Dec 2004 10:38:57 -0500
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101993665.6751.5.camel@berlin.east.gov>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
	<1101940970.7811.2.camel@berlin.east.gov>
	<20041202002549.GS27024@angus.ind.WPI.EDU>
	<1101993665.6751.5.camel@berlin.east.gov>
Message-ID: <1102001937.7849.4.camel@berlin.east.gov>

On Thu, 2004-12-02 at 08:21 -0500, Paul W. Frields wrote:
> On Wed, 2004-12-01 at 19:25 -0500, Charles R. Anderson wrote:
> > On Wed, Dec 01, 2004 at 05:42:50PM -0500, Paul W. Frields wrote:
> > > On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> > > > Perhaps don't leave the *PORT variables empty, but add sensible values?
> > > 
> > > Sensible values will be widely variant from one location to the next. A
> > > "sensible value" is one that gets through *your* firewall. What's there
> > > should be good enough for even the laziest admin, IMHO, and yes, I
> > > resemble that remark too. :-)
> > 
> > There are "standard" port numbers for some of these:
> > 
> > MOUNTD_PORT=635
> > NFSD_PORT=2049
> 
> For rpc.nfsd, you're right on. Sorry about that. For rpc.mountd and
> rpc.statd, the man pages show that ports are assigned randomly by
> portmap. Is that not correct?

As a correction to my correction, the current initscript for nfs doesn't
make any allowance for changing the listening port for nfsd. This is not
a value judgment, just an observation.

Bill Nottingham: Would you agree that bugs for these config files should
go, then, against the packages to which they refer (e.g. nfs-utils
for /etc/sysconfig/nfs)? Do you have any insight into whether the
maintainers would be interested in even doing this? I'll be happy to
file the tracker bug and the candidate for /etc/sysconfig/nfs to get
things started, if so.

-- 
Paul W. Frields, RHCE



From nbargnesi at gmail.com  Thu Dec  2 16:29:18 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Thu, 2 Dec 2004 11:29:18 -0500
Subject: OT: automating gui apps
In-Reply-To: <41AEEA31.3080602@hhs.nl>
References: <41AEEA31.3080602@hhs.nl>
Message-ID: <3077b8a0041202082954fe70a0@mail.gmail.com>

The closest thing to what you're looking for is xnee.
http://freshmeat.net/projects/xnee/
(x)nee is (n)ot an (e)vent (e)mulator

-Nick


On Thu, 02 Dec 2004 11:10:57 +0100, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Hi,
> 
> Sorry for posting OT, but I'm hoping that with the acumulated wisdom on
> this list someone can help me.
> 
> I've got this propietary motif application which uses a propietary
> database from which I want to export some data. I can export this data
> from the motif gui by selecting the right item from the menu, entering a
> filename, etc.
> 
> So my question is is there aay way to record mouse movements and
> mousebutton/key presses under X and replay those automaticly, the replay
> preferrably under Xvfb?
> 
> Thanks,
> 
> Hans
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From fedora_devel_list at poczta.fm  Thu Dec  2 16:32:03 2004
From: fedora_devel_list at poczta.fm (Dawid Gajownik)
Date: Thu, 02 Dec 2004 17:32:03 +0100
Subject: [initscripts] loadkeys -u by default?
Message-ID: <41AF4383.7000704@poczta.fm>

Hi!

I know that Fedora/RedHat tries to push UTF8 everywhere so how about
modifying /etc/rc.d/rc.sysinit to have such a line:

loadkeys -u $KEYMAP < /dev/tty0 > /dev/tty0 2>/dev/null && \

This could resolve some problems with inputing non-US-ASCII characters
on tty1 with Czech, Slovene or Polish keytable:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74264
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81760#c7
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125130#c2

Description of this bug is here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74263#c1

Unfortunately, I don't know whether it has disadvantages to other
keymaps :/

BTW may someone answer to 5th question in this bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125130#c3

-- 

   ^_*

----------------------------------------------------------------------
Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837



From david at fubar.dk  Thu Dec  2 16:48:56 2004
From: david at fubar.dk (David Zeuthen)
Date: Thu, 02 Dec 2004 11:48:56 -0500
Subject: adventures in booting
In-Reply-To: <1101869999.3544.65.camel@serenity.klika.si>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
Message-ID: <1102006136.12241.53.camel@davidz>


Hey,

sorry for the lag,

On Wed, 2004-12-01 at 03:59 +0100, Ziga Mahkovec wrote:
> On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> > So, I've looked a bit more into the booting process and how to optimize
> > it.
> 
> Great work!
> 

Thanks.

> > The results are pretty good I think, here is the general time line made
> > with a wallclock
> > 
> > 00: exit grub; start booting the kernel
> > 04: kernel prints audit()
> > 11: initrd is mounted; Red Hat nash visible
> >      mount / ro (normal initrd procedure)
> > 13: start bootchart logging; start readahead of approx 193MB files
> >      sleep until readahead is complete
> > 24: readahead done; now
> >      create /dev and modprobe (in background)
> >      mount / rw, enable swap
> >      start xfs
> >      startx as user davidz in background
> >      start messagebus
> >      start hald
> >      start acpid
> >      start NetworkManager
> 
> Do you have an idea of how much kudzu, cups and syslogd would add to
> these times?  rhgb too probably, or would it make sense to dump it
> completely?
> 

I think that cups and syslogd are mostly harmless - for capturing the
readahead files from my modified kernel I had syslogd log dump to /tmp
which I mounted as tmpfs. syslogd should probably start in before gdm,
but cupsd can certainly be started later (ideally it should be started
on demand). 

kudzu is a bit more difficult as it brings up dialogs - I think Bill
agrees (see the thread on fedora-desktop-list that I linked to in my
original mail) that hardware configuration should be handled in the
desktop GUI anyway.

> > 7. A number of things was started in parallel - I found that doing
> >    readahead while running modprobe wasn't helping anything; in fact
> >    it contributed negatively to performance (a bit to my surprise, I
> >    guess because the kernel was busy).
> 
> You think it might make sense to try running readahead in background,
> but after the modules are loaded?  Especially if the readahead list
> could somehow coincide with the order of services started, to further
> reduce seeking.
> Or is readahead best left running alone?
> 

Not sure; the big boost really comes from reordering the files on the
filesystem - running readahead (which takes 11 seconds) only gives me a
usable desktop four seconds earlier. I'm pretty sure no other process
should do any disk IO when readahead is running as that will almost
certainly incur seek penalties.

> > So, I think these numbers are good and there's still some room for
> > improvement; e.g. it takes ten seconds from grub to when the initrd is
> > mounted - surely the kernel can boot faster? It's after all 25% of the
> > time spent from grub until I have usable desktop.
> 
> I did some experiments with bootchart logging in the initrd phase.
> Packed the initrd image with bash, ps and a bunch of libraries and
> started logging early in the nash script... only to find out that the
> whole phase flies by in less than a second :)
> 

Yeah, I found that too.

> I would like to visualize the kernel boot though.  But I'd need pointers
> on what kind of data to collect, and how.
> 

I think some embedded systems (think DVD players) use patches to boot
the kernel faster - I wonder what the status of adding them to mainline
are?

> > Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
> > very useful.
> 
> BTW, I've had loads of fun with SVG lately, so you might want to try
> regenerating these charts.  Makes them scalable and about 15x smaller in
> file size.  Have a look at the SVG samples (rsvg does a pretty good
> job):
> http://www.klika.si/ziga/bootchart/#Samples
> 

Awesome.

Cheers,
David




From veillard at redhat.com  Thu Dec  2 16:58:44 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 2 Dec 2004 11:58:44 -0500
Subject: adventures in booting
In-Reply-To: <1102006136.12241.53.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz>
Message-ID: <20041202165844.GF25551@redhat.com>

On Thu, Dec 02, 2004 at 11:48:56AM -0500, David Zeuthen wrote:
> Not sure; the big boost really comes from reordering the files on the
> filesystem - running readahead (which takes 11 seconds) only gives me a

  I'm looking into this. a mix of creating a new directory, copying
the file there, then unlinking, linking and unlinking the new copies to the
old name is more likely to help. The problem is that it's also bad for
the current session where that change is done since you will end up with
multiple in-memory copies of all system libraries...
  It is gonna be a bit tricky to set-up, either as a post-install step
or very early on during boot. It's very easy to break too ...

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From david at fubar.dk  Thu Dec  2 17:40:06 2004
From: david at fubar.dk (David Zeuthen)
Date: Thu, 02 Dec 2004 12:40:06 -0500
Subject: adventures in booting
In-Reply-To: <20041202165844.GF25551@redhat.com>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
Message-ID: <1102009206.12241.89.camel@davidz>

On Thu, 2004-12-02 at 11:58 -0500, Daniel Veillard wrote:
> On Thu, Dec 02, 2004 at 11:48:56AM -0500, David Zeuthen wrote:
> > Not sure; the big boost really comes from reordering the files on the
> > filesystem - running readahead (which takes 11 seconds) only gives me a
> 
>   I'm looking into this. a mix of creating a new directory, copying
> the file there, then unlinking, linking and unlinking the new copies to the
> old name is more likely to help. The problem is that it's also bad for
> the current session where that change is done since you will end up with
> multiple in-memory copies of all system libraries...
>   It is gonna be a bit tricky to set-up, either as a post-install step
> or very early on during boot. It's very easy to break too ...
> 

To me it makes more sense to look at this on the block level than on the
file level; remember, a lot the files in my readahead set stems from
stat'ing files - for example, there are more than 2200 distinct .png
files in my readahead set. We probably only need one sector from most of
those (the inode) rather than the entire file.

I'm almost positive it requires kernel changes to do this the right way;
one naive idea is to have a userspace daemon, capturing what blocks are
read when (kernel tells this daemon using the kernel events layer). This
would run in the first three minutes on each and every boot. When the
system is idle (and only when running on AC power!) another daemon
rearranges blocks on the disk. What blocks to rearrange could be the
result of a computation involving several three-minute result sets.

Cheers,
David



From notting at redhat.com  Thu Dec  2 17:42:13 2004
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 2 Dec 2004 12:42:13 -0500
Subject: [initscripts] loadkeys -u by default?
In-Reply-To: <41AF4383.7000704@poczta.fm>
References: <41AF4383.7000704@poczta.fm>
Message-ID: <20041202174213.GA10728@nostromo.devel.redhat.com>

Dawid Gajownik (fedora_devel_list at poczta.fm) said: 
> Hi!
> 
> I know that Fedora/RedHat tries to push UTF8 everywhere so how about
> modifying /etc/rc.d/rc.sysinit to have such a line:
> 
> loadkeys -u $KEYMAP < /dev/tty0 > /dev/tty0 2>/dev/null && \

Seems reasonable, although there would need to be a lot of testing
on this.

Done in CVS, will be in newer initscripts packages.

Bill



From powers.jason at jimmy.harvard.edu  Thu Dec  2 17:51:22 2004
From: powers.jason at jimmy.harvard.edu (Jason Powers)
Date: Thu, 02 Dec 2004 12:51:22 -0500
Subject: stateless linux
Message-ID: <41AF561A.3060300@jimmy.harvard.edu>

I have it all set, snapshot set up and everything, but it doesn't load 
the diskless client. I've been in and through the very vanilla config I 
used, and through all the scripts in /usr/share/stateless/ it seems to 
trip when it attempts to create the pxelinux.0, and the pxe.config 
directory remains empty. The hourly script statelessGenPXEConfig.py 
returns the error:

Unable to get provisioning information for MA:CA:DD:RE:SS

I checked the ldap and all entries are presnt and pointed at the right 
place, what's next?

Jason



From ottohaliburton at comcast.net  Thu Dec  2 17:55:43 2004
From: ottohaliburton at comcast.net (Otto Haliburton)
Date: Thu, 02 Dec 2004 11:55:43 -0600
Subject: sources for up2date
Message-ID: <1102010143.4723.4.camel@c515816-a>

Does anyone know of a great list of repositories to put in the sources
file for up2date, as well as a excellant yum.conf.  Plus the ideal
repositories for yum.repo.d directory.  I have been looking for the
definitive list and found one after a search but unfortunately have been
unable to relocate it
-- 
Otto Haliburton <ottohaliburton at comcast.net>



From walters at redhat.com  Thu Dec  2 17:59:55 2004
From: walters at redhat.com (Colin Walters)
Date: Thu, 02 Dec 2004 12:59:55 -0500
Subject: adventures in booting
In-Reply-To: <1102009206.12241.89.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
Message-ID: <1102010395.4024.21.camel@nexus.verbum.private>

On Thu, 2004-12-02 at 12:40 -0500, David Zeuthen wrote:

> I'm almost positive it requires kernel changes to do this the right way;
> one naive idea is to have a userspace daemon, capturing what blocks are
> read when (kernel tells this daemon using the kernel events layer). This
> would run in the first three minutes on each and every boot. When the
> system is idle (and only when running on AC power!) another daemon
> rearranges blocks on the disk. What blocks to rearrange could be the
> result of a computation involving several three-minute result sets.

Rearranging sounds complex and dangerous, since it requires deep
integration with the filesystem.  The online resizing took quite a long
time to appear and that is conceptually much simpler.  Why not do it on
the block device layer (without knowledge of the filesystem) and just
copy those blocks to a reserved area of the block device?  Disks are
big, duplicating say 100MB for this purpose wouldn't be bad.  We would
need to ensure that mkfs.ext3 would leave enough space for this though
(and probably whatever does the copying would have to make sure that the
filesystem wasn't in the way; perhaps an ext flag).




From fcatrin at tuxpan.com  Thu Dec  2 18:08:18 2004
From: fcatrin at tuxpan.com (Franco Catrin)
Date: Thu, 02 Dec 2004 15:08:18 -0300
Subject: adventures in booting
In-Reply-To: <1102009206.12241.89.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
Message-ID: <1102010898.2968.63.camel@shaman.txp>

El jue, 02-12-2004 a las 12:40 -0500, David Zeuthen escribi?:

> To me it makes more sense to look at this on the block level than on the
> file level; remember, a lot the files in my readahead set stems from
> stat'ing files - for example, there are more than 2200 distinct .png
> files in my readahead set. We probably only need one sector from most of
> those (the inode) rather than the entire file.

where do those files come from?

if those png files come from the gtk theme, it was fixed:

http://bugzilla.gnome.org/show_bug.cgi?id=154034

-- 
Franco Catrin L.  TUXPAN
http://www.tuxpan.com/fcatrin



From walters at redhat.com  Thu Dec  2 18:08:00 2004
From: walters at redhat.com (Colin Walters)
Date: Thu, 02 Dec 2004 13:08:00 -0500
Subject: adventures in booting
In-Reply-To: <1102010395.4024.21.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
Message-ID: <1102010880.4024.28.camel@nexus.verbum.private>

On Thu, 2004-12-02 at 12:59 -0500, Colin Walters wrote:
> On Thu, 2004-12-02 at 12:40 -0500, David Zeuthen wrote:
> 
> > I'm almost positive it requires kernel changes to do this the right way;
> > one naive idea is to have a userspace daemon, capturing what blocks are
> > read when (kernel tells this daemon using the kernel events layer). This
> > would run in the first three minutes on each and every boot. When the
> > system is idle (and only when running on AC power!) another daemon
> > rearranges blocks on the disk. What blocks to rearrange could be the
> > result of a computation involving several three-minute result sets.
> 
> Rearranging sounds complex and dangerous, since it requires deep
> integration with the filesystem.  The online resizing took quite a long
> time to appear and that is conceptually much simpler.  Why not do it on
> the block device layer (without knowledge of the filesystem) and just
> copy those blocks to a reserved area of the block device?  Disks are
> big, duplicating say 100MB for this purpose wouldn't be bad. 

To flesh this out a bit more, you would also write out the mapping from
cache block -> original block to the cache, and make this a device-
mapper target.



From veillard at redhat.com  Thu Dec  2 18:08:00 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 2 Dec 2004 13:08:00 -0500
Subject: adventures in booting
In-Reply-To: <1102009206.12241.89.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz>
	<20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
Message-ID: <20041202180800.GG25551@redhat.com>

On Thu, Dec 02, 2004 at 12:40:06PM -0500, David Zeuthen wrote:
> On Thu, 2004-12-02 at 11:58 -0500, Daniel Veillard wrote:
> > On Thu, Dec 02, 2004 at 11:48:56AM -0500, David Zeuthen wrote:
> > > Not sure; the big boost really comes from reordering the files on the
> > > filesystem - running readahead (which takes 11 seconds) only gives me a
> > 
> >   I'm looking into this. a mix of creating a new directory, copying
> > the file there, then unlinking, linking and unlinking the new copies to the
> > old name is more likely to help. The problem is that it's also bad for
> > the current session where that change is done since you will end up with
> > multiple in-memory copies of all system libraries...
> >   It is gonna be a bit tricky to set-up, either as a post-install step
> > or very early on during boot. It's very easy to break too ...
> > 
> 
> To me it makes more sense to look at this on the block level than on the
> file level; remember, a lot the files in my readahead set stems from

  block level is quite harder, fs specific, and I'm afraid impossible to
do in a generic way, you would need specific kernel APIs for all filesystems
supported.

> stat'ing files - for example, there are more than 2200 distinct .png
> files in my readahead set. We probably only need one sector from most of
> those (the inode) rather than the entire file.
> 
> I'm almost positive it requires kernel changes to do this the right way;
> one naive idea is to have a userspace daemon, capturing what blocks are
> read when (kernel tells this daemon using the kernel events layer). This
> would run in the first three minutes on each and every boot. When the
> system is idle (and only when running on AC power!) another daemon
> rearranges blocks on the disk. What blocks to rearrange could be the
> result of a computation involving several three-minute result sets.

  I suggest a more generic but possibly slightly less efficient way
by working at the file level. Maybe it will not be optimal, inducing a
bit too much data or too many seeks, but would be doable without as
much risk than trying to push a block reallocation API though the full
I/O stack down to every fs driver.
  You suppose you can rearranges blocks on the disk, and I'm really not
sure it's doable realistically within a reasonnable time frame. Ideally
someone well versed in kernel FS internals can talk about this. Something
tells me it's not gonna fly...

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From walters at redhat.com  Thu Dec  2 18:25:39 2004
From: walters at redhat.com (Colin Walters)
Date: Thu, 02 Dec 2004 13:25:39 -0500
Subject: adventures in booting
In-Reply-To: <20041202165844.GF25551@redhat.com>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
Message-ID: <1102011939.4024.35.camel@nexus.verbum.private>

On Thu, 2004-12-02 at 11:58 -0500, Daniel Veillard wrote:
> On Thu, Dec 02, 2004 at 11:48:56AM -0500, David Zeuthen wrote:
> > Not sure; the big boost really comes from reordering the files on the
> > filesystem - running readahead (which takes 11 seconds) only gives me a
> 
>   I'm looking into this. a mix of creating a new directory, copying
> the file there, then unlinking, linking and unlinking the new copies to the
> old name is more likely to help. 

Eek.  So what happens if I install an RPM while this is happening, or
prelink runs, or...?  I think the caching should clearly go in the
kernel; anything else is going to have serious race conditions in some
form.




From mgalgoci at redhat.com  Thu Dec  2 18:42:32 2004
From: mgalgoci at redhat.com (Matthew Galgoci)
Date: Thu, 2 Dec 2004 13:42:32 -0500
Subject: 802.1x support
Message-ID: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>


Has anyone given any thought to adding 802.1x support to fc?

Mind you I don't mean exclusively for wireless support, but in general.

-- 
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155



From david at fubar.dk  Thu Dec  2 19:06:25 2004
From: david at fubar.dk (David Zeuthen)
Date: Thu, 02 Dec 2004 14:06:25 -0500
Subject: adventures in booting
In-Reply-To: <1102010395.4024.21.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
Message-ID: <1102014385.12241.138.camel@davidz>

On Thu, 2004-12-02 at 12:59 -0500, Colin Walters wrote:
> On Thu, 2004-12-02 at 12:40 -0500, David Zeuthen wrote:
> 
> > I'm almost positive it requires kernel changes to do this the right way;
> > one naive idea is to have a userspace daemon, capturing what blocks are
> > read when (kernel tells this daemon using the kernel events layer). This
> > would run in the first three minutes on each and every boot. When the
> > system is idle (and only when running on AC power!) another daemon
> > rearranges blocks on the disk. What blocks to rearrange could be the
> > result of a computation involving several three-minute result sets.
> 
> Rearranging sounds complex and dangerous, since it requires deep
> integration with the filesystem.  The online resizing took quite a long
> time to appear and that is conceptually much simpler.  Why not do it on
> the block device layer (without knowledge of the filesystem) and just
> copy those blocks to a reserved area of the block device?  Disks are
> big, duplicating say 100MB for this purpose wouldn't be bad.  We would
> need to ensure that mkfs.ext3 would leave enough space for this though
> (and probably whatever does the copying would have to make sure that the
> filesystem wasn't in the way; perhaps an ext flag).
> 

This sounds much simpler and better; for good measure, ensure that the
reserved area is in the beginning of the partition as reads are
generally faster on lower sectors. This article seems to suggest

 http://www.kernelthread.com/mac/apme/optimizations/

that Mac OS X is doing something that like although it appears to be on
a file system level rather than a block level. The concept of "hot
files" is interesting.

Cheers,
David

> 



From dcbw at redhat.com  Thu Dec  2 19:12:42 2004
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 02 Dec 2004 14:12:42 -0500
Subject: 802.1x support
In-Reply-To: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>
References: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>
Message-ID: <1102014762.11436.6.camel@dcbw.boston.redhat.com>

wpa_supplicant or Open1x come to mind...  we don't currently ship either
of them however.  I'd use wpa_supplicant most likely as it seems to have
broader hardware/server support and seems to support the required packet
capture functions on most drivers.

Dan

On Thu, 2004-12-02 at 13:42 -0500, Matthew Galgoci wrote:
> Has anyone given any thought to adding 802.1x support to fc?
> 
> Mind you I don't mean exclusively for wireless support, but in general.
> 
> -- 
> Matthew Galgoci
> System Administrator
> Red Hat, Inc
> 919.754.3700 x44155
> 



From fcatrin at tuxpan.com  Thu Dec  2 19:33:26 2004
From: fcatrin at tuxpan.com (Franco Catrin)
Date: Thu, 02 Dec 2004 16:33:26 -0300
Subject: adventures in booting
In-Reply-To: <1102014385.12241.138.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
	<1102014385.12241.138.camel@davidz>
Message-ID: <1102016006.2968.75.camel@shaman.txp>

El jue, 02-12-2004 a las 14:06 -0500, David Zeuthen escribi?:

[...]

> This sounds much simpler and better; for good measure, ensure that the
> reserved area is in the beginning of the partition as reads are
> generally faster on lower sectors. This article seems to suggest
> 
>  http://www.kernelthread.com/mac/apme/optimizations/
> 
> that Mac OS X is doing something that like although it appears to be on
> a file system level rather than a block level. The concept of "hot
> files" is interesting.

I was looking for this document for a long time, thanks.

BootCache sounds to me like a dynamic readahead, opposite to the current
static readahead in Fedora.  Done this way would rock for those users
that doesn't use the predefined readahead.files fileset

-- 
Franco Catrin L.  TUXPAN
http://www.tuxpan.com/fcatrin



From ziga.mahkovec at klika.si  Thu Dec  2 19:52:15 2004
From: ziga.mahkovec at klika.si (Ziga Mahkovec)
Date: Thu, 02 Dec 2004 20:52:15 +0100
Subject: adventures in booting
In-Reply-To: <1102016006.2968.75.camel@shaman.txp>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
	<1102014385.12241.138.camel@davidz>
	<1102016006.2968.75.camel@shaman.txp>
Message-ID: <1102017135.3225.5.camel@serenity.klika.si>

On Thu, 2004-12-02 at 16:33 -0300, Franco Catrin wrote:
> >  http://www.kernelthread.com/mac/apme/optimizations/
> > 
> I was looking for this document for a long time, thanks.
> 
> BootCache sounds to me like a dynamic readahead, opposite to the current
> static readahead in Fedora.  Done this way would rock for those users
> that doesn't use the predefined readahead.files fileset

Other interesting reads on the subject:

http://kerneltrap.org/node/view/2157 which also points to:
http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/default.aspx
(search prefetch)

-- 
Ziga



From fedora_devel_list at poczta.fm  Thu Dec  2 20:02:02 2004
From: fedora_devel_list at poczta.fm (Dawid Gajownik)
Date: Thu, 02 Dec 2004 21:02:02 +0100
Subject: [initscripts] loadkeys -u by default?
In-Reply-To: <20041202174213.GA10728@nostromo.devel.redhat.com>
References: <41AF4383.7000704@poczta.fm>
	<20041202174213.GA10728@nostromo.devel.redhat.com>
Message-ID: <41AF74BA.8040709@poczta.fm>

Dnia 12/02/2004 06:42 PM, U?ytkownik Bill Nottingham napisa?:

> Done in CVS, will be in newer initscripts packages.

Thanks!

-- 

   ^_*

----------------------------------------------------------------------
Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837



From guhvies at gmail.com  Thu Dec  2 20:16:15 2004
From: guhvies at gmail.com (ne...)
Date: Thu, 2 Dec 2004 15:16:15 -0500
Subject: sources for up2date
In-Reply-To: <1102010143.4723.4.camel@c515816-a>
References: <1102010143.4723.4.camel@c515816-a>
Message-ID: <a227b70c04120212161db08271@mail.gmail.com>

On Thu, 02 Dec 2004 11:55:43 -0600, Otto Haliburton
<ottohaliburton at comcast.net> wrote:
> Does anyone know of a great list of repositories to put in the sources
> file for up2date, as well as a excellant yum.conf.  Plus the ideal
> repositories for yum.repo.d directory.  I have been looking for the
> definitive list and found one after a search but unfortunately have been
> unable to relocate it
Well the yum.conf question usally comes up about once a week so I
guess searching the archives should help. WRT up2date, use the same
repos as in yum.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard. 
http://www.thespark.com/bastardtest



From veillard at redhat.com  Thu Dec  2 21:38:31 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 2 Dec 2004 16:38:31 -0500
Subject: adventures in booting
In-Reply-To: <1102011939.4024.35.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz>
	<20041202165844.GF25551@redhat.com>
	<1102011939.4024.35.camel@nexus.verbum.private>
Message-ID: <20041202213831.GI25551@redhat.com>

On Thu, Dec 02, 2004 at 01:25:39PM -0500, Colin Walters wrote:
> On Thu, 2004-12-02 at 11:58 -0500, Daniel Veillard wrote:
> > On Thu, Dec 02, 2004 at 11:48:56AM -0500, David Zeuthen wrote:
> > > Not sure; the big boost really comes from reordering the files on the
> > > filesystem - running readahead (which takes 11 seconds) only gives me a
> > 
> >   I'm looking into this. a mix of creating a new directory, copying
> > the file there, then unlinking, linking and unlinking the new copies to the
> > old name is more likely to help. 
> 
> Eek.  So what happens if I install an RPM while this is happening, or

  I don't expect this to happen in multiuser.

> prelink runs, or...?  I think the caching should clearly go in the
> kernel; anything else is going to have serious race conditions in some
> form.

  If the kernel has an atomic rename system call then it can be done
without race, if not that will be a very serious issue.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From walters at redhat.com  Thu Dec  2 21:59:49 2004
From: walters at redhat.com (Colin Walters)
Date: Thu, 02 Dec 2004 16:59:49 -0500
Subject: adventures in booting
In-Reply-To: <20041202213831.GI25551@redhat.com>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102011939.4024.35.camel@nexus.verbum.private>
	<20041202213831.GI25551@redhat.com>
Message-ID: <1102024790.4024.39.camel@nexus.verbum.private>

On Thu, 2004-12-02 at 16:38 -0500, Daniel Veillard wrote:

>   If the kernel has an atomic rename system call then it can be done
> without race, if not that will be a very serious issue.

It has an atomic rename for files; but you can't atomically change a
directory that has content.  Or am I missing something?  Not to mention
this would break things like RPM verification.




From mike at flyn.org  Thu Dec  2 22:39:59 2004
From: mike at flyn.org (W. Michael Petullo)
Date: Thu, 2 Dec 2004 16:39:59 -0600
Subject: Splash.xpm.gz
Message-ID: <20041202223959.GA3874@imp.flyn.org>

Why is boot/grub/splash.xpm.gz included in the kernel RPM?  Why is it
not in the grub RPM instead?  The reason I ask is that, when using
Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
Yaboot is used instead of grub on PowerPC.

-- 
Mike

:wq



From veillard at redhat.com  Thu Dec  2 23:40:06 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Thu, 2 Dec 2004 18:40:06 -0500
Subject: adventures in booting
In-Reply-To: <1102024790.4024.39.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz>
	<20041202165844.GF25551@redhat.com>
	<1102011939.4024.35.camel@nexus.verbum.private>
	<20041202213831.GI25551@redhat.com>
	<1102024790.4024.39.camel@nexus.verbum.private>
Message-ID: <20041202234006.GK25551@redhat.com>

On Thu, Dec 02, 2004 at 04:59:49PM -0500, Colin Walters wrote:
> On Thu, 2004-12-02 at 16:38 -0500, Daniel Veillard wrote:
> 
> >   If the kernel has an atomic rename system call then it can be done
> > without race, if not that will be a very serious issue.
> 
> It has an atomic rename for files; but you can't atomically change a
> directory that has content.  Or am I missing something?  Not to mention
> this would break things like RPM verification.

  I think you're missing something. It is possible to copy the file
somewhere else and then rename it to the original name, then update
the m_time and rpm -Va should not say anything, the checksum and file
system attributes should look alike.
  The copy to a single new directory is a trick to force allocation
in the same filesystem zone (if the FS has zones).

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From nmiell at comcast.net  Fri Dec  3 00:57:06 2004
From: nmiell at comcast.net (Nicholas Miell)
Date: Thu, 02 Dec 2004 16:57:06 -0800
Subject: i486 base architecture
In-Reply-To: <41AF1BD8.6080305@nc.rr.com>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
Message-ID: <1102035426.3593.3.camel@localhost.localdomain>

[ Stuff about what's going to 'Provide: cpu(cmov)' omitted. ]

Ok, now that that's settled, how are packages going to get the
"Requires: cpu(cmov)" dependency?

And why can't we just say that i686 packages all require a i686 variant
that provides CMOVcc?

Sure, there are i686 variants that don't, but what's stopping them from
using the generic i386 version (which is optimized for i686, anyway)?
-- 
Nicholas Miell <nmiell at comcast.net>



From jspaleta at gmail.com  Fri Dec  3 00:21:22 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 2 Dec 2004 19:21:22 -0500
Subject: Splash.xpm.gz
In-Reply-To: <20041202223959.GA3874@imp.flyn.org>
References: <20041202223959.GA3874@imp.flyn.org>
Message-ID: <604aa791041202162165a0a039@mail.gmail.com>

On Thu, 2 Dec 2004 16:39:59 -0600, W. Michael Petullo <mike at flyn.org> wrote:
> Why is boot/grub/splash.xpm.gz included in the kernel RPM?  Why is it
> not in the grub RPM instead?  The reason I ask is that, when using
> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> Yaboot is used instead of grub on PowerPC.

what?  
on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
in the development i386 tree splash.xpm.gz is part of fedora-logos packages
in fact the version of fedora-logos is the same in fc3 as in
development at the moment.
are you really really sure /boot/grub/splash.xpm.gz on your system is
part of the kernel rpm?

-jef



From n3npq at nc.rr.com  Fri Dec  3 01:27:44 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Thu, 02 Dec 2004 20:27:44 -0500
Subject: i486 base architecture
In-Reply-To: <1102035426.3593.3.camel@localhost.localdomain>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
	<1102035426.3593.3.camel@localhost.localdomain>
Message-ID: <41AFC110.1090504@nc.rr.com>

Nicholas Miell wrote:

>[ Stuff about what's going to 'Provide: cpu(cmov)' omitted. ]
>
>Ok, now that that's settled, how are packages going to get the
>"Requires: cpu(cmov)" dependency?
>  
>

Again, there's nothing (well you are gonna need a matching Provides: 
somehow) stopping
anyone from adding
    Requires: cpu(cmov)
to a package spec file, presumably because cmov is known to be used within
package executable.

The process can be done automagically as well, basically disassembling 
every elf
file and grepping for known i686 specific opcodes. That mechanism is crude
enough that perhaps some compiler geek would suggest a better mechanism
almost instantly ;-)

>And why can't we just say that i686 packages all require a i686 variant
>that provides CMOVcc?
>  
>

Because that is exactly where rpm is right now, with murky and implicit 
assumptions
about what is provided and what is not, and no clear way to identify without
the artifact of inventing bogus i686 arch names (kinda like ppc* is 
today, there's
way too many ppc* arches, and I certainly have no idea what 
distinguishing properties
each has, other than different letters after "ppc")

>Sure, there are i686 variants that don't, but what's stopping them from
>using the generic i386 version (which is optimized for i686, anyway)?
>  
>
And that is the lowest common denominator package naming that is 
currently being
used in FC4, some packages have ".i386.rpm" suffixes, yet will not run 
on hw arch i386,
causing user confision about every 3 months or so, and we discuss this 
topic Yet Again.

73 de Jeff



From nbargnesi at gmail.com  Fri Dec  3 01:40:35 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Thu, 2 Dec 2004 20:40:35 -0500
Subject: Splash.xpm.gz
In-Reply-To: <604aa791041202162165a0a039@mail.gmail.com>
References: <20041202223959.GA3874@imp.flyn.org>
	<604aa791041202162165a0a039@mail.gmail.com>
Message-ID: <3077b8a0041202174015000673@mail.gmail.com>

Same here - on x86_64 its in fedora-logos.
-Nick


On Thu, 2 Dec 2004 19:21:22 -0500, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Thu, 2 Dec 2004 16:39:59 -0600, W. Michael Petullo <mike at flyn.org> wrote:
> > Why is boot/grub/splash.xpm.gz included in the kernel RPM?  Why is it
> > not in the grub RPM instead?  The reason I ask is that, when using
> > Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> > Yaboot is used instead of grub on PowerPC.
> 
> what?
> on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
> in the development i386 tree splash.xpm.gz is part of fedora-logos packages
> in fact the version of fedora-logos is the same in fc3 as in
> development at the moment.
> are you really really sure /boot/grub/splash.xpm.gz on your system is
> part of the kernel rpm?
> 
> -jef
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From nmiell at comcast.net  Fri Dec  3 02:35:14 2004
From: nmiell at comcast.net (Nicholas Miell)
Date: Thu, 02 Dec 2004 18:35:14 -0800
Subject: i486 base architecture
In-Reply-To: <41AFC110.1090504@nc.rr.com>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
	<1102035426.3593.3.camel@localhost.localdomain>
	<41AFC110.1090504@nc.rr.com>
Message-ID: <1102041314.3593.23.camel@localhost.localdomain>

On Thu, 2004-12-02 at 20:27 -0500, Jeff Johnson wrote:
> Nicholas Miell wrote:
> >Ok, now that that's settled, how are packages going to get the
> >"Requires: cpu(cmov)" dependency?

> Again, there's nothing (well you are gonna need a matching Provides: 
> somehow) stopping anyone from adding
>     Requires: cpu(cmov)
> to a package spec file, presumably because cmov is known to be used within
> package executable.
>
> The process can be done automagically as well, basically disassembling 
> every elf file and grepping for known i686 specific opcodes. That mechanism
> is crude enough that perhaps some compiler geek would suggest a better
> mechanism almost instantly ;-)
> 

Both options appear to be fragile and error prone.

Requiring the manual addition of a dependency to the spec means lots of
package authors are going to forget to do it, making it effectively
useless as an indicator of what packages actually require (especially
because i686 packages already require CMOVcc).

Automagic dependencies are going to screw up for any piece of software
that selects different CPU optimized routines at run-time, some of which
use CMOVcc.

> >And why can't we just say that i686 packages all require a i686 variant
> >that provides CMOVcc?

> Because that is exactly where rpm is right now, with murky and implicit 
> assumptions about what is provided and what is not, and no clear way to 
> identify without the artifact of inventing bogus i686 arch names (kinda
> like ppc* is today, there's way too many ppc* arches, and I certainly
> have no idea what distinguishing properties each has, other than
> different letters after "ppc")

Well, instead of weird Requires that have to be manually inserted by the
spec author and Provides that are mysteriously provided by nothing, why
not just document exactly what the different RPM architectures mean.

This isn't as hard as you may initially think -- just say that each
target requires whatever gcc requires when optimizing for that target
with the default RPM build flags.

> >Sure, there are i686 variants that don't, but what's stopping them from
> >using the generic i386 version (which is optimized for i686, anyway)?
> >
> And that is the lowest common denominator package naming that is 
> currently being used in FC4, some packages have ".i386.rpm" suffixes, yet
> will not run on hw arch i386, causing user confision about every 3 months
> or so, and we discuss this topic Yet Again.

Well, that's a bug, those packages should be fixed.

And if you get tired of user confusion, make a FAQ. Saying "It's in the
FAQ, dimwit." or something to that effect can be rather satisfying.

-- 
Nicholas Miell <nmiell at comcast.net>



From hp at redhat.com  Fri Dec  3 02:55:39 2004
From: hp at redhat.com (Havoc Pennington)
Date: Thu, 02 Dec 2004 21:55:39 -0500
Subject: adventures in booting
In-Reply-To: <1102009206.12241.89.camel@davidz>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
Message-ID: <1102042539.4343.15.camel@localhost.localdomain>

On Thu, 2004-12-02 at 12:40 -0500, David Zeuthen wrote:
> 
> To me it makes more sense to look at this on the block level than on the
> file level; remember, a lot the files in my readahead set stems from
> stat'ing files - for example, there are more than 2200 distinct .png
> files in my readahead set. We probably only need one sector from most of
> those (the inode) rather than the entire file.
> 
> I'm almost positive it requires kernel changes to do this the right way;
> one naive idea is to have a userspace daemon, capturing what blocks are
> read when (kernel tells this daemon using the kernel events layer). This
> would run in the first three minutes on each and every boot. When the
> system is idle (and only when running on AC power!) another daemon
> rearranges blocks on the disk. What blocks to rearrange could be the
> result of a computation involving several three-minute result sets.

Stephen Tweedie mentioned some ideas for what could be done in the
kernel to optimize this stuff, I don't know specifics.

Havoc




From meetkaustubhghosh at vsnl.net  Fri Dec  3 06:10:59 2004
From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh)
Date: Fri, 03 Dec 2004 11:40:59 +0530
Subject: Can anyone give me some info about inodes?
Message-ID: <200412031140.29099.meetkaustubhghosh@vsnl.net>

Hi all,
I am new to this list and I have a question:
Can anyone please tell me the answers to the following:
  1.How many inodes are there in a single block ?
  2.After a inode is deleted , is it appended to the end of free inodes list?
  3.Is there any preference in which the inodes are allocated in choosing 
between inodes that has never been allocated and inodes which were once 
allocated but are now free?
  4.Doess the data in an inode remains unchanged when it is deleted?

Please consider the ext2 file system  while answering my query

It would help me immensely if I get the answers to the above.Thanks in advance 
for all the help you can give.

Thanks,
Kaustubh Ghosh



From ggw at wolves.durham.nc.us  Fri Dec  3 06:29:57 2004
From: ggw at wolves.durham.nc.us (Gregory Woodbury)
Date: Fri, 3 Dec 2004 01:29:57 -0500
Subject: Can anyone give me some info about inodes?
In-Reply-To: <200412031140.29099.meetkaustubhghosh@vsnl.net>
References: <200412031140.29099.meetkaustubhghosh@vsnl.net>
Message-ID: <20041203062957.GA23277@wolves.durham.nc.us>

On Fri, Dec 03, 2004 at 11:40:59AM +0530, Kaustubh Ghosh wrote:
> Hi all,
> I am new to this list and I have a question:
> Can anyone please tell me the answers to the following:
>   1.How many inodes are there in a single block ?
	Depends on the size of the inode, but I believe there is an
integral number of inodes per block, the kernel headers (inode.h?) tell
the tale.

>   2.After a inode is deleted , is it appended to the end of free inodes list?
	Yes

>   3.Is there any preference in which the inodes are allocated in choosing 
> between inodes that has never been allocated and inodes which were once 
> allocated but are now free?
	Since the inodes are added to the end of the free list there is
a defacto preference for new inodes.

>   4.Doess the data in an inode remains unchanged when it is deleted?
	No, I believe the inode blocklist is cleared when the contents
are deallocated.  This is necessary so that the free block list can be
reconstructed if necessary by fsck.

The code is available in the kernel tree, and on the net, you should
google for information as well.

-- 
G.Wolfe Woodbury     `- -'
RHCT                   U
The Line Eater is a boojum!



From meetkaustubhghosh at vsnl.net  Fri Dec  3 06:29:10 2004
From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh)
Date: Fri, 03 Dec 2004 11:59:10 +0530
Subject: Can anybody give me some info about inodes?
Message-ID: <200412031159.10588.meetkaustubhghosh@vsnl.net>

Hi all,
I am new to this list and I have a question:
Can anyone please tell me the answers to the following:
  1.How many inodes are there in a single block ?
  2.After a inode is deleted , is it appended to the end of free inodes list?
  3.Is there any preference in which the inodes are allocated in choosing 
between inodes that has never been allocated and inodes which were once 
allocated but are now free?
  4.Doess the data in an inode remains unchanged when it is deleted?

Please consider the ext2 file system  while answering my query

It would help me immensely if I get the answers to the above.Thanks in advance 
for all the help you can give.

Thanks,
Kaustubh Ghosh



From meetkaustubhghosh at vsnl.net  Fri Dec  3 06:30:04 2004
From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh)
Date: Fri, 03 Dec 2004 12:00:04 +0530
Subject: Can anybody give me some info about inodes?
Message-ID: <200412031200.04116.meetkaustubhghosh@vsnl.net>

Hi all,
I am new to this list and I have a question:
Can anyone please tell me the answers to the following:
  1.How many inodes are there in a single block ?
  2.After a inode is deleted , is it appended to the end of free inodes list?
  3.Is there any preference in which the inodes are allocated in choosing 
between inodes that has never been allocated and inodes which were once 
allocated but are now free?
  4.Doess the data in an inode remains unchanged when it is deleted?

Please consider the ext2 file system  while answering my query

It would help me immensely if I get the answers to the above.Thanks in advance 
for all the help you can give.

Thanks,
Kaustubh Ghosh



From ggw at wolves.durham.nc.us  Fri Dec  3 06:30:42 2004
From: ggw at wolves.durham.nc.us (Gregory Woodbury)
Date: Fri, 3 Dec 2004 01:30:42 -0500
Subject: Can anyone give me some info about inodes?
In-Reply-To: <200412031140.29099.meetkaustubhghosh@vsnl.net>
References: <200412031140.29099.meetkaustubhghosh@vsnl.net>
Message-ID: <20041203062957.GA23277@wolves.durham.nc.us>

On Fri, Dec 03, 2004 at 11:40:59AM +0530, Kaustubh Ghosh wrote:
> Hi all,
> I am new to this list and I have a question:
> Can anyone please tell me the answers to the following:
>   1.How many inodes are there in a single block ?
	Depends on the size of the inode, but I believe there is an
integral number of inodes per block, the kernel headers (inode.h?) tell
the tale.

>   2.After a inode is deleted , is it appended to the end of free inodes list?
	Yes

>   3.Is there any preference in which the inodes are allocated in choosing 
> between inodes that has never been allocated and inodes which were once 
> allocated but are now free?
	Since the inodes are added to the end of the free list there is
a defacto preference for new inodes.

>   4.Doess the data in an inode remains unchanged when it is deleted?
	No, I believe the inode blocklist is cleared when the contents
are deallocated.  This is necessary so that the free block list can be
reconstructed if necessary by fsck.

The code is available in the kernel tree, and on the net, you should
google for information as well.

-- 
G.Wolfe Woodbury     `- -'
RHCT                   U
The Line Eater is a boojum!



From pekkas at netcore.fi  Fri Dec  3 08:38:20 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 3 Dec 2004 10:38:20 +0200 (EET)
Subject: 802.1x support
In-Reply-To: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>
References: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>
Message-ID: <Pine.LNX.4.61.0412031036580.1750@netcore.fi>

On Thu, 2 Dec 2004, Matthew Galgoci wrote:
> Has anyone given any thought to adding 802.1x support to fc?
>
> Mind you I don't mean exclusively for wireless support, but in general.

I actually sent a message asking for this a month or two ago..

Would seem like a good idea to me.  Linux has been lagging behind 
Windows with this respect for a couple of years now.  There are 
solutions to fix this, but they have not been merged with 
distributions.  FC could be an ideal place to start testing this 
functionality.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From giallu at gmail.com  Fri Dec  3 08:42:14 2004
From: giallu at gmail.com (Gianluca Sforna)
Date: Fri, 3 Dec 2004 09:42:14 +0100
Subject: OT: automating gui apps
In-Reply-To: <3077b8a0041202082954fe70a0@mail.gmail.com>
References: <41AEEA31.3080602@hhs.nl>
	<3077b8a0041202082954fe70a0@mail.gmail.com>
Message-ID: <d5ad2147041203004270df87e8@mail.gmail.com>

Interesting, eventually this could be useful here too...

Did somoeone package it for FCx???

Gianluca


On Thu, 2 Dec 2004 11:29:18 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> The closest thing to what you're looking for is xnee.
> http://freshmeat.net/projects/xnee/
> (x)nee is (n)ot an (e)vent (e)mulator
> 
> -Nick
> 
> 
> 
> 
> On Thu, 02 Dec 2004 11:10:57 +0100, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> > Hi,
> >
> > Sorry for posting OT, but I'm hoping that with the acumulated wisdom on
> > this list someone can help me.
> >
> > I've got this propietary motif application which uses a propietary
> > database from which I want to export some data. I can export this data
> > from the motif gui by selecting the right item from the menu, entering a
> > filename, etc.
> >
> > So my question is is there aay way to record mouse movements and
> > mousebutton/key presses under X and replay those automaticly, the replay
> > preferrably under Xvfb?
> >
> > Thanks,
> >
> > Hans
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> 
> --
> 
> Nick Bargnesi
> http://www.den-4.com
> Den 4 Software
> 
> pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
> Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
> sub  2048g/56C5D45B 2004-12-02
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From n3npq at nc.rr.com  Fri Dec  3 09:46:41 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Fri, 03 Dec 2004 04:46:41 -0500
Subject: i486 base architecture
In-Reply-To: <1102041314.3593.23.camel@localhost.localdomain>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
	<1102035426.3593.3.camel@localhost.localdomain>
	<41AFC110.1090504@nc.rr.com>
	<1102041314.3593.23.camel@localhost.localdomain>
Message-ID: <41B03601.3080006@nc.rr.com>

Nicholas Miell wrote:

>On Thu, 2004-12-02 at 20:27 -0500, Jeff Johnson wrote:
>  
>
>>Nicholas Miell wrote:
>>    
>>
>>>Ok, now that that's settled, how are packages going to get the
>>>"Requires: cpu(cmov)" dependency?
>>>      
>>>
>
>  
>
>>Again, there's nothing (well you are gonna need a matching Provides: 
>>somehow) stopping anyone from adding
>>    Requires: cpu(cmov)
>>to a package spec file, presumably because cmov is known to be used within
>>package executable.
>>
>>The process can be done automagically as well, basically disassembling 
>>every elf file and grepping for known i686 specific opcodes. That mechanism
>>is crude enough that perhaps some compiler geek would suggest a better
>>mechanism almost instantly ;-)
>>
>>    
>>
>
>Both options appear to be fragile and error prone.
>
>Requiring the manual addition of a dependency to the spec means lots of
>package authors are going to forget to do it, making it effectively
>useless as an indicator of what packages actually require (especially
>because i686 packages already require CMOVcc).
>
>Automagic dependencies are going to screw up for any piece of software
>that selects different CPU optimized routines at run-time, some of which
>use CMOVcc.
>
>  
>
>>>And why can't we just say that i686 packages all require a i686 variant
>>>that provides CMOVcc?
>>>      
>>>
>
>  
>
>>Because that is exactly where rpm is right now, with murky and implicit 
>>assumptions about what is provided and what is not, and no clear way to 
>>identify without the artifact of inventing bogus i686 arch names (kinda
>>like ppc* is today, there's way too many ppc* arches, and I certainly
>>have no idea what distinguishing properties each has, other than
>>different letters after "ppc")
>>    
>>
>
>Well, instead of weird Requires that have to be manually inserted by the
>spec author and Provides that are mysteriously provided by nothing, why
>not just document exactly what the different RPM architectures mean.
>  
>

The package maintainers for the handful of packages that use, say, cmov 
are quite
knowledgeable and competent. Requiring manual entry is also a viable 
solution to
the general problem because a missing Requires: changes nothing that is 
not already
happening in practice, that, indeed, there are implict and undocumented 
dependencies
in existing packages.

But I'm all in favor of automation, do not think that I am suggesting 
manual package
edits as the best possible solution.

The rpm implementation does not control what strings are used to 
identify arch in packages.
For example, PLD is using "pentium3", "pentium4", and "amd64" while
Red Hat is using "i586", "i686" and "x86_64" with essentially the same
meanings, and all of those strings are being carried in default rpm 
configuration.

Documenting what is meant by all those strings that are used differently is
a vendor or distro, not an rpm, problem. The rpm implementation supports 
only the
strcmp mechanism, not the deeper semantic meaning of arch.

And the "weird Requires" is actually an attempt to rationalize this mess,
as arch in rpm is entirely the wrong name space to tag packages with,
there are way too many problems to do anything other than just
abandon arch as a meaningful objective identifier of rpm package content 
imho.

>This isn't as hard as you may initially think -- just say that each
>target requires whatever gcc requires when optimizing for that target
>with the default RPM build flags.
>  
>
That has already been attempted, the configured optflags (which is all that
rpm has ever attempted to control for when building a package) have been
in packages for years.

That of course doesn't work at all when packages do not use $RPM_OPT_FLAGS.

Attempting to reason from what gcc uses also does not "work" when there 
are, say,
several different sets of compilation flags used within a single 
package, so there is
no one "target requires whatever gcc requires", the mapping is many 
files within
the package compiled by gcc onto a single package arch identifier.

>  
>
>>>Sure, there are i686 variants that don't, but what's stopping them from
>>>using the generic i386 version (which is optimized for i686, anyway)?
>>>
>>>      
>>>
>>And that is the lowest common denominator package naming that is 
>>currently being used in FC4, some packages have ".i386.rpm" suffixes, yet
>>will not run on hw arch i386, causing user confision about every 3 months
>>or so, and we discuss this topic Yet Again.
>>    
>>
>
>Well, that's a bug, those packages should be fixed.
>

How, by changing the label from "i386" to "i486" or
by changing the compilation to agree with the label?

>
>And if you get tired of user confusion, make a FAQ. Saying "It's in the
>FAQ, dimwit." or something to that effect can be rather satisfying.
>

Easier than a FAQ is not making any change at all (i.e. leaving packages 
as "i386.rpm"),
which appears to be where this thread is ending up, not surprisingly.

Talk to you in a couple of months, when the "i386" vs. "i486" issue will 
surely arise again,
same Bat time, same Bat channel ;-)

73 de Jeff




From j.w.r.degoede at hhs.nl  Fri Dec  3 10:30:33 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 03 Dec 2004 11:30:33 +0100
Subject: OT: automating gui apps
In-Reply-To: <d5ad2147041203004270df87e8@mail.gmail.com>
References: <41AEEA31.3080602@hhs.nl>	<3077b8a0041202082954fe70a0@mail.gmail.com>
	<d5ad2147041203004270df87e8@mail.gmail.com>
Message-ID: <41B04049.6000909@hhs.nl>



Gianluca Sforna wrote:
> Interesting, eventually this could be useful here too...
> 
> Did somoeone package it for FCx???
> 
> Gianluca
> 
> 
> On Thu, 2 Dec 2004 11:29:18 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> 
>>The closest thing to what you're looking for is xnee.
>>http://freshmeat.net/projects/xnee/
>>(x)nee is (n)ot an (e)vent (e)mulator
>>
>>-Nick
>>
>>

I somehow missed your reply, but thanks to the reply to your reply I 
still got it :)

Thanks for the pointer I'll take a look.

Regards,

Hans

>>
>>
>>On Thu, 02 Dec 2004 11:10:57 +0100, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>>
>>>Hi,
>>>
>>>Sorry for posting OT, but I'm hoping that with the acumulated wisdom on
>>>this list someone can help me.
>>>
>>>I've got this propietary motif application which uses a propietary
>>>database from which I want to export some data. I can export this data
>>>from the motif gui by selecting the right item from the menu, entering a
>>>filename, etc.
>>>
>>>So my question is is there aay way to record mouse movements and
>>>mousebutton/key presses under X and replay those automaticly, the replay
>>>preferrably under Xvfb?
>>>
>>>Thanks,
>>>
>>>Hans
>>>
>>>--
>>>fedora-devel-list mailing list
>>>fedora-devel-list at redhat.com
>>>http://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>
>>
>>--
>>
>>Nick Bargnesi
>>http://www.den-4.com
>>Den 4 Software
>>
>>pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
>>Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
>>sub  2048g/56C5D45B 2004-12-02
>>
>>
>>
>>--
>>fedora-devel-list mailing list
>>fedora-devel-list at redhat.com
>>http://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
> 
> 



From buildsys at redhat.com  Fri Dec  3 12:48:46 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 3 Dec 2004 07:48:46 -0500
Subject: rawhide report: 20041203 changes
Message-ID: <200412031248.iB3CmkK31933@porkchop.devel.redhat.com>

 

 
Updated Packages:

boost-1.32.0-3
--------------
* Thu Dec 02 2004 Benjamin Kosnik <bkoz at redhat.com> 1.32.0-3
- (#122817: libboost_*.so symlinks missing)
- (#141574: half of the package is missing)
- (#141617: bad patch boost-base.patch)

cups-1:1.1.22-3
---------------
* Thu Dec 02 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.22-3
- Fix ref-before-use bug in debug output (bug #141585).

* Mon Nov 29 2004 Tim Waugh <twaugh at redhat.com>
- Copied "ext" patch over from xpdf RPM package.

docbook-style-xsl-1.67.2-1
--------------------------
* Thu Dec 02 2004 Tim Waugh <twaugh at redhat.com> 1.67.2-1
- 1.67.2.
- No longer need nbsp or listblock patches.

expect-5.42.1-2
---------------
* Fri Dec 03 2004 Jens Petersen <petersen at redhat.com> - 5.42.1-2
- fix "mkpasswd -v" failure when user not specified with
  expect-5.42-mkpasswd-verbose-user-141454.patch (J F Wheeler, 141454)

file-4.12-1
-----------
* Thu Dec 02 2004 Radek Vokal <rvokal at redhat.com> - 4.12-1
- upgrade to file-4.12
- removed Tim's patch, tuned magic patch

foomatic-3.0.2-10
-----------------
* Thu Dec 02 2004 Tim Waugh <twaugh at redhat.com> 3.0.2-10
- Added IEEE 1284 information for HP-Color_Inkjet_Printer_CP1700 (bug #141594).
- Added IEEE 1284 information for Samsung-ML-1720 (bug #141163).
- Added IEEE 1284 information for HP-OfficeJet_G95 (bug #141057).

gaim-1:1.1.0-1
--------------
* Thu Dec 02 2004 Warren Togami <wtogami at redhat.com> 1.1.0-1
- upgrade 1.1.0 (mostly bugfixes)
- fix PIE patch

net-tools-1.60-42
-----------------
* Fri Dec 03 2004 Radek Vokal <rvokal at redhat.com> 1.60-42
- filter out duplicate tcp entries (#139407)

rpmdb-fedora-1:4-0.20041203
---------------------------

selinux-policy-strict-1.19.10-1
-------------------------------
* Thu Dec 02 2004 Dan Walsh <dwalsh at redhat.com> 1.19-10-1
- Update to latest from NSA
- Fix tty devices from IBM Platforms

selinux-policy-targeted-1.19.10-1
---------------------------------
* Thu Dec 02 2004 Dan Walsh <dwalsh at redhat.com> 1.19-10-1
- Update to latest from NSA
- Fix tty devices from IBM Platforms

* Thu Dec 02 2004 Dan Walsh <dwalsh at redhat.com> 1.19-9-1
- Update to add execmem and execmod

sysklogd-1.4.1-24
-----------------
* Thu Dec 02 2004 Jason Vas Dias <jvdias at redhat.com> 1.4.1rh-24
- Allow kernel printk's to emit an odd number of continuous '%'s .
- (#141545)

* Thu Dec 02 2004 Jason Vas Dias <jvdias at redhat.com> 1.4.1rh-24
- Do not allow hostnames that resolve to the address of a local
- interface to be used for forwarding, else syslogd gets into
- an infinite loop sending messages to itself (as reported by
- Chuck Mead <csm at redhat.com>).

* Wed Dec 01 2004 Jason Vas Dias <jvdias at redhat.com> 1.4.1rh-23
- Allow SIGALRM to interrupt system calls, as syslogd expects.
- In Fedora Core, signal(SIGALRM,...) uses SA_RESTART; one is
- required to use siginterrupt() to get interruptable system calls.
- (#140983)

system-config-kickstart-2.5.17-1
--------------------------------
* Thu Dec 02 2004 Chris Lumens <clumens at redhat.com> - 2.5.16-1
- Remove obsolete dependency resolution radio buttons.

tetex-2.0.2-25
--------------
* Wed Dec 01 2004 Dan Walsh <dwalsh at redhat.com> 2.0.2-25
- Fix security context after install

thunderbird-0:1.0-0.rc1.0
-------------------------
* Wed Dec 01 2004 Christopher Aillon <caillon at redhat.com> 1.0-0.rc1.0
- Update to 1.0 rc1

unzip-5.51-6
------------
* Thu Dec 02 2004 Lon Hohberger <lhh at redhat.com> 5.51-6
- Rebuild

* Thu Dec 02 2004 Lon Hohberger <lhh at redhat.com> 5.51-5
- Fix segfault on extraction of symlinks

usermode-1.76-1
---------------
* Thu Dec 02 2004 Jindrich Novy <jnovy at redhat.com> 1.76-1
- fix dependencies to perl-XML-Parser #124170
- use "pamconsole" instead of "user" when parsing /etc/fstab with usermount
- no need to declare "perm" when SELinux is not enabled in userhelper

* Tue Nov 16 2004 Jindrich Novy <jnovy at redhat.com>
- update libuser interface to libuser-0.6

vim-1:6.3.035-2
---------------
* Thu Dec 02 2004 Karsten Hopp <karsten at redhat.de> 6.3.035-2 
- fix compressed docs handling (#141565)

xfce-utils-4.0.6-3
------------------
* Thu Dec 02 2004 Than Ngo <than at redhat.com> 4.0.6-3
- permission fix #141597



From avibrazil at gmail.com  Fri Dec  3 16:08:20 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Fri, 3 Dec 2004 13:08:20 -0300
Subject: UniConfed Elektra released (was: Elektrified X.org released)
In-Reply-To: <20041203010017.GP13588@worldvisions.ca>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<20041130144913.GA15676@devserv.devel.redhat.com>
	<ed0efd31041130071879fbf19d@mail.gmail.com>
	<20041130162338.GA10244@devserv.devel.redhat.com>
	<ed0efd3104113008349b0c47@mail.gmail.com>
	<20041130171728.GB10115@devserv.devel.redhat.com>
	<1101841021.11035.27.camel@support02.civic.twp.ypsilanti.mi.us>
	<ed0efd3104120109333920bd2f@mail.gmail.com>
	<20041203010017.GP13588@worldvisions.ca>
Message-ID: <ed0efd3104120308083897c0e9@mail.gmail.com>

On Thu, 2 Dec 2004 20:00:17 -0500, Avery Pennarun <apenwarr at nit.ca> wrote:
> On Wed, Dec 01, 2004 at 02:33:27PM -0300, Avi Alkalay wrote:
> 
> > The point is: only discussing ideas is very different that writing
> > code. In this last case you'll find issues that destroy entire
> > architectures you built in your head.
> > A single DB file and a deamon was obviously the first reasonable thing
> > to think and to implement, so read bellow.
> 
> Okay, so I kept my word: I spent a couple of hours today writing a UniConf
> frontend for elektra (AKA an elektra backend for UniConf).  This allows any
> elektra-using program to transparently use UniConf instead.

Uh?! That very good news !
I really wanted to see a UniConf backend to Elektra :-)


>  - Apparently x.org is already supported, since Avi has patched it for
>    elektra.  (Technically I didn't try this... just the kdb command-line
>    client.)

Yep. Give it a try.


>  - Elektra has a native C API, for you anti-C++ weenies.
> 
>  - UniConf has a native C++ API, for you anti-C weenies.

We had to do in C due to the project objectives we set.




>  - Elektra's API is somehow worse than the grotesque x.org monstrosity.

:-(
I don't think so....
Well, people have a tendency to like what is its own, and dislike others.
The API is very low level, similar to base OS calls. It has to be this way.



>  - Elektra's API can't do useful notifications except via polling (or
>    "simulated polling" - you at least have to keep calling its poll function
>    to check for changes, rather than it calling you).

Thats because its completely decentralized nature, as far as I can
think about. If you have a daemon you can intercept changes and avoid
polling.



>  - Elektra's notification support needs work.  It should have
>    registration/unregistration and callbacks, not "call this function
>    sometimes to see if anything has changed".  Trust me, I've been through
>    this enough times already.

Hummmm... good idea. Will think about it in the flight I have to take
this afternoon. :-)



>  - The Key data structure should have keyNew and keyFree functions (allocate
>    and deallocate keys), not keyInit and keyClose.  This would allow you to
>    make the data types completely transparent, making your library more
>    ABI-stable.  You'll know you've done it right when there are no more
>    data structure definitions in kdb.h.

Absolut abvious and good idea. How I didn't think about it !
In the end of the flight it will be done.


> Hey, Avi, can you convert apache next?  Or how about samba? :)

Apache is veeeery difficult, but possible. Samba is easy.
But I'm thinking right now to unify KConfig and GConf backends and
global settings namespace. So font, colors, etc global options will be
shared, and a Gnome app will be able to configure a KDE app. I think
you already have it in UniConf, right? I'll look for your sources
soon. After this, I'll probably dive on Samba.


> Have fun,

You too, Avery

Regards,
Avi



From walters at redhat.com  Fri Dec  3 18:33:42 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 03 Dec 2004 13:33:42 -0500
Subject: adventures in booting
In-Reply-To: <20041202234006.GK25551@redhat.com>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102011939.4024.35.camel@nexus.verbum.private>
	<20041202213831.GI25551@redhat.com>
	<1102024790.4024.39.camel@nexus.verbum.private>
	<20041202234006.GK25551@redhat.com>
Message-ID: <1102098822.4390.54.camel@nexus.verbum.private>

On Thu, 2004-12-02 at 18:40 -0500, Daniel Veillard wrote:
> On Thu, Dec 02, 2004 at 04:59:49PM -0500, Colin Walters wrote:
> > On Thu, 2004-12-02 at 16:38 -0500, Daniel Veillard wrote:
> > 
> > >   If the kernel has an atomic rename system call then it can be done
> > > without race, if not that will be a very serious issue.
> > 
> > It has an atomic rename for files; but you can't atomically change a
> > directory that has content.  Or am I missing something?  Not to mention
> > this would break things like RPM verification.
> 
>   I think you're missing something. It is possible to copy the file
> somewhere else and then rename it to the original name,

First, something could change the file while it is being copied.
Second, something could change the file (e.g. delete it) after you've
copied it, but before the rename.  Not to mention that when you are
walking a directory tree, it could have been changed in any way.  

I am worried about a solution like this, because it basically requires
that nothing else touches the entire directory tree while it's
happening.  If you do this late on shutdown, maybe we'd get away with
it.   Was that your plan?




From greg at kroah.com  Fri Dec  3 19:25:19 2004
From: greg at kroah.com (Greg KH)
Date: Fri, 3 Dec 2004 11:25:19 -0800
Subject: /proc/bus/usb ??
In-Reply-To: <45136.12.41.112.51.1101836256.squirrel@webmail.ec-group.com>
References: <45136.12.41.112.51.1101836256.squirrel@webmail.ec-group.com>
Message-ID: <20041203192519.GA3134@kroah.com>

On Tue, Nov 30, 2004 at 11:37:36AM -0600, Brian Millett wrote:
> I'm guessing that I should know this, sorry, but with the last initscripts
> update, I now get a message like
> "can't find /proc/bus/usb in /etc/fstab or /etc/mtab"
> 
> I have googled to see what should be in /etc/fstab and have found four
> variations.
> 
> usbdev /proc/bus/usb usbdevfs defaults 0 0
> usbdevfs /proc/bus/usb usbdevfs noauto 0 0
> none            /proc/bus/usb   usbdevfs defaults       0 0
> /proc/bus/usb           /proc/bus/usb           usbdevfs defaults   0 0
> 
> What should I have?  I do have a /proc/bus/usb that is populated.

The name "usbdevfs" is dead, use "usbfs" instead.  Newer kernels don't
even work with that term.

thanks,

greg k-h



From feliciano.matias at free.fr  Fri Dec  3 20:07:18 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Fri, 03 Dec 2004 21:07:18 +0100
Subject: Splash.xpm.gz
In-Reply-To: <20041202223959.GA3874@imp.flyn.org>
References: <20041202223959.GA3874@imp.flyn.org>
Message-ID: <1102104439.4521.0.camel@one.myworld>

Le jeudi 02 d?cembre 2004 ? 16:39 -0600, W. Michael Petullo a ?crit :
> Why is boot/grub/splash.xpm.gz included in the kernel RPM?

$ rpm -q -f /boot/grub/splash.xpm.gz
fedora-logos-1.1.29-1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041203/b394c214/attachment.sig>

From florin at andrei.myip.org  Fri Dec  3 20:49:02 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Fri, 03 Dec 2004 12:49:02 -0800
Subject: Configuring NFS under Linux for Firewall control
In-Reply-To: <1101996643.21680.30.camel@wombat.tiptoe.de>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101996643.21680.30.camel@wombat.tiptoe.de>
Message-ID: <1102106942.23074.6.camel@stantz.corp.sgi.com>

On Thu, 2004-12-02 at 15:10 +0100, Nils Philippsen wrote:
> On Wed, 2004-12-01 at 13:31 -0600, Jason L Tibbitts III wrote:

> > You have to set the NLM ports in modprobe.conf or on the kernel
> > command line.
> 
> Can you tell us the module options needed for that?

I believe it's something like this:

options lockd nlm_udpport=4001 nlm_tcpport=4001

Anyway, you can check the URL i posted in the first message in this
thread:

http://www.lowth.com/LinWiz/nfs_help.html

-- 
Florin Andrei

http://florin.myip.org/



From j.underwood at open.ac.uk  Sat Dec  4 02:09:33 2004
From: j.underwood at open.ac.uk (Jonathan Underwood)
Date: Sat, 4 Dec 2004 02:09:33 +0000 (GMT)
Subject: Troubles (bug) with control-center
Message-ID: <Pine.LNX.4.61.0412040203080.5521@pasiphae.open.ac.uk>

Hi,

I'm not entirely sure if it's appropriate to bring this problem across to 
here - apologies if not.

I just did a fresh install of FC3 onto a box previously running FC2, 
wiping the root partition, but leaving the/home partition untouched.  On 
using an account that had previously been used under FC2, 
gnome-keybinding-properties and gnome-theme-manager segfault.  However, 
from a new user account created under FC3, these programs function fine. 
So, I deleted .gnome* .gconf* .gtkrc .pan .themes .icons .gstreamer-0.8 
directories from the older account to see if that cleared up the problem. 
No joy.  So then I copied these across from the new (FC3) account, and 
again, no joy. So something seems to be breaking gnome 2.8 for accounts 
previously used under FC2, but it's not clear what. There's a bug report 
that's been open a while on this (Bugzilla 129098). Any insight gratefully 
received.

Thanks,
Jonathan.

ps. please cc me on any replies.



From dag at wieers.com  Sat Dec  4 06:24:23 2004
From: dag at wieers.com (Dag Wieers)
Date: Sat, 4 Dec 2004 07:24:23 +0100 (CET)
Subject: 802.1x support
In-Reply-To: <Pine.LNX.4.61.0412031036580.1750@netcore.fi>
References: <Pine.LNX.4.58.0412021340250.21643@lacrosse.corp.redhat.com>
	<Pine.LNX.4.61.0412031036580.1750@netcore.fi>
Message-ID: <Pine.LNX.4.61.0412040723050.921@horsea.3ti.be>

On Fri, 3 Dec 2004, Pekka Savola wrote:

> On Thu, 2 Dec 2004, Matthew Galgoci wrote:
> > Has anyone given any thought to adding 802.1x support to fc?
> > 
> > Mind you I don't mean exclusively for wireless support, but in general.
> 
> I actually sent a message asking for this a month or two ago..
> 
> Would seem like a good idea to me.  Linux has been lagging behind Windows with
> this respect for a couple of years now.  There are solutions to fix this, but
> they have not been merged with distributions.  FC could be an ideal place to
> start testing this functionality.

And if you require it for RHEL4, it may already be too late.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From byte at aeon.com.my  Sat Dec  4 09:18:37 2004
From: byte at aeon.com.my (Colin Charles)
Date: Sat, 04 Dec 2004 17:18:37 +0800
Subject: Splash.xpm.gz
In-Reply-To: <20041202223959.GA3874@imp.flyn.org>
References: <20041202223959.GA3874@imp.flyn.org>
Message-ID: <1102151917.32089.123.camel@localhost.localdomain>

On Thu, 2004-12-02 at 16:39 -0600, W. Michael Petullo wrote:
> Why is boot/grub/splash.xpm.gz included in the kernel RPM?  Why is it
> not in the grub RPM instead?  The reason I ask is that, when using
> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> Yaboot is used instead of grub on PowerPC.

Its fedora-logos-1.1.29-1, I just installed FC-3 on PowerPC (fresh
install) to make sure

Looks like fedora-logos needs a fix, but the funny thing is, when you
take a look at the fedora-logos.spec file, it has a nice little stub of
information that mentions the /boot/grub/splash.xpm.gz bit should be
ifarch i386, but its not been implemented/changed :)

I guess this is a peril of having fedora-logos as noarch, as opposed to
making it arch-specific
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From ang3l0 at katamail.com  Sat Dec  4 12:02:16 2004
From: ang3l0 at katamail.com (Angelo)
Date: Sat, 04 Dec 2004 13:02:16 +0100
Subject: Additional CDs on Fedora
Message-ID: <41B1A748.6030505@katamail.com>

I was wondering what is the format to create additional CDs for Fedora Core.

Someone here can point me to some kind of documentation about this ?

Thanks in advance.

Regards,
Angelo



From kyrre at solution-forge.net  Sat Dec  4 14:10:18 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Sat, 04 Dec 2004 15:10:18 +0100
Subject: config files obfuscation [was: Configuring NFS under Linux for
	Firewall control]
In-Reply-To: <1101999681.5631.274.camel@wx1.larc.nasa.gov>
References: <1101928668.31463.17.camel@stantz.corp.sgi.com>
	<ufaoehd3jeo.fsf@epithumia.math.uh.edu>
	<1101932004.31463.48.camel@stantz.corp.sgi.com>
	<1101936128.14817.8.camel@berlin.east.gov>
	<1101938575.31463.67.camel@stantz.corp.sgi.com>
	<1101999681.5631.274.camel@wx1.larc.nasa.gov>
Message-ID: <1102169417.2686.7.camel@kyrre>

tor, 02.12.2004 kl. 16.01 skrev Phil Schaffner:
> On Wed, 2004-12-01 at 14:02 -0800, Florin Andrei wrote:
> > On Wed, 2004-12-01 at 16:22 -0500, Paul W. Frields wrote:
> > > I haven't BZ'd this since I wasn't sure if anyone agreed with my
> > > suggestion, but will do so if I can get a second on the motion.
> > 
> > I'm not sure about the details either, but overall this is what i was
> > talking about.
> > Perhaps don't leave the *PORT variables empty, but add sensible
> > values?
> > 
> > -- 
> > Florin Andrei
> 
> Sounded like a second to me.  Consider this an "All in favor say aye.
> Aye!" response.  Very nice start.  Have wished for other files commented
> as well as smb.conf, and agree that every config file should at least
> have a commented template.
> 
> Perhaps a new thread, noting your BZ RFE, and soliciting suggestions (or
> submitting more good examples) for other /etc/... files that deserve
> this treatment is in order.
> 
> Phil
> 

Aye!

Comment'em
vsftpd.conf is also quite good, but is lacking *some* details.



From kyrre at solution-forge.net  Sat Dec  4 14:16:27 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Sat, 04 Dec 2004 15:16:27 +0100
Subject: adventures in booting
In-Reply-To: <1102010395.4024.21.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
Message-ID: <1102169787.2686.9.camel@kyrre>

tor, 02.12.2004 kl. 18.59 skrev Colin Walters:
> On Thu, 2004-12-02 at 12:40 -0500, David Zeuthen wrote:
> 
> > I'm almost positive it requires kernel changes to do this the right way;
> > one naive idea is to have a userspace daemon, capturing what blocks are
> > read when (kernel tells this daemon using the kernel events layer). This
> > would run in the first three minutes on each and every boot. When the
> > system is idle (and only when running on AC power!) another daemon
> > rearranges blocks on the disk. What blocks to rearrange could be the
> > result of a computation involving several three-minute result sets.
> 
> Rearranging sounds complex and dangerous, since it requires deep
> integration with the filesystem.  The online resizing took quite a long
> time to appear and that is conceptually much simpler.  Why not do it on
> the block device layer (without knowledge of the filesystem) and just
> copy those blocks to a reserved area of the block device?  Disks are
> big, duplicating say 100MB for this purpose wouldn't be bad.  We would
> need to ensure that mkfs.ext3 would leave enough space for this though
> (and probably whatever does the copying would have to make sure that the
> filesystem wasn't in the way; perhaps an ext flag).
> 

Hmm... /boot is usually quite "overbig", and must be situated within a
booting (ie. not at the end) part of the disk...



From kyrre at solution-forge.net  Sat Dec  4 14:22:33 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Sat, 04 Dec 2004 15:22:33 +0100
Subject: i486 base architecture
In-Reply-To: <41B03601.3080006@nc.rr.com>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
	<1102035426.3593.3.camel@localhost.localdomain>
	<41AFC110.1090504@nc.rr.com>
	<1102041314.3593.23.camel@localhost.localdomain>
	<41B03601.3080006@nc.rr.com>
Message-ID: <1102170153.2686.12.camel@kyrre>


> The rpm implementation does not control what strings are used to 
> identify arch in packages.
> For example, PLD is using "pentium3", "pentium4", and "amd64" while
> Red Hat is using "i586", "i686" and "x86_64" with essentially the same
> meanings, and all of those strings are being carried in default rpm 
> configuration.

The pentium 3 is definatly a i686 arch... the p2 and pentium pro as
well...



From n3npq at nc.rr.com  Sat Dec  4 15:17:09 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Sat, 04 Dec 2004 10:17:09 -0500
Subject: i486 base architecture
In-Reply-To: <1102170153.2686.12.camel@kyrre>
References: <1101909512.4123.7.camel@localhost.localdomain>
	<1101909736.2640.27.camel@laptop.fenrus.org>
	<41ADD2A0.6050703@nc.rr.com>
	<20041201141933.GA8641@devserv.devel.redhat.com>
	<20041201142647.GA8785@ee.oulu.fi> <41ADD72E.3040000@nc.rr.com>
	<1101917374.13895.3.camel@localhost.localdomain>
	<41ADFA36.4060703@nc.rr.com>
	<1101958666.3585.2.camel@localhost.localdomain>
	<41AE959C.7050903@nc.rr.com> <20041202091730.GA5806@ee.oulu.fi>
	<41AF1BD8.6080305@nc.rr.com>
	<1102035426.3593.3.camel@localhost.localdomain>
	<41AFC110.1090504@nc.rr.com>
	<1102041314.3593.23.camel@localhost.localdomain>
	<41B03601.3080006@nc.rr.com> <1102170153.2686.12.camel@kyrre>
Message-ID: <41B1D4F5.2030904@nc.rr.com>

Kyrre Ness Sjobak wrote:

>>The rpm implementation does not control what strings are used to 
>>identify arch in packages.
>>For example, PLD is using "pentium3", "pentium4", and "amd64" while
>>Red Hat is using "i586", "i686" and "x86_64" with essentially the same
>>meanings, and all of those strings are being carried in default rpm 
>>configuration.
>>    
>>
>
>The pentium 3 is definatly a i686 arch... the p2 and pentium pro as
>well...
>  
>

Right!

But "pentium3" is most definitely not an an "i686" arch for rpm, because 
the strings are not identical,
and because FC and RHEL do not build *.pentium3.rpm packages.

73 de Jeff




From buildsys at redhat.com  Sat Dec  4 18:56:18 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 4 Dec 2004 13:56:18 -0500
Subject: rawhide report: 20041204 changes
Message-ID: <200412041856.iB4IuIc04722@porkchop.devel.redhat.com>



From Bernd.Bartmann at sohanet.de  Sat Dec  4 19:18:46 2004
From: Bernd.Bartmann at sohanet.de (Bernd Bartmann)
Date: Sat, 04 Dec 2004 20:18:46 +0100
Subject: Missing update advisories
In-Reply-To: <41AB9C4A.2040205@sohanet.de>
References: <41A264DE.9090202@sohanet.de>		<604aa7910411221712528be@mail.gmail.com>	<41AB0B53.5060403@sohanet.de>	<604aa791041129065096a1a69@mail.gmail.com>	<41AB3A4F.2030802@sohanet.de>
	<41AB9C4A.2040205@sohanet.de>
Message-ID: <41B20D96.4010704@sohanet.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernd Bartmann wrote:
| To get the ball rolling I've just entered bug reports for all missing
| announcements that were on my list. To get an overview I've also created
| tracker bugs for each FC release:
|
| FC1 bug #141259
| FC2 bug #141258
| FC3 bug #141256
|
| Let's hope this is useful and wakes up some of the package maintainers.
| At least some of them are already answering to the bugs.

Update:

We got a lot of the missing announcements out this week, but some are
still not there and I even had to add some new to the list.

For the future I plan to open a new bug for a missing annoucement two
days after the rpms have appeared on the download mirrors.

Best regards.

- --
Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann at sohanet.de>
I.S. Security and Network Engineer
SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
Fon: +49 30 214783-44 / Fax: +49 30 214783-46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBsg2WkQuIaHu84cIRAsF3AJ41Jp1mD0hm4Qa9S1j6EExOJR5jcgCfd4GE
BdZPrtVyWOOjSPJuFK1eBs0=
=gbb1
-----END PGP SIGNATURE-----



From katzj at redhat.com  Sat Dec  4 22:25:07 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 04 Dec 2004 17:25:07 -0500
Subject: Splash.xpm.gz
In-Reply-To: <1102151917.32089.123.camel@localhost.localdomain>
References: <20041202223959.GA3874@imp.flyn.org>
	<1102151917.32089.123.camel@localhost.localdomain>
Message-ID: <1102199107.3876.14.camel@bree.local.net>

On Sat, 2004-12-04 at 17:18 +0800, Colin Charles wrote:
> Looks like fedora-logos needs a fix, but the funny thing is, when you
> take a look at the fedora-logos.spec file, it has a nice little stub of
> information that mentions the /boot/grub/splash.xpm.gz bit should be
> ifarch i386, but its not been implemented/changed :)
> 
> I guess this is a peril of having fedora-logos as noarch, as opposed to
> making it arch-specific

There's no way to fix it without making fedora-logos arch specific.  And
the value in having it as noarch (and thus the reduced build system
load, mirror space requirements, etc) outweigh the few kilobytes it puts
on people's systems who don't need it

Jeremy



From avibrazil at gmail.com  Sat Dec  4 22:41:37 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Sat, 4 Dec 2004 20:41:37 -0200
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <1101955405.7436.69.camel@Madison.badger.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<20041130144913.GA15676@devserv.devel.redhat.com>
	<ed0efd31041130071879fbf19d@mail.gmail.com>
	<20041130162338.GA10244@devserv.devel.redhat.com>
	<ed0efd3104113008349b0c47@mail.gmail.com>
	<20041130171728.GB10115@devserv.devel.redhat.com>
	<1101841021.11035.27.camel@support02.civic.twp.ypsilanti.mi.us>
	<ed0efd3104120109333920bd2f@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
Message-ID: <ed0efd31041204144172022baf@mail.gmail.com>

On Wed, 01 Dec 2004 21:43:24 -0500, Toshio <toshio at tiki-lounge.com> wrote:
> On Wed, 2004-12-01 at 14:33 -0300, Avi Alkalay wrote:
> > > Definitely.  Elektra still has major short comings (no transactional
> > > guarantees, no notification, no real access control, no temporary
> > > keys... mostly things Elektra can never do since it refuses to use a
> > > daemon), but it's at least a tiny step in teh right direction that might
> > > open some peoples' eyes.
> >
> > Notifications is there already. Check the code.
> 
> Avi, correct me if I'm misinterpretting, but the API docs seem to say
> that Elektra has "monitoring" rather than true notification.
> Notification as it exists in GConf is event driven (which is easy for a
> programmer to use) and reasonably performant.  The monitoring of keys
> that Elektra's API implements places a much higher burden on the
> programmer and seems like it would consume more system resources
> (scanning for changes instead of being notified when a change occurs.)
> 
> If the goal of Elektra truly is every program should use it to config,
> then this is going to need some rethinking because few programmers who
> need notification  (at minimum, desktop apps) will choose the extra work
> involved in Elektra over GConf.  If Elektra is only aiming at the
> current system services which don't change state dynamically (The app
> "resyncs" with its config via restart or reload of all config info
> rather than changing on the fly as each key is modified.)  then it might
> not need true notification... although I think there are system services
> could benefit from notification; it's just that the capablitity to do it
> isn't attractive with the current /etc files scheme.
> 
> -Toshio
> --
> Toshio <toshio at tiki-lounge.com>
> 
> 
> 


The way GConf works is compatible with the layer GConf sits on: It is
high level, (I think) it is integrated with an event driven framework
(Gnome), etc etc.

On the other hand, Elektra is very low level, in the same level as
libc functions. If it was notification instead of monitoring, how it
will notify a program that doesn't have an event loop? One way I can
think is to install a callback and Elektra will create a new thread or
process to wait for changes (remember we aren't in an event loop
context) and call your callback function, but it will work inside a
different thread and it can cause problems to your logic. So the
solution I was able to think is to give you the basics (monitoring),
and based on your program logic, you'll or wait for a change, or wrap
it in a thread context that your program can handle. The way
monitoring is implemented in Elektra is the best I could think for its
descentralized nature.

I'm open for other ideas in this space.

Thank you,
Avi



From ndbecker2 at verizon.net  Sat Dec  4 22:56:35 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Sat, 04 Dec 2004 17:56:35 -0500
Subject: rawhide report: 20041204 changes
References: <200412041856.iB4IuIc04722@porkchop.devel.redhat.com>
Message-ID: <cotfb3$glp$1@sea.gmane.org>

The more things change, the more they stay the same.



From mike at flyn.org  Fri Dec  3 02:30:37 2004
From: mike at flyn.org (W. Michael Petullo)
Date: Thu, 2 Dec 2004 20:30:37 -0600
Subject: Splash.xpm.gz
In-Reply-To: <604aa791041202162165a0a039@mail.gmail.com>
References: <20041202223959.GA3874@imp.flyn.org>
	<604aa791041202162165a0a039@mail.gmail.com>
Message-ID: <20041203023037.GA4207@imp.flyn.org>

>> Why is boot/grub/splash.xpm.gz included in the kernel RPM?  Why is it
>> not in the grub RPM instead?  The reason I ask is that, when using
>> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
>> Yaboot is used instead of grub on PowerPC.
 
> on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
> in the development i386 tree splash.xpm.gz is part of fedora-logos packages
> in fact the version of fedora-logos is the same in fc3 as in
> development at the moment.
> are you really really sure /boot/grub/splash.xpm.gz on your system is
> part of the kernel rpm?

Oops.  Let me rephrase my question why is splash.xpm.gz a part of the
fedora-logos...  Well, that makes a little more sense I suppose (obvious
trademark-type material should not go in GRUB RPM).  Sorry for the
confusion.  I suppose /boot/grub/splash.xpm.gz will remain on my system
while I patiently wait for GRUB 2's Mac support?  I'll concede that a
fedora-logos-grub package would be a bit much.

-- 
Mike

:wq



From thesource at ldb-jab.org  Sun Dec  5 04:43:14 2004
From: thesource at ldb-jab.org (Lawrence Bowie)
Date: Sat, 04 Dec 2004 23:43:14 -0500
Subject: freeglut-2.2.0 packaging
Message-ID: <41B291E2.30007@ldb-jab.org>

Can someone please tell me why freeglut does not include headers?



Name        : freeglut                     Relocations: (not relocatable)
Version     : 2.2.0                             Vendor: Red Hat, Inc.
Release     : 11                            Build Date: Thu 18 Mar 2004 
01:09:33 PM EST
Install Date: Fri 12 Nov 2004 06:13:12 PM EST      Build Host: 
porky.devel.redhat.com
Group       : System Environment/Libraries   Source RPM: 
freeglut-2.2.0-11.src.rpm
Size        : 362403                           License: MIT
Signature   : DSA/SHA1, Thu 06 May 2004 06:18:03 PM EDT, Key ID 
b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://freeglut.sourceforge.net
Summary     : A freely licensed alternative to the GLUT library
Description :
freeglut is a completely open source alternative to the OpenGL Utility 
Toolkit
(GLUT) library with an OSI approved free software license. GLUT was 
originally
written by Mark Kilgard to support the sample programs in the second edition
OpenGL 'RedBook'. Since then, GLUT has been used in a wide variety of 
practical
applications because it is simple, universally available and highly 
portable.

freeglut allows the user to create and manage windows containing OpenGL
contexts on a wide range of platforms and also read the mouse, keyboard and
joystick functions.
/usr/lib/libglut.so.3
/usr/lib/libglut.so.3.8.0
/usr/share/doc/freeglut-2.2.0
/usr/share/doc/freeglut-2.2.0/AUTHORS
/usr/share/doc/freeglut-2.2.0/COPYING
/usr/share/doc/freeglut-2.2.0/ChangeLog
/usr/share/doc/freeglut-2.2.0/INSTALL
/usr/share/doc/freeglut-2.2.0/NEWS
/usr/share/doc/freeglut-2.2.0/README
/usr/share/doc/freeglut-2.2.0/TODO
/usr/share/doc/freeglut-2.2.0/download.html
/usr/share/doc/freeglut-2.2.0/freeglut.html
/usr/share/doc/freeglut-2.2.0/freeglut_logo.png
/usr/share/doc/freeglut-2.2.0/freeglut_user_interface.html
/usr/share/doc/freeglut-2.2.0/index.html
/usr/share/doc/freeglut-2.2.0/ogl_sm.png
/usr/share/doc/freeglut-2.2.0/progress.html
/usr/share/doc/freeglut-2.2.0/structure.html





but yet when I compile it myself I get the following:

freeglut-2.2.0
freeglut-2.2.0/lib
freeglut-2.2.0/lib/libglut.a
freeglut-2.2.0/lib/libglut.so.3.8.0
freeglut-2.2.0/lib/libglut.la
freeglut-2.2.0/lib/libglut.so
freeglut-2.2.0/lib/libglut.so.3
freeglut-2.2.0/include
freeglut-2.2.0/include/GL
freeglut-2.2.0/include/GL/freeglut_ext.h
freeglut-2.2.0/include/GL/freeglut.h
freeglut-2.2.0/include/GL/glut.h
freeglut-2.2.0/include/GL/freeglut_std.h




Is there something wrong with this or is it me??????


Thanks,

LDB



From davej at redhat.com  Sun Dec  5 04:46:23 2004
From: davej at redhat.com (Dave Jones)
Date: Sat, 4 Dec 2004 23:46:23 -0500
Subject: freeglut-2.2.0 packaging
In-Reply-To: <41B291E2.30007@ldb-jab.org>
References: <41B291E2.30007@ldb-jab.org>
Message-ID: <20041205044623.GB19262@redhat.com>

On Sat, Dec 04, 2004 at 11:43:14PM -0500, Lawrence Bowie wrote:
 > Can someone please tell me why freeglut does not include headers?

they're in the freeglut-devel package.

		Dave
 



From thesource at ldb-jab.org  Sun Dec  5 04:51:50 2004
From: thesource at ldb-jab.org (Lawrence Bowie)
Date: Sat, 04 Dec 2004 23:51:50 -0500
Subject: freeglut-2.2.0 packaging
In-Reply-To: <20041205044623.GB19262@redhat.com>
References: <41B291E2.30007@ldb-jab.org> <20041205044623.GB19262@redhat.com>
Message-ID: <41B293E6.1010502@ldb-jab.org>

Why not just package them with freeglut? .. it is a library by 
definition anyway.

Thanks,

LDB

Dave Jones wrote:

>On Sat, Dec 04, 2004 at 11:43:14PM -0500, Lawrence Bowie wrote:
> > Can someone please tell me why freeglut does not include headers?
>
>they're in the freeglut-devel package.
>
>		Dave
> 
>
>  
>



From jspaleta at gmail.com  Sun Dec  5 05:55:42 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 5 Dec 2004 00:55:42 -0500
Subject: freeglut-2.2.0 packaging
In-Reply-To: <41B293E6.1010502@ldb-jab.org>
References: <41B291E2.30007@ldb-jab.org> <20041205044623.GB19262@redhat.com>
	<41B293E6.1010502@ldb-jab.org>
Message-ID: <604aa79104120421553e9fc6cd@mail.gmail.com>

On Sat, 04 Dec 2004 23:51:50 -0500, Lawrence Bowie
<thesource at ldb-jab.org> wrote:
> Why not just package them with freeglut? .. it is a library by
> definition anyway.

Because you don't need the headers on a system where you aren't
compiling...and headers for all the libraries in Core add up to a lot
of unneeded cruft on systems not meant to do development/compiling on.

-jef"yum list *-devel   is a fun command"spaleta



From symbiont at berlios.de  Sun Dec  5 14:57:42 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Sun, 5 Dec 2004 22:57:42 +0800
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <ed0efd31041204144172022baf@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
Message-ID: <200412052257.42528.symbiont@berlios.de>

On Sunday 05 December 2004 06:41, Avi Alkalay wrote:
>  If it was notification instead of monitoring, how it
> will notify a program that doesn't have an event loop?

What about gamin?  And then reload the appropriate config upon 
alteration.

-- 
-jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041205/0d1a89bf/attachment.sig>

From avibrazil at gmail.com  Sun Dec  5 15:13:02 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Sun, 5 Dec 2004 12:13:02 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <200412052257.42528.symbiont@berlios.de>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
Message-ID: <ed0efd31041205071313951a32@mail.gmail.com>

I'm having a look at inotify, which is the basis for gamin.

Thank you,
Avi


On Sun, 5 Dec 2004 22:57:42 +0800, Jeff Pitman <symbiont at berlios.de> wrote:
> On Sunday 05 December 2004 06:41, Avi Alkalay wrote:
> >  If it was notification instead of monitoring, how it
> > will notify a program that doesn't have an event loop?
> 
> What about gamin?  And then reload the appropriate config upon
> alteration.
> 
> --
> -jeff
>



From elanthis at awesomeplay.com  Sun Dec  5 17:57:30 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Sun, 05 Dec 2004 12:57:30 -0500
Subject: Elektrified X.org released (was: X configuration paradigm, and
 a proposal)
In-Reply-To: <ed0efd31041205071313951a32@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>	<1101955405.7436.69.camel@Madison.badger.com>	<ed0efd31041204144172022baf@mail.gmail.com>	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
Message-ID: <41B34C0A.7030104@awesomeplay.com>

Avi Alkalay wrote:

>I'm having a look at inotify, which is the basis for gamin.
>  
>

Don't tie your code to inotify, tie it to something like gamin.  Gamin 
can abstract away the different OS interfaces, so that machines without 
inotify will still have some form of notification (dnotify, polling, 
whatever).  There's no good reason to reimplement that code yourself.



From buildsys at redhat.com  Sun Dec  5 18:48:15 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 5 Dec 2004 13:48:15 -0500
Subject: rawhide report: 20041205 changes
Message-ID: <200412051848.iB5ImFm05965@porkchop.devel.redhat.com>

 

 
Updated Packages:

firefox-0:1.0-4
---------------
* Fri Dec 03 2004 Christopher Aillon <caillon at redhat.com> 0:1.0-4
- Add StartupWMClass patch from Damian Christey (#135830)
- Use system colors by default (#137810)
- Re-add s390(x)

* Sat Nov 20 2004 Christopher Blizzard <blizzard at redhat.com> 0:1.0-3
- Add patch that uses pango for selection.

rpmdb-fedora-1:4-0.20041205
---------------------------

rsh-0.17-26
-----------
* Sat Dec 04 2004 Karel Zak <kzak at redhat.com> 0.17-26
- "-D" option turns off reverse DNS in rexecd (#135827)

tree-1.5.0-2
------------
* Sun Dec 05 2004 Florian La Roche <laroche at redhat.com>
- add quotes around CPPFLAGS



From avibrazil at gmail.com  Sun Dec  5 19:17:36 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Sun, 5 Dec 2004 16:17:36 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <41B34C0A.7030104@awesomeplay.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
	<41B34C0A.7030104@awesomeplay.com>
Message-ID: <ed0efd31041205111711d4e097@mail.gmail.com>

On Sun, 05 Dec 2004 12:57:30 -0500, Sean Middleditch
<elanthis at awesomeplay.com> wrote:
> Avi Alkalay wrote:
> 
> >I'm having a look at inotify, which is the basis for gamin.
> >
> >
> 
> Don't tie your code to inotify, tie it to something like gamin.  Gamin
> can abstract away the different OS interfaces, so that machines without
> inotify will still have some form of notification (dnotify, polling,
> whatever).  There's no good reason to reimplement that code yourself.

Yeah I know.... I'll try to stick in the high level, but I'm worried
about dependencies. It makes no sense to have /lib/libkdb.so depending
on libs under /usr/lib.

The 5 minutes I spent reading about inotify made me believe it is a
kernel module, but I couldn't find it, nor the /dev entry, nor the
dmesg messages in the FC2 machine I have close to me right now. Is
this stuff already included in regular distros kernels ?

I'm still studing all of this....

Regards,
Avi



From elanthis at awesomeplay.com  Sun Dec  5 22:03:29 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Sun, 05 Dec 2004 17:03:29 -0500
Subject: Elektrified X.org released (was: X configuration paradigm, and
 a proposal)
In-Reply-To: <ed0efd31041205111711d4e097@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>	<1101955405.7436.69.camel@Madison.badger.com>	<ed0efd31041204144172022baf@mail.gmail.com>	<200412052257.42528.symbiont@berlios.de>	<ed0efd31041205071313951a32@mail.gmail.com>	<41B34C0A.7030104@awesomeplay.com>
	<ed0efd31041205111711d4e097@mail.gmail.com>
Message-ID: <41B385B1.1010706@awesomeplay.com>

Avi Alkalay wrote:

>On Sun, 05 Dec 2004 12:57:30 -0500, Sean Middleditch
><elanthis at awesomeplay.com> wrote:
>  
>
>>Avi Alkalay wrote:
>>
>>    
>>
>>>I'm having a look at inotify, which is the basis for gamin.
>>>
>>>
>>>      
>>>
>>Don't tie your code to inotify, tie it to something like gamin.  Gamin
>>can abstract away the different OS interfaces, so that machines without
>>inotify will still have some form of notification (dnotify, polling,
>>whatever).  There's no good reason to reimplement that code yourself.
>>    
>>
>
>Yeah I know.... I'll try to stick in the high level, but I'm worried
>about dependencies. It makes no sense to have /lib/libkdb.so depending
>on libs under /usr/lib.
>  
>
That does make sense, good point.

>The 5 minutes I spent reading about inotify made me believe it is a
>kernel module, but I couldn't find it, nor the /dev entry, nor the
>dmesg messages in the FC2 machine I have close to me right now. Is
>this stuff already included in regular distros kernels ?
>  
>
It's a patch, not a module.  it will, eventually, be part of the 
mainline kernel, but at the moment, you have to patch it in yourself.  
Or you can grab pre-patched kernels - for example, if you're running 
Netware Linux Desktop, RML has some patched kernel RPMS here: 
http://primates.ximian.com/~rml/kernel-rml/nld-9-i586/?C=N;O=A

>I'm still studing all of this....
>
>Regards,
>Avi
>
>  
>



From notting at redhat.com  Sat Dec  4 16:51:59 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 4 Dec 2004 11:51:59 -0500
Subject: adventures in booting
In-Reply-To: <1102169787.2686.9.camel@kyrre>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz>
	<20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
	<1102169787.2686.9.camel@kyrre>
Message-ID: <20041204165159.GA1633@nostromo.devel.redhat.com>

Kyrre Ness Sjobak (kyrre at solution-forge.net) said: 
> Hmm... /boot is usually quite "overbig", and must be situated within a
> booting (ie. not at the end) part of the disk...

Sure, just have mkinitrd have the *entire* filesystem image
on the initrd... :)

Bill



From byte at aeon.com.my  Mon Dec  6 04:21:11 2004
From: byte at aeon.com.my (Colin Charles)
Date: Mon, 06 Dec 2004 12:21:11 +0800
Subject: Splash.xpm.gz
In-Reply-To: <20041203023037.GA4207@imp.flyn.org>
References: <20041202223959.GA3874@imp.flyn.org>
	<604aa791041202162165a0a039@mail.gmail.com>
	<20041203023037.GA4207@imp.flyn.org>
Message-ID: <1102306871.32089.236.camel@localhost.localdomain>

On Thu, 2004-12-02 at 20:30 -0600, W. Michael Petullo wrote:

> Oops.  Let me rephrase my question why is splash.xpm.gz a part of the
> fedora-logos...  Well, that makes a little more sense I suppose (obvious
> trademark-type material should not go in GRUB RPM).  Sorry for the
> confusion.  I suppose /boot/grub/splash.xpm.gz will remain on my system
> while I patiently wait for GRUB 2's Mac support?  I'll concede that a
> fedora-logos-grub package would be a bit much.

Yes, you do however have better luck as we release a testing tree of
Fedora Core 3 so get all excited

And as Jeremy said, its probably a good idea to make fedora-logos *not*
arch specific
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From kjetil at fribyte.uib.no  Mon Dec  6 11:15:54 2004
From: kjetil at fribyte.uib.no (Kjetil =?ISO-8859-1?Q?Nyg=E5rd?=)
Date: Mon, 06 Dec 2004 12:15:54 +0100
Subject: Wine/Cedega and fedora 3
Message-ID: <1102331754.3973.11.camel@localhost.localdomain>

I tried to install cedega from Transgaming yesterday. But I could not
start it until I followed the instructions in their manual and did the
following changes to my Fedora install
1. Removed prelinking 
   (Think it should have been enough to remove "exec-shield")
2. echo 1>/proc/sys/vm/legacy_va_layout

Is it possible to change these in fedora so that users doesn't have to
do this themselves?



-- 
Kjetil Nyg?rd
Tlf: +47 41 47 43 37



From kjetil at fribyte.uib.no  Mon Dec  6 11:21:54 2004
From: kjetil at fribyte.uib.no (Kjetil =?ISO-8859-1?Q?Nyg=E5rd?=)
Date: Mon, 06 Dec 2004 12:21:54 +0100
Subject: Kudzu and automatic detection
Message-ID: <1102332114.3973.18.camel@localhost.localdomain>

In my office I have a printer which I don't have at home. And everytime
I come to the office, kudzu want to "configure" the printer. And when I
come home, it want to remove the printer again.

I also noticed that if I plugged the printer after starting the machine,
and kudzu has not configured my printer, the printer works just fine.

So I wonder if this is an unnecessary kudzu-configuration which should
be fixed?

My printer is a HP laserjet 2200dn connected through USB. I run Fedora
Core 3, and of cause CUPS is the printer daemon.

-- 
Kjetil Nyg?rd
Tlf: +47 41 47 43 37



From mandreiana at rdslink.ro  Mon Dec  6 11:39:18 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Mon, 06 Dec 2004 13:39:18 +0200
Subject: Kudzu and automatic detection
In-Reply-To: <1102332114.3973.18.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
Message-ID: <1102333158.3633.11.camel@marte.biciclete.ro>

On Mon, 2004-12-06 at 12:21 +0100, Kjetil Nyg?rd wrote:
> So I wonder if this is an unnecessary kudzu-configuration which should
> be fixed?
There's nothing to fix, kudzu properly removes/adds printer.
After adding, you can disable kudzu (run ntsysv), so it won't run
anymore. You can run it manually when needed: service kudzu start

-- 
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro



From mandreiana at rdslink.ro  Mon Dec  6 11:40:40 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Mon, 06 Dec 2004 13:40:40 +0200
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102331754.3973.11.camel@localhost.localdomain>
References: <1102331754.3973.11.camel@localhost.localdomain>
Message-ID: <1102333240.3633.13.camel@marte.biciclete.ro>

On Mon, 2004-12-06 at 12:15 +0100, Kjetil Nyg?rd wrote:
> 1. Removed prelinking 
>    (Think it should have been enough to remove "exec-shield")
> 2. echo 1>/proc/sys/vm/legacy_va_layout
> 
> Is it possible to change these in fedora so that users doesn't have to
> do this themselves?
No, most of us use prelink. I use it and wine works too. See wine bugs
with prelink for fixing wine.

-- 
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro



From jos at xos.nl  Mon Dec  6 12:14:24 2004
From: jos at xos.nl (Jos Vos)
Date: Mon, 06 Dec 2004 13:14:24 +0100
Subject: Thunderbird 1.0rc: XML Parsing error
Message-ID: <200412061214.iB6CEOt24948@xos037.xos.nl>

Hi,

When I select Preferences -> Advanced in Thunderbird 1.0rc I see a

  XML Parsing Error: not well-formed
  Location: chrome://messenger/content/pref-advanced.xul
  Line number 208, Column 5:

This is after rebuilding the src.rpm on RHEL3 (with a few tweaks),
so I'm now wondering if this also happens on FC3.  Anyone?

Thanks,

--
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From caillon at redhat.com  Mon Dec  6 12:30:04 2004
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 06 Dec 2004 07:30:04 -0500
Subject: Thunderbird 1.0rc: XML Parsing error
In-Reply-To: <200412061214.iB6CEOt24948@xos037.xos.nl>
References: <200412061214.iB6CEOt24948@xos037.xos.nl>
Message-ID: <41B450CC.9040106@redhat.com>

Jos Vos wrote:
> Hi,
> 
> When I select Preferences -> Advanced in Thunderbird 1.0rc I see a
> 
>   XML Parsing Error: not well-formed
>   Location: chrome://messenger/content/pref-advanced.xul
>   Line number 208, Column 5:
> 
> This is after rebuilding the src.rpm on RHEL3 (with a few tweaks),
> so I'm now wondering if this also happens on FC3.  Anyone?

Try bugzilla.  ;)

141899.  Should be fixed by tomorrorw.



From alan at redhat.com  Mon Dec  6 13:52:21 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Dec 2004 08:52:21 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102331754.3973.11.camel@localhost.localdomain>
References: <1102331754.3973.11.camel@localhost.localdomain>
Message-ID: <20041206135221.GB22035@devserv.devel.redhat.com>

On Mon, Dec 06, 2004 at 12:15:54PM +0100, Kjetil Nyg?rd wrote:
> 1. Removed prelinking 
>    (Think it should have been enough to remove "exec-shield")
> 2. echo 1>/proc/sys/vm/legacy_va_layout

Or to put it another way "disabled security to make buggy application
software work"

> Is it possible to change these in fedora so that users doesn't have to
> do this themselves?

When put differently it sounds a bad idea to me. Perhaps Transgaming could
lookg into why their software is making memory layout and exec assumptions
(assuming they haven't already of course) ? If it is tripping a real bug it
would be useful to know

Alan



From johnp at redhat.com  Mon Dec  6 13:56:24 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 08:56:24 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102332114.3973.18.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
Message-ID: <1102341384.18495.9.camel@localhost.localdomain>

On Mon, 2004-12-06 at 06:21, Kjetil Nyg?rd wrote:
> In my office I have a printer which I don't have at home. And everytime
> I come to the office, kudzu want to "configure" the printer. And when I
> come home, it want to remove the printer again.
> 
> I also noticed that if I plugged the printer after starting the machine,
> and kudzu has not configured my printer, the printer works just fine.
> 
> So I wonder if this is an unnecessary kudzu-configuration which should
> be fixed?
> 
> My printer is a HP laserjet 2200dn connected through USB. I run Fedora
> Core 3, and of cause CUPS is the printer daemon.
> 

I would just disable kudzu.  HAL handles hotplug printing now.  Perhaps
we should turn off the printing module in Kudzu for FC4.



From johnp at redhat.com  Mon Dec  6 14:00:52 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 09:00:52 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102331754.3973.11.camel@localhost.localdomain>
References: <1102331754.3973.11.camel@localhost.localdomain>
Message-ID: <1102341652.18495.14.camel@localhost.localdomain>

On Mon, 2004-12-06 at 06:15, Kjetil Nyg?rd wrote:
> I tried to install cedega from Transgaming yesterday. But I could not
> start it until I followed the instructions in their manual and did the
> following changes to my Fedora install
> 1. Removed prelinking 
>    (Think it should have been enough to remove "exec-shield")
> 2. echo 1>/proc/sys/vm/legacy_va_layout
> 
> Is it possible to change these in fedora so that users doesn't have to
> do this themselves?

These are bug with the way Cedega works.  Changing Fedora to work around
a program's bugs would be wrong.  Cedrega should be fixed.

> 
> -- 
> Kjetil Nyg?rd
> Tlf: +47 41 47 43 37



From dpaun at rogers.com  Mon Dec  6 14:53:59 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 09:53:59 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041206135221.GB22035@devserv.devel.redhat.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
Message-ID: <20041206145359.GB13664@rogers.com>

On Mon, Dec 06, 2004 at 08:52:21AM -0500, Alan Cox wrote:
> When put differently it sounds a bad idea to me. Perhaps Transgaming could
> lookg into why their software is making memory layout and exec assumptions
> (assuming they haven't already of course) ? If it is tripping a real bug it
> would be useful to know

Don't forget that it's not always possible to fix the broken app.
In this case, Wine/Cedega are trying to run binary Windows apps
that expect a certain layout. They may have their relocation record
stripped, and on.

-- 
Dimi.



From jspaleta at gmail.com  Mon Dec  6 15:00:11 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 6 Dec 2004 10:00:11 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102341384.18495.9.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102341384.18495.9.camel@localhost.localdomain>
Message-ID: <604aa7910412060700306166f4@mail.gmail.com>

On Mon, 06 Dec 2004 08:56:24 -0500, John (J5) Palmieri <johnp at redhat.com> wrote:
> I would just disable kudzu.  HAL handles hotplug printing now.  Perhaps
> we should turn off the printing module in Kudzu for FC4.

I personally have a poor understanding of the functionality split
between kudzu and hal now.
Maybe we need an assessment of the overlap not just for printers but
in a general view.
-jef



From johnp at redhat.com  Mon Dec  6 15:07:36 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 10:07:36 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <604aa7910412060700306166f4@mail.gmail.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102341384.18495.9.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
Message-ID: <1102345656.18495.28.camel@localhost.localdomain>

On Mon, 2004-12-06 at 10:00, Jeff Spaleta wrote:
> On Mon, 06 Dec 2004 08:56:24 -0500, John (J5) Palmieri <johnp at redhat.com> wrote:
> > I would just disable kudzu.  HAL handles hotplug printing now.  Perhaps
> > we should turn off the printing module in Kudzu for FC4.
> 
> I personally have a poor understanding of the functionality split
> between kudzu and hal now.
> Maybe we need an assessment of the overlap not just for printers but
> in a general view.
> -jef

That would be a good idea.  The hope is that one day we can move Kudzu
to use HAL's detection code.  It was a bit early when I replied before
but now that I think about it I remember why I didn't ask for Kudzu to
drop the printer detection module.  HAL handles hotplug devices but can
not handle static devices like those attached to parallel and com ports.
We can't just yet assume that legacy devices don't exist anymore so
taking it out of Kudzu would have been a regression.  We might be able
to tell Kudzu to ignore USB and Firewire devices.

--
J5



From nphilipp at redhat.com  Mon Dec  6 15:10:24 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 06 Dec 2004 16:10:24 +0100
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041206145359.GB13664@rogers.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<20041206145359.GB13664@rogers.com>
Message-ID: <1102345824.18601.14.camel@wombat.tiptoe.de>

On Mon, 2004-12-06 at 09:53 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 06, 2004 at 08:52:21AM -0500, Alan Cox wrote:
> > When put differently it sounds a bad idea to me. Perhaps Transgaming could
> > lookg into why their software is making memory layout and exec assumptions
> > (assuming they haven't already of course) ? If it is tripping a real bug it
> > would be useful to know
> 
> Don't forget that it's not always possible to fix the broken app.
> In this case, Wine/Cedega are trying to run binary Windows apps
> that expect a certain layout. They may have their relocation record
> stripped, and on.

I'm at a loss why we should use less secure defaults to accommodate the
proprietary Cedega running (likely) proprietary Windows applications.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From bgerst at didntduck.org  Mon Dec  6 15:13:05 2004
From: bgerst at didntduck.org (Brian Gerst)
Date: Mon, 06 Dec 2004 10:13:05 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041206135221.GB22035@devserv.devel.redhat.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
Message-ID: <41B47701.40905@didntduck.org>

Alan Cox wrote:

> On Mon, Dec 06, 2004 at 12:15:54PM +0100, Kjetil Nyg?rd wrote:
> 
>>1. Removed prelinking 
>>   (Think it should have been enough to remove "exec-shield")
>>2. echo 1>/proc/sys/vm/legacy_va_layout
> 
> 
> Or to put it another way "disabled security to make buggy application
> software work"
> 
> 
>>Is it possible to change these in fedora so that users doesn't have to
>>do this themselves?
> 
> 
> When put differently it sounds a bad idea to me. Perhaps Transgaming could
> lookg into why their software is making memory layout and exec assumptions
> (assuming they haven't already of course) ? If it is tripping a real bug it
> would be useful to know
> 
> Alan
> 

Wine (and derivatives) is sensitive to the VM layout because Windows 
binaries demand a specific virtual address range.  Many of these 
binaries are stripped and therefore non-relocatable.  The problem is 
that the new VM layout puts the libraries there, and Wine has no 
opportunity to tell the ELF loader that it needs that virtual address 
range free for its own use.  "setarch i386 -L wine ..." should work to 
disable exec-shield and legacy VM layout for just Wine, but the 
prelinked libraries will still load at the exec-shield address because 
there is no address range conflict at startup.  There needs to be a way 
to disable prelinked libraries for specific processes at execve time, so 
the libraries load at the "legacy" address range for that process.

Alternately, there needs to be a way for the ELF format to declare an 
address range as off-limits to the ELF loader.

--
				Brian Gerst



From elanthis at awesomeplay.com  Mon Dec  6 15:14:21 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Mon, 06 Dec 2004 10:14:21 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102345824.18601.14.camel@wombat.tiptoe.de>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<20041206145359.GB13664@rogers.com>
	<1102345824.18601.14.camel@wombat.tiptoe.de>
Message-ID: <1102346062.2159.2.camel@support02.civic.twp.ypsilanti.mi.us>

On Mon, 2004-12-06 at 16:10 +0100, Nils Philippsen wrote:
> On Mon, 2004-12-06 at 09:53 -0500, Dimitrie O. Paun wrote:
> > On Mon, Dec 06, 2004 at 08:52:21AM -0500, Alan Cox wrote:
> > > When put differently it sounds a bad idea to me. Perhaps Transgaming could
> > > lookg into why their software is making memory layout and exec assumptions
> > > (assuming they haven't already of course) ? If it is tripping a real bug it
> > > would be useful to know
> > 
> > Don't forget that it's not always possible to fix the broken app.
> > In this case, Wine/Cedega are trying to run binary Windows apps
> > that expect a certain layout. They may have their relocation record
> > stripped, and on.
> 
> I'm at a loss why we should use less secure defaults to accommodate the
> proprietary Cedega running (likely) proprietary Windows applications.

We shouldn't.  If the change needs to be made, Cedega should _offer_ to
change it for the user at install time.  There are *many* good reasons
to run proprietary apps - generally when people want to actually use
their computers, which is why most of us own one, and there aren't
capable Free versions of everything.  But sacrificing security for
everyone when it can be modified only for the users that need it is
silly.

> 
> Nils
> -- 
>      Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
> "They that can give up essential liberty to obtain a little temporary
>  safety deserve neither liberty nor safety."     -- B. Franklin, 1759
>  PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From jakub at redhat.com  Mon Dec  6 15:21:06 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 6 Dec 2004 10:21:06 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <41B47701.40905@didntduck.org>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<41B47701.40905@didntduck.org>
Message-ID: <20041206152106.GE10340@devserv.devel.redhat.com>

On Mon, Dec 06, 2004 at 10:13:05AM -0500, Brian Gerst wrote:
> there is no address range conflict at startup.  There needs to be a way 
> to disable prelinked libraries for specific processes at execve time, so 
> the libraries load at the "legacy" address range for that process.

There is no separate set of prelinked and non-prelinked libraries.
You can tell the dynamic linker to not honor the chosen library addresses
by setting LD_USE_LOAD_BIAS=0 in the environment of the program where you
need that.
But this doesn't affect kernel's placement of the binary (unless it is
a PIE this is hardcoded no matter what) and ld.so.
To prevent ld.so from being placed at certain addresses you can
put an p_flags = 0 PT_LOAD segment covering the range you want to reserve
into the wine executable, or do what wine does for several months already,
i.e. have statically linked program that does kernel's job of mapping
the binary and the dynamic linker into the address space and giving control
to the dynamic linker.

	Jakub



From alan at redhat.com  Mon Dec  6 15:23:30 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Dec 2004 10:23:30 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041206145359.GB13664@rogers.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<20041206145359.GB13664@rogers.com>
Message-ID: <20041206152330.GA29975@devserv.devel.redhat.com>

On Mon, Dec 06, 2004 at 09:53:59AM -0500, Dimitrie O. Paun wrote:
> Don't forget that it's not always possible to fix the broken app.
> In this case, Wine/Cedega are trying to run binary Windows apps
> that expect a certain layout. They may have their relocation record
> stripped, and on.

It is for reasons like this that mmap has MAP_FIXED.



From jos at xos.nl  Mon Dec  6 15:27:07 2004
From: jos at xos.nl (Jos Vos)
Date: Mon, 06 Dec 2004 16:27:07 +0100
Subject: Thunderbird 1.0 and Enigmail
Message-ID: <200412061527.iB6FR7u25957@xos037.xos.nl>

Hi,

Any chance to get Enigmail back, either in the Thunderbird 1.0 rpm
or as an additional Fedora (non-extras) package?

Enigmail is said to have a version for Thunderbird 1.0 now.  IIRC
it was once removed because of a maintenance nightmare, maybe this
problem disappears after the official release of Thunderbird?

Thanks,

--
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From alan at redhat.com  Mon Dec  6 15:30:10 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Dec 2004 10:30:10 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <41B47701.40905@didntduck.org>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<41B47701.40905@didntduck.org>
Message-ID: <20041206153010.GC29975@devserv.devel.redhat.com>

On Mon, Dec 06, 2004 at 10:13:05AM -0500, Brian Gerst wrote:
> binaries are stripped and therefore non-relocatable.  The problem is 
> that the new VM layout puts the libraries there, and Wine has no 
> opportunity to tell the ELF loader that it needs that virtual address 

An application can use its own ELF loader (or a modified one), or static
link a tiny stub app that reserves the memory it needs. It's really only luck
that they've avoided this in the past.




From bgerst at didntduck.org  Mon Dec  6 15:31:46 2004
From: bgerst at didntduck.org (Brian Gerst)
Date: Mon, 06 Dec 2004 10:31:46 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041206152330.GA29975@devserv.devel.redhat.com>
References: <1102331754.3973.11.camel@localhost.localdomain>	<20041206135221.GB22035@devserv.devel.redhat.com>	<20041206145359.GB13664@rogers.com>
	<20041206152330.GA29975@devserv.devel.redhat.com>
Message-ID: <41B47B62.9060508@didntduck.org>

Alan Cox wrote:
> On Mon, Dec 06, 2004 at 09:53:59AM -0500, Dimitrie O. Paun wrote:
> 
>>Don't forget that it's not always possible to fix the broken app.
>>In this case, Wine/Cedega are trying to run binary Windows apps
>>that expect a certain layout. They may have their relocation record
>>stripped, and on.
> 
> 
> It is for reasons like this that mmap has MAP_FIXED.
> 

The problem isn't mmap.  By the time Wine starts up the ELF loader has 
already taken the virtual address range Wine needs.

--
				Brian Gerst



From nbargnesi at gmail.com  Mon Dec  6 15:41:25 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Mon, 6 Dec 2004 10:41:25 -0500
Subject: JFS Filesystems?
Message-ID: <3077b8a00412060741f0be14a@mail.gmail.com>

Hey guys,
    I've got some high-end Athlon 64 workstations that I'd like to
use JFS exclusively on.  These machines have 8 hard drives in them six
of which are on SATA channels.  Attempting to install FC3 by booting
with "linux jfs" results in my being able to format drives using JFS.
However, after the package selection when it goes to install chkconfig
(second rpm I believe?), it fails with a complaint about installing
chkconfig due to a disc or hard drive error, or bad media, etc.  I get
the sense this is directly related to the JFS configuration though, if
I attempt to do the identical setup on ext3 partitions, everything
works flawlessly.
    I was however able to install FC3 on these machines using a root
partition of ext3 and jfs partitions not directly related to the FC3
directory structure, i.e., /opt, and some backup mount points.  I've
read about trying "linux jfs selinux=0" as jfs won't mingle with
selinux, which I haven't done yet.  Curious to see if anyone else is
using non-ext filesystems and experienced/gotten past this.  Or to
smack me upside the head and say selinux=0 should do it...
Regards,
Nick Bargnesi

-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From sds at epoch.ncsc.mil  Mon Dec  6 15:49:00 2004
From: sds at epoch.ncsc.mil (Stephen Smalley)
Date: Mon, 06 Dec 2004 10:49:00 -0500
Subject: JFS Filesystems?
In-Reply-To: <3077b8a00412060741f0be14a@mail.gmail.com>
References: <3077b8a00412060741f0be14a@mail.gmail.com>
Message-ID: <1102348140.23475.140.camel@moss-spartans.epoch.ncsc.mil>

On Mon, 2004-12-06 at 10:41, Nick Bargnesi wrote:
>     I was however able to install FC3 on these machines using a root
> partition of ext3 and jfs partitions not directly related to the FC3
> directory structure, i.e., /opt, and some backup mount points.  I've
> read about trying "linux jfs selinux=0" as jfs won't mingle with
> selinux, which I haven't done yet.  Curious to see if anyone else is
> using non-ext filesystems and experienced/gotten past this.  Or to
> smack me upside the head and say selinux=0 should do it...

IBM just posted a JFS patch this morning to the selinux mailing list
that they said allows them to use SELinux with JFS on FC3.  They said
that they are submitting it upstream soon, so hopefully SELinux and JFS
will play nicely with each other in the not-so-distant future.  Also
requires a small patch to the policy configuration to tell SELinux that
it should try using xattrs on jfs for file contexts.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency



From dpaun at rogers.com  Mon Dec  6 16:13:51 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 11:13:51 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102333158.3633.11.camel@marte.biciclete.ro>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
Message-ID: <20041206161351.GC13664@rogers.com>

On Mon, Dec 06, 2004 at 01:39:18PM +0200, Marius Andreiana wrote:
> On Mon, 2004-12-06 at 12:21 +0100, Kjetil Nyg?rd wrote:
> > So I wonder if this is an unnecessary kudzu-configuration which should
> > be fixed?
> There's nothing to fix, kudzu properly removes/adds printer.

Of course there is, what do you mean "kudzu properly removes/adds printer".
This is silly, once it's added and configured, it shouldn't remove/add
it on every reboot!

> After adding, you can disable kudzu (run ntsysv), so it won't run
> anymore. You can run it manually when needed: service kudzu start

If I *manually" have to do stuff, it's broken.

-- 
Dimi.



From dpaun at rogers.com  Mon Dec  6 16:36:54 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 11:36:54 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102345824.18601.14.camel@wombat.tiptoe.de>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041206135221.GB22035@devserv.devel.redhat.com>
	<20041206145359.GB13664@rogers.com>
	<1102345824.18601.14.camel@wombat.tiptoe.de>
Message-ID: <20041206163654.GD13664@rogers.com>

On Mon, Dec 06, 2004 at 04:10:24PM +0100, Nils Philippsen wrote:
> I'm at a loss why we should use less secure defaults to accommodate the
> proprietary Cedega running (likely) proprietary Windows applications.

I'm not advocating changing the default, I just wanted to highlight
the point that sometimes (in particular with app like Wine that must
provide another environment), things are hard to fix.

-- 
Dimi.



From ndbecker2 at verizon.net  Mon Dec  6 16:55:10 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Mon, 06 Dec 2004 11:55:10 -0500
Subject: xorg-x11-deprecated-libs yum problem
Message-ID: <cp22te$ps8$1@sea.gmane.org>

This is on FC3 x86_64.

>yum update
Error: Missing Dependency: xorg-x11-deprecated-libs is needed by package
xorg-x11-deprecated-libs-devel
Error: Missing Dependency: xorg-x11-devel is needed by package
xorg-x11-deprecated-libs-devel




From jspaleta at gmail.com  Mon Dec  6 16:54:46 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 6 Dec 2004 11:54:46 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <20041206161351.GC13664@rogers.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
Message-ID: <604aa79104120608545687bd21@mail.gmail.com>

On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> Of course there is, what do you mean "kudzu properly removes/adds printer".
> This is silly, once it's added and configured, it shouldn't remove/add
> it on every reboot!

If a piece of hardware is no longer available, shouldn't it be unconfigured?
Certainly you don't want the printer server to pretend a printer is
available locally when it isn't...that's certaintly not the ideal
behavior.  In a perfect world... the automation provided in the
project utopia software stack (udev,hal, etc...) would be able to
sense the existance of all hardware and automate the configuation and
unconfiguration as soon as any device is attached or detached. But
some hardware can't be sensed yet in the scope of the udev/hal
stack....yet, leaving a place for a boot time hardware
probing/polling/poking application like kudzu (or discover) to try to
handle the hardware that can not be sensed inside the project utopia
stack, in an effort to crudely duplicate what udev/hal would be doing.
In the perfect solution, unconfiguration wouldn't be limited to
bootup.. it would happen anytime the device was removed from the
system. This is what happens when udev/hal works correctly..and what
kudzu has to try to emulate at bootup.

> If I *manually" have to do stuff, it's broken.

If i have to manually reconfigure settings to suit my prefences...
things are broken?
So when I ask gnome to turn my lower panel into a autohiding
panel...that means gnome is broken? I didn't realize that the computer
could read my thoughts.

The issue isn't whether or not you have to "manually" reconfigure your
computer to suit your individual preferences. The issue is, does the
default behavior make sense for the designed for usage case.  I think
its perfectly reasonable for kudzu to be unconfiguring printers such
as parallel port printers and other hardware that the project utopia
stack can not deal with. I think its debatable about whether kudzu
should be ignoring them or not... but i don't see any broken
behavior.. i see at most duplication of similar behavior..that is NOT
causing an operational problem. For usb devices the uptopia software
stack wll be doing pretty much the same thing... unconfiguration
printers when not available...configuring printers where then they
are, but in a more sophisticated way.  I see no brokenness in the
original post, I see overlapping but yet compatible functionality
during a transitional period when udev/hal is being introduced into
the system.

-jef



From Nicolas.Mailhot at laPoste.net  Mon Dec  6 17:04:25 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 18:04:25 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <604aa79104120608545687bd21@mail.gmail.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
Message-ID: <1102352665.5801.10.camel@ulysse.olympe.o2t>

Le lundi 06 d?cembre 2004 ? 11:54 -0500, Jeff Spaleta a ?crit :
> On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> > Of course there is, what do you mean "kudzu properly removes/adds printer".
> > This is silly, once it's added and configured, it shouldn't remove/add
> > it on every reboot!
> 
> If a piece of hardware is no longer available, shouldn't it be unconfigured?

1. The piece of hardware should be marked unavailable
2. The sysadmin preferences should be stored
3. on new plug-in old preferences should be restored.

Given that modern buses like USB provide manufacturer, model and serial
number forgetting everything we know about a device every time it's shut
down (because powering down is sufficient for kudzu/hal to kill prefs)
is not acceptable.

I DO NOT WANT TO CHANGE MY PRITER DPI EVERY F* TIME IT'S POWERED UP !

(sorry for being emotional)

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/3f32ad61/attachment.sig>

From aaron.bennett at olin.edu  Mon Dec  6 17:16:16 2004
From: aaron.bennett at olin.edu (Aaron Bennett)
Date: Mon, 06 Dec 2004 12:16:16 -0500
Subject: status of Extras for Fedora Core 3
Message-ID: <41B493E0.7010407@olin.edu>

Hello,

I've been looking through the Fedora.us website as well as 
fedora.redhat.com for some information about when Fedora Extras will be 
built for FC3, or when it will be available, and I can't find anything.

Am I missing something?  
http://mirrors.kernel.org/fedora.us/fedora/fedora/3/i386/RPMS.extras/ is 
empty and the README says "This repository is replicated only for the 
convenience of apt users.  yum/up2date users should use Red Hat's 
download.fedora.redhat.com mirrors."  So I looked all through 
download.fedora.redhat.com and can't find anything either regarding Extras.

Livna.org has a set of FC3 rpms.  What's going on with Fedora.us? 


-- 
Aaron Bennett
UNIX Administrator
Franklin W. Olin College of Engineering




From jspaleta at gmail.com  Mon Dec  6 17:20:53 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 6 Dec 2004 12:20:53 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102352665.5801.10.camel@ulysse.olympe.o2t>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<1102352665.5801.10.camel@ulysse.olympe.o2t>
Message-ID: <604aa79104120609202a643cc0@mail.gmail.com>

On Mon, 06 Dec 2004 18:04:25 +0100, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> 1. The piece of hardware should be marked unavailable
> 2. The sysadmin preferences should be stored
> 3. on new plug-in old preferences should be restored.

And... does hal do this any better at the moment.. without "manual"
reconfiguration of hal policy?  And can't you "manually" reconfigure
the saved-state that kudzu uses?  I very much hope that someone will
develop tools to help creating local hal/kudzu policy for devices to
ease local system admin burden when reconfiguring devices when the
defaults do not work. You are speaking to a more general problem than
the original poster was describing.

-jef"as soon as you get emotional publicly, the chance that this
public discussion will be constructive decreases a great deal...and
i'm more than willing to push your buttons and watch your head
explode...but i'd prefer to do it in another forum where the
entertainment value of bloodsports is widely appreciated"spaleta



From caillon at redhat.com  Mon Dec  6 17:34:30 2004
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 06 Dec 2004 12:34:30 -0500
Subject: Thunderbird 1.0 and Enigmail
In-Reply-To: <200412061527.iB6FR7u25957@xos037.xos.nl>
References: <200412061527.iB6FR7u25957@xos037.xos.nl>
Message-ID: <41B49826.2010408@redhat.com>

Jos Vos wrote:
> Hi,
> 
> Any chance to get Enigmail back, either in the Thunderbird 1.0 rpm
> or as an additional Fedora (non-extras) package?
> 
> Enigmail is said to have a version for Thunderbird 1.0 now.  IIRC
> it was once removed because of a maintenance nightmare, maybe this
> problem disappears after the official release of Thunderbird?

The problem will always exist as long as they are not maintained by the 
same people and thus on different release cycles.  The basic nightmare 
is: new release by mozilla, enigmail is broken until a new release of 
it.  Generally, this is fairly quick, but it is unreliable, and when 
time becomes important (say for security updates), you can see where 
this becomes a problem.

I would very much applaud and offer what assistance I can to an effort 
to get Enigmail integrated into Mozilla Thunderbird's source, as I think 
that is the ideal solution here.



From krconnolly at mindspring.com  Mon Dec  6 17:34:20 2004
From: krconnolly at mindspring.com (Kevin Connolly)
Date: Mon, 6 Dec 2004 12:34:20 -0500 (GMT-05:00)
Subject: Default Desktop Manager
Message-ID: <23228324.1102354460609.JavaMail.root@wamui08.slb.atl.earthlink.net>

In the older versions of RH there was an option to switch the default desktop manager and it would save that particular preference by user.
I just, as of yesterday, brought up FC3 coming from rH7.3 with KDE as the choice manager (and no Gnome). Currently, the system is pointed to another rudimentary manager as default. Any way to change this through a conf. file anf if so which one?.....better yet if there's a place to point and click to

Aside: I have a combo CD/CDburner/DVD. I remember that when I installed rh7.3 there were some overlap device issues that I corrected by symbolically linking the DVD device to the CDrom. Would this be the same in FC3?

Thanks


BTW - Coming from 7.3 I see alot of nice changes to the system. Kudos to the team




From johnp at redhat.com  Mon Dec  6 17:38:57 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 12:38:57 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102352665.5801.10.camel@ulysse.olympe.o2t>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<1102352665.5801.10.camel@ulysse.olympe.o2t>
Message-ID: <1102354736.18495.39.camel@localhost.localdomain>

On Mon, 2004-12-06 at 12:04, Nicolas Mailhot wrote:
> Le lundi 06 d?cembre 2004 ? 11:54 -0500, Jeff Spaleta a ?crit :
> > On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> > > Of course there is, what do you mean "kudzu properly removes/adds printer".
> > > This is silly, once it's added and configured, it shouldn't remove/add
> > > it on every reboot!
> > 
> > If a piece of hardware is no longer available, shouldn't it be unconfigured?
> 
> 1. The piece of hardware should be marked unavailable
> 2. The sysadmin preferences should be stored
> 3. on new plug-in old preferences should be restored.
> 
> Given that modern buses like USB provide manufacturer, model and serial
> number 

They all don't.  But if they do HAL does configure the device
automatically.

> forgetting everything we know about a device every time it's shut
> down (because powering down is sufficient for kudzu/hal to kill prefs)
> is not acceptable.
> 
> I DO NOT WANT TO CHANGE MY PRITER DPI EVERY F* TIME IT'S POWERED UP !

I don't see a bug on this in bugzilla.  Rule of thumb is if it is not
filed in bugzilla it is not going to get fixed.  This is why we have the
test releases and rawhide.  Please file a bug on hal-cups-utils.

> (sorry for being emotional)

These threads often go off topic and become ignored when emotion comes
into them.  Thanks.

--
J5



From ssahni at gmail.com  Mon Dec  6 17:41:36 2004
From: ssahni at gmail.com (Simarjeet Sahni)
Date: Mon, 6 Dec 2004 12:41:36 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <604aa79104120608545687bd21@mail.gmail.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
Message-ID: <45b47df304120609417a598266@mail.gmail.com>

On Mon, 6 Dec 2004 11:54:46 -0500, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> > Of course there is, what do you mean "kudzu properly removes/adds printer".
> > This is silly, once it's added and configured, it shouldn't remove/add
> > it on every reboot!
> 
> If a piece of hardware is no longer available, shouldn't it be unconfigured?
> Certainly you don't want the printer server to pretend a printer is
> available locally when it isn't...that's certaintly not the ideal
> behavior.  In a perfect world... the automation provided in the
> project utopia software stack (udev,hal, etc...) would be able to
> sense the existance of all hardware and automate the configuation and
> unconfiguration as soon as any device is attached or detached. But
> some hardware can't be sensed yet in the scope of the udev/hal
> stack....yet, leaving a place for a boot time hardware
> probing/polling/poking application like kudzu (or discover) to try to
> handle the hardware that can not be sensed inside the project utopia
> stack, in an effort to crudely duplicate what udev/hal would be doing.
> In the perfect solution, unconfiguration wouldn't be limited to
> bootup.. it would happen anytime the device was removed from the
> system. This is what happens when udev/hal works correctly..and what
> kudzu has to try to emulate at bootup.

I agree, the device should be unavailabe if it has been removed,
however, its related user configured properties should not.

> 
> > If I *manually" have to do stuff, it's broken.
> 
> If i have to manually reconfigure settings to suit my prefences...
> things are broken?
> So when I ask gnome to turn my lower panel into a autohiding
> panel...that means gnome is broken? I didn't realize that the computer
> could read my thoughts.
> 

It doesn't need to read my mind, it just needs to not mess with it. If
you manually configure things, you are enforcing your choice on the
system.  So if you have to manually reconfigure the lower panel to
autohide every time you restart gnome, you'd understand the point. 
Your preferences should be held as configuration of choice.

However, going back to the context of the previous comment, manually
starting and stopping system services to limit the systems ability to
manage change is a bad thing.

> The issue isn't whether or not you have to "manually" reconfigure your
> computer to suit your individual preferences. The issue is, does the
> default behavior make sense for the designed for usage case.  I think
> its perfectly reasonable for kudzu to be unconfiguring printers such
> as parallel port printers and other hardware that the project utopia
> stack can not deal with. I think its debatable about whether kudzu
> should be ignoring them or not... but i don't see any broken
> behavior.. i see at most duplication of similar behavior..that is NOT
> causing an operational problem. For usb devices the uptopia software
> stack wll be doing pretty much the same thing... unconfiguration
> printers when not available...configuring printers where then they
> are, but in a more sophisticated way.  I see no brokenness in the
> original post, I see overlapping but yet compatible functionality
> during a transitional period when udev/hal is being introduced into
> the system.
> 

Its perfectly reasonable to expect kudzu or any other service not to
mess with you choices. Your decisions matter more for your system.

-- 
Regards,

Simarjeet Sahni



From dpaun at rogers.com  Mon Dec  6 17:49:59 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 12:49:59 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <604aa79104120608545687bd21@mail.gmail.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
Message-ID: <20041206174959.GE13664@rogers.com>

On Mon, Dec 06, 2004 at 11:54:46AM -0500, Jeff Spaleta wrote:
> On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> > Of course there is, what do you mean "kudzu properly removes/adds printer".
> > This is silly, once it's added and configured, it shouldn't remove/add
> > it on every reboot!
> 
> If a piece of hardware is no longer available, shouldn't it be unconfigured?

I don't know about that, and really I don't much care about unconfiguring
stuff. My understanding of the original post was that kudzu would try to
reconfigure the printer on every reboot, which is simply foobared.

Now, I have seen this a few times on my boxes:
  kudzu: your XYZ have been removed from your system. Remove configuration?
  me: eh, yes?
  kudzu: your XYZ have been added to your system. Configure device?
  me: why, you little...!

I don't care about some deep technical discussion on why this makes sense,
becuase it just doesn't.

And no, I don't think you should unconfigure anything. Just remember the
config, maybe use it next time you plug in the device.

> > If I *manually" have to do stuff, it's broken.
> 
> If i have to manually reconfigure settings to suit my prefences...
> things are broken?

Yes, if you have to do it every time you start your box.
Imagine if your had to reconfigure your desktop every time
you started X.

-- 
Dimi.



From guhvies at gmail.com  Mon Dec  6 18:02:05 2004
From: guhvies at gmail.com (ne...)
Date: Mon, 6 Dec 2004 13:02:05 -0500
Subject: Default Desktop Manager
In-Reply-To: <23228324.1102354460609.JavaMail.root@wamui08.slb.atl.earthlink.net>
References: <23228324.1102354460609.JavaMail.root@wamui08.slb.atl.earthlink.net>
Message-ID: <a227b70c04120610023b0c40ef@mail.gmail.com>

On Mon, 6 Dec 2004 12:34:20 -0500 (GMT-05:00), Kevin Connolly
<krconnolly at mindspring.com> wrote:
> In the older versions of RH there was an option to switch the default desktop manager and it would save that particular preference by user.
> I just, as of yesterday, brought up FC3 coming from rH7.3 with KDE as the choice manager (and no Gnome). Currently, the system is pointed to another rudimentary manager as default. Any way to change this through a conf. file anf if so which one?.....better yet if there's a place to point and click to
It is still the same: switchdesk kde


> Aside: I have a combo CD/CDburner/DVD. I remember that when I installed rh7.3 there were some overlap device issues that I corrected by symbolically linking the DVD device to the CDrom. Would this be the same in FC3?
Don't know but now these are found in /media as opposed to /mnt.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard. 
http://www.thespark.com/bastardtest



From rdieter at math.unl.edu  Mon Dec  6 18:08:39 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 06 Dec 2004 12:08:39 -0600
Subject: Default Desktop Manager
In-Reply-To: <23228324.1102354460609.JavaMail.root@wamui08.slb.atl.earthlink.net>
References: <23228324.1102354460609.JavaMail.root@wamui08.slb.atl.earthlink.net>
Message-ID: <41B4A027.3040206@math.unl.edu>

Kevin Connolly wrote:
> In the older versions of RH there was an option to switch the default desktop manager and it would save that particular preference by user.
> I just, as of yesterday, brought up FC3 coming from rH7.3 with KDE as the choice manager (and no Gnome). Currently, the system is pointed to another rudimentary manager as default. Any way to change this through a conf. file anf if so which one?.....better yet if there's a place to point and click to

It's controlled via /etc/sysconfig/desktop

To make KDE the default desktop environment, set
DESKTOP=KDE

To use KDE's kdm loginmanager, instead of gdm, set
DISPLAYMANAGER=KDE

Then either drop to runlevel 3 and back to 5 or reboot (simply 
restarting X isn't enough).

-- Rex



From krconnolly at mindspring.com  Mon Dec  6 18:14:38 2004
From: krconnolly at mindspring.com (Kevin Connolly)
Date: Mon, 6 Dec 2004 13:14:38 -0500 (GMT-05:00)
Subject: Default Desktop Manager
Message-ID: <32827997.1102356879053.JavaMail.root@wamui08.slb.atl.earthlink.net>

Thanks Rex.

I kind of like the logon screen, but I'll check out KDE's as well




From Nicolas.Mailhot at laPoste.net  Mon Dec  6 18:22:30 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 19:22:30 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <20041206174959.GE13664@rogers.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<20041206174959.GE13664@rogers.com>
Message-ID: <1102357351.16895.9.camel@rousalka.dyndns.org>

Le lundi 06 d?cembre 2004 ? 12:49 -0500, Dimitrie O. Paun a ?crit :
> On Mon, Dec 06, 2004 at 11:54:46AM -0500, Jeff Spaleta wrote:
> > On Mon, 6 Dec 2004 11:13:51 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> > > Of course there is, what do you mean "kudzu properly removes/adds printer".
> > > This is silly, once it's added and configured, it shouldn't remove/add
> > > it on every reboot!
> > 
> > If a piece of hardware is no longer available, shouldn't it be unconfigured?
> 
> I don't know about that, and really I don't much care about unconfiguring
> stuff. My understanding of the original post was that kudzu would try to
> reconfigure the printer on every reboot, which is simply foobared.
> 
> Now, I have seen this a few times on my boxes:
>   kudzu: your XYZ have been removed from your system. Remove configuration?
>   me: eh, yes?
>   kudzu: your XYZ have been added to your system. Configure device?
>   me: why, you little...!
> 
> I don't care about some deep technical discussion on why this makes sense,
> becuase it just doesn't.

1. it does if you don't want do do lot of coding
2. it doesn't from a normal user point of view
3. as a result kudzu won't be installed on any serious rawhide system
because it is plain annoying (just like the up2date applet we've been
discussing some weeks ago)
4. therefore it won't be tested

Rawhide is a testing ground for FC & RHEL. However to be tested it needs
to be dogfoodable. Numerous past and present examples (selinux, up2date,
kudzu, hal auto printer) show Rawhide users just disable the parts that
get too annoying (and this include RedHat people themselves).

> Yes, if you have to do it every time you start your box.
> Imagine if your had to reconfigure your desktop every time
> you started X.

For printers autodetection it's worse. My printer is shut down a lot
more often that my system. As a result, I've long since disable all the
automated stuff (kudzu, cups hal...) that made me loose 5 min every time
I touched the printer power button.

Cheers,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/d2f45943/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Mon Dec  6 18:30:09 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 19:30:09 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <1102354736.18495.39.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<1102352665.5801.10.camel@ulysse.olympe.o2t>
	<1102354736.18495.39.camel@localhost.localdomain>
Message-ID: <1102357809.16895.16.camel@rousalka.dyndns.org>

Le lundi 06 d?cembre 2004 ? 12:38 -0500, John (J5) Palmieri a ?crit :

> I don't see a bug on this in bugzilla.  Rule of thumb is if it is not
> filed in bugzilla it is not going to get fixed.  This is why we have the
> test releases and rawhide.  Please file a bug on hal-cups-utils.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119970

And yes the problem evolved somewhat since the bug was filled. The
number of steps to perform to get the printer operational after power-up
has shrunk a bit. But the autodetected hal printer is still pretty
useless - if I hadn't created my own printer setup (with a different
name than the HAL one else HAL would just nuke it) I couldn't print
without going into system-config-printer every single time the printer
is powered up.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/a835f0d3/attachment.sig>

From jspaleta at gmail.com  Mon Dec  6 18:40:52 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 6 Dec 2004 13:40:52 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <20041206174959.GE13664@rogers.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<20041206174959.GE13664@rogers.com>
Message-ID: <604aa79104120610404be28b50@mail.gmail.com>

On Mon, 6 Dec 2004 12:49:59 -0500, Dimitrie O. Paun <dpaun at rogers.com> wrote:
> I don't know about that, and really I don't much care about unconfiguring
> stuff. My understanding of the original post was that kudzu would try to
> reconfigure the printer on every reboot, which is simply foobared.

thats not what i read.... i would ask you to read the original post
again. The original poster has a situation where they boot at home and
at work.... work has the printer... home does not. I see nothing in
that post that suggest kudzu is asking to remove AND configure the
printer on the same bootup.

> 
> Now, I have seen this a few times on my boxes:
> kudzu: your XYZ have been removed from your system. Remove configuration?
> me: eh, yes?
> kudzu: your XYZ have been added to your system. Configure device?
> me: why, you little...!

You filed a bug about this detailing the specific devices this happens with?
I have ONE device out of seven usb devices that exhibits this
behavior... its a usb scanner... and i have a bug open about it. My
gut tells me this is because my scanner is being seen as both an sg
managed device as well as libusb managed, and kudzu is trying to deal
with the multiple aspects of usb-ness.  But this is not what the
original post is about at all.

> I don't care about some deep technical discussion on why this makes sense,
> becuase it just doesn't.

That's unfortunate since unexpected hardware problems tend to be about
"technical" issues, and it helps immensely if the reporter is open to
working with developers and learning about where the "technical"
problems lie. Hopefully someone else more inclined to discussing the
problems you are seeing will have your hardware will report in on
bugzilla.

> Yes, if you have to do it every time you start your box.
> Imagine if your had to reconfigure your desktop every time
> you started X.

Are you saying that you can't "manually" change the rules kudzu and
hal use? perhaps you just aren't aware of how.

-jef



From johnp at redhat.com  Mon Dec  6 18:54:51 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 13:54:51 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102357809.16895.16.camel@rousalka.dyndns.org>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<1102352665.5801.10.camel@ulysse.olympe.o2t>
	<1102354736.18495.39.camel@localhost.localdomain>
	<1102357809.16895.16.camel@rousalka.dyndns.org>
Message-ID: <1102359290.18495.65.camel@localhost.localdomain>

On Mon, 2004-12-06 at 13:30, Nicolas Mailhot wrote:
> Le lundi 06 d?cembre 2004 ? 12:38 -0500, John (J5) Palmieri a ?crit :
> 
> > I don't see a bug on this in bugzilla.  Rule of thumb is if it is not
> > filed in bugzilla it is not going to get fixed.  This is why we have the
> > test releases and rawhide.  Please file a bug on hal-cups-utils.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119970
> 
> And yes the problem evolved somewhat since the bug was filled. The
> number of steps to perform to get the printer operational after power-up
> has shrunk a bit. But the autodetected hal printer is still pretty
> useless - if I hadn't created my own printer setup (with a different
> name than the HAL one else HAL would just nuke it) I couldn't print
> without going into system-config-printer every single time the printer
> is powered up.

That bug is before my time.  HAL has come in to fix what you have been
experiencing and *should* work out of the box for most printers.  Why it
doesn't work for you even though it sets the queue up for you is all
together different.  Please file a new bug or reassign the current bug
to the hal-cups-config module with the precise steps you take to print a
document. Thanks.

--
J5



From dpaun at rogers.com  Mon Dec  6 19:00:08 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 14:00:08 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <604aa79104120610404be28b50@mail.gmail.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<20041206174959.GE13664@rogers.com>
	<604aa79104120610404be28b50@mail.gmail.com>
Message-ID: <20041206190008.GF13664@rogers.com>

On Mon, Dec 06, 2004 at 01:40:52PM -0500, Jeff Spaleta wrote:
> thats not what i read.... i would ask you to read the original post
> again. The original poster has a situation where they boot at home and
> at work.... work has the printer... home does not. I see nothing in
> that post that suggest kudzu is asking to remove AND configure the
> printer on the same bootup.

Maybe you are right, I must have misread the post. But in an ideal 
world even that should work (by saving the config) wihtout the pain 
to reconfigure the printer every time it's recycled.

> > Now, I have seen this a few times on my boxes:
> > kudzu: your XYZ have been removed from your system. Remove configuration?
> > me: eh, yes?
> > kudzu: your XYZ have been added to your system. Configure device?
> > me: why, you little...!
> 
> You filed a bug about this detailing the specific devices this happens with?

No, I must admit. On the other hand, I reboot so seldomly, that I don't
normally care. And now I no longer have that issue, I've just seen it
a few times myself.

> Are you saying that you can't "manually" change the rules kudzu and
> hal use? perhaps you just aren't aware of how.

What I'm saying is that if I need to manually tweak some obscure rules
to get decent behaviour out of my system, somethings is broken. Badly.

-- 
Dimi.



From Nicolas.Mailhot at laPoste.net  Mon Dec  6 19:15:40 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 20:15:40 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <1102359290.18495.65.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<1102352665.5801.10.camel@ulysse.olympe.o2t>
	<1102354736.18495.39.camel@localhost.localdomain>
	<1102357809.16895.16.camel@rousalka.dyndns.org>
	<1102359290.18495.65.camel@localhost.localdomain>
Message-ID: <1102360542.16895.32.camel@rousalka.dyndns.org>

Le lundi 06 d?cembre 2004 ? 13:54 -0500, John (J5) Palmieri a ?crit :
> On Mon, 2004-12-06 at 13:30, Nicolas Mailhot wrote:
> > Le lundi 06 d?cembre 2004 ? 12:38 -0500, John (J5) Palmieri a ?crit :
> > 
> > > I don't see a bug on this in bugzilla.  Rule of thumb is if it is not
> > > filed in bugzilla it is not going to get fixed.  This is why we have the
> > > test releases and rawhide.  Please file a bug on hal-cups-utils.
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119970
> > 
> > And yes the problem evolved somewhat since the bug was filled. The
> > number of steps to perform to get the printer operational after power-up
> > has shrunk a bit. But the autodetected hal printer is still pretty
> > useless - if I hadn't created my own printer setup (with a different
> > name than the HAL one else HAL would just nuke it) I couldn't print
> > without going into system-config-printer every single time the printer
> > is powered up.
> 
> That bug is before my time.  HAL has come in to fix what you have been
> experiencing and *should* work out of the box for most printers.  Why it
> doesn't work for you even though it sets the queue up for you is all
> together different. 

When I filled the bug the system didn't set up a new queue for the
printer when it was powered on *and* the old system-config-printer queue
didn't work anymore because somehow the printer device was changing
and/or cups didn't believe the printer was available again without doing
strong vodoo in system-config-printer.

Now the system can set up a new hal queue *and* the old manual one is
still working without major user intervention. So I use the manual
queue. I must admit I didn't try the hal queue lately (synonymous with
wasted paper so far) but last time I did every time I powered up the
printer HAL recreated a "default" queue for the model and forgot all my
old paper/dpi/economode/driver choices (this is a printer that can do
both PCL & PS, foomatic suggests PCL because a sister model can only do
PCL and the foomatic authors are afraid of user errors, but PS print
quality is much better) 

> Please file a new bug or reassign the current bug
> to the hal-cups-config module with the precise steps you take to print a
> document. Thanks.

Will try to do it next saturday. Don't have time to do a clean job
before.

Cheers,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/de7c28e7/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Mon Dec  6 19:19:23 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 20:19:23 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <20041206190008.GF13664@rogers.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102333158.3633.11.camel@marte.biciclete.ro>
	<20041206161351.GC13664@rogers.com>
	<604aa79104120608545687bd21@mail.gmail.com>
	<20041206174959.GE13664@rogers.com>
	<604aa79104120610404be28b50@mail.gmail.com>
	<20041206190008.GF13664@rogers.com>
Message-ID: <1102360763.16895.35.camel@rousalka.dyndns.org>

Le lundi 06 d?cembre 2004 ? 14:00 -0500, Dimitrie O. Paun a ?crit :
> On Mon, Dec 06, 2004 at 01:40:52PM -0500, Jeff Spaleta wrote:

> > Are you saying that you can't "manually" change the rules kudzu and
> > hal use? perhaps you just aren't aware of how.
> 
> What I'm saying is that if I need to manually tweak some obscure rules
> to get decent behaviour out of my system, somethings is broken. Badly.

Yep. Standard admin answer : 
/sbin/chkconfig --level 0123456 kudzu off (very good for boot times too)

Which does explain why kudzu does not get all the rawhide testing it
could.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/aad67795/attachment.sig>

From mattwhiteley at gmail.com  Mon Dec  6 19:13:11 2004
From: mattwhiteley at gmail.com (matt whiteley)
Date: Mon, 6 Dec 2004 11:13:11 -0800
Subject: Thunderbird 1.0 and Enigmail
In-Reply-To: <41B49826.2010408@redhat.com>
References: <200412061527.iB6FR7u25957@xos037.xos.nl>
	<41B49826.2010408@redhat.com>
Message-ID: <72ae109c0412061113118eb689@mail.gmail.com>

On Mon, 06 Dec 2004 12:34:30 -0500, Christopher Aillon
<caillon at redhat.com> wrote:
> The problem will always exist as long as they are not maintained by the
> same people and thus on different release cycles.  The basic nightmare
> is: new release by mozilla, enigmail is broken until a new release of
> it.  Generally, this is fairly quick, but it is unreliable, and when
> time becomes important (say for security updates), you can see where
> this becomes a problem.
> 
> I would very much applaud and offer what assistance I can to an effort
> to get Enigmail integrated into Mozilla Thunderbird's source, as I think
> that is the ideal solution here.

Makes a lot of sense, and I am not familiar with the mozilla code base
so this may be an ignorant question. When I download the thunderbird
build from mozilla, I can then install engimail in it as a user. When
I install the fedora rpm, I cannot install this same xpi file. It
makes sense to me that enigmail cannot be easily shipped in Fedora but
can the rpm be built so as to allow me to install it as a user in
~/.thunderbird/blah.default/extensions ?

Is this already possible, and I am just doing something wrong?

-- 
matt whiteley <mattwhiteley at gmail.com>



From smooge at gmail.com  Mon Dec  6 19:22:32 2004
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Mon, 6 Dec 2004 12:22:32 -0700
Subject: Thunderbird 1.0 and Enigmail
In-Reply-To: <41B49826.2010408@redhat.com>
References: <200412061527.iB6FR7u25957@xos037.xos.nl>
	<41B49826.2010408@redhat.com>
Message-ID: <80d7e40904120611226cf09d2d@mail.gmail.com>

On Mon, 06 Dec 2004 12:34:30 -0500, Christopher Aillon
<caillon at redhat.com> wrote:
> Jos Vos wrote:
> > Hi,
> >
> > Any chance to get Enigmail back, either in the Thunderbird 1.0 rpm
> > or as an additional Fedora (non-extras) package?
> >
> > Enigmail is said to have a version for Thunderbird 1.0 now.  IIRC
> > it was once removed because of a maintenance nightmare, maybe this
> > problem disappears after the official release of Thunderbird?
> 
> The problem will always exist as long as they are not maintained by the
> same people and thus on different release cycles.  The basic nightmare
> is: new release by mozilla, enigmail is broken until a new release of
> it.  Generally, this is fairly quick, but it is unreliable, and when
> time becomes important (say for security updates), you can see where
> this becomes a problem.
> 
> I would very much applaud and offer what assistance I can to an effort
> to get Enigmail integrated into Mozilla Thunderbird's source, as I think
> that is the ideal solution here.
> 
> 

And the fact that the Enigmail or Mozilla people do not advertise it
as an extension for Thunderbird when you look for extensions does not
help any. I think this is an issue where people contact the Enigmail
upstream, find out what the problem is, and see if it can be fixed.

> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From Nicolas.Mailhot at laPoste.net  Mon Dec  6 19:39:02 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 20:39:02 +0100
Subject: JPackage 1.6
Message-ID: <1102361942.16895.47.camel@rousalka.dyndns.org>

[This is a repost of the 19 november announce on JPackage lists. Since
JPackage serves is the upstream of numerous of FC Java packages I was
asked to echo it on FC-related rpm lists. Many thanks to Paul Nasrat for
the original announcement]

The JPackage Project http://www.jpackage.org/ is pleased to announce a
new release.  Upgrading should be a simple matter of pointing your
preferred depsolver at a mirror documented at
http://www.jpackage.org/repos.php

Since JPackage 1.5, the team has grown thanks to vendor interest and we
will continue providing packaging java packages, and we hope to have
some more exciting news soon.

JPackage will continue to host a devel repository for future large
changes. Please update your preferred depsolver to point to the 1.6
repositories as documented:

http://www.jpackage.org/repos.php

[ You will usually need the generic & distro-specific repository. Devel
is for testers ]

Thanks once more to all the contributors and users

Highlights
==========

Ant 1.6.2 is one of the biggest highlights, along with having maven and
lots of updated packages.


Contribuors
===========

In no particular order JPackage is:

* Ralph Apel
* Gary Benson
* Pete Chown
* Leonid Dubinsky
* Thomas Fitzsimmons
* Henri Gomez
* Sonja Krause-Harder
* Goulven Le Jeune
* Nicolas Mailhot
* Paul Nasrat
* Fernando Nasser
* Kaj J. Niemi
* Robert Ottenhag
* Jens Skripczynski
* Ville Skytt?
* Sebastiano Vigna
* David Walluck
* Christian Zoffoli

Thanks
======

In addition thanks to Randy Walter for Ant 1.6.X work and Carwyn Edwards
for work on the 1.5 JDK.

As always we wish to thank the community for all their contributions and
work.

Notes
=====

JPackage no longer supports or distributes Java SDK version 1.3. The
version of the Java SDK supported in this release is 1.4. Java SDK
1.5 from Sun is also provided in the non-free section.

Removed from free (5 packages: 2 removed + 3 obsolete)
======================================================

keytoolgui        (replaced by portecle)
plexus-container
saxpath            (merged into jaxen)
stylebook
toolbutton        (merged into toolbar)

Removed from non-free (4 packages)
==================================

java-1.3.1-bea
java-1.3.1-blackdown
java-1.3.1-ibm
java-1.3.1-sun

New in free (59 packages)
=========================

aopalliance
axion
blowfish-j
burlap
carol
classpathx-jaf
classpathx-mail
clover
easymock
easymockclassextension
eclipse-gef
ehcache
ehcache-bootstrap
freemarker
geronimo-modules
geronimo-specs
gnu-crypto
gvf
hessian
hibernate
howl-logger
ibatis
ibatis1
idb
jacorb
jakarta-commons-attributes
jakarta-commons-jexl
jakarta-commons-latka
jakarta-slide-server
jboss4-aop
jboss4-buildmagic-tasks
jboss4-cache
jboss4-common
jboss4-jmx
jboss4-system
jetty5
joesnmp
howl-logger
ibatis
ibatis1
idb
jacorb
jakarta-commons-attributes
jakarta-commons-jexl
jakarta-commons-latka
jakarta-slide-server
jboss4-aop
jboss4-buildmagic-tasks
jboss4-cache
jboss4-common
jboss4-jmx
jboss4-system
jetty5
joesnmp
jonas
jonathan-core
jonathan-jeremie
joram
jotm
junitejb
maven
netbeans
odmg
openejb
owanttask
owdeploysched
pdfbox
portecle
radeox
spring
swingwt
tranql
xapool
xml-commons-resolver-nb
xmlbeans

Thanks once more

The JPackage Team

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/7f521562/attachment.sig>

From ronny-vlug at vlugnet.org  Mon Dec  6 19:44:19 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Mon, 6 Dec 2004 20:44:19 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <1102345656.18495.28.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
Message-ID: <200412062044.19981.ronny-vlug@vlugnet.org>

On Monday 06 December 2004 16:07, John (J5) Palmieri wrote:
> We can't just yet assume that legacy devices don't exist anymore so
> taking it out of Kudzu would have been a regression.  We might be able
> to tell Kudzu to ignore USB and Firewire devices.
Wouldn't it be better to do configuration of legacy devices only on demand and 
not on every boot?
Kudzu slows down boot by some seconds (and I can't imagine it takes so long 
for probing PCI or USB).

-- 
http://LinuxWiki.org/RonnyBuchmann



From notting at redhat.com  Mon Dec  6 20:32:45 2004
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 6 Dec 2004 15:32:45 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <200412062044.19981.ronny-vlug@vlugnet.org>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
Message-ID: <20041206203244.GB4757@nostromo.devel.redhat.com>

Ronny Buchmann (ronny-vlug at vlugnet.org) said: 
> Wouldn't it be better to do configuration of legacy devices only on demand and 
> not on every boot?
> Kudzu slows down boot by some seconds (and I can't imagine it takes so long 
> for probing PCI or USB).

To really speed things up, all you have to declare is that all serial
mice must be manually configured... 

Bill



From aaron.bennett at olin.edu  Mon Dec  6 20:33:03 2004
From: aaron.bennett at olin.edu (Aaron Bennett)
Date: Mon, 06 Dec 2004 15:33:03 -0500
Subject: status of Extras for Fedora Core 3
In-Reply-To: <41B493E0.7010407@olin.edu>
References: <41B493E0.7010407@olin.edu>
Message-ID: <41B4C1FF.10303@olin.edu>

Aaron Bennett wrote:

> Hello,
>
> I've been looking through the Fedora.us website as well as 
> fedora.redhat.com for some information about when Fedora Extras will 
> be built for FC3, or when it will be available, and I can't find 
> anything.
>
> Am I missing something?  
> http://mirrors.kernel.org/fedora.us/fedora/fedora/3/i386/RPMS.extras/ 
> is empty and the README says "This repository is replicated only for 
> the convenience of apt users.  yum/up2date users should use Red Hat's 
> download.fedora.redhat.com mirrors."  So I looked all through 
> download.fedora.redhat.com and can't find anything either regarding 
> Extras.
>
> Livna.org has a set of FC3 rpms.  What's going on with Fedora.us?
>
I'm sorry-- I dug some more and found this 
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html 
which explains what's happening.

Mod parent -1 redundant.



-- 
Aaron Bennett
UNIX Administrator
Franklin W. Olin College of Engineering




From jspaleta at gmail.com  Mon Dec  6 20:42:25 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 6 Dec 2004 15:42:25 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <20041206203244.GB4757@nostromo.devel.redhat.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
Message-ID: <604aa791041206124251261138@mail.gmail.com>

On Mon, 6 Dec 2004 15:32:45 -0500, Bill Nottingham <notting at redhat.com> wrote:
> To really speed things up, all you have to declare is that all serial
> mice must be manually configured...

Fine... I hereby declare that all serial mice must be manually configured.
I also declare today December 6th to be henceforth known as "Serial
Mice Independence Day" and shall be universally celebrated by feasting
on the flesh of elephants.

-jef"Do i need to have my declaration be notarized or will a towne
crier sent through the streets be sufficient for notification?"spaleta



From michael.favia at insitesinc.com  Mon Dec  6 21:10:25 2004
From: michael.favia at insitesinc.com (Michael Favia)
Date: Mon, 06 Dec 2004 15:10:25 -0600
Subject: Kudzu and automatic detection
In-Reply-To: <20041206203244.GB4757@nostromo.devel.redhat.com>
References: <1102332114.3973.18.camel@localhost.localdomain>	<604aa7910412060700306166f4@mail.gmail.com>	<1102345656.18495.28.camel@localhost.localdomain>	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
Message-ID: <41B4CAC1.6080104@insitesinc.com>

Bill Nottingham wrote:

>Ronny Buchmann (ronny-vlug at vlugnet.org) said: 
>  
>
>>Wouldn't it be better to do configuration of legacy devices only on demand and 
>>not on every boot?
>>Kudzu slows down boot by some seconds (and I can't imagine it takes so long 
>>for probing PCI or USB).
>>    
>>
>
>To really speed things up, all you have to declare is that all serial
>mice must be manually configured... 
>  
>
or recycled. :)
-mf


-- 
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated    http://michael.insitesinc.com



From si at bananas.hopto.org  Mon Dec  6 21:20:24 2004
From: si at bananas.hopto.org (Si Jones)
Date: Mon, 06 Dec 2004 21:20:24 +0000
Subject: mplayer
Message-ID: <1102368024.3346.2.camel@apple.bananas.hopto.org>

Hi,

I was trying to package mplayer on amd64.

I have downloaded all the deps etc, but when i do rpmbuild -
bb /usr/src/redhat/specs/mplayer.spec etc.

I get an error of X11 not found.

Is this because I use to have nvidia drivers in and i have removed
them??

If it is, is there anyway of repairing this?

Cheers,

Si



From skvidal at phy.duke.edu  Mon Dec  6 21:21:46 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 06 Dec 2004 16:21:46 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <41B4CAC1.6080104@insitesinc.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
	<41B4CAC1.6080104@insitesinc.com>
Message-ID: <1102368107.14144.104.camel@cutter>

On Mon, 2004-12-06 at 15:10 -0600, Michael Favia wrote:
> Bill Nottingham wrote:
> 
> >Ronny Buchmann (ronny-vlug at vlugnet.org) said: 
> >  
> >
> >>Wouldn't it be better to do configuration of legacy devices only on demand and 
> >>not on every boot?
> >>Kudzu slows down boot by some seconds (and I can't imagine it takes so long 
> >>for probing PCI or USB).
> >>    
> >>
> >
> >To really speed things up, all you have to declare is that all serial
> >mice must be manually configured... 
> >  
> >
> or recycled. :)
> -mf

they make remarkably good projectile weapons when you swing them by the
tail... err.. cord.
-sv




From guhvies at gmail.com  Mon Dec  6 21:27:44 2004
From: guhvies at gmail.com (ne...)
Date: Mon, 6 Dec 2004 16:27:44 -0500
Subject: mplayer
In-Reply-To: <1102368024.3346.2.camel@apple.bananas.hopto.org>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
Message-ID: <a227b70c04120613272fd4e10f@mail.gmail.com>

On Mon, 06 Dec 2004 21:20:24 +0000, Si Jones <si at bananas.hopto.org> wrote:
> Hi,
> 
> I was trying to package mplayer on amd64.
> 
> I have downloaded all the deps etc, but when i do rpmbuild -
> bb /usr/src/redhat/specs/mplayer.spec etc.
> 
> I get an error of X11 not found.
> 
> Is this because I use to have nvidia drivers in and i have removed
> them??
Most likely because the X11 devel rpms are not installed.

> If it is, is there anyway of repairing this?
Install the X11 devel rpms.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard. 
http://www.thespark.com/bastardtest



From bpm at ec-group.com  Mon Dec  6 21:31:55 2004
From: bpm at ec-group.com (Brian Millett)
Date: Mon, 6 Dec 2004 15:31:55 -0600 (CST)
Subject: Kudzu and automatic detection
In-Reply-To: <1102368107.14144.104.camel@cutter>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
	<41B4CAC1.6080104@insitesinc.com>
	<1102368107.14144.104.camel@cutter>
Message-ID: <26516.12.41.112.51.1102368715.squirrel@webmail.ec-group.com>


> On Mon, 2004-12-06 at 15:10 -0600, Michael Favia wrote:
>> Bill Nottingham wrote:
>>
>> >Ronny Buchmann (ronny-vlug at vlugnet.org) said:
>> >
>> >
>> >>Wouldn't it be better to do configuration of legacy devices only on
>> demand and  not on every boot?
>> >>Kudzu slows down boot by some seconds (and I can't imagine it takes
>> so long  for probing PCI or USB).
>> >>
>> >>
>> >
>> >To really speed things up, all you have to declare is that all serial
>> mice must be manually configured...
>> >
>> >
>> or recycled. :)
>> -mf
>
> they make remarkably good projectile weapons when you swing them by the
> tail... err.. cord.

I just tie 3-4 together and go hunting for squirrels.

-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn





From avibrazil at gmail.com  Mon Dec  6 21:34:46 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Mon, 6 Dec 2004 19:34:46 -0200
Subject: JPackage 1.6
In-Reply-To: <1102361942.16895.47.camel@rousalka.dyndns.org>
References: <1102361942.16895.47.camel@rousalka.dyndns.org>
Message-ID: <ed0efd3104120613342d60570e@mail.gmail.com>

Your work is very very important to the community, to the business
applications development world, and Java users. I hope JPackage will
become a standard in all Linux distros.

Thank you, JPackage,
Avi

On Mon, 06 Dec 2004 20:39:02 +0100, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> [This is a repost of the 19 november announce on JPackage lists. Since
> JPackage serves is the upstream of numerous of FC Java packages I was
> asked to echo it on FC-related rpm lists. Many thanks to Paul Nasrat for
> the original announcement]
> 
> The JPackage Project http://www.jpackage.org/ is pleased to announce a
> new release.  Upgrading should be a simple matter of pointing your
> preferred depsolver at a mirror documented at
> http://www.jpackage.org/repos.php
> 
> Since JPackage 1.5, the team has grown thanks to vendor interest and we
> will continue providing packaging java packages, and we hope to have
> some more exciting news soon.
> 
> JPackage will continue to host a devel repository for future large
> changes. Please update your preferred depsolver to point to the 1.6
> repositories as documented:
> 
> http://www.jpackage.org/repos.php
> 
> [ You will usually need the generic & distro-specific repository. Devel
> is for testers ]
> 
> Thanks once more to all the contributors and users
> 
> Highlights
> ==========
> 
> Ant 1.6.2 is one of the biggest highlights, along with having maven and
> lots of updated packages.
> 
> Contribuors
> ===========
> 
> In no particular order JPackage is:
> 
> * Ralph Apel
> * Gary Benson
> * Pete Chown
> * Leonid Dubinsky
> * Thomas Fitzsimmons
> * Henri Gomez
> * Sonja Krause-Harder
> * Goulven Le Jeune
> * Nicolas Mailhot
> * Paul Nasrat
> * Fernando Nasser
> * Kaj J. Niemi
> * Robert Ottenhag
> * Jens Skripczynski
> * Ville Skytt?
> * Sebastiano Vigna
> * David Walluck
> * Christian Zoffoli
> 
> Thanks
> ======
> 
> In addition thanks to Randy Walter for Ant 1.6.X work and Carwyn Edwards
> for work on the 1.5 JDK.
> 
> As always we wish to thank the community for all their contributions and
> work.
> 
> Notes
> =====
> 
> JPackage no longer supports or distributes Java SDK version 1.3. The
> version of the Java SDK supported in this release is 1.4. Java SDK
> 1.5 from Sun is also provided in the non-free section.
> 
> Removed from free (5 packages: 2 removed + 3 obsolete)
> ======================================================
> 
> keytoolgui        (replaced by portecle)
> plexus-container
> saxpath            (merged into jaxen)
> stylebook
> toolbutton        (merged into toolbar)
> 
> Removed from non-free (4 packages)
> ==================================
> 
> java-1.3.1-bea
> java-1.3.1-blackdown
> java-1.3.1-ibm
> java-1.3.1-sun
> 
> New in free (59 packages)
> =========================
> 
> aopalliance
> axion
> blowfish-j
> burlap
> carol
> classpathx-jaf
> classpathx-mail
> clover
> easymock
> easymockclassextension
> eclipse-gef
> ehcache
> ehcache-bootstrap
> freemarker
> geronimo-modules
> geronimo-specs
> gnu-crypto
> gvf
> hessian
> hibernate
> howl-logger
> ibatis
> ibatis1
> idb
> jacorb
> jakarta-commons-attributes
> jakarta-commons-jexl
> jakarta-commons-latka
> jakarta-slide-server
> jboss4-aop
> jboss4-buildmagic-tasks
> jboss4-cache
> jboss4-common
> jboss4-jmx
> jboss4-system
> jetty5
> joesnmp
> howl-logger
> ibatis
> ibatis1
> idb
> jacorb
> jakarta-commons-attributes
> jakarta-commons-jexl
> jakarta-commons-latka
> jakarta-slide-server
> jboss4-aop
> jboss4-buildmagic-tasks
> jboss4-cache
> jboss4-common
> jboss4-jmx
> jboss4-system
> jetty5
> joesnmp
> jonas
> jonathan-core
> jonathan-jeremie
> joram
> jotm
> junitejb
> maven
> netbeans
> odmg
> openejb
> owanttask
> owdeploysched
> pdfbox
> portecle
> radeox
> spring
> swingwt
> tranql
> xapool
> xml-commons-resolver-nb
> xmlbeans
> 
> Thanks once more
> 
> The JPackage Team
> 
> --
> Nicolas Mailhot
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
>



From perbj at stanford.edu  Mon Dec  6 21:51:39 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 06 Dec 2004 13:51:39 -0800
Subject: Kudzu and automatic detection
In-Reply-To: <20041206203244.GB4757@nostromo.devel.redhat.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
Message-ID: <1102369899.3371.13.camel@localhost.localdomain>

On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
> To really speed things up, all you have to declare is that all serial
> mice must be manually configured... 

So maybe it's actually time to at least default to ignoring certain
types of legacy hardware by default? Pretty much no new user is going to
have a serial mouse anyways, and if the serial mouse probing could be
switchable by poking a parameter in /etc/sysconfig/kudzu the people who
still have such devices can rather easily get them detected. Now, in th
that file I can only find the parameter "SAFE" which the comment says
disables serial mouse, monitor DDC and PS/2 port probing.

Is there any simple way to dump only serial mouse probing while keeping
the probes for monitors and PS/2 keyboards and mice? Or could such a
switch be implemented reasonably easily? The latter devices aren't
exactly unusual yet, even though the PS/2 bus might be considered
"legacy"...

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From perbj at stanford.edu  Mon Dec  6 21:51:39 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 06 Dec 2004 13:51:39 -0800
Subject: Kudzu and automatic detection
In-Reply-To: <20041206203244.GB4757@nostromo.devel.redhat.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
Message-ID: <1102369899.3371.13.camel@localhost.localdomain>

On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
> To really speed things up, all you have to declare is that all serial
> mice must be manually configured... 

So maybe it's actually time to at least default to ignoring certain
types of legacy hardware by default? Pretty much no new user is going to
have a serial mouse anyways, and if the serial mouse probing could be
switchable by poking a parameter in /etc/sysconfig/kudzu the people who
still have such devices can rather easily get them detected. Now, in th
that file I can only find the parameter "SAFE" which the comment says
disables serial mouse, monitor DDC and PS/2 port probing.

Is there any simple way to dump only serial mouse probing while keeping
the probes for monitors and PS/2 keyboards and mice? Or could such a
switch be implemented reasonably easily? The latter devices aren't
exactly unusual yet, even though the PS/2 bus might be considered
"legacy"...

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From notting at redhat.com  Mon Dec  6 21:55:18 2004
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 6 Dec 2004 16:55:18 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102369899.3371.13.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
	<1102369899.3371.13.camel@localhost.localdomain>
Message-ID: <20041206215518.GA7123@nostromo.devel.redhat.com>

Per Bjornsson (perbj at stanford.edu) said: 
> On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
> > To really speed things up, all you have to declare is that all serial
> > mice must be manually configured... 
> 
> So maybe it's actually time to at least default to ignoring certain
> types of legacy hardware by default? Pretty much no new user is going to
> have a serial mouse anyways, and if the serial mouse probing could be
> switchable by poking a parameter in /etc/sysconfig/kudzu the people who
> still have such devices can rather easily get them detected. Now, in th
> that file I can only find the parameter "SAFE" which the comment says
> disables serial mouse, monitor DDC and PS/2 port probing.

Hm, that doesn't actually disable PS/2 these days. Should probably
fix this.

Bill



From si at bananas.hopto.org  Mon Dec  6 21:58:48 2004
From: si at bananas.hopto.org (Si Jones)
Date: Mon, 06 Dec 2004 21:58:48 +0000
Subject: mplayer
In-Reply-To: <a227b70c04120613272fd4e10f@mail.gmail.com>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
	<a227b70c04120613272fd4e10f@mail.gmail.com>
Message-ID: <1102370328.3346.7.camel@apple.bananas.hopto.org>

> > 
> > Is this because I use to have nvidia drivers in and i have removed
> > them??
> Most likely because the X11 devel rpms are not installed.
> 
> > If it is, is there anyway of repairing this?
> Install the X11 devel rpms.

Checked, it's not that!

when i check the configure.log it says:

============ Checking for X11 headers presence ============
Result is: yes (using /usr/X11R6/include)
##########################################

============ Checking for X11 libs presence ============
Result is: yes (using /usr/X11R6/lib)
##########################################

============ Checking for X11 ============

#include <X11/Xlib.h>
#include <X11/Xutil.h>
int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return
0; }

cc     /tmp/mplayer-conf-7136-12478.c -o /tmp/mplayer-conf-15235-12478.o
-I/usr/X11R6/include -L/usr/X11R6/lib -lXext -lX11 -lnsl
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when
searching for -lXext
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when
searching for -lXext
/usr/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status

ldd /tmp/mplayer-conf-15235-12478.o
ldd: /tmp/mplayer-conf-15235-12478.o: No such file or directory

Result is: no
##########################################

Cheers

Si



From mlauterbach at mail.wtamu.edu  Mon Dec  6 21:59:55 2004
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Mon, 6 Dec 2004 15:59:55 -0600
Subject: Kudzu and automatic detection
In-Reply-To: <45b47df304120609417a598266@mail.gmail.com>
Message-ID: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>

On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
>I agree, the device should be unavailabe if it has been removed,
>however, its related user configured properties should not.

What if it is actually gone, never to return?  
How can we tell the difference?

Matthew E. Lauterbach




From arjanv at redhat.com  Mon Dec  6 22:00:34 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 06 Dec 2004 17:00:34 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <1102369899.3371.13.camel@localhost.localdomain>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
	<1102369899.3371.13.camel@localhost.localdomain>
Message-ID: <1102370434.10277.3.camel@laptop.fenrus.org>

On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
> On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
> > To really speed things up, all you have to declare is that all serial
> > mice must be manually configured... 
> 
> So maybe it's actually time to at least default to ignoring certain
> types of legacy hardware by default? 

or... if you find a ps.2 or usb mouse skip the serial probing.. the
chance of having BOTH a ps2 one and a serial one are pretty low after
all :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/20c7c0dc/attachment.sig>

From ad+lists at uni-x.org  Mon Dec  6 22:13:37 2004
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Mon, 06 Dec 2004 23:13:37 +0100
Subject: mplayer
In-Reply-To: <1102370328.3346.7.camel@apple.bananas.hopto.org>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
	<a227b70c04120613272fd4e10f@mail.gmail.com>
	<1102370328.3346.7.camel@apple.bananas.hopto.org>
Message-ID: <1102371216.5318.102.camel@serendipity.dogma.lan>

Am Mo, den 06.12.2004 schrieb Si Jones um 22:58:

> when i check the configure.log it says:
> 
> ============ Checking for X11 headers presence ============
> Result is: yes (using /usr/X11R6/include)
> ##########################################
> 
> ============ Checking for X11 libs presence ============
> Result is: yes (using /usr/X11R6/lib)
> ##########################################

I have no x86_64 system, but shouldn't it find the 64bit libs?

> ============ Checking for X11 ============
> 
> #include <X11/Xlib.h>
> #include <X11/Xutil.h>
> int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return
> 0; }
> 
> cc     /tmp/mplayer-conf-7136-12478.c -o /tmp/mplayer-conf-15235-12478.o
> -I/usr/X11R6/include -L/usr/X11R6/lib -lXext -lX11 -lnsl

Shouldn't it be -L/usr/X11R6/lib64?

> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when
> searching for -lXext
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when
> searching for -lXext
> /usr/bin/ld: cannot find -lXext
> collect2: ld returned 1 exit status

> Si

Alexander


-- 
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp 
Serendipity 23:08:06 up 22:30, 17 users, 1.43, 1.35, 1.39 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/1168f517/attachment.sig>

From dpaun at rogers.com  Mon Dec  6 22:17:01 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 6 Dec 2004 17:17:01 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>
References: <45b47df304120609417a598266@mail.gmail.com>
	<20041206215957.5F5C23E6BF3@mail.wtamu.edu>
Message-ID: <20041206221701.GH13664@rogers.com>

On Mon, Dec 06, 2004 at 03:59:55PM -0600, Matthew E. Lauterbach wrote:
> On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
> >I agree, the device should be unavailabe if it has been removed,
> >however, its related user configured properties should not.
> 
> What if it is actually gone, never to return?  
> How can we tell the difference?

You can't, of course, but would it be a big deal to keep it around?

-- 
Dimi.



From si at bananas.hopto.org  Mon Dec  6 22:19:39 2004
From: si at bananas.hopto.org (Si Jones)
Date: Mon, 06 Dec 2004 22:19:39 +0000
Subject: mplayer
In-Reply-To: <1102371216.5318.102.camel@serendipity.dogma.lan>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
	<a227b70c04120613272fd4e10f@mail.gmail.com>
	<1102370328.3346.7.camel@apple.bananas.hopto.org>
	<1102371216.5318.102.camel@serendipity.dogma.lan>
Message-ID: <1102371579.3346.8.camel@apple.bananas.hopto.org>

On Mon, 2004-12-06 at 23:13 +0100, Alexander Dalloz wrote:
> Am Mo, den 06.12.2004 schrieb Si Jones um 22:58:
> 
> > when i check the configure.log it says:
> > 
> > ============ Checking for X11 headers presence ============
> > Result is: yes (using /usr/X11R6/include)
> > ##########################################
> > 
> > ============ Checking for X11 libs presence ============
> > Result is: yes (using /usr/X11R6/lib)
> > ##########################################
> 
> I have no x86_64 system, but shouldn't it find the 64bit libs?
> 
> > ============ Checking for X11 ============
> > 
> > #include <X11/Xlib.h>
> > #include <X11/Xutil.h>
> > int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return
> > 0; }
> > 
> > cc     /tmp/mplayer-conf-7136-12478.c -o /tmp/mplayer-conf-15235-12478.o
> > -I/usr/X11R6/include -L/usr/X11R6/lib -lXext -lX11 -lnsl
> 
> Shouldn't it be -L/usr/X11R6/lib64?
> 
> > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when
> > searching for -lXext
> > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when
> > searching for -lXext
> > /usr/bin/ld: cannot find -lXext
> > collect2: ld returned 1 exit status
> 
Which file do i need to change then for this????





From johnp at redhat.com  Mon Dec  6 22:20:59 2004
From: johnp at redhat.com (John (J5) Palmieri)
Date: Mon, 06 Dec 2004 17:20:59 -0500
Subject: Kudzu and automatic detection
In-Reply-To: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>
References: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>
Message-ID: <1102371659.18495.98.camel@localhost.localdomain>

On Mon, 2004-12-06 at 16:59, Matthew E. Lauterbach wrote:
> On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
> >I agree, the device should be unavailabe if it has been removed,
> >however, its related user configured properties should not.
> 
> What if it is actually gone, never to return?  
> How can we tell the difference?

Well it is not so bad to hold user configuration in gconf.  That is what
we do for printers that can't be autodetected.  Even if they never plug
the printer in again all it does it take up a small amount of disk
space.

--
J5



From Nicolas.Mailhot at laPoste.net  Mon Dec  6 22:26:11 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 06 Dec 2004 23:26:11 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>
References: <20041206215957.5F5C23E6BF3@mail.wtamu.edu>
Message-ID: <1102371971.22946.4.camel@rousalka.dyndns.org>

Le lundi 06 d?cembre 2004 ? 15:59 -0600, Matthew E. Lauterbach a ?crit :
> On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
> >I agree, the device should be unavailabe if it has been removed,
> >however, its related user configured properties should not.
> 
> What if it is actually gone, never to return?  
> How can we tell the difference?

Is this really a problem given today's storage sizes ? This message will
be heavier than most device property files. We are talking about a very
small set of critical tunings

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041206/b5c3c8e5/attachment.sig>

From mattwhiteley at gmail.com  Mon Dec  6 22:29:48 2004
From: mattwhiteley at gmail.com (matt whiteley)
Date: Mon, 6 Dec 2004 14:29:48 -0800
Subject: Thunderbird 1.0 and Enigmail
In-Reply-To: <80d7e40904120611226cf09d2d@mail.gmail.com>
References: <200412061527.iB6FR7u25957@xos037.xos.nl>
	<41B49826.2010408@redhat.com>
	<80d7e40904120611226cf09d2d@mail.gmail.com>
Message-ID: <72ae109c04120614292c6ce8b6@mail.gmail.com>

On Mon, 6 Dec 2004 12:22:32 -0700, Stephen J. Smoogen <smooge at gmail.com> wrote:
> And the fact that the Enigmail or Mozilla people do not advertise it
> as an extension for Thunderbird when you look for extensions does not
> help any. I think this is an issue where people contact the Enigmail
> upstream, find out what the problem is, and see if it can be fixed.
> --
> Stephen J Smoogen.
> CSIRT/Linux System Administrator

Normally enigmail not loading means mozilla was built with
--disable-shared or without --enable-crypto. The fedora build appears
to use both. It will install enigmail but then complains about
enigmime not being available but in new versions of enigmail, enigmime
is built in.

As for them not advertising:
http://enigmail.mozdev.org/
"Enigmail is an extension to the mail client of Mozilla / Netscape and
Thunderbird which allows users to access the authentication and
encryption features provided by the popular GnuPG software"

http://texturizer.net/thunderbird/faq.html#q2.12
"Hooks to PGP or GnuPG are not included in Thunderbird, but are under
development at Enigmail."

Also at:
http://extensionroom.mozdev.org/list.php/Thunderbird/privacy
https://update.mozilla.org/extensions/showlist.php?application=thunderbird&os=linux&version=0.9

-- 
matt whiteley <mattwhiteley at gmail.com>



From mlauterbach at mail.wtamu.edu  Mon Dec  6 22:38:57 2004
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Mon, 6 Dec 2004 16:38:57 -0600
Subject: Kudzu and automatic detection
In-Reply-To: <1102371971.22946.4.camel@rousalka.dyndns.org>
Message-ID: <20041206223858.B7CA13E66F6@mail.wtamu.edu>

On Monday, December 06, 2004 4:26 PM -0600, Nicolas Mailhot wrote:
> Le lundi 06 d?cembre 2004 ? 15:59 -0600, Matthew E. Lauterbach a ?crit :
> > On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
> > >I agree, the device should be unavailabe if it has been removed,
> > >however, its related user configured properties should not.
> >
> > What if it is actually gone, never to return?
> > How can we tell the difference?
> 
> Is this really a problem given today's storage sizes ? This message will
> be heavier than most device property files. We are talking about a very
> small set of critical tunings
> 
It's a very small problem.  I think that if you can determine that it isn't
coming back you should clean up after it.  I agree that if the device will
return or if you can't tell the difference it would be better to keep the
user configuration.





From ronny-vlug at vlugnet.org  Mon Dec  6 23:03:31 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Tue, 7 Dec 2004 00:03:31 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <20041206203244.GB4757@nostromo.devel.redhat.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
Message-ID: <200412070003.31300.ronny-vlug@vlugnet.org>

On Monday 06 December 2004 21:32, Bill Nottingham wrote:
> Ronny Buchmann (ronny-vlug at vlugnet.org) said:
> > Wouldn't it be better to do configuration of legacy devices only on
> > demand and not on every boot?
> > Kudzu slows down boot by some seconds (and I can't imagine it takes so
> > long for probing PCI or USB).
>
> To really speed things up, all you have to declare is that all serial
> mice must be manually configured...
Ah, this reminds me that kudzu probes for mice (or something else) on the 
serial port even if used as console. Should file a bug about it...

-- 
http://LinuxWiki.org/RonnyBuchmann



From warren at togami.com  Tue Dec  7 04:15:24 2004
From: warren at togami.com (Warren Togami)
Date: Mon, 06 Dec 2004 18:15:24 -1000
Subject: Thunderbird 1.0rc: XML Parsing error
In-Reply-To: <200412061214.iB6CEOt24948@xos037.xos.nl>
References: <200412061214.iB6CEOt24948@xos037.xos.nl>
Message-ID: <41B52E5C.3040102@togami.com>

Jos Vos wrote:
> Hi,
> 
> When I select Preferences -> Advanced in Thunderbird 1.0rc I see a
> 
>   XML Parsing Error: not well-formed
>   Location: chrome://messenger/content/pref-advanced.xul
>   Line number 208, Column 5:
> 
> This is after rebuilding the src.rpm on RHEL3 (with a few tweaks),
> so I'm now wondering if this also happens on FC3.  Anyone?
> 
> Thanks,
> 

This kind of problem happened to me after upgrading without restarting 
thunderbird.  Have you tried closing thunderbird completely and reopening?

Warren



From remco at rvt.com  Tue Dec  7 06:06:05 2004
From: remco at rvt.com (Remco Treffkorn)
Date: Mon, 6 Dec 2004 22:06:05 -0800
Subject: Kudzu and automatic detection
In-Reply-To: <26516.12.41.112.51.1102368715.squirrel@webmail.ec-group.com>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<1102368107.14144.104.camel@cutter>
	<26516.12.41.112.51.1102368715.squirrel@webmail.ec-group.com>
Message-ID: <200412062206.05470.remco@rvt.com>

On Monday 06 December 2004 13:31, Brian Millett wrote:
> > On Mon, 2004-12-06 at 15:10 -0600, Michael Favia wrote:
...
> > they make remarkably good projectile weapons when you swing them by the
> > tail... err.. cord.
>
> I just tie 3-4 together and go hunting for squirrels.
>

It's illegal in your state! And you should not eat squirrels since they are 
high in colesterol.

What movie was this from?...

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201



From sandmann at redhat.com  Tue Dec  7 06:26:55 2004
From: sandmann at redhat.com (=?ISO-8859-1?Q?S=F8ren_Sandmann_Pedersen?=)
Date: Tue, 07 Dec 2004 01:26:55 -0500
Subject: adventures in booting
In-Reply-To: <1102010880.4024.28.camel@nexus.verbum.private>
References: <1101692986.2025.22.camel@davidz>	<1101869999.3544.65.camel@serenity.klika.si>	<1102006136.12241.53.camel@davidz>
	<20041202165844.GF25551@redhat.com>	<1102009206.12241.89.camel@davidz>	<1102010395.4024.21.camel@nexus.verbum.private>
	<1102010880.4024.28.camel@nexus.verbum.private>
Message-ID: <41B54D2F.90107@redhat.com>

Colin Walters wrote:

>>>I'm almost positive it requires kernel changes to do this the right way;
>>>one naive idea is to have a userspace daemon, capturing what blocks are
>>>read when (kernel tells this daemon using the kernel events layer). This
>>>would run in the first three minutes on each and every boot. When the
>>>system is idle (and only when running on AC power!) another daemon
>>>rearranges blocks on the disk. What blocks to rearrange could be the
>>>result of a computation involving several three-minute result sets.
>>>      
>>>
>>Rearranging sounds complex and dangerous, since it requires deep
>>integration with the filesystem.  The online resizing took quite a long
>>time to appear and that is conceptually much simpler.  Why not do it on
>>the block device layer (without knowledge of the filesystem) and just
>>copy those blocks to a reserved area of the block device?  Disks are
>>big, duplicating say 100MB for this purpose wouldn't be bad. 
>>    
>>
Doing the rearranging at the block level has several advantages:

   - We don't need to have this thread again (and don't need to apply
     another hack) when people realizes that OpenOffice *also* needs
     disk rearranging to start faster.

   - It is a general speedup across the system

   - If the disk blocks are generally arranged in such a way that
     blocks accessed together are close together, then readahead
     in the kernel becomes a matter of just reading further ahead
     *on the disk* instead of as now reading further ahead in the file.

   - when a set of blocks are read in, the VM system knows that
     those blocks are likely to be needed soon, so it can consider
     it a bad idea to throw those pages away.


S?ren



From dax at gurulabs.com  Tue Dec  7 07:18:39 2004
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 07 Dec 2004 00:18:39 -0700
Subject: pam_krb5, NFSv4, AutoFS mounted home dirs
Message-ID: <1102403919.4278.54.camel@mentorng.gurulabs.com>

I have three testing FC2 boxes in a Kerb5 realm, with the following
updates:

kernel-smp-2.6.9-1.6_FC2
pam_krb5-2.1.2-1
nfs-utils-1.0.6-44 (note that the FC3 SRPM will only compile with gcc
3.4)

I'm trying to setup centralized home directories securely shared with
strong user authentication with integrity checking (aka krb5i) and
moving adding encrypted NFS (aka krb5p) when supported. Something I've
been wanting to do for years.

I've run into a minor issue, and a show stopper.

Minor issue: 

I had to insert a "modprobe rpcsec_gss_krb5" into /etc/init.d/rpcgssd on
the client(s) and into /etc/init.d/rpcsvcgssd on the server.

Show stopper:

pam_krb5 creates per session ticket cache files
as /tmp/krb5cc_p<digits>, while the NFS client's rpcsec_gss daemon
expects the ticket cache file to be /tmp/krb5cc_$UID.

This issue is mentioned briefly on:
http://www.citi.umich.edu/projects/nfsv4/2.4-nfsv4/release1/install.html

The solution on the page doesn't work (catch-22) in a krb5-secured-
automounted-homedir scenario as, it says to add the following to your
login script:

    # move kerberos cred file to a place where gssd can find it
    TMPNAME=`/bin/basename ${KRB5CCNAME:-unset}`
    if [ -f /tmp/${TMPNAME} ]; then
      mv /tmp/${TMPNAME} /tmp/krb5cc_${UID}
      KRB5CCNAME="FILE:/tmp/krb5cc_${UID}"
    fi

The page also says:

"The Kerberos PAM library creates a per-session ticket file in /tmp.
This file must be moved to a per-UID location so that gssd can find it
(this will be fixed in a future release)."

What the current status?
What's the solution? 
Has anyone approached Nalin about modifying pam_krb5?
What's the impact of ditching per session ticket cache and going to per
UID?

Thanks,
Dax Kelson
Guru Labs



From jos at xos.nl  Tue Dec  7 08:43:01 2004
From: jos at xos.nl (Jos Vos)
Date: Tue, 7 Dec 2004 09:43:01 +0100
Subject: Thunderbird 1.0rc: XML Parsing error
In-Reply-To: <41B52E5C.3040102@togami.com>;
	from warren@togami.com on Mon, Dec 06, 2004 at 06:15:24PM -1000
References: <200412061214.iB6CEOt24948@xos037.xos.nl>
	<41B52E5C.3040102@togami.com>
Message-ID: <20041207094301.A29981@xos037.xos.nl>

On Mon, Dec 06, 2004 at 06:15:24PM -1000, Warren Togami wrote:

> This kind of problem happened to me after upgrading without restarting 
> thunderbird.  Have you tried closing thunderbird completely and reopening?

Christopher pointed out that it is a known bug (#141899) that
will be solved RSN.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From j.w.r.degoede at hhs.nl  Tue Dec  7 09:07:57 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 07 Dec 2004 10:07:57 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <20041206223858.B7CA13E66F6@mail.wtamu.edu>
References: <20041206223858.B7CA13E66F6@mail.wtamu.edu>
Message-ID: <41B572ED.4090308@hhs.nl>



Matthew E. Lauterbach wrote:
> On Monday, December 06, 2004 4:26 PM -0600, Nicolas Mailhot wrote:
> 
>>Le lundi 06 d?cembre 2004 ? 15:59 -0600, Matthew E. Lauterbach a ?crit :
>>
>>>On Monday, December 06, 2004 11:42 AM, Simarjeet Sahni wrote:
>>>
>>>>I agree, the device should be unavailabe if it has been removed,
>>>>however, its related user configured properties should not.
>>>
>>>What if it is actually gone, never to return?
>>>How can we tell the difference?
>>
>>Is this really a problem given today's storage sizes ? This message will
>>be heavier than most device property files. We are talking about a very
>>small set of critical tunings
>>
> 
> It's a very small problem.  I think that if you can determine that it isn't
> coming back you should clean up after it.  I agree that if the device will
> return or if you can't tell the difference it would be better to keep the
> user configuration.
> 
> 
> 

Well,

AFAIK this one is easy, just keep a timestamp when the device was last 
seen and nuke it if it hasn't been used for a year.

Regards,

Hans



From rmy at tigress.co.uk  Tue Dec  7 10:01:15 2004
From: rmy at tigress.co.uk (Ron Yorston)
Date: Tue, 7 Dec 2004 10:01:15 GMT
Subject: Kudzu and automatic detection
Message-ID: <200412071001.KAA28776@internal.tigress.co.uk>

"John (J5) Palmieri" <johnp at redhat.com> wrote:
>On Mon, 2004-12-06 at 13:30, Nicolas Mailhot wrote:
>> Le lundi 06 d?cembre 2004 ? 12:38 -0500, John (J5) Palmieri a ?crit :
>> 
>> > I don't see a bug on this in bugzilla.  Rule of thumb is if it is not
>> > filed in bugzilla it is not going to get fixed.  This is why we have the
>> > test releases and rawhide.  Please file a bug on hal-cups-utils.
>> 
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119970
>> 
>> And yes the problem evolved somewhat since the bug was filled. The
>> number of steps to perform to get the printer operational after power-up
>> has shrunk a bit. But the autodetected hal printer is still pretty
>> useless - if I hadn't created my own printer setup (with a different
>> name than the HAL one else HAL would just nuke it) I couldn't print
>> without going into system-config-printer every single time the printer
>> is powered up.
>
>That bug is before my time.

Then this one will be even more before your time:

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58901

Things do seem to have got better since then, but it's clearly still an
issue in some cases.  My solution to 58901 was a patch to kudzu which
allowed the user to specify that a device was expected to be connected
intermittently.  In that case kudzu would retain the configuration and
not pester the user about it as the device came and went.

Ron



From nbargnesi at gmail.com  Tue Dec  7 06:07:03 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Tue, 7 Dec 2004 01:07:03 -0500
Subject: JFS Filesystems?
In-Reply-To: <1102348140.23475.140.camel@moss-spartans.epoch.ncsc.mil>
References: <3077b8a00412060741f0be14a@mail.gmail.com>
	<1102348140.23475.140.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <3077b8a004120622077349abb6@mail.gmail.com>

Bah, "linux jfs selinux=0" works.  I had to change the kernel params
on these stations to root=/dev/sdf1 when it couldn't find the "/"
label, but that worked.  All eight drives are using JFS now.
-Nick



On Mon, 06 Dec 2004 10:49:00 -0500, Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> On Mon, 2004-12-06 at 10:41, Nick Bargnesi wrote:
> >     I was however able to install FC3 on these machines using a root
> > partition of ext3 and jfs partitions not directly related to the FC3
> > directory structure, i.e., /opt, and some backup mount points.  I've
> > read about trying "linux jfs selinux=0" as jfs won't mingle with
> > selinux, which I haven't done yet.  Curious to see if anyone else is
> > using non-ext filesystems and experienced/gotten past this.  Or to
> > smack me upside the head and say selinux=0 should do it...
> 
> IBM just posted a JFS patch this morning to the selinux mailing list
> that they said allows them to use SELinux with JFS on FC3.  They said
> that they are submitting it upstream soon, so hopefully SELinux and JFS
> will play nicely with each other in the not-so-distant future.  Also
> requires a small patch to the policy configuration to tell SELinux that
> it should try using xattrs on jfs for file contexts.
> 
> --
> Stephen Smalley <sds at epoch.ncsc.mil>
> National Security Agency
> 
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From stuart at terminus.co.uk  Tue Dec  7 10:35:28 2004
From: stuart at terminus.co.uk (Stuart Children)
Date: Tue, 07 Dec 2004 10:35:28 +0000
Subject: Kudzu and automatic detection
In-Reply-To: <1102370434.10277.3.camel@laptop.fenrus.org>
References: <1102332114.3973.18.camel@localhost.localdomain>	<604aa7910412060700306166f4@mail.gmail.com>	<1102345656.18495.28.camel@localhost.localdomain>	<200412062044.19981.ronny-vlug@vlugnet.org>	<20041206203244.GB4757@nostromo.devel.redhat.com>	<1102369899.3371.13.camel@localhost.localdomain>
	<1102370434.10277.3.camel@laptop.fenrus.org>
Message-ID: <41B58770.3070105@terminus.co.uk>

Arjan van de Ven wrote:
> On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
> 
>>On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
>>
>>>To really speed things up, all you have to declare is that all serial
>>>mice must be manually configured... 
>>
>>So maybe it's actually time to at least default to ignoring certain
>>types of legacy hardware by default? 
> 
> 
> or... if you find a ps.2 or usb mouse skip the serial probing.. the
> chance of having BOTH a ps2 one and a serial one are pretty low after
> all :)

Absolutely! I can't imagine that would upset anyone, and means you 
shouldn't get through the boot process without some type of pointing 
device operational.

If kudzu/whatever is run interactively then you could clearly show a 
"skip serial mouse detection if usb/ps2 mouse found first" checkbox [1] 
[2] which can be disabled by the user if necessary. It would be a shame 
to drop automagic configuration for these things completely.

[1] Or just detect everything anyway - time taken isn't so important in 
that case - though that could be confusing to users.

[2] In fact a more general "skip legacy hardware" option might be more 
appropriate.

PS: Anyone want a two-button serial mouse that's been sitting in a box 
with other junk for several years? :) I think I vaguely recall using it 
once. Really not worth ebaying so if you're in London or are happy to 
pay for postage...

-- 
Stuart



From tjarls at iee.lu  Tue Dec  7 12:19:48 2004
From: tjarls at iee.lu (Charles Lopes)
Date: Tue, 07 Dec 2004 13:19:48 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <1102370434.10277.3.camel@laptop.fenrus.org>
References: <1102332114.3973.18.camel@localhost.localdomain>	<604aa7910412060700306166f4@mail.gmail.com>	<1102345656.18495.28.camel@localhost.localdomain>	<200412062044.19981.ronny-vlug@vlugnet.org>	<20041206203244.GB4757@nostromo.devel.redhat.com>	<1102369899.3371.13.camel@localhost.localdomain>
	<1102370434.10277.3.camel@laptop.fenrus.org>
Message-ID: <41B59FE4.7030407@iee.lu>

Arjan van de Ven wrote:

>On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
>  
>
>>On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
>>    
>>
>>>To really speed things up, all you have to declare is that all serial
>>>mice must be manually configured... 
>>>      
>>>
>>So maybe it's actually time to at least default to ignoring certain
>>types of legacy hardware by default? 
>>    
>>
>
>or... if you find a ps.2 or usb mouse skip the serial probing.. the
>chance of having BOTH a ps2 one and a serial one are pretty low after
>all :)
>  
>
Except if you happen to have both a mouse and a trackball. I have seen 
quite a few workstations equiped with a PS2 mouse and a serial 
trackball. It was quite a common setup for CAD stations just a couple of 
years ago.




From buildsys at redhat.com  Tue Dec  7 13:02:29 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 7 Dec 2004 08:02:29 -0500
Subject: rawhide report: 20041207 changes
Message-ID: <200412071302.iB7D2Tt25402@porkchop.devel.redhat.com>

 

 
Updated Packages:

abiword-1:2.2.1-1
-----------------
* Mon Dec 06 2004 Caolan McNamara <caolanm at redhat.com> - 1:2.2.1-1
- bump to new version
- geometry patch upstreamed
- security patch upstreamed
- removeoledecod patch upstreamed
- regenerate desktop patch

authconfig-4.6.7-1
------------------
* Mon Dec 06 2004 Tomas Mraz <tmraz at redhat.com> - 4.6.7-1
- updated translations
- winbind in authconfig-gtk.py was setting the nsswitch.conf on the auth tab
- use GtkComboBox instead of deprecated GtkOptionMenu
- disable options with not installed binaries, remove unnecessary deps of
  authconfig-gtk

bluez-utils-2.10-4
------------------
* Tue Dec 07 2004 Florian La Roche <laroche at redhat.com>
- add prereq for service/chkconfig

coreutils-5.2.1-34
------------------
* Mon Dec 06 2004 Tim Waugh <twaugh at redhat.com> 5.2.1-34
- Don't set fs uid until after pam_open_session (bug #77791)..

exim-4.43-2
-----------
* Mon Dec 06 2004 Thomas Woerner <twoerner at redhat.com> 4.43-2
- rebuild

foomatic-3.0.2-11
-----------------
* Mon Dec 06 2004 Tim Waugh <twaugh at redhat.com> 3.0.2-11
- Updated db to 20041206.

gamin-0.0.19-1
--------------
* Fri Dec 03 2004 Daniel Veillard <veillard at redhat.com> 0.0.19-1
- still chasing the loop bug, made another pass at checking GList,
  added own copy with memory poisonning of GList implementation.
- fixed a compile issue when compiling without debug

glib2-2.4.8-1
-------------
* Mon Dec 06 2004 Matthias Clasen <mclasen at redhat.com> - 2.4.8-1
- Upgrade to 2.4.8

gtk2-2.4.14-1
-------------
* Mon Dec 06 2004 Matthias Clasen <mclasen at redhat.com> - 2.4.14-1
- Upgrade to 2.4.14
- Remove the no longer needed pa.po patch
- Adjust gtk+-2.4.7-update-counter.patch

* Wed Dec 01 2004 Matthias Clasen <mclasen at redhat.com> - 2.4.13-13
- Revert an accidental ABI change.  (#151450)

initscripts-8.01-1
------------------
* Mon Dec 06 2004 Bill Nottingham <notting at redhat.com> 8.01-1
- further bootup noise reductions
- rc.d/rc.sysinit: do implicit unicode conversion on keymap

java-1.4.2-gcj-compat-0:1.4.2.0-21jpp
-------------------------------------
* Mon Dec 06 2004 Gary Benson <gbenson at redhat.com> 0:1.4.2.0-21jpp
- Add tools.jar to CLASSPATH.
- Remove ecj.jar from CLASSPATH.

* Fri Dec 03 2004 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-16jpp
- Add license to java files.

* Fri Dec 03 2004 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-15jpp
- Require gcc-java.
- Add -fullversion.

libpng-2:1.2.8-1
----------------
* Mon Dec 06 2004 Matthias Clasen <mclasen at redhat.com> - 2:1.2.8-1
- Update to 1.2.8

* Wed Sep 15 2004 Matthias Clasen <mclasen at redhat.com> - 2:1.2.7-1
- Update to 1.2.7

* Tue Aug 17 2004 Matthias Clasen <mclasen at redhat.com> - 2:1.2.6-1
- Update to 1.2.6
- Combine patches

libpng10-1.0.18-1
-----------------
* Mon Dec 06 2004 Matthias Clasen <mclasen at redhat.com> - 1.0.18-1
- Update to 1.0.18

rpmdb-fedora-1:4-0.20041207
---------------------------

rsh-0.17-27
-----------
* Mon Dec 06 2004 Karel Zak <kzak at redhat.com> 0.17-27
- remove BSD stuff "signal(SIGCHLD, SIG_IGN)". It's unsupported by POSIX/linux. (#122315)

thunderbird-0:1.0-0.rc1.1
-------------------------
* Mon Dec 06 2004 Christopher Aillon <caillon at redhat.com> 1.0-0.rc1.1
- Fix advanced prefs

valgrind-1:2.2.0-7
------------------
* Mon Dec 06 2004 Jakub Jelinek <jakub at redhat.com> 2.2.0-7
- update URL (#141873)

vim-1:6.3.042-1
---------------
* Mon Dec 06 2004 Karsten Hopp <karsten at redhat.de> 6.3.042-1 
- patchlevel 42



From strange at nsk.no-ip.org  Tue Dec  7 13:46:37 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 7 Dec 2004 13:46:37 +0000
Subject: rawhide report: 20041207 changes
In-Reply-To: <200412071302.iB7D2Tt25402@porkchop.devel.redhat.com>
References: <200412071302.iB7D2Tt25402@porkchop.devel.redhat.com>
Message-ID: <20041207134637.GB13482@nsk.no-ip.org>


Still no util-linux-2.12a-19
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140933).

I need it to recover a partition.

Regards,
Luciano Rocha

-- 
Consciousness: that annoying time between naps.



From enrico.scholz at informatik.tu-chemnitz.de  Tue Dec  7 15:28:52 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 07 Dec 2004 16:28:52 +0100
Subject: Broken %post scriptlets in recent java packages
Message-ID: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>

Hello,

recent java-packages (ant*, xerces*, ...) have scriptlets like

| $ rpm -q --scripts servletapi5-javadoc
| postinstall scriptlet (using /bin/sh):
| rm -f /usr/share/javadoc/servletapi5
| rm -f /usr/share/javadoc/jsp-api
| ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
| ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api


This is really bad code because it does not make sense in an rpm-world
and causes problems in combination with the %_netsharedpath feature.

E.g. when the /usr/share filesystem is shared between several hosts you
can:

* manage (add, remove, modify) files on this filesystem on exactly one
  host, and
* mount this filesystem (e.g. over NFS) as read-only on the other hosts
  and add it to rpm's %_netsharedpath. E.g.

  | # cat /proc/mounts | grep /usr/share
  | morden:/usr/share /usr/share nfs ro,...
  |
  | # rpm --showrc | grep netsha
  | -14: _netsharedpath     ...:/usr/share:...

  Then, rpm will assume the files under /usr/share as existing and does
  not touch them:

  | $ rpm -qs servletapi5-javadoc
  | net shared    /usr/share/javadoc/jsp-api-5.0.18
  | net shared    /usr/share/javadoc/jsp-api-5.0.18/JAVADOC.PLACEHOLDER
  | net shared    /usr/share/javadoc/servletapi5-5.0.18
  | net shared    /usr/share/javadoc/servletapi5-5.0.18/JAVADOC.PLACEHOLDER




In such a scenario, scriptlets like above will fail horribly

| Preparing...                ########################################### [100%]
|    1:servletapi5-javadoc    ########################################### [ 50%]
| rm: cannot remove `/usr/share/javadoc/servletapi5': Read-only file system
| rm: cannot remove `/usr/share/javadoc/jsp-api': Read-only file system
| ln: creating symbolic link `/usr/share/javadoc/servletapi5/servletapi5-5.0.18' to `servletapi5-5.0.18': Read-only file system
| ln: creating symbolic link `/usr/share/javadoc/jsp-api/jsp-api-5.0.18' to `jsp-api-5.0.18': Read-only file system
| error: %post(servletapi5-javadoc-5.0.18-1jpp_3fc) scriptlet failed, exit status 1


As already said, this does not make sense in an rpm-world. There, the
'jsp-api' symlink should be created in the %install stage and packaged
as an ordinary file. Then, rpm will unpack it correctly (inclusive
honoring the %_netsharedpath) and no %post scriptlet is needed.





Enrico



From Nicolas.Mailhot at laPoste.net  Tue Dec  7 15:51:08 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Tue, 07 Dec 2004 16:51:08 +0100
Subject: Broken %post scriptlets in recent java packages
In-Reply-To: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1102434668.9807.5.camel@ulysse.olympe.o2t>

Le mardi 07 d?cembre 2004 ? 16:28 +0100, Enrico Scholz a ?crit :
> Hello,
> 
> recent java-packages (ant*, xerces*, ...) have scriptlets like
> 
> | $ rpm -q --scripts servletapi5-javadoc
> | postinstall scriptlet (using /bin/sh):
> | rm -f /usr/share/javadoc/servletapi5
> | rm -f /usr/share/javadoc/jsp-api
> | ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
> | ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api
> 
> 
> This is really bad code because it does not make sense in an rpm-world
> and causes problems in combination with the %_netsharedpath feature.

This is one of the last raw areas on JPackage 1.6.
To this date no one has found a satisfactory way to build & install
interlinked javadocs (I think you'll find several threads on this
problem in list archives). The current solution is Ville's (I think) and
he publicly stated he didn't like it.

If you're interested by the problem feel free to review specs and
propose solutions on jpackage-discuss at zarb.org. JPackage enhancements
will end up in rawhide then FC/RHEL (and given your heavy Fedora
involvement I can't imagine you not getting direct repo commit access if
you asked for it)

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041207/5af1e0ce/attachment.sig>

From harald at redhat.com  Tue Dec  7 15:55:26 2004
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 07 Dec 2004 16:55:26 +0100
Subject: Fine-tunign of Bluecurve QT theme
In-Reply-To: <1101742092.31196.26.camel@localhost.localdomain>
References: <1101742092.31196.26.camel@localhost.localdomain>
Message-ID: <41B5D26E.7080702@redhat.com>

Peter Backlund wrote:
> Hello.
> 
> I've just opened a general bug about the differences between the QT and
> Gtk Bluecurve styles, with a partial patch. The bug lists quite a few
> differences that I've found (xmag is your friend!). If there are any QT
> hackers on the list who are interested in helping out, please take a
> look at 
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141125
> 
> Bye,
> 
> Peter Backlund
> 

Cool work! Thx!



From michael.favia at insitesinc.com  Tue Dec  7 16:32:32 2004
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 07 Dec 2004 10:32:32 -0600
Subject: Kudzu and automatic detection
In-Reply-To: <41B572ED.4090308@hhs.nl>
References: <20041206223858.B7CA13E66F6@mail.wtamu.edu>
	<41B572ED.4090308@hhs.nl>
Message-ID: <41B5DB20.4060804@insitesinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans de Goede wrote:

|
| Well,
|
| AFAIK this one is easy, just keep a timestamp when the device was
| last seen and nuke it if it hasn't been used for a year.

A simple solution like this makes sense to me. I just wanted to
clarify that we are only keeping the settings/preference files and not
the existence in the GUI for an entire year. If the device is plugged
back in the device becomes active in the UI again. Otherwise i would
have a lot of digital clutter on my desktop and in my printer folder
on my laptop.

- --
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated       http://michael.insitesinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtdsgBVsNYjF2rDYRAhOBAJ9YvGpgmIowp5fWuWZ1j0DrMtk0wgCfRtIv
sWki9J1G+G5AJFKcsiBl068=
=aGOM
-----END PGP SIGNATURE-----



From dax at gurulabs.com  Tue Dec  7 17:48:36 2004
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 07 Dec 2004 10:48:36 -0700
Subject: pam_krb5, NFSv4, AutoFS mounted home dirs (update)
In-Reply-To: <1102403919.4278.54.camel@mentorng.gurulabs.com>
References: <1102403919.4278.54.camel@mentorng.gurulabs.com>
Message-ID: <1102441716.4148.23.camel@mentorng.gurulabs.com>

On Tue, 2004-12-07 at 00:18 -0700, Dax Kelson wrote:

> pam_krb5 creates per session ticket cache files
> as /tmp/krb5cc_p<digits>, while the NFS client's rpcsec_gss daemon
> expects the ticket cache file to be /tmp/krb5cc_$UID.
> 

Turns out this statement needs to be modified.

pam_krb5 does create (or try to create) ticket cache files of the
form /tmp/krb5cc_$UID.

It is the MIT kerberos telnet server and/or the MIT kerberos "login"
replacement (/usr/kerberos/sbin/login.krb5) that creates ticket caches
in the form /tmp/krb5cc_p<4digits>.

So, the gss daemon still needs patching or some other solution created.

Dax Kelson
Guru Labs



From nbargnesi at gmail.com  Tue Dec  7 18:17:13 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Tue, 7 Dec 2004 13:17:13 -0500
Subject: mplayer
In-Reply-To: <3077b8a0041207101326cea4ec@mail.gmail.com>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
	<a227b70c04120613272fd4e10f@mail.gmail.com>
	<1102370328.3346.7.camel@apple.bananas.hopto.org>
	<1102371216.5318.102.camel@serendipity.dogma.lan>
	<1102371579.3346.8.camel@apple.bananas.hopto.org>
	<3077b8a0041207101326cea4ec@mail.gmail.com>
Message-ID: <3077b8a004120710174459cbe9@mail.gmail.com>

Btw, Matthias Saou's http://www.freshrpms.net yum repo has x86_64
packages as well as Dag Wieer's yum repo.  Hopefully I spelled those
right.  A suggestion though, install mplayer's i386 RPMs on your amd64
so you get all the codecs.  There are quite a few codecs not available
when mplayer is built in 64 bit mode.


On Tue, 7 Dec 2004 13:13:58 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> When I've build mplayer from source on x86_64, I've recalled using
> --with-x-libraries=/usr/X11R6/lib64 I believe.  My guess is the
> /usr/X11R6/lib location is being used because 32 bit X libraries are
> installed as well.
> 
> 
> 
> 
> On Mon, 06 Dec 2004 22:19:39 +0000, Si Jones <si at bananas.hopto.org> wrote:
> > On Mon, 2004-12-06 at 23:13 +0100, Alexander Dalloz wrote:
> >
> >
> > > Am Mo, den 06.12.2004 schrieb Si Jones um 22:58:
> > >
> > > > when i check the configure.log it says:
> > > >
> > > > ============ Checking for X11 headers presence ============
> > > > Result is: yes (using /usr/X11R6/include)
> > > > ##########################################
> > > >
> > > > ============ Checking for X11 libs presence ============
> > > > Result is: yes (using /usr/X11R6/lib)
> > > > ##########################################
> > >
> > > I have no x86_64 system, but shouldn't it find the 64bit libs?
> > >
> > > > ============ Checking for X11 ============
> > > >
> > > > #include <X11/Xlib.h>
> > > > #include <X11/Xutil.h>
> > > > int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return
> > > > 0; }
> > > >
> > > > cc     /tmp/mplayer-conf-7136-12478.c -o /tmp/mplayer-conf-15235-12478.o
> > > > -I/usr/X11R6/include -L/usr/X11R6/lib -lXext -lX11 -lnsl
> > >
> > > Shouldn't it be -L/usr/X11R6/lib64?
> > >
> > > > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when
> > > > searching for -lXext
> > > > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when
> > > > searching for -lXext
> > > > /usr/bin/ld: cannot find -lXext
> > > > collect2: ld returned 1 exit status
> > >
> > Which file do i need to change then for this????
> >
> >
> >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> 
> --
> 
> Nick Bargnesi
> http://www.den-4.com
> Den 4 Software
> 
> pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
> Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
> sub  2048g/56C5D45B 2004-12-02
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From nbargnesi at gmail.com  Tue Dec  7 18:13:58 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Tue, 7 Dec 2004 13:13:58 -0500
Subject: mplayer
In-Reply-To: <1102371579.3346.8.camel@apple.bananas.hopto.org>
References: <1102368024.3346.2.camel@apple.bananas.hopto.org>
	<a227b70c04120613272fd4e10f@mail.gmail.com>
	<1102370328.3346.7.camel@apple.bananas.hopto.org>
	<1102371216.5318.102.camel@serendipity.dogma.lan>
	<1102371579.3346.8.camel@apple.bananas.hopto.org>
Message-ID: <3077b8a0041207101326cea4ec@mail.gmail.com>

When I've build mplayer from source on x86_64, I've recalled using
--with-x-libraries=/usr/X11R6/lib64 I believe.  My guess is the
/usr/X11R6/lib location is being used because 32 bit X libraries are
installed as well.



On Mon, 06 Dec 2004 22:19:39 +0000, Si Jones <si at bananas.hopto.org> wrote:
> On Mon, 2004-12-06 at 23:13 +0100, Alexander Dalloz wrote:
> 
> 
> > Am Mo, den 06.12.2004 schrieb Si Jones um 22:58:
> >
> > > when i check the configure.log it says:
> > >
> > > ============ Checking for X11 headers presence ============
> > > Result is: yes (using /usr/X11R6/include)
> > > ##########################################
> > >
> > > ============ Checking for X11 libs presence ============
> > > Result is: yes (using /usr/X11R6/lib)
> > > ##########################################
> >
> > I have no x86_64 system, but shouldn't it find the 64bit libs?
> >
> > > ============ Checking for X11 ============
> > >
> > > #include <X11/Xlib.h>
> > > #include <X11/Xutil.h>
> > > int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return
> > > 0; }
> > >
> > > cc     /tmp/mplayer-conf-7136-12478.c -o /tmp/mplayer-conf-15235-12478.o
> > > -I/usr/X11R6/include -L/usr/X11R6/lib -lXext -lX11 -lnsl
> >
> > Shouldn't it be -L/usr/X11R6/lib64?
> >
> > > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.so when
> > > searching for -lXext
> > > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXext.a when
> > > searching for -lXext
> > > /usr/bin/ld: cannot find -lXext
> > > collect2: ld returned 1 exit status
> > 
> Which file do i need to change then for this????
> 
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From kyrre at solution-forge.net  Tue Dec  7 19:24:26 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 07 Dec 2004 20:24:26 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <41B59FE4.7030407@iee.lu>
References: <1102332114.3973.18.camel@localhost.localdomain>
	<604aa7910412060700306166f4@mail.gmail.com>
	<1102345656.18495.28.camel@localhost.localdomain>
	<200412062044.19981.ronny-vlug@vlugnet.org>
	<20041206203244.GB4757@nostromo.devel.redhat.com>
	<1102369899.3371.13.camel@localhost.localdomain>
	<1102370434.10277.3.camel@laptop.fenrus.org> <41B59FE4.7030407@iee.lu>
Message-ID: <1102447466.3891.6.camel@kyrre>

tir, 07.12.2004 kl. 13.19 skrev Charles Lopes:
> Arjan van de Ven wrote:
> 
> >On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
> >  
> >
> >>On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
> >>    
> >>
> >>>To really speed things up, all you have to declare is that all serial
> >>>mice must be manually configured... 
> >>>      
> >>>
> >>So maybe it's actually time to at least default to ignoring certain
> >>types of legacy hardware by default? 
> >>    
> >>
> >
> >or... if you find a ps.2 or usb mouse skip the serial probing.. the
> >chance of having BOTH a ps2 one and a serial one are pretty low after
> >all :)
> >  
> >
> Except if you happen to have both a mouse and a trackball. I have seen 
> quite a few workstations equiped with a PS2 mouse and a serial 
> trackball. It was quite a common setup for CAD stations just a couple of 
> years ago.

A pc i administer has that setup. It has a (fairly broken) ps/2-mouse,
and an old ps/2 trackball connected. I haven't removed the mouse since
most users just stare at you when you tell them that the huge box
sitting besides the computer is used for the tasks as a mouse...

Yes i know... I *should* replace the mouse...

Now i didn't have any problem with starting system-config-mouse and
configuring the thing. It was quite easy, could even be done from the
console! :)

Now i would scream i suddenly wasn't able to hotplug a (ps/2 or USB)
mouse into my laptop and instantly start using it. I hear a windows
admin i know rumbeling over that his box'en dont do that... Very funny
when you have a lot of morons thinking "steal the mouse" is the worlds
funnyest game... While he and his users has to bloody reboot (well, its
windows after all), all i and my users has to do is bend over and
replace the plug, and continue working. That kindof takes the fun out of
it...

Kyrre



From kyrre at solution-forge.net  Tue Dec  7 19:32:38 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 07 Dec 2004 20:32:38 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <41B5DB20.4060804@insitesinc.com>
References: <20041206223858.B7CA13E66F6@mail.wtamu.edu>
	<41B572ED.4090308@hhs.nl>  <41B5DB20.4060804@insitesinc.com>
Message-ID: <1102447957.3891.10.camel@kyrre>

tir, 07.12.2004 kl. 17.32 skrev Michael Favia:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hans de Goede wrote:
> 
> |
> | Well,
> |
> | AFAIK this one is easy, just keep a timestamp when the device was
> | last seen and nuke it if it hasn't been used for a year.
> 
> A simple solution like this makes sense to me. I just wanted to
> clarify that we are only keeping the settings/preference files and not
> the existence in the GUI for an entire year. If the device is plugged
> back in the device becomes active in the UI again. Otherwise i would
> have a lot of digital clutter on my desktop and in my printer folder
> on my laptop.
> 

What about making the printer stopped in cups, and then make sure
programs actually don't print to it? (ie. changing something in the UI
when printer is stopped)

If the user really has thrown away the printer, let the *user* delete it
from system-config-printer. It ain't that hard to find and figure out,
most of those config tools are pretty good AND understandable.



From Hugh_Caley at affymetrix.com  Tue Dec  7 19:57:35 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Tue, 07 Dec 2004 11:57:35 -0800
Subject: Stale NFS Filehandles and Permission Denied
Message-ID: <41B60B2F.80907@affymetrix.com>

BTW, upgrading to 2.6.9-1.6_FC2smp seems to have fixed our stale NFS 
Filehandle problem.

Hugh

-- 
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley at affymetrix.com



From giovannialzetta at yahoo.it  Tue Dec  7 18:36:57 2004
From: giovannialzetta at yahoo.it (Giovanni Alzetta)
Date: Tue, 7 Dec 2004 19:36:57 +0100
Subject: HELP!!! hda error!!!
Message-ID: <200412071936.57865.giovannialzetta@yahoo.it>

Well, one my friend have 2 hard disk. So I installed fedora linux on the 
second. Now when I start fedora I see a hda system control than an error and 
something like this:
"enter root password"
"or type ctrl+d"
if I press ctrl+d I reboot the computer. If I enter the root password I'm in a 
"read only" file system, so I can't do anything.
I do that: install fedora, at the start I saw a hda control, but nothing of 
strange, than copy some files from windows to fedora and erase those files in 
windows. Than I reboot the computer and BOOM!!! The error come.
So I tried with knoppix to copy files from fedora to windows, but I can't go 
in the home, I just can't read files from that home.
So there are two solutions:
-how to read files with knoppix?
- how to erase the error with fedora
Thanks for help!!!!!! (please answer!)
bye bye
P.S. I think that the hard disk of the my friend don't work very well, because 
windows become crazy every 2-3 months. (and sorry for my bad English)



From mike at navi.cx  Tue Dec  7 20:05:36 2004
From: mike at navi.cx (Mike Hearn)
Date: Tue, 07 Dec 2004 20:05:36 +0000
Subject: Wine/Cedega and fedora 3
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
Message-ID: <pan.2004.12.07.20.05.34.577743@navi.cx>

On Mon, 06 Dec 2004 09:00:52 -0500, John (J5) Palmieri wrote:
> These are bug with the way Cedega works.

No, it's an incompatibility between the Linux VM layout and the Windows VM
layout. Up until the introduction of execshield there was no need to
enforce this, on any platform. There are no "bugs" here.

> Changing Fedora to work around a program's bugs would be wrong.

No, actually it wouldn't be wrong. Some bugs will never be fixed (think
unmaintained proprietary apps) and some bugs could be but a fix
won't be available for a while. Fedora is supposed to be useful, right? So
if an app which a lot of people need doesn't work, it's not being useful.

> Cedrega should be fixed.

You say that like it's a trivial 2 minute typo or something. It's not. The
current approach taken in WineHQ (which TransGaming can't easily use due
to the LGPL license not working with their business model) is the *third*
attempt at a working solution.

The first failed on systems with overcommit disabled, and didn't protect
all VM areas anyway.

The second blocked on a kernel bug. This is the PT_LOAD approach Jakub
suggested elsewhere in the thread. Unfortunately this bug was only
discovered *after* I had implemented it and found it didn't work. A fix
was developed for said bug, but it didn't work on some obscure CPU arch
the patch developer didn't have access to, and was dropped.

The third is what we use now, and it took many months to stabilise and
work out all the problems with vDSO kernels, aggressive compiler
optimizations, systems that ship TLS enabled static libcs, and a host of
other bugs I've probably forgotten about. Here is the code:

  http://source.winehq.org/source/loader/preloader.c

Pretty isn't it? If you can understand all of it on first reading, well
done, have a cookie. The Cedega team is much smaller than the WineHQ
community is (about 4-5 people). I did talk
to one of the TG guys about this and he strongly implied that they would
not be fixing this problem: switching off execshield/prelink would
continue to be the recommended way of making Cedega work. 

So this is one of these "bugs" that will probably never be fixed. Ever.

In short by the time a good solution was found for
Wine+execshield/prelink, over a year had passed. Most
of the work was done by CodeWeavers although much of the preliminary R&D
was done by me as a volunteer before I joined the company.

Unfortunately like a lot of Red Hatters you seem to see the world in black
and white. Especially you are very fast to blame others "buggy code" when
problems arise. This attitude is quite tiring: do you realise that every
single Red Hat/Fedora release from RH9 onwards has broken Wine in some
way? Every single one? Usually these were not simple things to fix. They
required extremely complex re-working of core code which few understand.

I'm not saying execshield or prelink or NPTL or the 4G VM patch or
anything else that broke it are bad technologies, they aren't and I am
very happy that we were able to find a solution that allows Wine to work
when they're active. But please, have a more considerate attitude for
those of us that have sunk months into dealing with these sparkly new
features instead of writing things off as "bugs" which "should be fixed".

thanks -mike



From kyrre at solution-forge.net  Tue Dec  7 20:10:31 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 07 Dec 2004 21:10:31 +0100
Subject: adventures in booting
In-Reply-To: <20041204165159.GA1633@nostromo.devel.redhat.com>
References: <1101692986.2025.22.camel@davidz>
	<1101869999.3544.65.camel@serenity.klika.si>
	<1102006136.12241.53.camel@davidz> <20041202165844.GF25551@redhat.com>
	<1102009206.12241.89.camel@davidz>
	<1102010395.4024.21.camel@nexus.verbum.private>
	<1102169787.2686.9.camel@kyrre>
	<20041204165159.GA1633@nostromo.devel.redhat.com>
Message-ID: <1102450231.3891.25.camel@kyrre>

l?r, 04.12.2004 kl. 17.51 skrev Bill Nottingham:
> Kyrre Ness Sjobak (kyrre at solution-forge.net) said: 
> > Hmm... /boot is usually quite "overbig", and must be situated within a
> > booting (ie. not at the end) part of the disk...
> 
> Sure, just have mkinitrd have the *entire* filesystem image
> on the initrd... :)
> 

Great idea! Now you only need one rpm installed - the kernel one :) Just
imagine how easy that would make upgrading the system...



From kyrre at solution-forge.net  Tue Dec  7 20:13:06 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 07 Dec 2004 21:13:06 +0100
Subject: HELP!!! hda error!!!
In-Reply-To: <200412071936.57865.giovannialzetta@yahoo.it>
References: <200412071936.57865.giovannialzetta@yahoo.it>
Message-ID: <1102450385.3891.27.camel@kyrre>

tir, 07.12.2004 kl. 19.36 skrev Giovanni Alzetta:
> Well, one my friend have 2 hard disk. So I installed fedora linux on the 
> second. Now when I start fedora I see a hda system control than an error and 
> something like this:
> "enter root password"
> "or type ctrl+d"
> if I press ctrl+d I reboot the computer. If I enter the root password I'm in a 
> "read only" file system, so I can't do anything.
> I do that: install fedora, at the start I saw a hda control, but nothing of 
> strange, than copy some files from windows to fedora and erase those files in 
> windows. Than I reboot the computer and BOOM!!! The error come.
> So I tried with knoppix to copy files from fedora to windows, but I can't go 
> in the home, I just can't read files from that home.
> So there are two solutions:
> -how to read files with knoppix?
> - how to erase the error with fedora
> Thanks for help!!!!!! (please answer!)
> bye bye
> P.S. I think that the hard disk of the my friend don't work very well, because 
> windows become crazy every 2-3 months. (and sorry for my bad English)

You could try to fsck it from the rescue-cd/knoppix etc.

Note that this belongs on the *user* list.



From alan at redhat.com  Tue Dec  7 20:19:33 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 7 Dec 2004 15:19:33 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <pan.2004.12.07.20.05.34.577743@navi.cx>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
Message-ID: <20041207201933.GC3589@devserv.devel.redhat.com>

On Tue, Dec 07, 2004 at 08:05:36PM +0000, Mike Hearn wrote:
> when they're active. But please, have a more considerate attitude for
> those of us that have sunk months into dealing with these sparkly new
> features instead of writing things off as "bugs" which "should be fixed".

Wine was always buggy, it made an assumption that the LSB, POSIX, and SuS didnt
allow. That doesn't have a lot to do with whether people appreciate the amount
of work required and done to resolve it. 

As to Cedega well if they want to be proprietary they have to fix their own bugs
There isn't any danger of the arch setting stuff going away in a hurry, there is
a lot of old proprietary stuff that needs this and nobody wants to break it
pointlessly. The original proposal for default insecurity however is not good
and quite different.




From mike at navi.cx  Tue Dec  7 21:31:52 2004
From: mike at navi.cx (Mike Hearn)
Date: Tue, 07 Dec 2004 21:31:52 +0000
Subject: Wine/Cedega and fedora 3
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<20041207201933.GC3589@devserv.devel.redhat.com>
Message-ID: <pan.2004.12.07.21.31.51.414095@navi.cx>

On Tue, 07 Dec 2004 15:19:33 -0500, Alan Cox wrote:
> Wine was always buggy, it made an assumption that the LSB, POSIX, and SuS didnt
> allow. That doesn't have a lot to do with whether people appreciate the amount
> of work required and done to resolve it.

Yes, I thought you might say that. Technically there's a possibility that
it'll rain for a week solid in Wales and your house will be washed away.
Presumably you don't have a wall of sandbags permenantly in place to
guard against this? Of course, there are no guarantees it
won't happen, but presumably you'd still appreciate a bit of help if it
did.

We could attempt to anticipate every potential possibility allowed under
every standard implemented by the kernel, and then code around them. But
then we'd spend all our time writing code that didn't actually do anything
for the users, instead of making stuff work.



From alan at redhat.com  Tue Dec  7 21:34:59 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 7 Dec 2004 16:34:59 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <pan.2004.12.07.21.31.51.414095@navi.cx>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<20041207201933.GC3589@devserv.devel.redhat.com>
	<pan.2004.12.07.21.31.51.414095@navi.cx>
Message-ID: <20041207213459.GA8011@devserv.devel.redhat.com>

On Tue, Dec 07, 2004 at 09:31:52PM +0000, Mike Hearn wrote:
> Yes, I thought you might say that. Technically there's a possibility that
> it'll rain for a week solid in Wales and your house will be washed away.

You've never been here have you. It regularly does that

> Presumably you don't have a wall of sandbags permenantly in place to
> guard against this? Of course, there are no guarantees it

Folks in other bits of town do 8)

> We could attempt to anticipate every potential possibility allowed under
> every standard implemented by the kernel, and then code around them. But
> then we'd spend all our time writing code that didn't actually do anything
> for the users, instead of making stuff work.

Agreed. I know why code takes shortcuts or avoids nasties like that. I write
code that does just the same, but at the end of the day its that code which
is buggy.




From mike at navi.cx  Tue Dec  7 21:49:34 2004
From: mike at navi.cx (Mike Hearn)
Date: Tue, 07 Dec 2004 21:49:34 +0000
Subject: Wine/Cedega and fedora 3
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<20041207201933.GC3589@devserv.devel.redhat.com>
	<pan.2004.12.07.21.31.51.414095@navi.cx>
	<20041207213459.GA8011@devserv.devel.redhat.com>
Message-ID: <pan.2004.12.07.21.49.29.236040@navi.cx>

On Tue, 07 Dec 2004 16:34:59 -0500, Alan Cox wrote:
> You've never been here have you. It regularly does that

Oh, a fair few holidays ended up that way, that's why I chose it as an
example :)
 
> Agreed. I know why code takes shortcuts or avoids nasties like that. I
> write code that does just the same, but at the end of the day its that
> code which is buggy.

Yeah, it was buggy in the sense that it's our responsibility to
fix (and we did). No argument there. Still, I thought I'd point out to J5
that Cedega is likely to never be fixed in the same way. Also it's not
always a black and white "they fucked up, so they deserve to lose" type
issue.



From ben.steeves at gmail.com  Tue Dec  7 22:19:00 2004
From: ben.steeves at gmail.com (Ben Steeves)
Date: Tue, 7 Dec 2004 18:19:00 -0400
Subject: Wine/Cedega and fedora 3
In-Reply-To: <pan.2004.12.07.21.49.29.236040@navi.cx>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<20041207201933.GC3589@devserv.devel.redhat.com>
	<pan.2004.12.07.21.31.51.414095@navi.cx>
	<20041207213459.GA8011@devserv.devel.redhat.com>
	<pan.2004.12.07.21.49.29.236040@navi.cx>
Message-ID: <7ebb24d104120714192eff015e@mail.gmail.com>

On Tue, 07 Dec 2004 21:49:34 +0000, Mike Hearn <mike at navi.cx> wrote:
> that Cedega is likely to never be fixed in the same way. Also it's not
> always a black and white "they fucked up, so they deserve to lose" type
> issue.
> 

Sadly, when developers (be they kernel or app) take that stance,
ultimately it's the USERS who lose.  And that mindset is a huge hurdle
to widespread adoption of Linux.

-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From warren at togami.com  Tue Dec  7 21:36:42 2004
From: warren at togami.com (Warren Togami)
Date: Tue, 07 Dec 2004 11:36:42 -1000
Subject: HELP!!! hda error!!!
In-Reply-To: <200412071936.57865.giovannialzetta@yahoo.it>
References: <200412071936.57865.giovannialzetta@yahoo.it>
Message-ID: <41B6226A.6070707@togami.com>

Giovanni Alzetta wrote:
> Well, one my friend have 2 hard disk. So I installed fedora linux on the 
> second. Now when I start fedora I see a hda system control than an error and 
> something like this:
> "enter root password"
> "or type ctrl+d"
> if I press ctrl+d I reboot the computer. If I enter the root password I'm in a 
> "read only" file system, so I can't do anything.
> I do that: install fedora, at the start I saw a hda control, but nothing of 
> strange, than copy some files from windows to fedora and erase those files in 
> windows. Than I reboot the computer and BOOM!!! The error come.
> So I tried with knoppix to copy files from fedora to windows, but I can't go 
> in the home, I just can't read files from that home.
> So there are two solutions:
> -how to read files with knoppix?
> - how to erase the error with fedora
> Thanks for help!!!!!! (please answer!)
> bye bye
> P.S. I think that the hard disk of the my friend don't work very well, because 
> windows become crazy every 2-3 months. (and sorry for my bad English)
> 

http://fedora.linux.duke.edu/wiki/index.cgi/PostIsOffTopic
fedora-devel-list is NOT for user support questions.  Please use the 
appropriate list.

Warren Togami
wtogami at redhat.com



From seanlkml at sympatico.ca  Tue Dec  7 22:44:28 2004
From: seanlkml at sympatico.ca (Sean)
Date: Tue, 7 Dec 2004 17:44:28 -0500 (EST)
Subject: Wine/Cedega and fedora 3
In-Reply-To: <7ebb24d104120714192eff015e@mail.gmail.com>
References: <1102331754.3973.11.camel@localhost.localdomain><1102341652.18495.14.camel@localhost.localdomain><pan.2004.12.07.20.05.34.577743@navi.cx><20041207201933.GC3589@devserv.devel.redhat.com><pan.2004.12.07.21.31.51.414095@navi.cx><20041207213459.GA8011@devserv.devel.redhat.com><pan.2004.12.07.21.49.29.236040@navi.cx><7ebb24d104120714192eff015e@mail.gmail.com>
Message-ID: <35470.10.10.10.28.1102459468.squirrel@linux1>

On Tue, December 7, 2004 5:19 pm, Ben Steeves said:
>
> Sadly, when developers (be they kernel or app) take that stance,
> ultimately it's the USERS who lose.  And that mindset is a huge
> hurdle to widespread adoption of Linux.
>

Huh?  Linux does have widespread adoption.  Mac, BSD, and others haven't
been accused of such a mindset and don't have MS Windows like numbers
either.  People really over estimate this "mindset" issue and its
importance as the reason Linux hasn't dominated the desktop market yet.

Personally, i'm getting tired of people criticising the developers
attitudes.   Developers work for *their own* users, and most are doing a
good job.   If a developer doesn't bend over backwards to accomodate
someone elses needs, then he's obviously concluded that the effort would
not benefit *his* user base.  period.  That is the way open source has
worked to make Linux as successful as it has become today.  Why lament a
process that has worked so well?

Sean




From michael.favia at insitesinc.com  Wed Dec  8 00:26:40 2004
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 07 Dec 2004 18:26:40 -0600
Subject: Kudzu and automatic detection
In-Reply-To: <1102447957.3891.10.camel@kyrre>
References: <20041206223858.B7CA13E66F6@mail.wtamu.edu>	<41B572ED.4090308@hhs.nl>
	<41B5DB20.4060804@insitesinc.com> <1102447957.3891.10.camel@kyrre>
Message-ID: <41B64A40.7080803@insitesinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyrre Ness Sjobak wrote:
| What about making the printer stopped in cups, and then make sure
| programs actually don't print to it? (ie. changing something in the UI
| when printer is stopped)
|
| If the user really has thrown away the printer, let the *user* delete it
| from system-config-printer. It ain't that hard to find and figure out,
| most of those config tools are pretty good AND understandable.
|

While i dont know if it is the best solution i struggle to think of a
more elegant one and it sounds decently reasonable to me.

My only concern is that i like to unify the operation of devices and
interfaces as much as possible so users have to learn as little as
possible to work with their system compentently.

To that end i would imagine that treating all hot-pluggable devices as
similiarly (as is reasonable) is the best route. That way when a user
plugs in a USB key, digicam or USB printer the operations the user makes
with the GUI are familiar (a real issue for beginners).

Perhaps some stoage mechanism to record the previous settings for the
device and save them in the background until the device is plugged back
in again really is the best method.

I dont like the idea of hidden settings that activate (sounds like
malware) but it shouldnt be too difficult to integrate a reset to
defaults option.

- --
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated       http://michael.insitesinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtkpABVsNYjF2rDYRAkWqAJ4uFHgZRGxBnUu4Pl8Gusiuj8zi5ACeNQNn
KTb8hSQokwB7aiediJWoQvc=
=IJKm
-----END PGP SIGNATURE-----



From veillard at redhat.com  Wed Dec  8 00:49:52 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Tue, 7 Dec 2004 19:49:52 -0500
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <ed0efd31041205111711d4e097@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
	<41B34C0A.7030104@awesomeplay.com>
	<ed0efd31041205111711d4e097@mail.gmail.com>
Message-ID: <20041208004952.GB25551@redhat.com>

On Sun, Dec 05, 2004 at 04:17:36PM -0300, Avi Alkalay wrote:
> On Sun, 05 Dec 2004 12:57:30 -0500, Sean Middleditch
> <elanthis at awesomeplay.com> wrote:
> > Avi Alkalay wrote:
> > 
> > >I'm having a look at inotify, which is the basis for gamin.
> > >
> > >
> > 
> > Don't tie your code to inotify, tie it to something like gamin.  Gamin
> > can abstract away the different OS interfaces, so that machines without
> > inotify will still have some form of notification (dnotify, polling,
> > whatever).  There's no good reason to reimplement that code yourself.
> 
> Yeah I know.... I'll try to stick in the high level, but I'm worried
> about dependencies. It makes no sense to have /lib/libkdb.so depending
> on libs under /usr/lib.
> 
> The 5 minutes I spent reading about inotify made me believe it is a
> kernel module, but I couldn't find it, nor the /dev entry, nor the
> dmesg messages in the FC2 machine I have close to me right now. Is
> this stuff already included in regular distros kernels ?

  Use gamin. If inotify is present it will use it, if not it will fallback
to whatever is available. And if you're on Solaris, you can still use FAM
to provide the equivalent API as gamin.
  And gamin only dependancy on the client side is libc, you really have no
excuse to not use it :-)

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From mpeters at mac.com  Wed Dec  8 01:02:53 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Wed, 08 Dec 2004 01:02:53 +0000
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102467595l.5036l.1l@devel.mpeters.us> (from mpeters@mac.com
	on Tue Dec  7 16:59:55 2004)
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
Message-ID: <1102467773l.5036l.2l@devel.mpeters.us>

An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 2150
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/5be67387/attachment.eml>

From jspaleta at gmail.com  Wed Dec  8 01:09:45 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 7 Dec 2004 20:09:45 -0500
Subject: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102467773l.5036l.2l@devel.mpeters.us>
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
Message-ID: <604aa7910412071709236825ce@mail.gmail.com>

On Wed, 08 Dec 2004 01:02:53 +0000, Michael A. Peters <mpeters at mac.com> wrote:
> Maybe "Fedora Extras" is the right place for these packages, but I
> don't know, packages in "Extras" should link against current shared
> libraries, and extras maintaining compat-* packages may result in some
> maintainers using those instead of rebuilding/patching when needed.

Take a look at the Terminology page on the fedora website. This sounds
like something the Fedora Alternatives namespace is suppose to cover
somewhere along the line.

-jef



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec  8 02:05:54 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 08 Dec 2004 03:05:54 +0100
Subject: Broken %post scriptlets in recent java packages
In-Reply-To: <1102434668.9807.5.camel@ulysse.olympe.o2t> (Nicolas Mailhot's
	message of "Tue, 07 Dec 2004 16:51:08 +0100")
References: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1102434668.9807.5.camel@ulysse.olympe.o2t>
Message-ID: <87y8g95yt9.fsf@kosh.ultra.csn.tu-chemnitz.de>

Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes:

>> recent java-packages (ant*, xerces*, ...) have scriptlets like
>> 
>> | $ rpm -q --scripts servletapi5-javadoc
>> | postinstall scriptlet (using /bin/sh):
>> | rm -f /usr/share/javadoc/servletapi5
>> | rm -f /usr/share/javadoc/jsp-api
>> | ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
>> | ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api
>> 
>> 
>> This is really bad code because it does not make sense in an rpm-world
>> and causes problems in combination with the %_netsharedpath feature.
> ...
> If you're interested by the problem feel free to review specs and
> propose solutions on jpackage-discuss at zarb.org.

I fear that my preferred solution (%macro magic) will conflict with
policies of jpackage. The feature that every /etc/rpm/macros.* file will
be read by rpm is relatively new and might not exist on all jpackage
platforms.

Missing backward-compatibility will not be a problem on FC so it could
be used there.



Enrico



From avibrazil at gmail.com  Wed Dec  8 02:14:24 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Tue, 7 Dec 2004 23:14:24 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <20041208004952.GB25551@redhat.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
	<41B34C0A.7030104@awesomeplay.com>
	<ed0efd31041205111711d4e097@mail.gmail.com>
	<20041208004952.GB25551@redhat.com>
Message-ID: <ed0efd3104120718146ccb9cc2@mail.gmail.com>

On Tue, 7 Dec 2004 19:49:52 -0500, Daniel Veillard <veillard at redhat.com> wrote:
>   Use gamin. If inotify is present it will use it, if not it will fallback
> to whatever is available. And if you're on Solaris, you can still use FAM
> to provide the equivalent API as gamin.
>   And gamin only dependancy on the client side is libc, you really have no
> excuse to not use it :-)

OK about the client. But to really have it, I imagine you need the server too.
So then what early bootup programs (when you still don't have /usr/lib
mounted or any services running) will have ?

Thank you,
Avi



From avibrazil at gmail.com  Wed Dec  8 02:17:28 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Tue, 7 Dec 2004 23:17:28 -0300
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <ed0efd3104120718146ccb9cc2@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
	<41B34C0A.7030104@awesomeplay.com>
	<ed0efd31041205111711d4e097@mail.gmail.com>
	<20041208004952.GB25551@redhat.com>
	<ed0efd3104120718146ccb9cc2@mail.gmail.com>
Message-ID: <ed0efd3104120718171cb7e705@mail.gmail.com>

On Tue, 7 Dec 2004 23:14:24 -0300, Avi Alkalay <avibrazil at gmail.com> wrote:
> 
> 
> On Tue, 7 Dec 2004 19:49:52 -0500, Daniel Veillard <veillard at redhat.com> wrote:
> >   Use gamin. If inotify is present it will use it, if not it will fallback
> > to whatever is available. And if you're on Solaris, you can still use FAM
> > to provide the equivalent API as gamin.
> >   And gamin only dependancy on the client side is libc, you really have no
> > excuse to not use it :-)
> 
> OK about the client. But to really have it, I imagine you need the server too.
> So then what early bootup programs (when you still don't have /usr/lib
> mounted or any services running) will have ?
> 

Well, maybe not depend on gamin, FAM etc, through dlopen, and handle
linking errors, and not providing notification in early boot
stage.....



From elanthis at awesomeplay.com  Wed Dec  8 03:00:32 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Tue, 07 Dec 2004 22:00:32 -0500
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102467773l.5036l.2l@devel.mpeters.us>
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
Message-ID: <1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>

On Wed, 2004-12-08 at 01:02 +0000, Michael A. Peters wrote:
> email message attachment
> On Wed, 2004-12-08 at 01:02 +0000, Michael A. Peters wrote:
> > Cross posted (from fedora users to fedora-devel ... maybe we need a  
> > fedora-philosophy list ? ;)
> > 
> > On 12/07/2004 12:34:23 PM, Aleksandar Milivojevic wrote:
> > > Paul Howarth wrote:
> > >> http://www.city-fan.org/ftp/contrib/sysutils/Mirroring/compat-libcurl-7.11.2-2.i386.rpm
> > > 
> > > I'd kind of expect this RPM to be part of FC3 distro, but it wasn't.
> > 
> > I agree.
> > I've had to package a couple compat libraries myself (libgal2 and  
> > libgtkhtml3) as software I needed refused to compile against the fc3  
> > (gnome 2.8) versions, but did fine against the fc2 (gnome 2.6)  
> > versions.
> > 
> > I'm not sure they should be installed by default on a fc3 system -  
> > compat-libstdc++ does because fc3 ships with software that wants it (I  
> > think OO.o) - but what would be *nice* is if a fedora-compat repository  
> > were somewhat maintained that included binary compat shared libraries  
> > for cases such as these, where a third party package wants an older  
> > version of a shared library.

This whole compat-foo thing Red Hat/Fedora does is so incredibly goofy.
It's a great example of the poor (non-existent, perhaps) packaging
standards employed in those distros.

Let's look at an example.  Use has libfoo installed in FCX.  FCY comes
along with a new major version of libfoo, and a compat-libfoo.  Several
more revisions of FC late, libfoo is one or two more versions along, and
compat-libfoo is either no longer in the distro, or doesn't have the
version of foo from FCX.  The user upgrades, perhaps does a fresh
reinstall - either way, it doesn't matter, because the user will find
that apps installed in FCX (quite possibly third party apps) no longer
work.

And what about the maintenance cost of the compat packages?  Keeping a
compat-foo package that has several major revisions in it cannot be
something the maintainers enjoy doing.

If the packages had just used a more intelligent naming scheme, this
problem wouldn't exist, ever.  Name the packages libfoo1, libfoo2, etc.
Get rid of the compat-foo stuff.  If you upgrade, libfoo1 stays around,
libfoo2 is installed, no problems.  Ten years down the road (assuming
the glibc/gcc gods don't decide to screw users over again and break tons
of ABI) you can still install your apps that relies on libfoo1.  You may
not have that package, but you can grab it online and install it, and it
just works.  No worries that you need an old version of compat-foo that
need manual rpm -i invocation to install alongside the current compat-
foo, no worries about having a 100MB compat-foo, etc.

It gets better.  Most of the Fedora Core 1 Extras installed on FC2, and
many install on FC3.  Most of the FC2 Extra install on FC3.  Most of the
conflicts I do run into are *not* problems with the underlying software
but just poor packaging.  Switching to a libfoo<version> scheme, and you
could even get rid of the multi-distro Extra.  Why have your servers
store 3 copies of Extras when you can just have one?

That also has better implications for third party packages, which quite
a few users use.  Even with the bazillion CDs distro ship these days (it
really does seem like the Linux distribution version of a penis
comparison sometimes, doesn't it?) users often need or want third party
packages.  Even for a lot of software Fedora ships I still use third
party versions because it's goofy to have to upgrade an entire OS (and
wait for said upgrade to be released, even if it is no more than 6
months) to get an updated package with bugs fixed.

Fedora released are packaged like appliances.  They're only intended to
work with themself, and external packages only if they customize
themself to the specific Fedora release.  It doesn't have to be that
way.  The distribution can be a *platform*.  Commercial *and* Open
Source ISVs, and the users themselves, benefit from having a platform.

It's not a big task.  Just fixing the small, simple things like the curl
package is really all that's needed in most cases.  The fact that, as I
said, Fedora Core 1 Extras *mostly* install fine on FC3 proves that.



From mpeters at mac.com  Wed Dec  8 05:11:03 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Wed, 08 Dec 2004 05:11:03 +0000
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
	(from elanthis@awesomeplay.com on Tue Dec  7 19:00:32 2004)
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
	<1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
Message-ID: <1102482663l.5810l.1l@devel.mpeters.us>

On 12/07/2004 07:00:32 PM, Sean Middleditch wrote:

> 
> If the packages had just used a more intelligent naming scheme, this
> problem wouldn't exist, ever.  Name the packages libfoo1, libfoo2,
> etc.
> Get rid of the compat-foo stuff.  If you upgrade, libfoo1 stays
> around,
> libfoo2 is installed, no problems.  Ten years down the road (assuming
> the glibc/gcc gods don't decide to screw users over again and break
> tons
> of ABI) you can still install your apps that relies on libfoo1.

Assuming that libfoo2 and libfoo1 don't install conflicting files. This  
is the case with curl - both packages install a /usr/bin/curl binary.

Sure, you could separate out libcurl from curl and have curl depend  
upon libcurl, or you can just make a compat-libcurl package that  
installs alongside current curl and only provides an older version of  
the shared library. Ten years down the road you can still install that  
same compat-libcurl package, and maybe even have 3 or 4 other compat- 
libcurl packages installed right next to it. There is no problem with  
the rpm naming scheme. The only reason for calling it compat-libfoo  
instead of just libfoo is to make it easier for users. Note that there  
are several kernel packages all named kernel - all getting along.

There is nothing wrong with the current naming scheme, in fact, it is  
better for cases where MightyApp depends upon libfoo but builds against  
several different versions - then MightyApp just needs libfoo-devel to  
build and doesn't have to care about version in the name.

Oh - and it probably is better to rebuild the compat packages for each  
new release of the distro, rather than keep using the same 10 year old  
build. Not because you have to, but because if libfoo links against  
libbar, and succesfully builds against a new current version of libbar,  
then the user can have a compat-libfoo that uses current libbar and  
doesn't need a compat-libbar.

The less compat packages a user has to have, the better, because older  
versions of libraries are going to take the longest to be security  
patched because they are low demand and patches have to be back-ported.

When compat libraries are used, it should be understand the library is  
depricated and the compat library is provided as a convenience until  
your software is updated.




From seanlkml at sympatico.ca  Wed Dec  8 05:24:09 2004
From: seanlkml at sympatico.ca (Sean)
Date: Wed, 8 Dec 2004 00:24:09 -0500 (EST)
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
References: <41B5DFCF.50803@cox.net><41B5EA1D.4080907@city-fan.org><41B613CF.4040303@pbl.ca><1102467595l.5036l.1l@devel.mpeters.us><1102467773l.5036l.2l@devel.mpeters.us><1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
Message-ID: <36204.10.10.10.28.1102483449.squirrel@linux1>

On Tue, December 7, 2004 10:00 pm, Sean Middleditch said:

> [...]
> If the packages had just used a more intelligent naming scheme, this
> problem wouldn't exist, ever.  Name the packages libfoo1, libfoo2, etc.
> Get rid of the compat-foo stuff.  If you upgrade, libfoo1 stays around,
> libfoo2 is installed, no problems.  Ten years down the road (assuming
> the glibc/gcc gods don't decide to screw users over again and break tons
> of ABI) you can still install your apps that relies on libfoo1.  You may
> not have that package, but you can grab it online and install it, and it
> just works.  No worries that you need an old version of compat-foo that
> need manual rpm -i invocation to install alongside the current compat-
> foo, no worries about having a 100MB compat-foo, etc.
> [...]

Ten years down the road all you need to do is download the recompiled
version of your app against the latest version of the library.   With a
proper repository infrastructure most of this can be more or less
transparent to the users.  Thus reducing the bloat of the older libraries.
 Pretty straight forward for packagers to automate the recompilation of
applications for different targets too.

After recompiling, any ABI changes will be accounted for as well as
security and performance improvements.   There's seems to be little reason
to need old libraries on an open source platform.  One version of compat-*
libs seems like a reasonable tradeoff to facilitate a transition to the
next rev.
Stable platforms with long life cycles like RHEL also reduce the issue.  
Fedora seems to be doing the right thing considering what its trying to
accomplish and provide for the people that choose it as a distro.

Sean




From j.w.r.degoede at hhs.nl  Wed Dec  8 07:35:45 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 08 Dec 2004 08:35:45 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <41B64A40.7080803@insitesinc.com>
References: <20041206223858.B7CA13E66F6@mail.wtamu.edu>	<41B572ED.4090308@hhs.nl>	<41B5DB20.4060804@insitesinc.com>
	<1102447957.3891.10.camel@kyrre> <41B64A40.7080803@insitesinc.com>
Message-ID: <41B6AED1.5040002@hhs.nl>

<snip>

About the serial mouse probing, I had a bright moment yesterday. This is 
actually quite easy.

1) We're moving to a hotplug world, users buy lotts of gadgets and plug 
them in and out of something which runs Fedora when they feel like it.
2) Afaik we already handle hotplugging of ps/2 and usb mice (although 
badly see below)
3) afaik X will also start if /dev/input/mice doesn't actually has any 
mice behind it.
4) So the solution to slow legacy serial mouse probing is todo it 
asynchroniously, so that the rest of the boot can continue, and generate 
a "fake" hotplug event when a mouse is found.

About doing handling multiple mice wrong. Currently X uses 
/dev/input/mice and all mice attached control the core pointer, there is 
no way for apps like the gimp or non networked simultanious mutiplayer 
games to see that there are 3 mice and use them as 3 seperate mice.

This can be done in X by setting up Xinput, but this doesn't get done 
automaticly, and X can't add an xinput  device after a hotplug, this 
requires a X restart.

Regards,


Hans








From shiva at sewingwitch.com  Wed Dec  8 07:43:48 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 07 Dec 2004 23:43:48 -0800
Subject: Wine/Cedega and fedora 3
In-Reply-To: <pan.2004.12.07.20.05.34.577743@navi.cx>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
Message-ID: <CF4FB8076F810087D4D3BC0C@[10.0.0.4]>

--On Tuesday, December 07, 2004 8:05 PM +0000 Mike Hearn <mike at navi.cx> 
wrote:

> do you realise that every
> single Red Hat/Fedora release from RH9 onwards has broken Wine in some
> way? Every single one? Usually these were not simple things to fix. They
> required extremely complex re-working of core code which few understand.

Makes me wonder if MS has the same problem when it wants to modify its 
kernel.




From Nicolas.Mailhot at laPoste.net  Wed Dec  8 08:16:39 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 08 Dec 2004 09:16:39 +0100
Subject: Broken %post scriptlets in recent java packages
In-Reply-To: <87y8g95yt9.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1102434668.9807.5.camel@ulysse.olympe.o2t>
	<87y8g95yt9.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1102493799.7401.2.camel@rousalka.dyndns.org>

Le mercredi 08 d?cembre 2004 ? 03:05 +0100, Enrico Scholz a ?crit :
> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes:
> 
> >> recent java-packages (ant*, xerces*, ...) have scriptlets like
> >> 
> >> | $ rpm -q --scripts servletapi5-javadoc
> >> | postinstall scriptlet (using /bin/sh):
> >> | rm -f /usr/share/javadoc/servletapi5
> >> | rm -f /usr/share/javadoc/jsp-api
> >> | ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
> >> | ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api
> >> 
> >> 
> >> This is really bad code because it does not make sense in an rpm-world
> >> and causes problems in combination with the %_netsharedpath feature.
> > ...
> > If you're interested by the problem feel free to review specs and
> > propose solutions on jpackage-discuss at zarb.org.
> 
> I fear that my preferred solution (%macro magic) will conflict with
> policies of jpackage. The feature that every /etc/rpm/macros.* file will
> be read by rpm is relatively new and might not exist on all jpackage
> platforms.

Good excuse but... we've been depending on our own sets of macros
forever. So we already have a macro file + all the plumbing to get it
deployed on every platform we target;)

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/125a6b58/attachment.sig>

From fedora at wir-sind-cool.org  Wed Dec  8 09:32:09 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 8 Dec 2004 10:32:09 +0100
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102467773l.5036l.2l@devel.mpeters.us>
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
Message-ID: <20041208103209.164bdbdf.fedora@wir-sind-cool.org>

On Wed, 08 Dec 2004 01:02:53 +0000, Michael A. Peters wrote:

> Maybe "Fedora Extras" is the right place for these packages, but I
> don't know, packages in "Extras" should link against current shared
> libraries, and extras maintaining compat-* packages may result in some
> maintainers using those instead of rebuilding/patching when needed.

Maintainers can't used them for that. Because a compat-* package
should not contain the headers files and libraries which are needed at
build/link-time and not put these in a compat-*-devel package
either. With compiler and standard library being an exception. Hence
the current platform cannot be used to develop full-blown applications
for the old platform and compile with and link with old libraries. But
applications built on the old platform can be installed and run on the
current platform, since the libraries needed at run-time are available
in compat-* packages.

There are other compat-* style packages in Extras already, when
multiple versions/APIs of a library are needed at once by different
applications in a repository. Those packages usually either apply the
"foo$APIVERSION" or "foo$LIBMAJORVERSION" naming scheme, as in "foo2",
"foo3", and so on. These are complete packages which come with their
%name-devel counterparts.



From fedora at wir-sind-cool.org  Wed Dec  8 09:37:23 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 8 Dec 2004 10:37:23 +0100
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <1102482663l.5810l.1l@devel.mpeters.us>
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
	<1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
	<1102482663l.5810l.1l@devel.mpeters.us>
Message-ID: <20041208103723.2ad32790.fedora@wir-sind-cool.org>

On Wed, 08 Dec 2004 05:11:03 +0000, Michael A. Peters wrote:

> On 12/07/2004 07:00:32 PM, Sean Middleditch wrote:
> 
> > 
> > If the packages had just used a more intelligent naming scheme, this
> > problem wouldn't exist, ever.  Name the packages libfoo1, libfoo2,
> > etc.
> > Get rid of the compat-foo stuff.  If you upgrade, libfoo1 stays
> > around,
> > libfoo2 is installed, no problems.  Ten years down the road (assuming
> > the glibc/gcc gods don't decide to screw users over again and break
> > tons
> > of ABI) you can still install your apps that relies on libfoo1.
> 
> Assuming that libfoo2 and libfoo1 don't install conflicting files. This  
> is the case with curl - both packages install a /usr/bin/curl binary.
> 
> Sure, you could separate out libcurl from curl and have curl depend  
> upon libcurl, or you can just make a compat-libcurl package that  
> installs alongside current curl and only provides an older version of  
> the shared library. Ten years down the road you can still install that  
> same compat-libcurl package, and maybe even have 3 or 4 other compat- 
> libcurl packages installed right next to it.

And 3 or 4 corresponding compiler toolkit chains, too, because you
need to maintain ABI compatibility with the ten years old platforms
and not just provide old libraries.

> There is no problem with  
> the rpm naming scheme. The only reason for calling it compat-libfoo  
> instead of just libfoo is to make it easier for users. Note that there  
> are several kernel packages all named kernel - all getting along.

In the days of package dependency resolvers, who decide for you from
where to take a needed library, the package name doesn't matter much.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3
loadavg: 0.00 0.05 0.09



From tjarls at iee.lu  Wed Dec  8 10:14:13 2004
From: tjarls at iee.lu (Charles Lopes)
Date: Wed, 08 Dec 2004 11:14:13 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <1102447466.3891.6.camel@kyrre>
References: <1102332114.3973.18.camel@localhost.localdomain>	<604aa7910412060700306166f4@mail.gmail.com>	<1102345656.18495.28.camel@localhost.localdomain>	<200412062044.19981.ronny-vlug@vlugnet.org>	<20041206203244.GB4757@nostromo.devel.redhat.com>	<1102369899.3371.13.camel@localhost.localdomain>	<1102370434.10277.3.camel@laptop.fenrus.org>
	<41B59FE4.7030407@iee.lu> <1102447466.3891.6.camel@kyrre>
Message-ID: <41B6D3F5.4020204@iee.lu>

Kyrre Ness Sjobak wrote:

>tir, 07.12.2004 kl. 13.19 skrev Charles Lopes:
>  
>
>>Arjan van de Ven wrote:
>>
>>    
>>
>>>On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
>>> 
>>>
>>>      
>>>
>>>>On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>To really speed things up, all you have to declare is that all serial
>>>>>mice must be manually configured... 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>So maybe it's actually time to at least default to ignoring certain
>>>>types of legacy hardware by default? 
>>>>   
>>>>
>>>>        
>>>>
>>>or... if you find a ps.2 or usb mouse skip the serial probing.. the
>>>chance of having BOTH a ps2 one and a serial one are pretty low after
>>>all :)
>>> 
>>>
>>>      
>>>
>>Except if you happen to have both a mouse and a trackball. I have seen 
>>quite a few workstations equiped with a PS2 mouse and a serial 
>>trackball. It was quite a common setup for CAD stations just a couple of 
>>years ago.
>>    
>>
>
>A pc i administer has that setup. It has a (fairly broken) ps/2-mouse,
>and an old ps/2 trackball connected. I haven't removed the mouse since
>most users just stare at you when you tell them that the huge box
>sitting besides the computer is used for the tasks as a mouse...
>
>Yes i know... I *should* replace the mouse...
>
>Now i didn't have any problem with starting system-config-mouse and
>configuring the thing. It was quite easy, could even be done from the
>console! :)
>
>  
>
I see your point. So if a USB or PS/2 mouse is found, serial probing 
should be skipped because in the few cases where one has both a PS/2 and 
a serial mouse, X will be useable with just one mouse and one can always 
manually configure the serial mouse with system-config-mouse. The 
approach sounds quite safe now.



From mike at navi.cx  Wed Dec  8 11:39:35 2004
From: mike at navi.cx (Mike Hearn)
Date: Wed, 08 Dec 2004 11:39:35 +0000
Subject: Wine/Cedega and fedora 3
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
Message-ID: <pan.2004.12.08.11.39.34.927483@navi.cx>

On Tue, 07 Dec 2004 23:43:48 -0800, Kenneth Porter wrote:
> Makes me wonder if MS has the same problem when it wants to modify its 
> kernel.

Yes they do, see the /3gig switch to the kernel. Changing the
VM layout in this case revealed a lot of code which assumed it'd never
get a pointer above the 2gig boundary so they stored information in the
high bit of pointers, etc. The now-disabled 4G/4G VM patch on Linux showed
the same problem. So you can modify the address space, but you have to
manually enable it. Perhaps if it was a more widely wanted feature they'd
have put code in to enable it on an app-by-app basis.

It's not just the kernel. Same problems occur when they want to modify
anything, really. They have multiple dedicated app-compat teams which
buy/download software and regression test it. They also have an advanced
patching/shimming system so some of the most broken software can still
work. That's common when a program checks the result of GetVersion() and
refuses to run on anything but Windows 95 exactly, for instance.

The thing is, their programmers salaries are directly linked to upgrade
sales so, outside of a few power-play examples, they take great care not
to break things.

Because they have such a huge base of software relative to Linux, and
because they value backwards compatibility so highly, that means they have
to move slower and sometimes not make a certain change because it'd break
stuff. That's a simple equation: the utility of a feature is outweighed
by the negative utility of the breakage. Once Linux gets as widely
deployed as Windows is, it'll have to move much slower too. Oh sure the
patches may be written even faster, but that doesn't mean people will
actually be *using* them.

In the specific case of execshield, compatibility issues aside the way
they implemented shared libraries would make it very hard to do
efficiently.



From mike at navi.cx  Wed Dec  8 11:41:57 2004
From: mike at navi.cx (Mike Hearn)
Date: Wed, 08 Dec 2004 11:41:57 +0000
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
	<1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
	<36204.10.10.10.28.1102483449.squirrel@linux1>
Message-ID: <pan.2004.12.08.11.41.57.844235@navi.cx>

On Wed, 08 Dec 2004 00:24:09 -0500, Sean wrote:
> After recompiling, any ABI changes will be accounted for as well as
> security and performance improvements.   There's seems to be little reason
> to need old libraries on an open source platform.

That's only true of ABI changes. API and semantic changes the compiler
cannot magically fix. Old libraries are still necessary.



From seanlkml at sympatico.ca  Wed Dec  8 11:46:35 2004
From: seanlkml at sympatico.ca (Sean)
Date: Wed, 8 Dec 2004 06:46:35 -0500 (EST)
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
In-Reply-To: <pan.2004.12.08.11.41.57.844235@navi.cx>
References: <41B5DFCF.50803@cox.net>
	<41B5EA1D.4080907@city-fan.org><41B613CF.4040303@pbl.ca>
	<1102467595l.5036l.1l@devel.mpeters.us><1102467773l.5036l.2l@devel.mpeters.us><1102474832.19526.94.camel@stargrazer.home.awesomeplay.com><36204.10.10.10.28.1102483449.squirrel@linux1>
	<pan.2004.12.08.11.41.57.844235@navi.cx>
Message-ID: <37643.10.10.10.28.1102506395.squirrel@linux1>

On Wed, December 8, 2004 6:41 am, Mike Hearn said:

>
> That's only true of ABI changes. API and semantic changes the compiler
> cannot magically fix. Old libraries are still necessary.

You're right but the old libraries are only necessary if the application
hasn't been updated to reflect the changes.

Sean




From mike at navi.cx  Wed Dec  8 11:54:04 2004
From: mike at navi.cx (Mike Hearn)
Date: Wed, 08 Dec 2004 11:54:04 +0000
Subject: Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters@mac.com]
References: <41B5DFCF.50803@cox.net> <41B5EA1D.4080907@city-fan.org>
	<41B613CF.4040303@pbl.ca> <1102467595l.5036l.1l@devel.mpeters.us>
	<1102467773l.5036l.2l@devel.mpeters.us>
	<1102474832.19526.94.camel@stargrazer.home.awesomeplay.com>
	<36204.10.10.10.28.1102483449.squirrel@linux1>
	<pan.2004.12.08.11.41.57.844235@navi.cx>
	<37643.10.10.10.28.1102506395.squirrel@linux1>
Message-ID: <pan.2004.12.08.11.54.04.275209@navi.cx>

On Wed, 08 Dec 2004 06:46:35 -0500, Sean wrote:
> You're right but the old libraries are only necessary if the application
> hasn't been updated to reflect the changes.

Yep, but this is quite common even for popular apps eg, XMMS still
uses GTK1 and I think GNUcash still uses GNOME 1.4 - old libraries stick
around for ages.



From seanlkml at sympatico.ca  Wed Dec  8 11:53:06 2004
From: seanlkml at sympatico.ca (Sean)
Date: Wed, 8 Dec 2004 06:53:06 -0500 (EST)
Subject: Wine/Cedega and fedora 3
In-Reply-To: <pan.2004.12.08.11.39.34.927483@navi.cx>
References: <1102331754.3973.11.camel@localhost.localdomain><1102341652.18495.14.camel@localhost.localdomain><pan.2004.12.07.20.05.34.577743@navi.cx><CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
Message-ID: <37671.10.10.10.28.1102506786.squirrel@linux1>

On Wed, December 8, 2004 6:39 am, Mike Hearn said:
> On Tue, 07 Dec 2004 23:43:48 -0800, Kenneth Porter wrote:
> [...]
> Because they have such a huge base of software relative to Linux, and
> because they value backwards compatibility so highly, that means they have
> to move slower and sometimes not make a certain change because it'd break
> stuff. That's a simple equation: the utility of a feature is outweighed
> by the negative utility of the breakage. Once Linux gets as widely
> deployed as Windows is, it'll have to move much slower too. Oh sure the
> patches may be written even faster, but that doesn't mean people will
> actually be *using* them.
> [...]

This is already in practice today.  Look at the distros that have long
slow life cycles for this very reason.   Seems likely that there will
always be a certain segment of people who want to be pushing at the front
edge and can deal with the associated blood loss.   It seems that the
ideal structure is already in place.   Fast moving distros like Fedora
with and slow moving ones like RHEL.   What's the problem?

Sean




From j.w.r.degoede at hhs.nl  Wed Dec  8 11:58:36 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 08 Dec 2004 12:58:36 +0100
Subject: Kudzu and automatic detection
In-Reply-To: <41B6D3F5.4020204@iee.lu>
References: <1102332114.3973.18.camel@localhost.localdomain>	<604aa7910412060700306166f4@mail.gmail.com>	<1102345656.18495.28.camel@localhost.localdomain>	<200412062044.19981.ronny-vlug@vlugnet.org>	<20041206203244.GB4757@nostromo.devel.redhat.com>	<1102369899.3371.13.camel@localhost.localdomain>	<1102370434.10277.3.camel@laptop.fenrus.org>	<41B59FE4.7030407@iee.lu>
	<1102447466.3891.6.camel@kyrre> <41B6D3F5.4020204@iee.lu>
Message-ID: <41B6EC6C.2030802@hhs.nl>

Charles Lopes wrote:
> Kyrre Ness Sjobak wrote:
> 
>> tir, 07.12.2004 kl. 13.19 skrev Charles Lopes:
>>  
>>
>>> Arjan van de Ven wrote:
>>>
>>>   
>>>
>>>> On Mon, 2004-12-06 at 13:51 -0800, Per Bjornsson wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>> On Mon, 2004-12-06 at 15:32 -0500, Bill Nottingham wrote:
>>>>>  
>>>>>       
>>>>>
>>>>>> To really speed things up, all you have to declare is that all serial
>>>>>> mice must be manually configured...    
>>>>>>         
>>>>>
>>>>> So maybe it's actually time to at least default to ignoring certain
>>>>> types of legacy hardware by default?  
>>>>>       
>>>>
>>>> or... if you find a ps.2 or usb mouse skip the serial probing.. the
>>>> chance of having BOTH a ps2 one and a serial one are pretty low after
>>>> all :)
>>>>
>>>>
>>>>     
>>>
>>> Except if you happen to have both a mouse and a trackball. I have 
>>> seen quite a few workstations equiped with a PS2 mouse and a serial 
>>> trackball. It was quite a common setup for CAD stations just a couple 
>>> of years ago.
>>>   
>>
>>
>> A pc i administer has that setup. It has a (fairly broken) ps/2-mouse,
>> and an old ps/2 trackball connected. I haven't removed the mouse since
>> most users just stare at you when you tell them that the huge box
>> sitting besides the computer is used for the tasks as a mouse...
>>
>> Yes i know... I *should* replace the mouse...
>>
>> Now i didn't have any problem with starting system-config-mouse and
>> configuring the thing. It was quite easy, could even be done from the
>> console! :)
>>
>>  
>>
> I see your point. So if a USB or PS/2 mouse is found, serial probing 
> should be skipped because in the few cases where one has both a PS/2 and 
> a serial mouse, X will be useable with just one mouse and one can always 
> manually configure the serial mouse with system-config-mouse. The 
> approach sounds quite safe now.
> 

Please don't go this way, see my suggestion to solve this in a previous 
post, just detect the serial mouses async.

Regards,

Hans




From buildsys at redhat.com  Wed Dec  8 13:02:32 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 8 Dec 2004 08:02:32 -0500
Subject: rawhide report: 20041208 changes
Message-ID: <200412081302.iB8D2WP06344@porkchop.devel.redhat.com>

New package slib
	platform independent library for scheme


 
Updated Packages:

a2ps-4.13b-42
-------------
* Tue Dec 07 2004 Tim Waugh <twaugh at redhat.com> 4.13b-42
- Fixed configure.in.
- Fixed m4 files.
- Apply patch from bug #122699 to fix "too many includes" error.

ethereal-0.10.7-2
-----------------
* Tue Dec 07 2004 Radek Vokal <rvokal at redhat.com> 0.10.7-2
- changed mozilla default browser to htmlview (#142107)
- warning: update doesn't overwrite default preferences in ~/.ethereal/preferences

evolution-data-server-1.0.2-6
-----------------------------
* Tue Dec 07 2004 David Malcolm <dmalcolm at redhat.com> - 1.0.2-6
- Amortize writes to a local cache of a webcal calendar, fixing further aspect of #141283 (upstream bugzilla #70267), as posted to mailing list here:
http://lists.ximian.com/archives/public/evolution-patches/2004-December/008338.html
(The groupwise part of that patch did not cleanly apply, so I removed it).

ftp-0.17-23
-----------
* Tue Dec 07 2004 Thomas Woerner <twoerner at redhat.com> 0.17-23
- fixed mget with runique (#79367)

gcc4-4.0.0-0.14
---------------
* Tue Dec 07 2004 Jakub Jelinek  <jakub at redhat.com> 4.0.0-0.14
- update from trunk
  - fix DEPENDENCIES_OUTPUT handling (#140921)
- fix libstdc++.so symlinks (#141985)
- make sure target's LOAD_EXTEND_OP or lack thereof doesn't influence
  gcj -C output (#141730)

gnome-bluetooth-0.5.1-8
-----------------------
* Tue Dec 07 2004 Harald Hoyer <harald at redhat.com> - 0.5.1-8
- added requires for python-abi

* Tue Dec 07 2004 Harald Hoyer <harald at redhat.com> - 0.5.1-7
- split package into app, libs and devel

iputils-20020927-19
-------------------
* Tue Dec 07 2004 Radek Vokal <rvokal at redhat.com> 20020927-19
- return values fixed - patch from suse.de

kernel-2.6.9-1.1020_FC4
-----------------------
* Mon Dec 06 2004 Rik van Riel <riel at redhat.com>
- apparently Xen works better without serial drivers in domain0 (#141497)

libgnomedb-1:1.0.4-4
--------------------
* Tue Dec 07 2004 Caolan McNamara <caolanm at redhat.com> 1.0.4-4
- #rh142098# missing return

python-2.4-2
------------
* Mon Dec 06 2004 Jeff Johnson <jbj at jbj.org> 2.4-2
- db-4.3.21 returns DB_BUFFER_SMALL rather than ENOMEM (#141994).
- add Provide: python(abi) = 2.4
- include msgfmt/pygettext *.pyc and *.pyo from brp-python-bytecompile.

rpmdb-fedora-1:4-0.20041208
---------------------------

selinux-policy-strict-1.19.11-1
-------------------------------
* Fri Dec 03 2004 Dan Walsh <dwalsh at redhat.com> 1.19-11-1
- Merge with upstream

selinux-policy-targeted-1.19.11-1
---------------------------------
* Fri Dec 03 2004 Dan Walsh <dwalsh at redhat.com> 1.19-11-1
- Merge with upstream

shadow-utils-2:4.0.3-56
-----------------------
* Fri Dec 03 2004 Adrian Havill <havill at redhat.com> 2:4.0.3-56
- tweak max allowed length of user/group names to sizeof(ut_user)-1
  to allow for '\0' termination
- add lastlog support for >4gb (#125445)

* Tue Nov 23 2004 Bill Nottingham <notting at redhat.com>
- ghost lastlog here (#139539)

* Tue Nov 16 2004 Adrian Havill <havill at redhat.com> 2:4.0.3-42
- change MAXMEM static limit on group count to dynamic (#125510)
- re-allow "$" as last char for the sake of samba (#132782)
- don't strip binaries for debuginfo

util-linux-2.12a-20
-------------------
* Tue Dec 07 2004 Steve Dickson <SteveD at RedHat.com> 2.12a-20
- Corrected a buffer overflow problem with nfs mounts.
  (bz# 141733)

* Wed Dec 01 2004 Elliot Lee <sopwith at redhat.com> 2.12a-19
- Patches for various bugs.

* Mon Nov 29 2004 Steve Dickson <SteveD at RedHat.com> 2.12a-18
- Made NFS mounts adhere to the IP protocol if specified on
  command line as well as made NFS umounts adhere to the
  current IP protocol. Fix #140016



From mr700 at globalnet.bg  Wed Dec  8 13:51:19 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Wed, 8 Dec 2004 15:51:19 +0200
Subject: konsole/gnome-terminal/xterm, UTF-8 and backspace
Message-ID: <200412081551.19352@-mr700>

    Hello,
    when a shell/python script reads input from the user in konsole and
gnome-terminal it I enter non-ascii characters (ex: "?????", "Test" in
English) backspace does not work correct. For example:
--- cut ---
$ echo -n "Test: "; read a; echo "[$a]"
Test: ?????
[ You can paste this, then hit backspace 4 times to get the next line ]
Test: ?
[ Press Enter here and you get ]
[???]
$ _
--- cut ---
    If I erase one character I get '[?????'
    Text editing in bash and mc works, but in python 'starts to erase'
the '>>> ' prompt. In xterm instead of cyrilic letters I get spaces.
I wanted to enter a bug, but I don't know against what to. Looks like
backspace erases single bytes, while these letters consist of 2. Can
someone direct me and confirm it?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From P at draigBrady.com  Wed Dec  8 14:19:42 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Wed, 08 Dec 2004 14:19:42 +0000
Subject: konsole/gnome-terminal/xterm, UTF-8 and backspace
In-Reply-To: <200412081551.19352@-mr700>
References: <200412081551.19352@-mr700>
Message-ID: <41B70D7E.6000908@draigBrady.com>

Doncho N. Gunchev wrote:
>     Hello,
>     when a shell/python script reads input from the user in konsole and
> gnome-terminal it I enter non-ascii characters (ex: "?????", "Test" in
> English) backspace does not work correct. For example:
> --- cut ---
> $ echo -n "Test: "; read a; echo "[$a]"
> Test: ?????
> [ You can paste this, then hit backspace 4 times to get the next line ]
> Test: ?
> [ Press Enter here and you get ]
> [???]
> $ _
> --- cut ---
>     If I erase one character I get '[?????'
>     Text editing in bash and mc works, but in python 'starts to erase'
> the '>>> ' prompt. In xterm instead of cyrilic letters I get spaces.
> I wanted to enter a bug, but I don't know against what to. Looks like
> backspace erases single bytes, while these letters consist of 2. Can
> someone direct me and confirm it?
> 

Both python and bash use readline to do line editing.
4.3-13 is the latest in rawhide but version 5.0 is available
which seems to fix the issues you mention. Search for
multibyte in: http://cnswww.cns.cwru.edu/php/chet/readline/CHANGES

-- 
P?draig Brady - http://www.pixelbeat.org
--



From cra at WPI.EDU  Wed Dec  8 14:12:53 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 8 Dec 2004 09:12:53 -0500
Subject: Elektrified X.org released (was: X configuration paradigm,
	and a proposal)
In-Reply-To: <ed0efd3104120718171cb7e705@mail.gmail.com>
References: <ed0efd310411300525669cd21b@mail.gmail.com>
	<1101955405.7436.69.camel@Madison.badger.com>
	<ed0efd31041204144172022baf@mail.gmail.com>
	<200412052257.42528.symbiont@berlios.de>
	<ed0efd31041205071313951a32@mail.gmail.com>
	<41B34C0A.7030104@awesomeplay.com>
	<ed0efd31041205111711d4e097@mail.gmail.com>
	<20041208004952.GB25551@redhat.com>
	<ed0efd3104120718146ccb9cc2@mail.gmail.com>
	<ed0efd3104120718171cb7e705@mail.gmail.com>
Message-ID: <20041208141253.GC12428@angus.ind.WPI.EDU>

On Tue, Dec 07, 2004 at 11:17:28PM -0300, Avi Alkalay wrote:
> On Tue, 7 Dec 2004 23:14:24 -0300, Avi Alkalay <avibrazil at gmail.com> wrote:
> > OK about the client. But to really have it, I imagine you need the server too.
> > So then what early bootup programs (when you still don't have /usr/lib
> > mounted or any services running) will have ?
> 
> Well, maybe not depend on gamin, FAM etc, through dlopen, and handle
> linking errors, and not providing notification in early boot
> stage.....

Maybe gamin should be moved to /lib?



From elanthis at awesomeplay.com  Wed Dec  8 14:46:19 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 09:46:19 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <37671.10.10.10.28.1102506786.squirrel@linux1>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
	<37671.10.10.10.28.1102506786.squirrel@linux1>
Message-ID: <1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 06:53 -0500, Sean wrote:
> On Wed, December 8, 2004 6:39 am, Mike Hearn said:
> > On Tue, 07 Dec 2004 23:43:48 -0800, Kenneth Porter wrote:
> > [...]
> > Because they have such a huge base of software relative to Linux, and
> > because they value backwards compatibility so highly, that means they have
> > to move slower and sometimes not make a certain change because it'd break
> > stuff. That's a simple equation: the utility of a feature is outweighed
> > by the negative utility of the breakage. Once Linux gets as widely
> > deployed as Windows is, it'll have to move much slower too. Oh sure the
> > patches may be written even faster, but that doesn't mean people will
> > actually be *using* them.
> > [...]
> 
> This is already in practice today.  Look at the distros that have long
> slow life cycles for this very reason.   Seems likely that there will
> always be a certain segment of people who want to be pushing at the front
> edge and can deal with the associated blood loss.   It seems that the
> ideal structure is already in place.   Fast moving distros like Fedora
> with and slow moving ones like RHEL.   What's the problem?

The problem is that nothing is solved.  I have RHEL 2.1, but it's near
bloody impossible to find up-to-date RPMs of various software I need for
it.  I *could* upgrade to RHEL 3.0, but then that would require massive
server downtime across several *very* important servers, and who knows
if things will actually work afterwards?

Why the hell should I have to upgrade my operating system to get a new
version of SSH or Exim installed?

Why should I have to compile it and patch it myself, then becoming
responsible to manually track all security updates and repatch/rebuild
it asap after each is released, when it's *already* being repatched and
recompiling by thousands of other people around the world, including
people at Red Hat?

With the "solution" you seem to think to exists, those are my only two
options.  Neither is very appealing at all.

> 
> Sean
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From janina at rednote.net  Wed Dec  8 15:07:16 2004
From: janina at rednote.net (Janina Sajka)
Date: Wed, 8 Dec 2004 10:07:16 -0500
Subject: X86_64 Yum Question
Message-ID: <20041208150715.GA5817@rednote.net>

Is there a way to tell yum to install a i386 version of some package if
the x86_64 version isn't available? Is there some documentation that I
should be reading on this? Or more generally on the do's and don'ts of
mixing 32 bit apps onto an 64 system?

Thanks for any guidance.

				Janina

> Hi,
> 
> When I select Preferences -> Advanced in Thunderbird 1.0rc I see a
> 
>   XML Parsing Error: not well-formed
>   Location: chrome://messenger/content/pref-advanced.xul
>   Line number 208, Column 5:
> 
> This is after rebuilding the src.rpm on RHEL3 (with a few tweaks),
> so I'm now wondering if this also happens on FC3.  Anyone?
> 
> Thanks,
> 

This kind of problem happened to me after upgrading without restarting 
thunderbird.  Have you tried closing thunderbird completely and reopening?

Warren

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list



From seanlkml at sympatico.ca  Wed Dec  8 15:06:50 2004
From: seanlkml at sympatico.ca (Sean)
Date: Wed, 8 Dec 2004 10:06:50 -0500 (EST)
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain><1102341652.18495.14.camel@localhost.localdomain><pan.2004.12.07.20.05.34.577743@navi.cx><CF4FB8076F810087D4D3BC0C@[10.0.0.4]><pan.2004.12.08.11.39.34.927483@navi.cx><37671.10.10.10.28.1102506786.squirrel@linux1>
	<1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <38231.10.10.10.28.1102518410.squirrel@linux1>

On Wed, December 8, 2004 9:46 am, Sean Middleditch said:
>
> The problem is that nothing is solved.  I have RHEL 2.1, but it's near
> bloody impossible to find up-to-date RPMs of various software I need for
> it.  I *could* upgrade to RHEL 3.0, but then that would require massive
> server downtime across several *very* important servers, and who knows
> if things will actually work afterwards?

These were the same issues facing people moving from Windows NT to Windows
2000.  There's no magic bullet.

> Why the hell should I have to upgrade my operating system to get a new
> version of SSH or Exim installed?

The same is true with Windows 2000, the updates from Microsoft are slowing
down.  You take the software that is released by them at the pace they
release it or you roll your own.   I don't see the difference between that
and RHEL 2.1.

>
> Why should I have to compile it and patch it myself, then becoming
> responsible to manually track all security updates and repatch/rebuild
> it asap after each is released, when it's *already* being repatched and
> recompiling by thousands of other people around the world, including
> people at Red Hat?
>

So, we need a RHEL 2.1 extras repository?   Sounds like an opportunity.
Even without a RHEL repository, the burden of recompiling custom rpm's
really isn't all that great anyway.

> With the "solution" you seem to think to exists, those are my only two
> options.  Neither is very appealing at all.

Exactly what extra solution do you have on a Windows 2000 box?   Does your
complaint boil down to you prefer binaries over source code?

Sean





From skvidal at phy.duke.edu  Wed Dec  8 15:10:08 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 08 Dec 2004 10:10:08 -0500
Subject: X86_64 Yum Question
In-Reply-To: <20041208150715.GA5817@rednote.net>
References: <20041208150715.GA5817@rednote.net>
Message-ID: <1102518608.24730.13.camel@opus.phy.duke.edu>

On Wed, 2004-12-08 at 10:07 -0500, Janina Sajka wrote:
> Is there a way to tell yum to install a i386 version of some package if
> the x86_64 version isn't available? Is there some documentation that I
> should be reading on this? Or more generally on the do's and don'ts of
> mixing 32 bit apps onto an 64 system?
> 
> Thanks for any guidance.

yum install file.i386


-sv



From cra at WPI.EDU  Wed Dec  8 15:15:07 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 8 Dec 2004 10:15:07 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
	<37671.10.10.10.28.1102506786.squirrel@linux1>
	<1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <20041208151507.GD12428@angus.ind.WPI.EDU>

On Wed, Dec 08, 2004 at 09:46:19AM -0500, Sean Middleditch wrote:
> Why the hell should I have to upgrade my operating system to get a new
> version of SSH or Exim installed?

Why do you need a new version of SSH?  Are not the RHEL security 
updates sufficient?



From janina at rednote.net  Wed Dec  8 15:15:11 2004
From: janina at rednote.net (Janina Sajka)
Date: Wed, 8 Dec 2004 10:15:11 -0500
Subject: X86_64 Yum Question
In-Reply-To: <1102518608.24730.13.camel@opus.phy.duke.edu>
References: <20041208150715.GA5817@rednote.net>
	<1102518608.24730.13.camel@opus.phy.duke.edu>
Message-ID: <20041208151510.GB5817@rednote.net>

seth vidal writes:
> On Wed, 2004-12-08 at 10:07 -0500, Janina Sajka wrote:
> > Is there a way to tell yum to install a i386 version of some package if
> > the x86_64 version isn't available? Is there some documentation that I
> > should be reading on this? Or more generally on the do's and don'ts of
> > mixing 32 bit apps onto an 64 system?
> > 
> > Thanks for any guidance.
> 
> yum install file.i386

Yes, that will certainly help in the current instance. Thanks. Guess I'm
having another "duh" moment.

> 
> 
> -sv
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Chair
				Accessibility Workgroup
				Free Standards Group (FSG)

janina at freestandards.org	Phone: +1 202.494.7040



From alan at redhat.com  Wed Dec  8 15:17:07 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 10:17:07 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <38231.10.10.10.28.1102518410.squirrel@linux1>
References: <1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
	<38231.10.10.10.28.1102518410.squirrel@linux1>
Message-ID: <20041208151707.GA4055@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 10:06:50AM -0500, Sean wrote:
> So, we need a RHEL 2.1 extras repository?   Sounds like an opportunity.
> Even without a RHEL repository, the burden of recompiling custom rpm's
> really isn't all that great anyway.

dag.wieers.com



From thomasz at hostmaster.org  Wed Dec  8 15:18:52 2004
From: thomasz at hostmaster.org (Thomas Zehetbauer)
Date: Wed, 08 Dec 2004 16:18:52 +0100
Subject: X86_64 Yum Question
In-Reply-To: <20041208150715.GA5817@rednote.net>
References: <20041208150715.GA5817@rednote.net>
Message-ID: <1102519132.4468.68.camel@hostmaster.org>

yum defaults to installing both x86_64 and i386 packages if they are
available in the x86_64 repository. You can force either architecture by
appending .i386 or .x86_64 to the package name.

Tom

-- 
  T h o m a s   Z e h e t b a u e r   ( TZ251 )
  PGP encrypted mail preferred - KeyID 96FFCB89
      finger thomasz at hostmaster.org for key

Attempting to apply the OSI layers model to a real network is just like
attempting to represent seven dimensions in four dimensional reality.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/1034c9f1/attachment.sig>

From russell at coker.com.au  Wed Dec  8 15:24:31 2004
From: russell at coker.com.au (Russell Coker)
Date: Thu, 9 Dec 2004 02:24:31 +1100
Subject: Some encryption-related projects
In-Reply-To: <20041114191651.GA5555@imp.flyn.org>
References: <20041114191651.GA5555@imp.flyn.org>
Message-ID: <200412090224.34893.russell@coker.com.au>

On Monday 15 November 2004 06:16, "W. Michael Petullo" <mike at flyn.org> wrote:
> 2.  Encrypted root filesystem.
>
> Red Hat Bug #182479 discusses adding support for an encrypted root

It's #124789.

> filesystem to Fedora.  The bug contains a patch for mkinird that
> facilitates this.  Eventually it would be nice to see support in anaconda
> for this, but #182479 is the first step.

One thing you miss in the latest patch is support for an encrypted root device 
on top of an LVM volume.

With your patch the code does the following starting at about line 730 in 
mkinitrd:

if [ "$kernelmajor" == "2.4" ]; then
# kernel 2.4.x LVM stufff
elif [ -n "$root_enc" ]; then
# crypto-root stuff
else
# kernel 2.6.x LVM stuff
fi

What you really want is to have the crypto root stuff occurring outside the if 
statement in question.  Also inside the "if [ -n "$root_enc" ]; then" block 
you want to have "if [ -z $root_lvm ]; then" around the "mkdmnod" bit so that 
mkdmnod doesn't get called twice.


Also in recent kernels the AES module is aes-i586 (maybe we should have an 
alias in the module-init-tools config).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From nphilipp at redhat.com  Wed Dec  8 15:24:38 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Wed, 08 Dec 2004 16:24:38 +0100
Subject: X86_64 Yum Question
In-Reply-To: <1102518608.24730.13.camel@opus.phy.duke.edu>
References: <20041208150715.GA5817@rednote.net>
	<1102518608.24730.13.camel@opus.phy.duke.edu>
Message-ID: <1102519478.4261.38.camel@gibraltar.stuttgart.redhat.com>

On Wed, 2004-12-08 at 10:10 -0500, seth vidal wrote:
> On Wed, 2004-12-08 at 10:07 -0500, Janina Sajka wrote:
> > Is there a way to tell yum to install a i386 version of some package if
> > the x86_64 version isn't available? Is there some documentation that I
> > should be reading on this? Or more generally on the do's and don'ts of
> > mixing 32 bit apps onto an 64 system?
> > 
> > Thanks for any guidance.
> 
> yum install file.i386

Just for the sake of completeness and google: up2date takes the --arch
option which works on RHN -- I haven't tried it against yum or apt
repositories yet.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/b7f64198/attachment.sig>

From elanthis at awesomeplay.com  Wed Dec  8 15:42:36 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 10:42:36 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041208151507.GD12428@angus.ind.WPI.EDU>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
	<37671.10.10.10.28.1102506786.squirrel@linux1>
	<1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
	<20041208151507.GD12428@angus.ind.WPI.EDU>
Message-ID: <1102520556.4257.46.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 10:15 -0500, Charles R. Anderson wrote:
> On Wed, Dec 08, 2004 at 09:46:19AM -0500, Sean Middleditch wrote:
> > Why the hell should I have to upgrade my operating system to get a new
> > version of SSH or Exim installed?
> 
> Why do you need a new version of SSH?  Are not the RHEL security 
> updates sufficient?

RHEL 2.1's OpenSSH does not support gssapi-with-mic.  It's something I
can live without, and am indeed doing just that, because packaging
headaches make it too difficult to use one of the bazillion existing
repositories/packages of newer OpenSSH versions.  The only choice I have
is to install from source, and then I become the security maintainer,
instead of letting the trusted third-party repository do it for me.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From elanthis at awesomeplay.com  Wed Dec  8 15:44:27 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 10:44:27 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <38231.10.10.10.28.1102518410.squirrel@linux1>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
	<37671.10.10.10.28.1102506786.squirrel@linux1>
	<1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
	<38231.10.10.10.28.1102518410.squirrel@linux1>
Message-ID: <1102520667.4257.50.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 10:06 -0500, Sean wrote:
> On Wed, December 8, 2004 9:46 am, Sean Middleditch said:
> >
> > The problem is that nothing is solved.  I have RHEL 2.1, but it's near
> > bloody impossible to find up-to-date RPMs of various software I need for
> > it.  I *could* upgrade to RHEL 3.0, but then that would require massive
> > server downtime across several *very* important servers, and who knows
> > if things will actually work afterwards?
> 
> These were the same issues facing people moving from Windows NT to Windows
> 2000.  There's no magic bullet.

The issues are, in general, far smaller.  While things may break in the
upgrade, far less things break.  With Linux, you watch the entire bloody
OS break since glibc or gcc or some other insanely important component
decides to just become incompatible for the most trivial of advantages,
most of which can be had _without_ breaking ABI.

With most Windows upgrade problems I've seen (very, very few - I can
count them on one hand) the problem was usually broken applications that
made assumptions.  That problem definitely does exist in Linux, no
questions, and I'm not complaining (to the OS guys) about that.  With
most Linux upgrade problems I've seen (more than I can count) it's not
the apps, but the OS that breaks perfectly well behaved apps.  In most
cases, the OS itself is fine, but the way the OS was packages created
artificial conflicts that don't really exist anywhere but in RPM
headers!

> 
> > Why the hell should I have to upgrade my operating system to get a new
> > version of SSH or Exim installed?
> 
> The same is true with Windows 2000, the updates from Microsoft are slowing
> down.  You take the software that is released by them at the pace they
> release it or you roll your own.   I don't see the difference between that
> and RHEL 2.1.

Most people in reality do not just use software from one vendor.  If we
only used Microsoft software our IT staff wouldn't be needed, since our
network wouldn't actually do anything other than exist.  Likewise, if we
only used what Red Hat slapped on their CDs, we wouldn't be here,
because the network would be useless.  If all our software was supplied
by Novell, our network would let us share files that we wouldn't have
because the apps we use aren't supplied by Novell.

Real deployments depend on third party software from ISVs, be they
proprietary or open source.  Red Hat knows that, and work with it, which
is good.

> 
> >
> > Why should I have to compile it and patch it myself, then becoming
> > responsible to manually track all security updates and repatch/rebuild
> > it asap after each is released, when it's *already* being repatched and
> > recompiling by thousands of other people around the world, including
> > people at Red Hat?
> >
> 
> So, we need a RHEL 2.1 extras repository?   Sounds like an opportunity.
> Even without a RHEL repository, the burden of recompiling custom rpm's
> really isn't all that great anyway.

An extras repository just for RHEL 2.1?  So the small handful of people
who are capable of putting the time and effort into maintaining quality
packages can be spread even thinner?  Re-read my original mail on this
subject - this kind of mass duplication of effort and waste of human
resources is completely pointless, and can be worked around by just
doing a better job packaging in most cases.

The biggest differences between two versions of a distro are usually
which versions of libraries are available.  If the packaging of those
libraries would allow parallel installation without the headaches (which
the libraries themselvs often have no problem with) there wouldn't be
any reason to have to recompile an app for each version of each distro
of Linux.  You'd just compile it once, provide copies of the library
RPMs for distros that only have older/newer versions, and things would
Just Work(tm) independent of whether you use RHEL 2.1, RHEL 3.0, Novell
Enterprise Linux, Mandrake, whatever.

> 
> > With the "solution" you seem to think to exists, those are my only two
> > options.  Neither is very appealing at all.
> 
> Exactly what extra solution do you have on a Windows 2000 box?   Does your
> complaint boil down to you prefer binaries over source code?

When I'm trying to get work done that doesn't involve code I'm writing?
Of course I prefer binaries.  It wouldn't do me a lot of good to prefer
source code in that kind of case.  Source doesn't do any real work at
all for you.  The binaries do.  The second you touch the source, you
completely break the chain of automatic security updates from your
vendor, the QA testing done by your vendor, the compatibility with ISVs
that only tested against what your vendor supplied, the upgrade path for
new versions of the OS supplied by the vendor, etc.  By "vendor" I mean
whichever vendor the app came from, be it my OS vendor (Red Hat),
framework library vendor (Novell), application vendor (quite a few), or
other open source vendor (openssh.org, exim.org, whoever).

All of which would be unnecessary in most cases with slightly better
packaging standards.  There's no good reason why I shouldn't be able to
drop in a third-party repository that over-rides some RH-supplied
package and just have things work, especially if I trust that repository
to handle security updates.  Due to how RH packages things third party
vendors need to supply packages for four or five versions of RHL, two or
three versions of RHEL, three versions of Fedora, not to mention
multiple architectures of each, nor the other distros they probably want
to support (SUSE/Novell, Debian, Mandrake, etc.).  Then they have to
host all those insanely redundant bits somewhere.  Then there's the UI
head-aches that causes.  It's bloody stupid.  A binary compiled on x86
against libs X, Y, and Z should just work, end of story, on Linux x86
with libs X, Y, and Z installed, and there should be *no* reason why you
can't install those libs if they're not already.  The only thing that
does stop it is apathy on the part of the developers and packagers.

Big huge Extras repositories are not the answer.  If they were, Debian
would be a utopia, because they have more "extras" than Fedora or RHEL
will have anytime soon.  There will always be apps that just aren't in
any Extras repository, there will always be apps that upgraded more
frequently than the Extras maintainers care (or are able) to keep up
with.  There will always be the fact that Extras repositories are only
maintained for a limited time until you are forced to upgrade your
entire OS and all related software just to keep up with a single
application.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From janina at rednote.net  Wed Dec  8 15:50:36 2004
From: janina at rednote.net (Janina Sajka)
Date: Wed, 8 Dec 2004 10:50:36 -0500
Subject: X86_64 Yum Question
In-Reply-To: <1102519132.4468.68.camel@hostmaster.org>
References: <20041208150715.GA5817@rednote.net>
	<1102519132.4468.68.camel@hostmaster.org>
Message-ID: <20041208155036.GC5817@rednote.net>

Thomas Zehetbauer writes:
> yum defaults to installing both x86_64 and i386 packages if they are
> available in the x86_64 repository. You can force either architecture by
> appending .i386 or .x86_64 to the package name.

I decided not to go there. I was trying to install the recently released
flumotion, which is actually a noarch. The only way I was able to get at
it with yum was to globally replace $basearch with 'i386' in the
gstreamer .repo files.

Unfortunately, the x86_64 gstreamer-plugins reported a conflict. A yum
remove gstreamer-plugins was going to remove so much, I backed out:

Performing the following to resolve dependencies:
  Remove: gnome-applets.x86_64 1:2.8.0-5
  Remove: gnome-media.x86_64 0:2.8.0-3.FC3.1
  Remove: gnome-session.x86_64 0:2.8.0-4
  Remove: gnome-volume-manager.x86_64 0:1.1.0-5
  Remove: gstreamer-plugins-devel.x86_64 0:0.8.5-1
  Remove: nautilus-media.x86_64 0:0.8.1-3
  Remove: rhythmbox.x86_64 0:0.8.8-1
  Remove: totem.x86_64 0:0.99.19-1
Is this ok [y/N]: n

I decided not to go there. For my immediate purposes I have made my
point, which is that I could do it, if needed, it seems--but better to
tell my colleagues to stick with 32-bit unless/until we can build x86_64
of the flumotion dependencies (gstreamer-python, at least).

BTW: We're setting up to stream the FSG Accessibility WG face-to-face in
Hawaii next month. They've come up with an amd64 machine as the
capture/encode/stream server, and I'm seeing caution flags in my mind.

> 
> Tom
> 
> -- 
>   T h o m a s   Z e h e t b a u e r   ( TZ251 )
>   PGP encrypted mail preferred - KeyID 96FFCB89
>       finger thomasz at hostmaster.org for key
> 
> Attempting to apply the OSI layers model to a real network is just like
> attempting to represent seven dimensions in four dimensional reality.
> 
> 
> 



> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Chair
				Accessibility Workgroup
				Free Standards Group (FSG)

janina at freestandards.org	Phone: +1 202.494.7040



From jspaleta at gmail.com  Wed Dec  8 16:01:41 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 8 Dec 2004 11:01:41 -0500
Subject: X86_64 Yum Question
In-Reply-To: <20041208155036.GC5817@rednote.net>
References: <20041208150715.GA5817@rednote.net>
	<1102519132.4468.68.camel@hostmaster.org>
	<20041208155036.GC5817@rednote.net>
Message-ID: <604aa79104120808016f283b32@mail.gmail.com>

On Wed, 8 Dec 2004 10:50:36 -0500, Janina Sajka <janina at rednote.net> wrote:
> Unfortunately, the x86_64 gstreamer-plugins reported a conflict.

gstreamers-plugins from where? parallel installable 32bit and 64bit
rpm packages should be possible the package just needs to be made
aware of the problem and make the 'multilib' corrections that would
allow for it.

-jef



From rjune at bravegnuworld.com  Wed Dec  8 16:05:32 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 11:05:32 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102520556.4257.46.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041208151507.GD12428@angus.ind.WPI.EDU>
	<1102520556.4257.46.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <200412081105.38772.rjune@bravegnuworld.com>

> RHEL 2.1's OpenSSH does not support gssapi-with-mic.  It's something I
> can live without, and am indeed doing just that, because packaging
> headaches make it too difficult to use one of the bazillion existing
> repositories/packages of newer OpenSSH versions.  The only choice I have
> is to install from source, and then I become the security maintainer,
> instead of letting the trusted third-party repository do it for me.
wow. that's just amazing.
You want RPMs of later versions of OpenSSH for RHEL so that you can have 
gssapi-with-mic support. You don't want to do this yourself because it will 
break compatibility with all the other ISVs who've provided software you run 
on your machine. I will be more than happy to provide to you, RPMs for later 
versions of Openssh for RHEL 2.1, or any other distro you decide to use. I 
would be thrilled to add RHEL to the list of distros I support in my 
repository. It will cost you $50 dollars a month per package you want me to 
track and maintain.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/7f4e5abd/attachment.sig>

From elanthis at awesomeplay.com  Wed Dec  8 16:27:32 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 11:27:32 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <200412081105.38772.rjune@bravegnuworld.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041208151507.GD12428@angus.ind.WPI.EDU>
	<1102520556.4257.46.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081105.38772.rjune@bravegnuworld.com>
Message-ID: <1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 11:05 -0500, Richard June wrote:
> > RHEL 2.1's OpenSSH does not support gssapi-with-mic.  It's something I
> > can live without, and am indeed doing just that, because packaging
> > headaches make it too difficult to use one of the bazillion existing
> > repositories/packages of newer OpenSSH versions.  The only choice I have
> > is to install from source, and then I become the security maintainer,
> > instead of letting the trusted third-party repository do it for me.
> wow. that's just amazing.
> You want RPMs of later versions of OpenSSH for RHEL so that you can have 
> gssapi-with-mic support. You don't want to do this yourself because it will 
> break compatibility with all the other ISVs who've provided software you run 
> on your machine. I will be more than happy to provide to you, RPMs for later 

No.  I don't want to do it because I lose any security updates from any
vendor.  I would become the package vendor, and as a result, I'd become
responsible for packaging security updates.  My point was that there are
people who package newer versions of OpenSSH *and* provide security
updates, but I haven't been able to use any of those packages on RHEL
2.1.

It's goofy.  It's a waste of effort.  Someone *already* packages new
versions of OpenSSH, why should someone else have to *repackage* the
exact same binary just to get a different set of RPM headers?  How does
that make sense?

> versions of Openssh for RHEL 2.1, or any other distro you decide to use. I 
> would be thrilled to add RHEL to the list of distros I support in my 
> repository. It will cost you $50 dollars a month per package you want me to 
> track and maintain.

If the OpenSSH issue were really that important, I wouldn't have many
other choices, would I?  Thankfully most of the stuff I run into are
things that, after wasting insane amounts of time on, I can fix myself
(I'm sure you're happy to know your tax money goes towards me having to
duplicate work already done by hundreds to thousands of other
administrators around the world) or I can just live without.  In the
OpenSSH case, I don't *need* gssapi-with-mic, it just simplifies a lot
of what I do, especially when I have long ssh->ssh->ssh chains going
through several firewalls.

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From rjune at bravegnuworld.com  Wed Dec  8 16:57:28 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 11:57:28 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <200412081157.33716.rjune@bravegnuworld.com>

[snip]
> No.  I don't want to do it because I lose any security updates from any
> vendor.  I would become the package vendor, and as a result, I'd become
> responsible for packaging security updates.  My point was that there are
> people who package newer versions of OpenSSH *and* provide security
> updates, but I haven't been able to use any of those packages on RHEL
> 2.1.
Uhm, updating OpenSSH doesn't mean you lose *all* updates from *any* vendor. 
it means you roll your own OpenSSH. If you like, I'll write you a script that 
will check for the latest update from fedora core 3, rebuild it on your box, 
and drop it in a directory for you to inspect/install. 

> It's goofy.  It's a waste of effort.  Someone *already* packages new
> versions of OpenSSH, why should someone else have to *repackage* the
> exact same binary just to get a different set of RPM headers?  How does
> that make sense?
It's not really *goofy*  RHEL 2.1 is not the same as RHEL 3.0, you don't 
expect software built against Windows XP to flawlessly work with windows  98. 
At least with OpenSource, you have the ability to rebuild for your distro. 
Glibc changes, K5 changes, all kinds of things that OpenSSH depends on 
change. 

> > versions of Openssh for RHEL 2.1, or any other distro you decide to use.
> > I would be thrilled to add RHEL to the list of distros I support in my
> > repository. It will cost you $50 dollars a month per package you want me
> > to track and maintain.
>
> If the OpenSSH issue were really that important, I wouldn't have many
> other choices, would I?  Thankfully most of the stuff I run into are
> things that, after wasting insane amounts of time on, I can fix myself
> (I'm sure you're happy to know your tax money goes towards me having to
> duplicate work already done by hundreds to thousands of other
> administrators around the world) or I can just live without.  In the
> OpenSSH case, I don't *need* gssapi-with-mic, it just simplifies a lot
> of what I do, especially when I have long ssh->ssh->ssh chains going
> through several firewalls.
Well, if your email address is indicative of where you work, you shouldn't be 
getting *any* of my tax money period. And you probably shouldn't get any of 
it anyway. But if my tax money does go to you doing work, then I have a right 
to expect to benefit from it. So you need to post and share all the work you 
have done.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/a4f13bd7/attachment.sig>

From twaugh at redhat.com  Wed Dec  8 17:03:02 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 8 Dec 2004 17:03:02 +0000
Subject: RFC: root/non-root bash prompts different colours?
Message-ID: <20041208170302.GI5322@redhat.com>

See:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139628

Should we implement a scheme to differentiate root/non-root bash
prompts by colour?

Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/4e481363/attachment.sig>

From alan at redhat.com  Wed Dec  8 17:07:26 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 12:07:26 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170302.GI5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
Message-ID: <20041208170726.GA6036@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 05:03:02PM +0000, Tim Waugh wrote:
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139628
> 
> Should we implement a scheme to differentiate root/non-root bash
> prompts by colour?

As proposed no. It makes the prompt the same in all cases for colourblind
users. A combination might work but you would to implemnent some fairly fancy
logic topic to dynamically adjust the colour scheme based on the background
and foreground colour of the display, as well as avoiding red on mono monitors.

Alan



From seanlkml at sympatico.ca  Wed Dec  8 17:08:33 2004
From: seanlkml at sympatico.ca (Sean)
Date: Wed, 8 Dec 2004 12:08:33 -0500 (EST)
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102520667.4257.50.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain><1102341652.18495.14.camel@localhost.localdomain><pan.2004.12.07.20.05.34.577743@navi.cx><CF4FB8076F810087D4D3BC0C@[10.0.0.4]><pan.2004.12.08.11.39.34.927483@navi.cx><37671.10.10.10.28.1102506786.squirrel@linux1><1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us><38231.10.10.10.28.1102518410.squirrel@linux1>
	<1102520667.4257.50.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <38413.10.10.10.28.1102525713.squirrel@linux1>

On Wed, December 8, 2004 10:44 am, Sean Middleditch said:

[snip]

Sean,

You seem to want the entire Linux world to Just Get Along[tm] and have
everyone play by the same rules so that proprietary app vendors lives
would
be a little easier.   But there is no way to impose such a solution across
the entire spectrum.

The truth is, the Linux development model is messy with diverse groups of
developers in a wild web of cooperation and competition.  This model is
incredibly powerful and has created the huge success that we have today.
The fact that there are some interoperability issues is hardly surprising,
but their resolution is usually not really that difficult.

Nobody is _ever_ going to get all the people involved in Linux to agree to
anything.   The beauty of open source is, you don't have to get people to
agree, you have the power to do what you want.

Perhaps you'll have some luck convincing RedHat to include every library
ever developed for ever.   But i'm not sure the demand for it is as great
as you think.  Nor would it help on other distributions that refuse to
implement that plan.

Sticking with a long lived distribution really does minimize the problems
for users.  As for proprietary application vendors, the burden imposed by
the Linux landscape really isn't insurmountable.   They have a number of
options on how to provide their products.

Cheers,
Sean




From rjune at bravegnuworld.com  Wed Dec  8 17:13:19 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 12:13:19 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170726.GA6036@devserv.devel.redhat.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
Message-ID: <200412081213.23307.rjune@bravegnuworld.com>

On Wednesday 08 December 2004 12:07, Alan Cox wrote:
> On Wed, Dec 08, 2004 at 05:03:02PM +0000, Tim Waugh wrote:
> >   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139628
> >
> > Should we implement a scheme to differentiate root/non-root bash
> > prompts by colour?
>
> As proposed no. It makes the prompt the same in all cases for colourblind
> users. A combination might work but you would to implemnent some fairly
> fancy logic topic to dynamically adjust the colour scheme based on the
> background and foreground colour of the display, as well as avoiding red on
> mono monitors.
>
> Alan
Wow, that's ugly for both users and root.
why not set root's foreground to blink?

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/19c01fab/attachment.sig>

From mr700 at globalnet.bg  Wed Dec  8 17:26:06 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Wed, 8 Dec 2004 19:26:06 +0200
Subject: konsole/gnome-terminal/xterm, UTF-8 and backspace
In-Reply-To: <41B70D7E.6000908@draigBrady.com>
References: <200412081551.19352@-mr700> <41B70D7E.6000908@draigBrady.com>
Message-ID: <200412081926.06734@-mr700>

On 2004 12 08 (Wednesday) 16:19, P at draigBrady.com wrote:
> Doncho N. Gunchev wrote:
> >     Hello,
> >     when a shell/python script reads input from the user in konsole and
> > gnome-terminal it I enter non-ascii characters (ex: "?????", "Test" in
> > English) backspace does not work correct. For example:
> > --- cut ---
> > $ echo -n "Test: "; read a; echo "[$a]"
> > Test: ?????
> > [ You can paste this, then hit backspace 4 times to get the next line ]
> > Test: ?
> > [ Press Enter here and you get ]
> > [???]
> > $ _
> > --- cut ---
> >     If I erase one character I get '[?????'
> >     Text editing in bash and mc works, but in python 'starts to erase'
> > the '>>> ' prompt. In xterm instead of cyrilic letters I get spaces.
> > I wanted to enter a bug, but I don't know against what to. Looks like
> > backspace erases single bytes, while these letters consist of 2. Can
> > someone direct me and confirm it?
> > 
> 
> Both python and bash use readline to do line editing.
> 4.3-13 is the latest in rawhide but version 5.0 is available
> which seems to fix the issues you mention. Search for
> multibyte in: http://cnswww.cns.cwru.edu/php/chet/readline/CHANGES
> 

    Thanks, bug # 142265 entered:
        http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142265

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From elanthis at awesomeplay.com  Wed Dec  8 17:39:22 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 12:39:22 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <200412081157.33716.rjune@bravegnuworld.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081157.33716.rjune@bravegnuworld.com>
Message-ID: <1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 11:57 -0500, Richard June wrote:
> [snip]
> > No.  I don't want to do it because I lose any security updates from any
> > vendor.  I would become the package vendor, and as a result, I'd become
> > responsible for packaging security updates.  My point was that there are
> > people who package newer versions of OpenSSH *and* provide security
> > updates, but I haven't been able to use any of those packages on RHEL
> > 2.1.
> Uhm, updating OpenSSH doesn't mean you lose *all* updates from *any* vendor. 

Sorry, I meant to say that I lose any updates available from any of the
OpenSSH vendors, of which there are several I could choose from.

> > It's goofy.  It's a waste of effort.  Someone *already* packages new
> > versions of OpenSSH, why should someone else have to *repackage* the
> > exact same binary just to get a different set of RPM headers?  How does
> > that make sense?
> It's not really *goofy*  RHEL 2.1 is not the same as RHEL 3.0, you don't 
> expect software built against Windows XP to flawlessly work with windows  98. 

Yes, actually, I do.  And I'm rarely disappointed.  I really can't
remember the last major conflict I've seen with a Windows app that
wasn't fixable with minor configuration tweaks... we have a couple
proprietary apps here for tax management that aren't even developed
anymore, were originally installed on Win98 machines, and which still
run fine after upgrading to WinXP and then SP2.

Most commercial games are developed on 2000 or XP and yet still support
98.  Windows does not generally break compatibility and does not
generally have magic compilations environments where the exact same
source can end up with wildly different binary requirements and
interfaces depending on where and when it was compiled.  I don't expect
Linux to be at that level of interface stability at this moment, but I
do expect to at least be slowly moving towards it, eventually.

Which is what this whole thread is about.  Things that can be improved
that have absolutely no negative impact on how Linux works now for any
users while potentially improving things for other users.  Better
packaging isn't going to hurt anyone, but it will help.  I haven't yet
seen so much as a single argument against my original suggestion - not
one.

> > If the OpenSSH issue were really that important, I wouldn't have many
> > other choices, would I?  Thankfully most of the stuff I run into are
> > things that, after wasting insane amounts of time on, I can fix myself
> > (I'm sure you're happy to know your tax money goes towards me having to
> > duplicate work already done by hundreds to thousands of other
> > administrators around the world) or I can just live without.  In the
> > OpenSSH case, I don't *need* gssapi-with-mic, it just simplifies a lot
> > of what I do, especially when I have long ssh->ssh->ssh chains going
> > through several firewalls.
> Well, if your email address is indicative of where you work, you shouldn't be 
> getting *any* of my tax money period. And you probably shouldn't get any of 

No, the mail address I use for mailing lists is my personal address.
Keeps things simpler.  ^_^

> it anyway. But if my tax money does go to you doing work, then I have a right 
> to expect to benefit from it. So you need to post and share all the work you 
> have done.

Despite common belief, computers do a lot of work besides just generate
software.  ~_^  My work benefits our residents.  Some of it directly,
some indirectly by improving productivity in our offices.  We also do
release any patches we write back upstream - most of the GNOME and
Debian stuff I've done, for example.  Definitely one of the advantages
of working here, even with the crappy pay.  ;-)
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From alan at redhat.com  Wed Dec  8 17:42:03 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 12:42:03 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412081213.23307.rjune@bravegnuworld.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
Message-ID: <20041208174203.GA2811@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 12:13:19PM -0500, Richard June wrote:
> > Alan
> Wow, that's ugly for both users and root.
> why not set root's foreground to blink?

Not all terminal devices support blink 8)



From fedora-devel at camperquake.de  Wed Dec  8 17:47:59 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Wed, 8 Dec 2004 18:47:59 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208174203.GA2811@devserv.devel.redhat.com>;
	from alan@redhat.com on Wed, Dec 08, 2004 at 12:42:03PM -0500
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
Message-ID: <20041208184759.A7420@ryoko.camperquake.de>

On Wed, Dec 08, 2004 at 12:42:03PM -0500, Alan Cox wrote:

> Not all terminal devices support blink 8)

How about making it beep every second?



From stuart at terminus.co.uk  Wed Dec  8 17:48:03 2004
From: stuart at terminus.co.uk (Stuart Children)
Date: Wed, 08 Dec 2004 17:48:03 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170302.GI5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
Message-ID: <41B73E53.4050408@terminus.co.uk>

Tim Waugh wrote:
> Should we implement a scheme to differentiate root/non-root bash
> prompts by colour?

Don't the colour escape sequences break (FSVO break) some terminals? 
Could be annoying for people connecting in from other systems.

I'd say no regardless. It's too dificult to choose appropriate colours. 
If you really wanted to do this then bold might be more suitable (though 
still has the above issue). However, I don't know that either of them 
necessarily make it clear to the user "this is a root shell, it can be 
used to destory your system".

Personally, I think the current \u and \$ in the prompt are sufficient 
to determine that the shell has changed and you are now root. Though I 
would agree that \$ doesn't do this by itself. If all you want to do is 
draw more attention to the fact that the shell has changed, or which one 
you're currently in (trying to help people not type into the wrong 
terminal for example), then you could just make the prompts just look a 
bit more different. Eg: "\u@\h \W \$" for regular users, "[[[SUPERUSER 
\u@\h \W]]]\$" for root.

If the main point is trying to alert the user to the fact that it's far 
easier to do damage when you're root then whey not have a message in 
su/sudo that gets printed if it's attached to a terminal? Though I think 
if someone's managed to find that out how to become root on the command 
line they should be aware enough of what they're doing.

My vote is change nothing.

-- 
Stuart



From alan at redhat.com  Wed Dec  8 17:48:40 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 12:48:40 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081157.33716.rjune@bravegnuworld.com>
	<1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <20041208174840.GC2811@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 12:39:22PM -0500, Sean Middleditch wrote:
> Most commercial games are developed on 2000 or XP and yet still support
> 98.  Windows does not generally break compatibility and does not
> generally have magic compilations environments where the exact same

That generally has more to do with the fact that 50% of Windows users are
on Win98 and don't plan to move until the are dragged kicking and screaming
probably onto 64bit.

> that have absolutely no negative impact on how Linux works now for any
> users while potentially improving things for other users.  Better
> packaging isn't going to hurt anyone, but it will help.  I haven't yet

Im still a little confused the precise points you want to see improve. Can you
enumerate them as concise points ?



From dcbw at redhat.com  Wed Dec  8 17:49:31 2004
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 08 Dec 2004 12:49:31 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081157.33716.rjune@bravegnuworld.com>
	<1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <1102528171.26105.28.camel@dcbw.boston.redhat.com>

On Wed, 2004-12-08 at 12:39 -0500, Sean Middleditch wrote:
> Most commercial games are developed on 2000 or XP and yet still support
> 98.  Windows does not generally break compatibility and does not
> generally have magic compilations environments where the exact same
> source can end up with wildly different binary requirements and
> interfaces depending on where and when it was compiled.  I don't expect
> Linux to be at that level of interface stability at this moment, but I
> do expect to at least be slowly moving towards it, eventually.

None of the Need For Speed games from EA from v3 (including Porsche
Unleashed) and earlier work on Win2K/XP/NT at all.  EA declines to fix
this.  It most certainly happens on Windows.  Or how about a vendor of
certain moving-message sign software that requires a specific version of
Java that only works on < 2000?  There are tons of smaller cases where
certain apps don't work on newer versions of Windows that are based on
NT because they were designed for 95/98/ME only.  What do NT/Win2k/XP
users do then when they wish to upgrade?

Dan



From elanthis at awesomeplay.com  Wed Dec  8 17:50:49 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 12:50:49 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <38413.10.10.10.28.1102525713.squirrel@linux1>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<1102341652.18495.14.camel@localhost.localdomain>
	<pan.2004.12.07.20.05.34.577743@navi.cx>
	<CF4FB8076F810087D4D3BC0C@[10.0.0.4]>
	<pan.2004.12.08.11.39.34.927483@navi.cx>
	<37671.10.10.10.28.1102506786.squirrel@linux1>
	<1102517179.4257.7.camel@support02.civic.twp.ypsilanti.mi.us>
	<38231.10.10.10.28.1102518410.squirrel@linux1>
	<1102520667.4257.50.camel@support02.civic.twp.ypsilanti.mi.us>
	<38413.10.10.10.28.1102525713.squirrel@linux1>
Message-ID: <1102528249.4257.118.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 12:08 -0500, Sean wrote:
> On Wed, December 8, 2004 10:44 am, Sean Middleditch said:
> 
> [snip]
> 
> Sean,
> 
> You seem to want the entire Linux world to Just Get Along[tm] and have
> everyone play by the same rules so that proprietary app vendors lives
> would
> be a little easier.   But there is no way to impose such a solution across
> the entire spectrum.

Stop there.  You seem hung up on the proprietary app stuff.  I think
I've made it as clear as I can that *Open Source* apps are hurt too.  In
fact, I haven't had any problems installing proprietary apps here at
work.  It's the third party open source apps that are a pain.

> 
> The truth is, the Linux development model is messy with diverse groups of
> developers in a wild web of cooperation and competition.  This model is
> incredibly powerful and has created the huge success that we have today.
> The fact that there are some interoperability issues is hardly surprising,
> but their resolution is usually not really that difficult.

Right.  That's my whole point.  Resolution is not really that difficult.
So why are you arguing against the simple resolution?

> 
> Nobody is _ever_ going to get all the people involved in Linux to agree to
> anything.   The beauty of open source is, you don't have to get people to
> agree, you have the power to do what you want.

> 
> Perhaps you'll have some luck convincing RedHat to include every library
> ever developed for ever.   But i'm not sure the demand for it is as great
> as you think.  Nor would it help on other distributions that refuse to
> implement that plan.

That is *not* what I've asked for.  I've made it rather clear that I
think that Red Hat even *trying* to provide tons of software is goofy.
Centralization, as I've said, is *NOT* the answer and never will be.

> 
> Sticking with a long lived distribution really does minimize the problems
> for users.  As for proprietary application vendors, the burden imposed by
> the Linux landscape really isn't insurmountable.   They have a number of
> options on how to provide their products.

It's not the vendors I'm worried about.  It's the users.  Or even the
Open Source developers.  Every hour that I spend dealing with some
stupid breakage is an hour that I *could* have spent writing code.  Or,
heck, out with friends or family or whatever.  Maybe that list of "cool
projects I want to do but haven't yet" would be a bit smaller if it
didn't take hours to get a simple actively maintained open source app
installed because it's dependencies conflict left and right due to poor
packaging and/or poor library interface management.

This argument is getting close to going in circles.  Do you have any
actual arguments against anything I've proposed or asked for?  I haven't
actually seen one yet...
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From nbargnesi at gmail.com  Wed Dec  8 17:53:15 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 8 Dec 2004 12:53:15 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208174203.GA2811@devserv.devel.redhat.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
Message-ID: <3077b8a00412080953c065ab9@mail.gmail.com>

On Wed, 8 Dec 2004 12:42:03 -0500, Alan Cox <alan at redhat.com> wrote:
> On Wed, Dec 08, 2004 at 12:13:19PM -0500, Richard June wrote:
> > > Alan
> > Wow, that's ugly for both users and root.
> > why not set root's foreground to blink?
> 
> Not all terminal devices support blink 8)

Ever had too much coffee and tried staring at a blinking prompt?
Yet another option would just be to alter PS1 to display something like:

-- WARNING - LOGGED IN AS ROOT --
[root at machine root]#  

Might look obtrusive but it gets the point across to the color blind
administrators and feature-less terminals.


> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From twaugh at redhat.com  Wed Dec  8 17:56:51 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 8 Dec 2004 17:56:51 +0000
Subject: Upgrading readline
Message-ID: <20041208175651.GL5322@redhat.com>

For upgrading readline to a new major release (in Fedora development),
do I need to provide a readline4 package, or is it sufficient to just
rebuild the packages that depend on it?

Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/b706dd04/attachment.sig>

From elanthis at awesomeplay.com  Wed Dec  8 17:57:02 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 12:57:02 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041208174840.GC2811@devserv.devel.redhat.com>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081157.33716.rjune@bravegnuworld.com>
	<1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
	<20041208174840.GC2811@devserv.devel.redhat.com>
Message-ID: <1102528622.4257.125.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 12:48 -0500, Alan Cox wrote:
> On Wed, Dec 08, 2004 at 12:39:22PM -0500, Sean Middleditch wrote:
> > that have absolutely no negative impact on how Linux works now for any
> > users while potentially improving things for other users.  Better
> > packaging isn't going to hurt anyone, but it will help.  I haven't yet
> 
> Im still a little confused the precise points you want to see improve. Can you
> enumerate them as concise points ?

The biggest thing Red Hat could do is simply provide a little cleaner
packaging.  There are libraries that Red Hat packages which are clearly
capable of being parallel installed and otherwise working beautifully,
but Red Hat's packages cause artificial incompatibilities.

Take the libcurl examples from the other thread.  The curl package has
both the libcurl library and the curl utility.  When curl was upgrade,
it dropped libcurl.so.2 and added libcurl.so.3.  There is only one
package that, depending on version, provides two totally different
interfaces.  You can't even manually install both versions since both
include the curl utiltiy and thus have true conflicts.  I had a third
part open source app (Xine) that depended on libcurl.so.2.  Apps from
Fedora requires libcurl.so.3.  It took around a month for a new Xine
compiled against libcurl.so.3 to appear.  I had to uninstall and not use
Xine for a month.

However, there was no reason why this should have happened.  Both
libcurl and Xine were correctly functioning and well written in terms of
library interfaces.  The entire problem with artificially created by the
RPM packages.

If libcurl had been split from the curl package and given proper names
like libcurl02 and libcurl03, this problem never would have occured.
The upgrade would have installed libcurl03, any utilities/apps that
needed libcurl.so.3 would be satisfied, and apps that still needed
libcurl.so.2 wouldn't have any problems as the packages would be stick
in this exclusive "one or the other" problem.

It's just little stuff like that I want to see fixed.  That's it, on Red
Hat's part.

In general, I'd like to see more responsibility on the part of certain
library developers.  Mike Hearn and Havoc Pennington have written some
pieces on all the details of library management, I don't think I can
really say it any better than they did.  ~_^

> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From alan at redhat.com  Wed Dec  8 17:57:29 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 12:57:29 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208184759.A7420@ryoko.camperquake.de>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<20041208184759.A7420@ryoko.camperquake.de>
Message-ID: <20041208175729.GE2811@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 06:47:59PM +0100, Ralf Ertzinger wrote:
> On Wed, Dec 08, 2004 at 12:42:03PM -0500, Alan Cox wrote:
> > Not all terminal devices support blink 8)
> How about making it beep every second?

Deaf users ?

More seriously there is a need to be careful with this. Nowdays many people 
remember blind users but there are still programs whose alerts can only be
set to be audio, an a lot of games where audio clues are valuable but provide
no visual equivalent.

Alan



From cmadams at hiwaay.net  Wed Dec  8 17:59:35 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 8 Dec 2004 11:59:35 -0600
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412081213.23307.rjune@bravegnuworld.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
Message-ID: <20041208175935.GA1450210@hiwaay.net>

Once upon a time, Richard June <rjune at bravegnuworld.com> said:
> Wow, that's ugly for both users and root.
> why not set root's foreground to blink?

Because blinking is damn annoying.

If anyone is going to do anything like this, please use tput to get
terminal capabilities before doing it (not everyone uses the same
terminal, not all terminals have color, and not all terminals use the
same escape sequences).

Something like:

colors=`tput colors`
if [ `id -un` = root ]; then
	if ((${colors:-0} > 7)); then
		standout=`tput setaf 5`
	else
		standout=`tput bold`
	fi
else
	if ((${colors:-0} > 7)); then
		standout=`tput setaf 6`
	else
		standout=""
	fi
fi
if [ "$standout" != "" ]; then
	normal=`tput sgr0`
	if ((${colors:-0} > 7)); then
		other=`tput setaf 2`
	else
		other="$normal"
	fi

	if [ "$normal" = "" ]; then
		standout=""
		other=""
	else
		standout="\[$standout\]"
		other="\[$other\]"
		normal="\[$normal\]"
	fi
fi

PS1="${other}[${standout}\u@\h \W${other}]\$${normal} "
unset standout other normal

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From ben.steeves at gmail.com  Wed Dec  8 18:00:14 2004
From: ben.steeves at gmail.com (Ben Steeves)
Date: Wed, 8 Dec 2004 14:00:14 -0400
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a00412080953c065ab9@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
Message-ID: <7ebb24d104120810001239d037@mail.gmail.com>

On Wed, 8 Dec 2004 12:53:15 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> -- WARNING - LOGGED IN AS ROOT --
> [root at machine root]#
> 
> Might look obtrusive but it gets the point across to the color blind
> administrators and feature-less terminals.

Reverse video is supported on just about every terminal I can think of
(I'm sure there are some that I can't, tho :-) -- and it works for
colour-blind users, too.

Personally, all my root prompts are reversed video, with the
background colour different on different servers.  It helps when you
have root shells on four or five boxes open at once... wouldn't want
to shutdown the wrong server, now would we ;-)

Ben
-- 
Ben Steeves                     _                    bcs at metacon.ca
 The ASCII ribbon campaign     ( )            ben.steeves at gmail.com
   against HTML e-mail          X                GPG ID: 0xB3EBF1D9
http://www.metacon.ca/bcs      / \     Yahoo Messenger: ben_steeves



From rahulsundaram at yahoo.co.in  Wed Dec  8 18:02:22 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 10:02:22 -0800 (PST)
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <41B73E53.4050408@terminus.co.uk>
Message-ID: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>

Hi


> I'd say no regardless. It's too dificult to choose
> appropriate colours. 

I dont think so. with some amount of careful thought
it should be possible
Though I think 
> if someone's managed to find that out how to become
> root on the command 
> line they should be aware enough of what they're
> doing.


Not necessarily. Its a problem of educating the user
better. If it has a distintive prompt (maybe red?)
suggesting the user be careful when working with it,
this can be useful. Many distros have a unique
wallpaper on the desktop for root users for example.
Ubuntu has choosen to use sudo since they are focussed
on the desktop

If fedora was catering just to old time unix users who
are used to working with Linux on the server, then
this definitely is not needed but since its trying to
be appealing to everyone including newbies, it is
important that we do something like this. Not
necessarily what was suggested in the bug report
(consider that a arbitrary exmaple) but something
similar



=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



From rjune at bravegnuworld.com  Wed Dec  8 18:04:50 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 13:04:50 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a00412080953c065ab9@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
Message-ID: <200412081304.54413.rjune@bravegnuworld.com>


> -- WARNING - LOGGED IN AS ROOT --
> [root at machine root]#
>
> Might look obtrusive but it gets the point across to the color blind
> administrators and feature-less terminals.

And that good sir, wins the prize as most obvious way to do it that fits the 
criteria. Good job. /me pats your back.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/a34d2d7a/attachment.sig>

From rahulsundaram at yahoo.co.in  Wed Dec  8 18:05:38 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 10:05:38 -0800 (PST)
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208175729.GE2811@devserv.devel.redhat.com>
Message-ID: <20041208180538.70229.qmail@web8501.mail.in.yahoo.com>


--- Alan Cox <alan at redhat.com> wrote:

> On Wed, Dec 08, 2004 at 06:47:59PM +0100, Ralf
> Ertzinger wrote:
> > On Wed, Dec 08, 2004 at 12:42:03PM -0500, Alan Cox
> wrote:
> > > Not all terminal devices support blink 8)
> > How about making it beep every second?
> 
> Deaf users ?
> 
> More seriously there is a need to be careful with
> this. 

very true Alan

Nowdays many people 
> remember blind users but there are still programs
> whose alerts can only be
> set to be audio, an a lot of games where audio clues
> are valuable but provide
> no visual equivalent.
> 
> Alan


Maybe we need a comprehensive accessibility framework
not just for Gnome but in bash too?

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250



From rahulsundaram at yahoo.co.in  Wed Dec  8 18:07:00 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 10:07:00 -0800 (PST)
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102528622.4257.125.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <20041208180700.70503.qmail@web8501.mail.in.yahoo.com>

Hi


 There are libraries that Red Hat
> packages which are clearly
> capable of being parallel installed and otherwise
> working beautifully,
> but Red Hat's packages cause artificial
> incompatibilities.
> 
> Take the libcurl examples from the other thread.

have you filed a bug report?

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From frank at pineaus.com  Wed Dec  8 18:09:09 2004
From: frank at pineaus.com (Frank Pineau)
Date: Wed, 08 Dec 2004 13:09:09 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <7ebb24d104120810001239d037@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
Message-ID: <1102529349.3612.30.camel@morbo>

On Wed, 2004-12-08 at 14:00 -0400, Ben Steeves wrote:
> On Wed, 8 Dec 2004 12:53:15 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> > -- WARNING - LOGGED IN AS ROOT --
> > [root at machine root]#
> > 
> > Might look obtrusive but it gets the point across to the color blind
> > administrators and feature-less terminals.
> 
> Reverse video is supported on just about every terminal I can think of
> (I'm sure there are some that I can't, tho :-) -- and it works for
> colour-blind users, too.
> 
> Personally, all my root prompts are reversed video, with the
> background colour different on different servers.  It helps when you
> have root shells on four or five boxes open at once... wouldn't want
> to shutdown the wrong server, now would we ;-)


That was my prompt that Rahul posted.  Sorry about squeaking in mid-
thread, I just joined the list.

Yeah, it's an ugly prompt, but it works well for me :)  I used to use
all-red for root and all white for non-root, but I ran into some issues
on some terminals I was using.

It seems to me that if a user were colour blind, then it would be the
same net effect as not changing the prompt at all.  The prompt already
contains the user name, as well as a # or a $ (depending on state).

I don't like the idea of adding "-- WARNING - LOGGED IN AS ROOT --"
unless it's part of the actual prompt (which would be nuts).  When I've
got six terminal sessions running and half are root, I need more
indication besides a one-line banner when I first start the session.

-- 
Fix it! Fix it! Fix it! Fix it! Fix it! Fix it!... Fix it! Fix it! Fix
it!

--Fry
  Futurama - "A Clone of My Own"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/6fccc5f2/attachment.sig>

From notting at redhat.com  Wed Dec  8 18:14:08 2004
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Dec 2004 13:14:08 -0500
Subject: Upgrading readline
In-Reply-To: <20041208175651.GL5322@redhat.com>
References: <20041208175651.GL5322@redhat.com>
Message-ID: <20041208181407.GA5978@nostromo.devel.redhat.com>

Tim Waugh (twaugh at redhat.com) said: 
> For upgrading readline to a new major release (in Fedora development),
> do I need to provide a readline4 package, or is it sufficient to just
> rebuild the packages that depend on it?

A compat library may be nice, considering the number of apps that link
against it.

Bill



From rjune at bravegnuworld.com  Wed Dec  8 18:24:39 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 13:24:39 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<200412081157.33716.rjune@bravegnuworld.com>
	<1102527562.4257.105.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <200412081324.44601.rjune@bravegnuworld.com>

On Wednesday 08 December 2004 12:39, Sean Middleditch wrote:
> On Wed, 2004-12-08 at 11:57 -0500, Richard June wrote:
> > [snip]
> >
> > > No.  I don't want to do it because I lose any security updates from any
> > > vendor.  I would become the package vendor, and as a result, I'd become
> > > responsible for packaging security updates.  My point was that there
> > > are people who package newer versions of OpenSSH *and* provide security
> > > updates, but I haven't been able to use any of those packages on RHEL
> > > 2.1.
> >
> > Uhm, updating OpenSSH doesn't mean you lose *all* updates from *any*
> > vendor.
>
> Sorry, I meant to say that I lose any updates available from any of the
> OpenSSH vendors, of which there are several I could choose from.
Uhm, if the vendor doesn't offer what you want, why don't you look to a 
different vendor? I know there are vendors who would be glad to do this for 
you.

> > > It's goofy.  It's a waste of effort.  Someone *already* packages new
> > > versions of OpenSSH, why should someone else have to *repackage* the
> > > exact same binary just to get a different set of RPM headers?  How does
> > > that make sense?
> >
> > It's not really *goofy*  RHEL 2.1 is not the same as RHEL 3.0, you don't
> > expect software built against Windows XP to flawlessly work with windows 
> > 98.
>
> Yes, actually, I do.  And I'm rarely disappointed.  I really can't
> remember the last major conflict I've seen with a Windows app that
> wasn't fixable with minor configuration tweaks... we have a couple
> proprietary apps here for tax management that aren't even developed
> anymore, were originally installed on Win98 machines, and which still
> run fine after upgrading to WinXP and then SP2.
[BZZT] Stop right there. I didn't say anything about expecting RHEL 2.1 
software to work on RHEL 3.0. Backwards compatibility is a valid expectation. 
and I have a handfull of donated games at my library that don't work at *all* 
on Windows XP, and the vendors refuse to fix them. Leaving me with a bunch of 
nice coasters. If they were Open Source, at least I could attempt to fix 
them. 

> Most commercial games are developed on 2000 or XP and yet still support
> 98.  Windows does not generally break compatibility and does not
> generally have magic compilations environments where the exact same
> source can end up with wildly different binary requirements and
> interfaces depending on where and when it was compiled.  I don't expect
> Linux to be at that level of interface stability at this moment, but I
> do expect to at least be slowly moving towards it, eventually.
>
> Which is what this whole thread is about.  Things that can be improved
> that have absolutely no negative impact on how Linux works now for any
> users while potentially improving things for other users.  Better
> packaging isn't going to hurt anyone, but it will help.  I haven't yet
> seen so much as a single argument against my original suggestion - not
> one.
Better packaging won't hurt anyone. but mostly I've not seen you argue for 
anything specificly, just better packaging in general, and includeing all 
deps in the RPM, which is *not* better packaging. (as in another post) if a 
package (Xine) requires libcurl.so.2, and the OS supplies libcurl.so.3, there 
are two valid answers, rebuild the package for the OS(which is what they did) 
or have the OS provide compatibility RPMs(which they do for some libraries). 
Something like curl-libs2 would have been perfectly valid, and pretty simple 
to do. Curl should be broken up into util and the libs anyway. More depends 
on libcurl than the curl utility.

[snip]
> > it anyway. But if my tax money does go to you doing work, then I have a
> > right to expect to benefit from it. So you need to post and share all the
> > work you have done.
>
> Despite common belief, computers do a lot of work besides just generate
> software.  ~_^  My work benefits our residents.  Some of it directly,
> some indirectly by improving productivity in our offices.  We also do
> release any patches we write back upstream - most of the GNOME and
> Debian stuff I've done, for example.  Definitely one of the advantages
> of working here, even with the crappy pay.  ;-)
Yes, your work benefits your residents. but if you get *my* tax money, then I 
have a right to expect a benefit as well as I am paying you. If it's a local 
office funded only by local money, then you owe nothing to anybody but your 
residents. As I mentioned. I do work for a library, as such we are acutely 
aware of our responsibility to the public. We spend as little as possible, 
and make everything we can transparent. Why? because that's the way it should 
be.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/0dc0841c/attachment.sig>

From nbargnesi at gmail.com  Wed Dec  8 18:25:28 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 8 Dec 2004 13:25:28 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102529349.3612.30.camel@morbo>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102529349.3612.30.camel@morbo>
Message-ID: <3077b8a00412081025254c6227@mail.gmail.com>

On Wed, 08 Dec 2004 13:09:09 -0500, Frank Pineau <frank at pineaus.com> wrote:
> On Wed, 2004-12-08 at 14:00 -0400, Ben Steeves wrote:
> 
> 
> > On Wed, 8 Dec 2004 12:53:15 -0500, Nick Bargnesi <nbargnesi at gmail.com> wrote:
> > > -- WARNING - LOGGED IN AS ROOT --
> > > [root at machine root]#
> > >
> > > Might look obtrusive but it gets the point across to the color blind
> > > administrators and feature-less terminals.
> >
> > Reverse video is supported on just about every terminal I can think of
> > (I'm sure there are some that I can't, tho :-) -- and it works for
> > colour-blind users, too.
> >
> > Personally, all my root prompts are reversed video, with the
> > background colour different on different servers.  It helps when you
> > have root shells on four or five boxes open at once... wouldn't want
> > to shutdown the wrong server, now would we ;-)
> 
> 
> That was my prompt that Rahul posted.  Sorry about squeaking in mid-
> thread, I just joined the list.
> 
> Yeah, it's an ugly prompt, but it works well for me :)  I used to use
> all-red for root and all white for non-root, but I ran into some issues
> on some terminals I was using.
> 
> It seems to me that if a user were colour blind, then it would be the
> same net effect as not changing the prompt at all.  The prompt already
> contains the user name, as well as a # or a $ (depending on state).
> 
> I don't like the idea of adding "-- WARNING - LOGGED IN AS ROOT --"
> unless it's part of the actual prompt (which would be nuts).  When I've
> got six terminal sessions running and half are root, I need more
> indication besides a one-line banner when I first start the session.
> 

Who said it was a one-liner?  
i.e., 
export PS1="\n-- WARNING - Use your head.  You're root. --\n[\u@\h \W]$ "


> --
> Fix it! Fix it! Fix it! Fix it! Fix it! Fix it!... Fix it! Fix it! Fix
> it!
> 
> --Fry
>   Futurama - "A Clone of My Own"
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From elanthis at awesomeplay.com  Wed Dec  8 18:28:07 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 08 Dec 2004 13:28:07 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <20041208180700.70503.qmail@web8501.mail.in.yahoo.com>
References: <20041208180700.70503.qmail@web8501.mail.in.yahoo.com>
Message-ID: <1102530487.4257.129.camel@support02.civic.twp.ypsilanti.mi.us>

On Wed, 2004-12-08 at 10:07 -0800, Rahul Sundaram wrote:
> Hi
> 
> 
>  There are libraries that Red Hat
> > packages which are clearly
> > capable of being parallel installed and otherwise
> > working beautifully,
> > but Red Hat's packages cause artificial
> > incompatibilities.
> > 
> > Take the libcurl examples from the other thread.
> 
> have you filed a bug report?

Of course.

> 
> =====
> Regards
> Rahul Sundaram
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - 250MB free storage. Do more. Manage less. 
> http://info.mail.yahoo.com/mail_250
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From symbiont at berlios.de  Wed Dec  8 18:33:19 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Thu, 9 Dec 2004 02:33:19 +0800
Subject: Upgrading readline
In-Reply-To: <20041208181407.GA5978@nostromo.devel.redhat.com>
References: <20041208175651.GL5322@redhat.com>
	<20041208181407.GA5978@nostromo.devel.redhat.com>
Message-ID: <200412090233.19617.symbiont@berlios.de>

On Thursday 09 December 2004 02:14, Bill Nottingham wrote:
> > For upgrading readline to a new major release (in Fedora
> > development), do I need to provide a readline4 package, or is it
> > sufficient to just rebuild the packages that depend on it?
>
> A compat library may be nice, considering the number of apps that
> link against it.

Check ABI compat within pkg first.  Eg, you can link python 1.5 against 
db4 cuz db4 has db1-ish stuff still.  Reduction of compat madness is 
optimal.

have fun,
-- 
-jeff



From Nicolas.Mailhot at laPoste.net  Wed Dec  8 18:38:28 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 08 Dec 2004 19:38:28 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412081304.54413.rjune@bravegnuworld.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<200412081304.54413.rjune@bravegnuworld.com>
Message-ID: <1102531109.10699.0.camel@rousalka.dyndns.org>

Le mercredi 08 d?cembre 2004 ? 13:04 -0500, Richard June a ?crit :
> > -- WARNING - LOGGED IN AS ROOT --
> > [root at machine root]#
> >
> > Might look obtrusive but it gets the point across to the color blind
> > administrators and feature-less terminals.
> 
> And that good sir, wins the prize as most obvious way to do it that fits the 
> criteria. Good job. /me pats your back.

Well it has localisation problems (runs;)

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/180be294/attachment.sig>

From nbargnesi at gmail.com  Wed Dec  8 18:48:45 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 8 Dec 2004 13:48:45 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102531109.10699.0.camel@rousalka.dyndns.org>
References: <20041208170302.GI5322@redhat.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<200412081304.54413.rjune@bravegnuworld.com>
	<1102531109.10699.0.camel@rousalka.dyndns.org>
Message-ID: <3077b8a004120810486e8d3a66@mail.gmail.com>

On Wed, 08 Dec 2004 19:38:28 +0100, Nicolas Mailhot
<Nicolas.Mailhot at laposte.net> wrote:
> Le mercredi 08 d?cembre 2004 ? 13:04 -0500, Richard June a ?crit :
> > > -- WARNING - LOGGED IN AS ROOT --
> > > [root at machine root]#
> > >
> > > Might look obtrusive but it gets the point across to the color blind
> > > administrators and feature-less terminals.
> >
> > And that good sir, wins the prize as most obvious way to do it that fits the
> > criteria. Good job. /me pats your back.
> 
> Well it has localisation problems (runs;)
> 

Eh...
-- [WARNING] [ALERTE] [DIE WARNUNG] [ALARMA] [ALERTA] --
[root at machine root]#

Unfortunately, I couldn't find the klingon translation for all the
wrinkly-skinned root users.

> Regards,
> 
> --
> Nicolas Mailhot
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From n3npq at nc.rr.com  Wed Dec  8 19:11:14 2004
From: n3npq at nc.rr.com (Jeff Johnson)
Date: Wed, 08 Dec 2004 14:11:14 -0500
Subject: Upgrading readline
In-Reply-To: <20041208175651.GL5322@redhat.com>
References: <20041208175651.GL5322@redhat.com>
Message-ID: <41B751D2.5070105@nc.rr.com>

Tim Waugh wrote:

>For upgrading readline to a new major release (in Fedora development),
>do I need to provide a readline4 package, or is it sufficient to just
>rebuild the packages that depend on it?
>  
>

Prolly.

Alternatively, if the API changes aren't seriously different, you might just
as well add versioned symbols so that we can get rid of all this 
compat-baggage
once and for all, and provide an explicit and trackable ABI in the same 
soname
just like glibc does.

See elfutils for hints on serious and sober use of versioned symbols.

FWIW, I'm convinced that libselinux is going to need to undertake versioned
symbols Real Soon Now as well, bit that's fedora-selinux, not 
fedora-devel, fodder.

73 de Jeff



From rjune at bravegnuworld.com  Wed Dec  8 19:15:54 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Wed, 8 Dec 2004 14:15:54 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a004120810486e8d3a66@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<1102531109.10699.0.camel@rousalka.dyndns.org>
	<3077b8a004120810486e8d3a66@mail.gmail.com>
Message-ID: <200412081415.58467.rjune@bravegnuworld.com>

On Wednesday 08 December 2004 13:48, Nick Bargnesi wrote:
> On Wed, 08 Dec 2004 19:38:28 +0100, Nicolas Mailhot
>
> <Nicolas.Mailhot at laposte.net> wrote:
> > Le mercredi 08 d?cembre 2004 ? 13:04 -0500, Richard June a ?crit :
> > > > -- WARNING - LOGGED IN AS ROOT --
> > > > [root at machine root]#
> > > >
> > > > Might look obtrusive but it gets the point across to the color blind
> > > > administrators and feature-less terminals.
> > >
> > > And that good sir, wins the prize as most obvious way to do it that
> > > fits the criteria. Good job. /me pats your back.
> >
> > Well it has localisation problems (runs;)
>
> Eh...
> -- [WARNING] [ALERTE] [DIE WARNUNG] [ALARMA] [ALERTA] --
> [root at machine root]#
>
> Unfortunately, I couldn't find the klingon translation for all the
> wrinkly-skinned root users.
Wouldn't that be lumpy forheaded root users?
-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/81d911e4/attachment.sig>

From rahulsundaram at yahoo.co.in  Wed Dec  8 19:34:15 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 11:34:15 -0800 (PST)
Subject: Fedora and Redhat EL
Message-ID: <20041208193415.60910.qmail@web8510.mail.in.yahoo.com>

Hi

I have been using both Fedora and Redhat EL systems
and it seems to me that the split between these
distributions makes it more easy for Fedora to form a
community with a set of third party repositories and
packagers working with it while Redhat EL is left out
in the cold with a few exceptions like dag's
repository. 

One of the reasons is that Redhat EL is tied into a
subscription model (ie) the binaries are not available
for free from Redhat itself. While third party
rebuilds like centos(centos.org) do a good job of
filling that need, it might be more beneficial for
Redhat to supply the binaries and ISO images itself
without a support subscription attached to it. A
subscription would only be available for a fee. 

Benefits

* Business strategy is clear, Software is free.
Support costs.
* Prevents Redhat EL(or even Linux itself) being
called a costly affair
* Redhat can actively form  a community just like what
it is trying to do with the fedora project

Disadvantage

- From a business viewpoint

One of the reasons seems to be that people would
download the software and expect Redhat to support it
too.  

I see a few choices to make that clear to the end user

* A click through agreement that says the software is
unsupported. 

* called it redhat-unsupported-(arch).iso

* A nag in the installer warning that the software is
unsupported when its the download version. Remove all
the trademarks and stuff you need to protect and swap
it with a free set of things you dont need to care
about..

Bandwidth

ISO images are only available directly to those who
mirror it.

up2date, yum or whatever never points to the redhat
mirrors in the downloaded version and instead switches
between the free mirrors as required

Since those who want to use it for free are going to
use a rebuild anyway, I dont see a potential loss
there.

Your thoughts?


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 



From skvidal at phy.duke.edu  Wed Dec  8 19:38:37 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 08 Dec 2004 14:38:37 -0500
Subject: Fedora and Redhat EL
In-Reply-To: <20041208193415.60910.qmail@web8510.mail.in.yahoo.com>
References: <20041208193415.60910.qmail@web8510.mail.in.yahoo.com>
Message-ID: <1102534717.24730.64.camel@opus.phy.duke.edu>

On Wed, 2004-12-08 at 11:34 -0800, Rahul Sundaram wrote:
> Hi
> 
> I have been using both Fedora and Redhat EL systems
> and it seems to me that the split between these
> distributions makes it more easy for Fedora to form a
> community with a set of third party repositories and
> packagers working with it while Redhat EL is left out
> in the cold with a few exceptions like dag's
> repository. 
> 
> One of the reasons is that Redhat EL is tied into a
> subscription model (ie) the binaries are not available
> for free from Redhat itself. While third party
> rebuilds like centos(centos.org) do a good job of
> filling that need, it might be more beneficial for
> Redhat to supply the binaries and ISO images itself
> without a support subscription attached to it. A
> subscription would only be available for a fee. 
> 

I'm fairly sure this is off-topic for this list.

I'm not even sure where it's on topic, but I'm positive this list is not
it.

-sv




From rahulsundaram at yahoo.co.in  Wed Dec  8 19:42:36 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 11:42:36 -0800 (PST)
Subject: Fedora and Redhat EL
In-Reply-To: <1102534717.24730.64.camel@opus.phy.duke.edu>
Message-ID: <20041208194236.85213.qmail@web8501.mail.in.yahoo.com>

Hi


> 
> I'm fairly sure this is off-topic for this list.
> 
> I'm not even sure where it's on topic, but I'm
> positive this list is not
> it.
> 
> -sv


Ok if somebody can point me to a list where its
supposed to be on topic if such a list exists and the
relevant people are willing to discuss this I will
move the discussion there otherwise I dont see any
other option but to drop this one



=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



From sjansen at gurulabs.com  Wed Dec  8 20:24:32 2004
From: sjansen at gurulabs.com (Stuart Jansen)
Date: Wed, 08 Dec 2004 13:24:32 -0700
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a00412080953c065ab9@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
Message-ID: <1102537472.3902.11.camel@vision>

On Wed, 2004-12-08 at 12:53 -0500, Nick Bargnesi wrote:
> Yet another option would just be to alter PS1 to display something like:
> 
> -- WARNING - LOGGED IN AS ROOT --
> [root at machine root]#  

I like modifying PS1 to include this warning. It's simple and effective.
At least one person has expressed disgust at the idea of a multi-line
PS1, but it isn't hard to remove after installation. Of course, I may
not be one to speak as my PS1 is five lines tall.

Just want to re-inforce a point already made by Nick: 



> export PS1="\n-- WARNING - Use your head.  You're root. --\n[\u@\h
\W]$ "

I've found that with multi-line prompts, including a blank line at the
start makes them much easier to read. Although that does push root's PS1
from a moderate 2 lines to a slightly extreme three...

-- 
Stuart Jansen <sjansen at gurulabs.com>
Guru Labs, L.C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041208/0b0f31a2/attachment.sig>

From christopher.hotchkiss at gmail.com  Wed Dec  8 20:31:56 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Wed, 8 Dec 2004 15:31:56 -0500
Subject: Stateless kickstart problem
Message-ID: <7f48492a041208123146b28827@mail.gmail.com>

I got back to work trying to get this up and running today. I ran into
the following problem, I needed a proxy to download the stateless
packages properly, the section of the kickstart is below.

    f.close()
    def do_chroot (commands):
        quoted = re.sub ("'", "'\\''", commands)
        os.system ("chroot /mnt/sysimage sh -c '%s'" % quoted)
    do_chroot ("http_proxy=\"http://192.168.0.246:3128\" yum -c
/tmp/stateless.yum.conf install stateless-client")

### Now launch the real bootstrap
    sys.path.append ('/mnt/sysimage/usr/share/stateless/')
    import bootstrap
    bootstrap.run('aware-of-vacuity.boston.redhat.com', 'Test42')

Is this correct? Secondly, what I replace the boston.redhat.com line with?
-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From cra at WPI.EDU  Wed Dec  8 21:21:11 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 8 Dec 2004 16:21:11 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
References: <1102331754.3973.11.camel@localhost.localdomain>
	<20041208151507.GD12428@angus.ind.WPI.EDU>
	<1102520556.4257.46.camel@support02.civic.twp.ypsilanti.mi.us>
	<200412081105.38772.rjune@bravegnuworld.com>
	<1102523252.4257.65.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <20041208212111.GU27024@angus.ind.WPI.EDU>

On Wed, Dec 08, 2004 at 11:27:32AM -0500, Sean Middleditch wrote:
> It's goofy.  It's a waste of effort.  Someone *already* packages new
> versions of OpenSSH, why should someone else have to *repackage* the
> exact same binary just to get a different set of RPM headers?  How does
> that make sense?

It's not just headers.  It could be ABI differences.

> OpenSSH case, I don't *need* gssapi-with-mic, it just simplifies a lot
> of what I do, especially when I have long ssh->ssh->ssh chains going
> through several firewalls.

Is "rpmbuild --rebuild someone-elses-new-openssh.src.rpm" each time
someone else releases a security fix that hard?



From seyman at wanadoo.fr  Wed Dec  8 20:41:10 2004
From: seyman at wanadoo.fr (Emmanuel Seyman)
Date: Wed, 8 Dec 2004 21:41:10 +0100
Subject: Fedora and Redhat EL
In-Reply-To: <20041208194236.85213.qmail@web8501.mail.in.yahoo.com>
References: <1102534717.24730.64.camel@opus.phy.duke.edu>
	<20041208194236.85213.qmail@web8501.mail.in.yahoo.com>
Message-ID: <20041208204110.GA6235@orient.maison.moi>

On Wed, Dec 08, 2004 at 11:42:36AM -0800, Rahul Sundaram wrote:
> 
> Ok if somebody can point me to a list where its
> supposed to be on topic if such a list exists and the
> relevant people are willing to discuss this I will
> move the discussion there otherwise I dont see any
> other option but to drop this one

Red Hat's Taroon list <taroon-list (at) redhat.com> gets my vote.

Emmanuel



From dnielsen at breakmygentoo.net  Wed Dec  8 22:19:11 2004
From: dnielsen at breakmygentoo.net (David Nielsen)
Date: Wed, 08 Dec 2004 23:19:11 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a00412080953c065ab9@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
Message-ID: <1102544351.2817.4.camel@localhost>

ons, 08 12 2004 kl. 12:53 -0500, skrev Nick Bargnesi:
> On Wed, 8 Dec 2004 12:42:03 -0500, Alan Cox <alan at redhat.com> wrote:
> > On Wed, Dec 08, 2004 at 12:13:19PM -0500, Richard June wrote:
> > > > Alan
> > > Wow, that's ugly for both users and root.
> > > why not set root's foreground to blink?
> > 
> > Not all terminal devices support blink 8)
> 
> Ever had too much coffee and tried staring at a blinking prompt?
> Yet another option would just be to alter PS1 to display something like:
> 
> -- WARNING - LOGGED IN AS ROOT --
> [root at machine root]#  

Blinking stuff on a screen is bad combined with certain illnesses like
some forms of epilepsy.

- David *Suffering from Tourette's and not being all to happy about the
blinking stuff either* Nielsen



From Hugh_Caley at affymetrix.com  Wed Dec  8 22:45:54 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Wed, 08 Dec 2004 14:45:54 -0800
Subject: Slow X on x86_64
Message-ID: <1102545954.4248.7.camel@puglia.ev.affymetrix.com>

I'm having a problem with an install of FC3 on an Opteron machine.  The
X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
same with both a Matrox G550 and an ATI Radeon 9200 card.

Seems to be a problem with drm and dri initialization.

Anyone else seeing this?

I've added to a bugzilla bug that seems to be on target.  There are
errors and xorg.conf snippets there.  Interestingly, it seems that it
isn't x86_64 specific.  

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142105

--
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley at affymetrix.com



From alan at redhat.com  Wed Dec  8 23:21:54 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 8 Dec 2004 18:21:54 -0500
Subject: Slow X on x86_64
In-Reply-To: <1102545954.4248.7.camel@puglia.ev.affymetrix.com>
References: <1102545954.4248.7.camel@puglia.ev.affymetrix.com>
Message-ID: <20041208232154.GG17112@devserv.devel.redhat.com>

On Wed, Dec 08, 2004 at 02:45:54PM -0800, Hugh Caley wrote:
> I'm having a problem with an install of FC3 on an Opteron machine.  The
> X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
> similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
> same with both a Matrox G550 and an ATI Radeon 9200 card.

Maxtrox at least was 32bit only for DRI until very recently. Radeon should
be working. Mine does anyway 8)

> Anyone else seeing this?

Logs ?



From vamsi at CS.ColoState.EDU  Wed Dec  8 23:28:52 2004
From: vamsi at CS.ColoState.EDU (Vamsi K Kambhampati)
Date: Wed, 08 Dec 2004 16:28:52 -0700
Subject: Fedora Core Release Policy
Message-ID: <41B78E34.1070300@cs.colostate.edu>


I dont know if this question was raised before, but is there a general 
policy pertaining to fedora core release cycles? I mean is the release 
policy something similar to kernel releases? (odd for development, even 
for stable/bug-fixed packages?).

I apologize if this would not be the appropriate list, but oh well all I 
need is an answer (from someone).

Thanks
-- Vamsi



From sopwith at redhat.com  Wed Dec  8 23:46:14 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Wed, 8 Dec 2004 18:46:14 -0500 (EST)
Subject: Fedora Core Release Policy
In-Reply-To: <41B78E34.1070300@cs.colostate.edu>
References: <41B78E34.1070300@cs.colostate.edu>
Message-ID: <Pine.LNX.4.58.0412081844230.27163@devserv.devel.redhat.com>

On Wed, 8 Dec 2004, Vamsi K Kambhampati wrote:

> policy pertaining to fedora core release cycles? I mean is the release 
> policy something similar to kernel releases? (odd for development, even 
> for stable/bug-fixed packages?).

That particular practice only applies to even/odd subversions (the "Y" in
X.Y). Fedora Core uses integer-only release numbers and yes, all the
Fedora Core releases are stable releases.

-- Elliot



From barryn at pobox.com  Thu Dec  9 00:48:50 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Wed, 8 Dec 2004 16:48:50 -0800
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170302.GI5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
Message-ID: <20041209004850.GA14727@ip68-4-98-123.oc.oc.cox.net>

On Wed, Dec 08, 2004 at 05:03:02PM +0000, Tim Waugh wrote:
> Should we implement a scheme to differentiate root/non-root bash
> prompts by colour?

IIRC Gentoo does something like this. It might be worth looking at
what they do. (I would go ahead and do that now, except that I don't
happen to have Gentoo installed on any of my systems at the moment. And
I think it's going to be at least another day or two before I have the
time.)

-Barry K. Nathan <barryn at pobox.com>



From nbargnesi at gmail.com  Thu Dec  9 00:54:30 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 8 Dec 2004 19:54:30 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041209004850.GA14727@ip68-4-98-123.oc.oc.cox.net>
References: <20041208170302.GI5322@redhat.com>
	<20041209004850.GA14727@ip68-4-98-123.oc.oc.cox.net>
Message-ID: <3077b8a004120816543066565c@mail.gmail.com>

On Wed, 8 Dec 2004 16:48:50 -0800, Barry K. Nathan <barryn at pobox.com> wrote:
> On Wed, Dec 08, 2004 at 05:03:02PM +0000, Tim Waugh wrote:
> > Should we implement a scheme to differentiate root/non-root bash
> > prompts by colour?
> 
> IIRC Gentoo does something like this. It might be worth looking at
> what they do. (I would go ahead and do that now, except that I don't
> happen to have Gentoo installed on any of my systems at the moment. And
> I think it's going to be at least another day or two before I have the
> time.)

The last time I saw a gentoo root prompt on a machine, the machine's
name or username was red.  Which has been discussed and seemingly
vetoed.

> 
> -Barry K. Nathan <barryn at pobox.com>
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From nbargnesi at gmail.com  Thu Dec  9 00:57:15 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 8 Dec 2004 19:57:15 -0500
Subject: Slow X on x86_64
In-Reply-To: <20041208232154.GG17112@devserv.devel.redhat.com>
References: <1102545954.4248.7.camel@puglia.ev.affymetrix.com>
	<20041208232154.GG17112@devserv.devel.redhat.com>
Message-ID: <3077b8a0041208165769378f01@mail.gmail.com>

On Wed, 8 Dec 2004 18:21:54 -0500, Alan Cox <alan at redhat.com> wrote:
> On Wed, Dec 08, 2004 at 02:45:54PM -0800, Hugh Caley wrote:
> > I'm having a problem with an install of FC3 on an Opteron machine.  The
> > X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
> > similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
> > same with both a Matrox G550 and an ATI Radeon 9200 card.
> 
> Maxtrox at least was 32bit only for DRI until very recently. Radeon should
> be working. Mine does anyway 8)
> 
> > Anyone else seeing this?

No help for you really, but I've stuck with all nvidia cards and I've
never had a problem on x86_64.  (~glxgears 9000 fps, mmm...)


> 
> Logs ?
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From mr700 at globalnet.bg  Thu Dec  9 01:06:20 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Thu, 9 Dec 2004 03:06:20 +0200
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208184759.A7420@ryoko.camperquake.de>
References: <20041208170302.GI5322@redhat.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<20041208184759.A7420@ryoko.camperquake.de>
Message-ID: <200412090306.21698@-mr700>

On 2004-12-08 (Wednesday) 19:47, Ralf Ertzinger wrote:
> On Wed, Dec 08, 2004 at 12:42:03PM -0500, Alan Cox wrote:
> 
> > Not all terminal devices support blink 8)
> 
> How about making it beep every second?
> 

    This pretty sure is gonna make many of us mad and we'll have to
ask Alan to use his "torture kit" on you ;P~
    Now serious. I think a sound every second, even nice girl's voice,
will be too annoying. AFAIK red blinking color is hypnotic/dangerous
for some people. We all know that root's prompt starts with '[root'
and ends with ']# ', users' prompt starts with their username and
ends with ']$ ' already. I wonder why do you want to "differentiate
root/non-root bash prompts" even more? What about tcsh, zsh, ash, all
shells from /etc/shells [ except /sbin/nologin :) ]?
    PS: something like /etc/nologin's idea can be usefull too - type
something like '/etc/root-prompt-warning' before root's prompt?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From rahulsundaram at yahoo.co.in  Thu Dec  9 01:11:11 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 8 Dec 2004 17:11:11 -0800 (PST)
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412090306.21698@-mr700>
Message-ID: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>

Hi

 We all know that root's prompt
> starts with '[root'
> and ends with ']# ', users' prompt starts with their
> username and
> ends with ']$ ' already. I wonder why do you want to
> "differentiate
> root/non-root bash prompts" even more? 


as explained earlier the nature of fedora attracts
newbies who need to understand that using root always
is a dangerous practise. even administrators would
like a more visual? enhancement.

as long as it works, is not annoying and actually
helpful I dont see any reason why you should complain.





=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 



From jon at jonshouse.co.uk  Thu Dec  9 01:40:23 2004
From: jon at jonshouse.co.uk (Jonathan Andrews)
Date: Thu, 09 Dec 2004 01:40:23 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
Message-ID: <1102556423.9691.724.camel@jonspc>

On Thu, 2004-12-09 at 01:11, Rahul Sundaram wrote:
> Hi
> 
>  We all know that root's prompt
> > starts with '[root'
> > and ends with ']# ', users' prompt starts with their
> > username and
> > ends with ']$ ' already. I wonder why do you want to
> > "differentiate
> > root/non-root bash prompts" even more? 
> 
> 
> as explained earlier the nature of fedora attracts
> newbies who need to understand that using root always
> is a dangerous practise. even administrators would
> like a more visual? enhancement.
> 
> as long as it works, is not annoying and actually
> helpful I dont see any reason why you should complain.

Some of us more cautious people use terminals with different backgrounds
to identify different computers, so changing the default colour for for
root prompts using ansi would break that setup. My dangerous machine
(one in a rack I have to drive 200 miles to get to) already has a red
background on the xterm, so red text as default would be no text at
all!!  Its a minor point, but I suspect other have similar setups.... If
people want to play with colours how about changing the dark blue colour
in 'ls' to one that people can read like cyan, i'm yet to find a
computer I could read that text on yet - Its only the dark blue, but it
would save starting a session with 'unalias ls' every time I login to a
redhat box :-|   ....    

Cheers,
Jon




From mr700 at globalnet.bg  Thu Dec  9 01:45:17 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Thu, 9 Dec 2004 03:45:17 +0200
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
Message-ID: <200412090345.17882@-mr700>

On 2004-12-09 (Thursday) 03:11, Rahul Sundaram wrote:
> Hi
> 
>  We all know that root's prompt
> > starts with '[root'
> > and ends with ']# ', users' prompt starts with their
> > username and
> > ends with ']$ ' already. I wonder why do you want to
> > "differentiate
> > root/non-root bash prompts" even more? 
> 
> 
> as explained earlier the nature of fedora attracts
> newbies who need to understand that using root always
> is a dangerous practise. even administrators would
> like a more visual? enhancement.

    That's good.

> 
> as long as it works, is not annoying and actually
> helpful I dont see any reason why you should complain.
> 

    I think 'making it beep every second' is annoying. Do
you remember the discussion about gdm and it's single beep?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From janina at rednote.net  Thu Dec  9 02:05:37 2004
From: janina at rednote.net (Janina Sajka)
Date: Wed, 8 Dec 2004 21:05:37 -0500
Subject: X86_64 Yum Question
In-Reply-To: <604aa79104120808016f283b32@mail.gmail.com>
References: <20041208150715.GA5817@rednote.net>
	<1102519132.4468.68.camel@hostmaster.org>
	<20041208155036.GC5817@rednote.net>
	<604aa79104120808016f283b32@mail.gmail.com>
Message-ID: <20041209020537.GA29323@rednote.net>

Jeff Spaleta writes:
> On Wed, 8 Dec 2004 10:50:36 -0500, Janina Sajka <janina at rednote.net> wrote:
> > Unfortunately, the x86_64 gstreamer-plugins reported a conflict.
> 
> gstreamers-plugins from where? parallel installable 32bit and 64bit
> rpm packages should be possible the package just needs to be made
> aware of the problem and make the 'multilib' corrections that would
> allow for it.

Indeed, that seems to be the attempt. The only extant gstreamer-plugins
is stock FC3 x86_64. Not sure where the conflict with 0.8.6 is coming
from, though:

Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package flumotion.noarch 0:0.1.3-1.3 set to be installed
--> Running transaction check
--> Processing Dependency: gstreamer-python>= 0.7.93 for package:
flumotion
--> Processing Dependency: python-imaging for package: flumotion
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package gstreamer-python.i386 0:0.8.0-0.fdr.1.3 set to be installed
---> Package python-imaging.x86_64 0:1.1.4-2.1.fc3.rf set to be
installed
--> Running transaction check
--> Processing Dependency: libgstinterfaces-0.8.so.0 for package:
gstreamer-python
--> Processing Dependency: libgstplay-0.8.so.0 for package:
gstreamer-python
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package gstreamer-plugins.i386 0:0.8.6-0.fdr.1.3 set to be
installed
--> Running transaction check
--> Processing Dependency: libHermes.so.1 for package: gstreamer-plugins
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package Hermes.i386 0:1.3.3-4.1.fc3.rf set to be installed
--> Running transaction check

Dependencies Resolved
Transaction Listing:
  Install: flumotion.noarch 0:0.1.3-1.3

Performing the following to resolve dependencies:
  Install: Hermes.i386 0:1.3.3-4.1.fc3.rf
  Install: gstreamer-plugins.i386 0:0.8.6-0.fdr.1.3
  Install: gstreamer-python.i386 0:0.8.0-0.fdr.1.3
  Install: python-imaging.x86_64 0:1.1.4-2.1.fc3.rf
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Check Error:   file /etc/gconf/schemas/gstreamer-0.8.schemas
from install of gstreamer-plugins-0.8.6-0.fdr.1.3 conflicts with file
from package gstreamer-plugins-0.8.5-1

				Janina

> 
> -jef
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Chair
				Accessibility Workgroup
				Free Standards Group (FSG)

janina at freestandards.org	Phone: +1 202.494.7040



From mr700 at globalnet.bg  Thu Dec  9 02:06:35 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Thu, 9 Dec 2004 04:06:35 +0200
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102556423.9691.724.camel@jonspc>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
	<1102556423.9691.724.camel@jonspc>
Message-ID: <200412090406.36130@-mr700>

On 2004-12-09 (Thursday) 03:40, Jonathan Andrews wrote:
...
> If people want to play with colours how about changing the dark blue
> colour in 'ls' to one that people can read like cyan, i'm yet to find a
> computer I could read that text on yet - Its only the dark blue, but it
> would save starting a session with 'unalias ls' every time I login to a
> redhat box :-|   ....    
> 

    Just export your onw LS_COLORS in your ~/.bashrc, ex change:
from default: LS_COLORS='no=00:fi=00:di=00;34:....
to cyandir  : LS_COLORS='no=00:fi=00:di=00;36:....
    or append this in .bashrc / put it in /etc/profile.d/z_my_colors.sh:
--- cut ---
LS_COLORS=$(echo "$LS_COLORS" | sed 's/00;34:/00;36:/g')
export LS_COLORS
--- cut ---

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From skvidal at phy.duke.edu  Thu Dec  9 03:04:08 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 08 Dec 2004 22:04:08 -0500
Subject: X86_64 Yum Question
In-Reply-To: <20041209020537.GA29323@rednote.net>
References: <20041208150715.GA5817@rednote.net>
	<1102519132.4468.68.camel@hostmaster.org>
	<20041208155036.GC5817@rednote.net>
	<604aa79104120808016f283b32@mail.gmail.com>
	<20041209020537.GA29323@rednote.net>
Message-ID: <1102561448.18985.0.camel@cutter>

> --> Processing Dependency: python-imaging for package: flumotion
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gstreamer-python.i386 0:0.8.0-0.fdr.1.3 set to be installed
> ---> Package python-imaging.x86_64 0:1.1.4-2.1.fc3.rf set to be
> installed
> --> Running transaction check
> --> Processing Dependency: libgstinterfaces-0.8.so.0 for package:
> gstreamer-python
> --> Processing Dependency: libgstplay-0.8.so.0 for package:
> gstreamer-python
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gstreamer-plugins.i386 0:0.8.6-0.fdr.1.3 set to be
> installed
> --> Running transaction check
> --> Processing Dependency: libHermes.so.1 for package: gstreamer-plugins
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package Hermes.i386 0:1.3.3-4.1.fc3.rf set to be installed
> --> Running transaction check
> 
> Dependencies Resolved
> Transaction Listing:
>   Install: flumotion.noarch 0:0.1.3-1.3
> 
> Performing the following to resolve dependencies:
>   Install: Hermes.i386 0:1.3.3-4.1.fc3.rf
>   Install: gstreamer-plugins.i386 0:0.8.6-0.fdr.1.3
>   Install: gstreamer-python.i386 0:0.8.0-0.fdr.1.3
>   Install: python-imaging.x86_64 0:1.1.4-2.1.fc3.rf
> Is this ok [y/N]: y
> Downloading Packages:
> Running Transaction Test
> Finished Transaction Test
> Transaction Check Error:   file /etc/gconf/schemas/gstreamer-0.8.schemas
> from install of gstreamer-plugins-0.8.6-0.fdr.1.3 conflicts with file
> from package gstreamer-plugins-0.8.5-1

Two different arch's of the same package owning the same file.

the file isn't identical so it's complaining.
-sv




From carlos.efr at mail.telepac.pt  Thu Dec  9 03:04:45 2004
From: carlos.efr at mail.telepac.pt (Carlos Rodrigues)
Date: Thu, 09 Dec 2004 03:04:45 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170302.GI5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
Message-ID: <41B7C0CD.9040006@mail.telepac.pt>

Tim Waugh wrote:
> See:
> 
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139628
> 
> Should we implement a scheme to differentiate root/non-root bash
> prompts by colour?
> 
> Tim.
> */
> 

Please don't. Lets not turn Fedora into "colorful" territory like some 
other distros do. IMHO, the current "root at foobar" info is sufficient.

Carlos Rodrigues

-- 
url: http://tudo-sobre-nada.blogspot.com



From mike at flyn.org  Thu Dec  9 03:46:34 2004
From: mike at flyn.org (W. Michael Petullo)
Date: Wed, 8 Dec 2004 21:46:34 -0600
Subject: Some encryption-related projects
In-Reply-To: <200412090224.34893.russell@coker.com.au>
References: <20041114191651.GA5555@imp.flyn.org>
	<200412090224.34893.russell@coker.com.au>
Message-ID: <20041209034634.GA5294@imp.flyn.org>

>> 2.  Encrypted root filesystem.
>>
>> Red Hat Bug #182479 discusses adding support for an encrypted root
 
> It's #124789.
 
>> filesystem to Fedora.  The bug contains a patch for mkinird that
>> facilitates this.  Eventually it would be nice to see support in anaconda
>> for this, but #182479 is the first step.
 
> One thing you miss in the latest patch is support for an encrypted
> root device on top of an LVM volume.
 
> With your patch the code does the following starting at about line 730 in 
> mkinitrd:
 
> if [ "$kernelmajor" == "2.4" ]; then
> # kernel 2.4.x LVM stufff
> elif [ -n "$root_enc" ]; then
> # crypto-root stuff
> else
> # kernel 2.6.x LVM stuff
> fi
 
> What you really want is to have the crypto root stuff occurring outside
> the if statement in question.  Also inside the "if [ -n "$root_enc"
> ]; then" block you want to have "if [ -z $root_lvm ]; then" around the
> "mkdmnod" bit so that mkdmnod doesn't get called twice.

I'm sorry, but I don't have any experience with LVM volumes.  What I
do know is that right now if root_enc=1 then root_lvm=1 but root_lvm=1
does NOT mean root_enc=1.  The tests go like this (line 852):

if [ is LVM (actually is device mapper) ]; then
  root_lvm=1
  if [ is encrypted ]; then
    root_enc=1
  fi
fi

So, how can I support both of these cases:

LVM volume, unencrypted
LVM volume encrypted

?

I need a way to test if a root filesystem is really an LVM volume and
not possibly just a DM/encrypted volume.  In other words, how can I
ask "is this device mapper volume truly a LVM volume?"  Root_enc and
root_lvm need to be decoupled.

> Also in recent kernels the AES module is aes-i586 (maybe we should have an 
> alias in the module-init-tools config).

In my recent kernels, aes is not aes-i586 because my kernel is built
for PowerPC.  So I imagine an alias from aes to aes-i586 would make
i586 more consistent with other architectures.

-- 
Mike

:wq



From ville.skytta at iki.fi  Thu Dec  9 07:41:21 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Thu, 09 Dec 2004 09:41:21 +0200
Subject: Broken %post scriptlets in recent java packages
In-Reply-To: <1102434668.9807.5.camel@ulysse.olympe.o2t>
References: <87d5xm6saz.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1102434668.9807.5.camel@ulysse.olympe.o2t>
Message-ID: <1102578081.7026.73.camel@bobcat.mine.nu>

On Tue, 2004-12-07 at 16:51 +0100, Nicolas Mailhot wrote:
> Le mardi 07 d?cembre 2004 ? 16:28 +0100, Enrico Scholz a ?crit :
> > Hello,
> > 
> > recent java-packages (ant*, xerces*, ...) have scriptlets like
> > 
> > | $ rpm -q --scripts servletapi5-javadoc
> > | postinstall scriptlet (using /bin/sh):
> > | rm -f /usr/share/javadoc/servletapi5
> > | rm -f /usr/share/javadoc/jsp-api
> > | ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
> > | ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api
> > 
> > 
> > This is really bad code because it does not make sense in an rpm-world
> > and causes problems in combination with the %_netsharedpath feature.
> 
> This is one of the last raw areas on JPackage 1.6.
> To this date no one has found a satisfactory way to build & install
> interlinked javadocs (I think you'll find several threads on this
> problem in list archives). The current solution is Ville's (I think) and
> he publicly stated he didn't like it.

Actually that basic "solution" predates me in JPackage.   And "didn't
like" is a understatement, that's seriously ugly stuff and needs work.

The basic requirements, IMO in order of importance are that: it needs to
work, it needs to provide something unversioned (for bookmarking, IDE
config, javadoc crosslinking etc), and it must be possible to install
several versions of the same javadoc package in parallel.  Currently #1
fails in certain situations.



From jon at jonshouse.co.uk  Thu Dec  9 09:03:48 2004
From: jon at jonshouse.co.uk (Jonathan Andrews)
Date: Thu, 09 Dec 2004 09:03:48 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412090406.36130@-mr700>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
	<1102556423.9691.724.camel@jonspc>  <200412090406.36130@-mr700>
Message-ID: <1102583027.9691.1177.camel@jonspc>

On Thu, 2004-12-09 at 02:06, Doncho N. Gunchev wrote:
> On 2004-12-09 (Thursday) 03:40, Jonathan Andrews wrote:
> ...
> > If people want to play with colours how about changing the dark blue
> > colour in 'ls' to one that people can read like cyan, i'm yet to find a
> > computer I could read that text on yet - Its only the dark blue, but it
> > would save starting a session with 'unalias ls' every time I login to a
> > redhat box :-|   ....    
> > 
> 
>     Just export your onw LS_COLORS in your ~/.bashrc, ex change:
> from default: LS_COLORS='no=00:fi=00:di=00;34:....
> to cyandir  : LS_COLORS='no=00:fi=00:di=00;36:....
>     or append this in .bashrc / put it in /etc/profile.d/z_my_colors.sh:
> --- cut ---
> LS_COLORS=$(echo "$LS_COLORS" | sed 's/00;34:/00;36:/g')
> export LS_COLORS
> --- cut ---

Yes, im aware of how to change it on a per machine basis - my home
machines have modified DIR_COLORS and DIR_COLORS.xterm ....... But I was
complaining about the default. Its also not practical to modify every
machine I have to administer in a working week - or desirable for me to
confuse other admins by changing things on a persistent basis, so
'unalias ls' is a quick way to ensure I can at least read the session.
If the default wasn't dark blue it wouldn't be an issue, I cant be alone
in finding the dark blue unreadable on a black background on most
monitors.

Jon




From fedora at wir-sind-cool.org  Thu Dec  9 09:50:28 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 9 Dec 2004 10:50:28 +0100
Subject: X86_64 Yum Question
In-Reply-To: <20041209020537.GA29323@rednote.net>
References: <20041208150715.GA5817@rednote.net>
	<1102519132.4468.68.camel@hostmaster.org>
	<20041208155036.GC5817@rednote.net>
	<604aa79104120808016f283b32@mail.gmail.com>
	<20041209020537.GA29323@rednote.net>
Message-ID: <20041209105028.40941dc0.fedora@wir-sind-cool.org>

On Wed, 8 Dec 2004 21:05:37 -0500, Janina Sajka wrote:

> Performing the following to resolve dependencies:
>   Install: Hermes.i386 0:1.3.3-4.1.fc3.rf
>   Install: gstreamer-plugins.i386 0:0.8.6-0.fdr.1.3
>   Install: gstreamer-python.i386 0:0.8.0-0.fdr.1.3
>   Install: python-imaging.x86_64 0:1.1.4-2.1.fc3.rf
> Is this ok [y/N]: y

.rf = rpmforge?

0.fdr = ?

Those with 0.fdr in the release tag are not from fedora.us, but from
somewhere else as gstreamer-plugins would be an upgrade of Fedora Core.
There are at least two or three repositories which have started using
the same tag. Maybe there's documentation about the repositories you
have enabled.



From dwmw2 at infradead.org  Thu Dec  9 10:13:09 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Dec 2004 10:13:09 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <7ebb24d104120810001239d037@mail.gmail.com>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
Message-ID: <1102587189.22606.73.camel@localhost.localdomain>

On Wed, 2004-12-08 at 14:00 -0400, Ben Steeves wrote:
> Personally, all my root prompts are reversed video, with the
> background colour different on different servers.  It helps when you
> have root shells on four or five boxes open at once... wouldn't want
> to shutdown the wrong server, now would we ;-)

That one I tend to fix by renaming /sbin/reboot to "reboot-`hostname`".
You also have to make a script called 'reboot' which says something
along the lines of "if you're sure, use reboot-`hostname`", or you'll
confuse other admins and tab-completion will bite you anyway :)

I really don't see the point in changing colours in the prompt. If the
user is unaware of the distinction and the danger of doing things as
root, changing the colour of the prompt isn't going to help. If the user
_is_ aware of the difference, then the standard $/# indicator is
sufficient.

Adding an extra line of warning beforehand is slightly less obnoxious,
but really only slightly so. I can just about manage at the moment to
put up with the 'new' ([\u@\h \W]\\$; introduced circa 1996?) prompt
when I'm root, but if such a change is made I'll actually have to go and
change it on all the machines I run. The hash sign is perfectly
sufficient.

-- 
dwmw2



From giallu at gmail.com  Thu Dec  9 10:25:17 2004
From: giallu at gmail.com (Gianluca Sforna)
Date: Thu, 9 Dec 2004 11:25:17 +0100
Subject: First rpm packaging attempt: OpenMOIV
Message-ID: <d5ad214704120902256bc690ec@mail.gmail.com>

I finally managed to file in bugzilla.fedura.us my first rpm package.

https://bugzilla.fedora.us/show_bug.cgi?id=2329

Is there any other additional step I should take now??

Some info from the package description:
OpenMOIV is an object-oriented, 3D multi-platform toolkit that helps you
develop molecular visualization applications. OpenMOIV is an evolution of
the original Molecular Inventor? from SGI? that optimizes the rendering of
molecular structures and adds a whole new set of functionalities. Molecular
Inventor is also an extension of the Open Inventor toolkit, and runs on top
of it. OpenMOIV simplifies the process of writing molecular visualization
applications with atoms, bonds, surfaces and residues.



From ralph+fedora at strg-alt-entf.org  Thu Dec  9 11:29:09 2004
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Thu, 9 Dec 2004 12:29:09 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208184759.A7420@ryoko.camperquake.de>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<20041208184759.A7420@ryoko.camperquake.de>
Message-ID: <20041209112909.GF6807@br-online.de>

Ralf Ertzinger wrote:
> On Wed, Dec 08, 2004 at 12:42:03PM -0500, Alan Cox wrote:
> 
> > Not all terminal devices support blink 8)
> 
> How about making it beep every second?

Great idea. I won't hear my servers beeping though ... >:)

Ralph
-- 
Ralph Angenendt......ra at br-online.de | .."Text processing has made it possible
Bayerischer Rundfunk...HA-Multimedia | ....to right-justify any idea, even one
Rundfunkplatz 1........80300 M?nchen | .which cannot be justified on any other
Tl:089.5900.16023..Fx:089.5900.16240 | ..........grounds." -- J. Finnegan, USC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/2eb6a56b/attachment.sig>

From twaugh at redhat.com  Thu Dec  9 11:53:58 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Thu, 9 Dec 2004 11:53:58 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102587189.22606.73.camel@localhost.localdomain>
References: <20041208170302.GI5322@redhat.com>
	<20041208170726.GA6036@devserv.devel.redhat.com>
	<200412081213.23307.rjune@bravegnuworld.com>
	<20041208174203.GA2811@devserv.devel.redhat.com>
	<3077b8a00412080953c065ab9@mail.gmail.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102587189.22606.73.camel@localhost.localdomain>
Message-ID: <20041209115358.GQ5322@redhat.com>

On Thu, Dec 09, 2004 at 10:13:09AM +0000, David Woodhouse wrote:

> I really don't see the point in changing colours in the prompt. If the
> user is unaware of the distinction and the danger of doing things as
> root, changing the colour of the prompt isn't going to help. If the user
> _is_ aware of the difference, then the standard $/# indicator is
> sufficient.

I tend to agree with this, and favour keeping things as they are.

Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/42ddad12/attachment.sig>

From Axel.Thimm at atrpms.net  Thu Dec  9 12:26:22 2004
From: Axel.Thimm at atrpms.net (Axel Thimm)
Date: Thu, 9 Dec 2004 13:26:22 +0100
Subject: Smart package manager (Was: Same named packages,
	different dependencies)
In-Reply-To: <Pine.LNX.4.61.0412091241350.921@horsea.3ti.be>
References: <316ED7CB.08FDAD59.005FFA64@netscape.net>
	<41B81A67.40404@netscape.net> <41B8251F.7060901@city-fan.org>
	<Pine.LNX.4.61.0412091241350.921@horsea.3ti.be>
Message-ID: <20041209122622.GA17341@neu.nirvana>

On Thu, Dec 09, 2004 at 12:50:03PM +0100, Dag Wieers wrote:
> With smart you can decide what repositories you trust to be
> upgrading your system by default, which ones cannot override core
> packages and even which repositories are prefered on a per package
> basis.

In theory you could do that with apt, too, but there were bugs or at
least the documenation was not in sync with the code (meaning the code
did behave differently than the docs specified).

In general having such a system is not a bad idea. Of course long term
the reasons for prioritizing repos should be examined and fixed. OTOH
we know that some issues with repos not being compatible to users by
definition have been attacked quite often in the last 1 1/2 year and
still were not resolved. So there is definitely a need for such a
system.

There will be bugs in using prioritized repo structure, such as A
requiring a fixed package B, which is forbidden to be upgraded by
smart/apt due to priority rules. In order to overcome such a situation
B would have to provide B-feature-X-is-fixed and A depend on this.

Currently the assumption is that since A and B are maintained in the
same repo, such implicit dependencies/properties are seldomly cast
into the specfile. Creating dependencies on specific releases also
makes the package less generic and portable.

An example would be transcode, which can have a lot of different
support in its baggage. smart itself would be another example, which
requires a patched up rpm, which ATrpms provides, but from a package
POV is indistinguishable from a non-patched rpm (there are no extra
Provides). Using smart from ATrpms for say Red Hat 7.3 w/o using the
patched up rpm will do no good.

The bottom line seems to be, if there will be support from repos for
prioritizing schemes, each package need to be considered outside of it
own repo context, which is quite hard to do. OTOH it rises the
packaging quality of that package, and it will make it cross-repo
friendlier will even make it more cross-distro friendly.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/a6b3ca29/attachment.sig>
-------------- next part --------------
-- 
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

From buildsys at redhat.com  Thu Dec  9 12:56:39 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 9 Dec 2004 07:56:39 -0500
Subject: rawhide report: 20041209 changes
Message-ID: <200412091256.iB9Cudc01807@porkchop.devel.redhat.com>



From cra at WPI.EDU  Thu Dec  9 13:56:16 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Thu, 9 Dec 2004 08:56:16 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102583027.9691.1177.camel@jonspc>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
	<1102556423.9691.724.camel@jonspc> <200412090406.36130@-mr700>
	<1102583027.9691.1177.camel@jonspc>
Message-ID: <20041209135616.GF12428@angus.ind.WPI.EDU>

On Thu, Dec 09, 2004 at 09:03:48AM +0000, Jonathan Andrews wrote:
> If the default wasn't dark blue it wouldn't be an issue, I cant be alone
> in finding the dark blue unreadable on a black background on most
> monitors.

You aren't.  I always change it too.



From paul at frields.com  Thu Dec  9 14:03:47 2004
From: paul at frields.com (Paul W. Frields)
Date: Thu, 09 Dec 2004 09:03:47 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102556423.9691.724.camel@jonspc>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
	<1102556423.9691.724.camel@jonspc>
Message-ID: <1102601027.6806.14.camel@bettie.internal.frields.org>

On Thu, 2004-12-09 at 01:40 +0000, Jonathan Andrews wrote:
> On Thu, 2004-12-09 at 01:11, Rahul Sundaram wrote:
> > Hi
> > 
> >  We all know that root's prompt
> > > starts with '[root'
> > > and ends with ']# ', users' prompt starts with their
> > > username and
> > > ends with ']$ ' already. I wonder why do you want to
> > > "differentiate
> > > root/non-root bash prompts" even more? 
> > 
> > 
> > as explained earlier the nature of fedora attracts
> > newbies who need to understand that using root always
> > is a dangerous practise. even administrators would
> > like a more visual? enhancement.
> > 
> > as long as it works, is not annoying and actually
> > helpful I dont see any reason why you should complain.
> 
> Some of us more cautious people use terminals with different backgrounds
> to identify different computers, so changing the default colour for for
> root prompts using ansi would break that setup. My dangerous machine
> (one in a rack I have to drive 200 miles to get to) already has a red
> background on the xterm, so red text as default would be no text at
> all!!  Its a minor point, but I suspect other have similar setups.... If
> people want to play with colours how about changing the dark blue colour
> in 'ls' to one that people can read like cyan, i'm yet to find a
> computer I could read that text on yet - Its only the dark blue, but it
> would save starting a session with 'unalias ls' every time I login to a
> redhat box :-|   ....    

Colors and sounds both seem to get less than a ringing endorsement (for
good reasons, IMHO). Likewise with multi-line $PS1. Although I'm
personally in favor of leaving this as is, what about something as
simple as:

PS1="[++ \u@\h \W ++]\$ "      #    [++ root at foohost tmp ++]#

The chief problem with the "less is more" approach is probably that
after repeated issuance, the impact is somewhat lessened. I would think
almost any prompting system suffers similarly; prompts that are
successful at overcoming that factor probably fail usability tests (at
least with regard to the "user satisfaction" portion of those tests).

The above example, and similar fixes, really only have impact when
viewed in contrast with the existing prompt, e.g. an su session launched
from a user's normal prompt. In that case, the question becomes: How
much better is it to see the slightly longer $PS1, in addition to the
normal change of '$' to '#'?  When one logs into the console or X as
root, on the other hand and this prompt is issued from start to finish
of the session -- or normal scrolling processes remove the contrasting,
original prompt from view -- my bet would be that the user quickly
becomes used to the prompt, and it loses its effectiveness.

Sorry to butt in, especially if this particular US$0.02 is redundant.

-- 
Paul W. Frields, RHCE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/9c48bed8/attachment.sig>

From steve at silug.org  Thu Dec  9 14:08:21 2004
From: steve at silug.org (Steven Pritchard)
Date: Thu, 9 Dec 2004 08:08:21 -0600
Subject: Xen in rawhide
Message-ID: <20041209140821.GA23850@osiris.silug.org>

Does anyone know if the Xen rpms in rawhide are supposed to be working
at this point?  The xen0 package appears to be missing xen.gz.

BTW, thank you to whoever @redhat.com decided to add the Xen builds...
I spent a rather disturbing amount of time trying to build my own
rpms, but I never managed to get anything that worked.

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From mlauterbach at mail.wtamu.edu  Thu Dec  9 14:11:11 2004
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Thu, 9 Dec 2004 08:11:11 -0600
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102601027.6806.14.camel@bettie.internal.frields.org>
Message-ID: <20041209141108.9EDC43E62DE@mail.wtamu.edu>

On Thursday, December 09, 2004 8:04 AM, Paul W. Frields wrote:
> 
> The chief problem with the "less is more" approach is probably that
> after repeated issuance, the impact is somewhat lessened. I 
> would think
> almost any prompting system suffers similarly; prompts that are
> successful at overcoming that factor probably fail usability tests (at
> least with regard to the "user satisfaction" portion of those tests).
> 
> The above example, and similar fixes, really only have impact when
> viewed in contrast with the existing prompt, e.g. an su 
> session launched
> from a user's normal prompt. In that case, the question becomes: How
> much better is it to see the slightly longer $PS1, in addition to the
> normal change of '$' to '#'?  When one logs into the console or X as
> root, on the other hand and this prompt is issued from start to finish
> of the session -- or normal scrolling processes remove the 
> contrasting,
> original prompt from view -- my bet would be that the user quickly
> becomes used to the prompt, and it loses its effectiveness.
> 
> Sorry to butt in, especially if this particular US$0.02 is redundant.
> 
> -- 
> Paul W. Frields, RHCE
> 

Perhaps you could just rig the keyboard to give the user a mild electric
shock every couple of seconds.  That would teach people to limit their root
use.

Matthew E. Lauterbach



From P at draigBrady.com  Thu Dec  9 14:19:48 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Thu, 09 Dec 2004 14:19:48 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102583027.9691.1177.camel@jonspc>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>	<1102556423.9691.724.camel@jonspc>
	<200412090406.36130@-mr700> <1102583027.9691.1177.camel@jonspc>
Message-ID: <41B85F04.4080603@draigBrady.com>

Jonathan Andrews wrote:
> Yes, im aware of how to change it on a per machine basis - my home
> machines have modified DIR_COLORS and DIR_COLORS.xterm ....... But I was
> complaining about the default. Its also not practical to modify every
> machine I have to administer in a working week - or desirable for me to
> confuse other admins by changing things on a persistent basis, so
> 'unalias ls' is a quick way to ensure I can at least read the session.
> If the default wasn't dark blue it wouldn't be an issue, I cant be alone
> in finding the dark blue unreadable on a black background on most
> monitors.

I agree. However things are setup for light coloured
terminals by default. Though that begs the question of
why virtual terminals are dark by default. Note to change this:

setterm -background white -foreground black -store && clear

It's also worth noting that the colors used for dark terminals
are quite useable on light terminals but not vice versa.

Anyway I've got some notes for setting various terminal
apps up for dark terminals here:
http://www.pixelbeat.org/docs/darkterm.html

-- 
P?draig Brady - http://www.pixelbeat.org
--



From lsomike at futzin.com  Thu Dec  9 14:42:17 2004
From: lsomike at futzin.com (Mike Klinke)
Date: Thu, 9 Dec 2004 08:42:17 -0600
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041209115358.GQ5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
	<1102587189.22606.73.camel@localhost.localdomain>
	<20041209115358.GQ5322@redhat.com>
Message-ID: <200412090842.18083.lsomike@futzin.com>

On Thursday 09 December 2004 05:53, Tim Waugh wrote:
> On Thu, Dec 09, 2004 at 10:13:09AM +0000, David Woodhouse wrote:
> > I really don't see the point in changing colours in the prompt.
> > If the user is unaware of the distinction and the danger of
> > doing things as root, changing the colour of the prompt isn't
> > going to help. If the user _is_ aware of the difference, then
> > the standard $/# indicator is sufficient.
>
> I tend to agree with this, and favour keeping things as they are.
>
> Tim.
> */

Let me add a "vote" in this column too.  Although having the machine 
throw up a picture of Robbie the Robot waving his arms and shouting 
"Danger! Danger!" would be entertaining the first time or two.

Regards, Mike Klinke

 



From mike at navi.cx  Thu Dec  9 14:54:26 2004
From: mike at navi.cx (Mike Hearn)
Date: Thu, 09 Dec 2004 14:54:26 +0000
Subject: Upgrading readline
References: <20041208175651.GL5322@redhat.com> <41B751D2.5070105@nc.rr.com>
Message-ID: <pan.2004.12.09.14.54.26.305491@navi.cx>

On Wed, 08 Dec 2004 14:11:14 -0500, Jeff Johnson wrote:
> Alternatively, if the API changes aren't seriously different, you might just
> as well add versioned symbols so that we can get rid of all this 
> compat-baggage
> once and for all, and provide an explicit and trackable ABI in the same 
> soname
> just like glibc does.

Eek no, please don't.

(a) It's not portable, so it means forking upstream
(b) Symbol overloading is confusing for people and practically nobody
    understands how to select a particular version at compile time.
    If the API changed that is essential otherwise you won't be able
    to build apps using the older API on newer systems.

Actually providing one version per symbol though is a good idea (and it's
more portable), and hopefully more libraries will do it in future. The
benefits of providing multiple versions per symbol is something I was
never convinced about given the costs. Just provide two packages and
install them both.



From harald at redhat.com  Thu Dec  9 15:17:43 2004
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 09 Dec 2004 16:17:43 +0100
Subject: RFE: shutdown (was Re: RFC: root/non-root bash prompts different
 colours?)
In-Reply-To: <1102556423.9691.724.camel@jonspc>
References: <20041209011111.24432.qmail@web8505.mail.in.yahoo.com>
	<1102556423.9691.724.camel@jonspc>
Message-ID: <41B86C97.7050304@redhat.com>

Jonathan Andrews wrote:
  > Some of us more cautious people use terminals with different backgrounds
> to identify different computers, so changing the default colour for for
> root prompts using ansi would break that setup. My dangerous machine
> (one in a rack I have to drive 200 miles to get to) already has a red
> background on the xterm, so red text as default would be no text at
> all!!  Its a minor point, but I suspect other have similar setups.... If
> people want to play with colours how about changing the dark blue colour
> in 'ls' to one that people can read like cyan, i'm yet to find a
> computer I could read that text on yet - Its only the dark blue, but it
> would save starting a session with 'unalias ls' every time I login to a
> redhat box :-|   ....    
> 
> Cheers,
> Jon
> 
> 


That reminds me to make an RFE for poweroff/reboot/shutdown to ask for the 
machine's name before proceeding! :)
Does not happen often, but the times it happened it was sometimes very very, 
well unproductive :)



From stuart at terminus.co.uk  Thu Dec  9 15:26:38 2004
From: stuart at terminus.co.uk (Stuart Children)
Date: Thu, 09 Dec 2004 15:26:38 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
References: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
Message-ID: <41B86EAE.3010304@terminus.co.uk>

Rahul Sundaram wrote:
>>I'd say no regardless. It's too dificult to choose
>>appropriate colours. 
> 
> I dont think so. with some amount of careful thought
> it should be possible

There have been several good reasons given already why colours in 
particular are bad. I'll give one more: are you sure that a given colour 
implies what you think it does in different cultures?

> If fedora was catering just to old time unix users who
> are used to working with Linux on the server, then
> this definitely is not needed but since its trying to
> be appealing to everyone including newbies, it is
> important that we do something like this.

If you really want to make the "danger" of a root shell more obvious to 
newbies, then how about: Create a new application launcher "root 
terminal" which prompts for the root password, gives you a nice stern 
warning dialogue, and could have different window decoration to a 
regular terminal. This way root's shell is left alone for people who 
know how to get there other ways, and all the "warnings" are easily 
localisable and themable - as well as contained within the one launcher 
that the rest of us don't have to use.

I'm all for getting as many people as possible to use Fedora. However, 
that does not mean we should be pandering to newbies; or doing things 
that will inconvenience the more experienced users. The command line is 
supposed to be powerful - but with great power comes great 
responsibility (apologies, couldn't resist). Until newbies gain enough 
experience for that, they should be given more friendly and safer 
methods to configure their system. So if you feel the 
"newbie-friendlyness" of Fedora needs work then I'd suggest time and 
effort would best be spent helping create/improve the GUI admin tools. 
Those are also beneficial to advanced users.

Cheers

-- 
Stuart



From laroche at redhat.com  Thu Dec  9 15:53:58 2004
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 9 Dec 2004 16:53:58 +0100
Subject: Xen in rawhide
In-Reply-To: <20041209140821.GA23850@osiris.silug.org>
References: <20041209140821.GA23850@osiris.silug.org>
Message-ID: <20041209155358.GA5932@dudweiler.stuttgart.redhat.com>

On Thu, Dec 09, 2004 at 08:08:21AM -0600, Steven Pritchard wrote:
> Does anyone know if the Xen rpms in rawhide are supposed to be working
> at this point?  The xen0 package appears to be missing xen.gz.
> 
> BTW, thank you to whoever @redhat.com decided to add the Xen builds...
> I spent a rather disturbing amount of time trying to build my own
> rpms, but I never managed to get anything that worked.

I've seen rpm packages on http://people.redhat.com/riel/

greetings,

Florian La Roche



From nbargnesi at gmail.com  Thu Dec  9 16:38:16 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Thu, 9 Dec 2004 11:38:16 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <41B86EAE.3010304@terminus.co.uk>
References: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
	<41B86EAE.3010304@terminus.co.uk>
Message-ID: <3077b8a004120908382f64adab@mail.gmail.com>

On Thu, 09 Dec 2004 15:26:38 +0000, Stuart Children
<stuart at terminus.co.uk> wrote:
> Rahul Sundaram wrote:
> >>I'd say no regardless. It's too dificult to choose
> >>appropriate colours.
> >
> > I dont think so. with some amount of careful thought
> > it should be possible
> 
> There have been several good reasons given already why colours in
> particular are bad. I'll give one more: are you sure that a given colour
> implies what you think it does in different cultures?
> 
> > If fedora was catering just to old time unix users who
> > are used to working with Linux on the server, then
> > this definitely is not needed but since its trying to
> > be appealing to everyone including newbies, it is
> > important that we do something like this.
> 
> If you really want to make the "danger" of a root shell more obvious to
> newbies, then how about: Create a new application launcher "root
> terminal" which prompts for the root password, gives you a nice stern
> warning dialogue, and could have different window decoration to a
> regular terminal. This way root's shell is left alone for people who
> know how to get there other ways, and all the "warnings" are easily
> localisable and themable - as well as contained within the one launcher
> that the rest of us don't have to use.
> 
> I'm all for getting as many people as possible to use Fedora. However,
> that does not mean we should be pandering to newbies; or doing things
> that will inconvenience the more experienced users. The command line is
> supposed to be powerful - but with great power comes great
> responsibility (apologies, couldn't resist). Until newbies gain enough
> experience for that, they should be given more friendly and safer
> methods to configure their system. So if you feel the
> "newbie-friendlyness" of Fedora needs work then I'd suggest time and
> effort would best be spent helping create/improve the GUI admin tools.
> Those are also beneficial to advanced users.
> 

This is the best idea yet, drop the whole idea of altering the prompt
and stick any warnings inside kde, gnome, and xfce.  I can't say I
would want my fedora installations to warn me about using root though.

> Cheers
> 
> --
> Stuart
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From frank at pineaus.com  Thu Dec  9 16:44:51 2004
From: frank at pineaus.com (Frank Pineau)
Date: Thu, 09 Dec 2004 11:44:51 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a004120908382f64adab@mail.gmail.com>
References: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
	<41B86EAE.3010304@terminus.co.uk>
	<3077b8a004120908382f64adab@mail.gmail.com>
Message-ID: <1102610691.3547.7.camel@morbo>

On Thu, 2004-12-09 at 11:38 -0500, Nick Bargnesi wrote:

> 
> This is the best idea yet, drop the whole idea of altering the prompt
> and stick any warnings inside kde, gnome, and xfce.  I can't say I
> would want my fedora installations to warn me about using root though.
> 

FWIW, the only reason I change my prompt is so that when I have multiple
terminal sessions open, some root, some non-, I can more easily
distinguish between them.  I found that the # wasn't enough to catch my
eye.  It doesn't really serve as a warning to me that I'm in a root
session, it's more just an identifier.


-- 
Fix it! Fix it! Fix it! Fix it! Fix it! Fix it!... Fix it! Fix it! Fix
it!

--Fry
  Futurama - "A Clone of My Own"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/0ca14835/attachment.sig>

From rahulsundaram at yahoo.co.in  Thu Dec  9 16:46:57 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 9 Dec 2004 08:46:57 -0800 (PST)
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <3077b8a004120908382f64adab@mail.gmail.com>
Message-ID: <20041209164657.72492.qmail@web8504.mail.in.yahoo.com>

Hi

> This is the best idea yet, drop the whole idea of
> altering the prompt
> and stick any warnings inside kde, gnome, and xfce. 
> I can't say I
> would want my fedora installations to warn me about
> using root though.

RFE has been closed

https://bugzilla.redhat.com/beta/show_bug.cgi?id=139628

=====
Regards
Rahul Sundaram


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail



From steve at silug.org  Thu Dec  9 16:47:42 2004
From: steve at silug.org (Steven Pritchard)
Date: Thu, 9 Dec 2004 10:47:42 -0600
Subject: Xen in rawhide
In-Reply-To: <20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
Message-ID: <20041209164742.GA24437@osiris.silug.org>

On Thu, Dec 09, 2004 at 04:53:58PM +0100, Florian La Roche wrote:
> I've seen rpm packages on http://people.redhat.com/riel/

That's exactly what I was looking for.  Thanks.  :-)

Are these other bits likely to be added to rawhide any time soon?

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From Nicolas.Mailhot at laPoste.net  Thu Dec  9 16:54:12 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Thu, 09 Dec 2004 17:54:12 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102610691.3547.7.camel@morbo>
References: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
	<41B86EAE.3010304@terminus.co.uk>
	<3077b8a004120908382f64adab@mail.gmail.com>
	<1102610691.3547.7.camel@morbo>
Message-ID: <1102611252.19119.7.camel@ulysse.olympe.o2t>

Le jeudi 09 d?cembre 2004 ? 11:44 -0500, Frank Pineau a ?crit :
> On Thu, 2004-12-09 at 11:38 -0500, Nick Bargnesi wrote:
> 
> > 
> > This is the best idea yet, drop the whole idea of altering the prompt
> > and stick any warnings inside kde, gnome, and xfce.  I can't say I
> > would want my fedora installations to warn me about using root though.
> > 
> 
> FWIW, the only reason I change my prompt is so that when I have multiple
> terminal sessions open, some root, some non-, I can more easily
> distinguish between them.  I found that the # wasn't enough to catch my
> eye.  It doesn't really serve as a warning to me that I'm in a root
> session, it's more just an identifier.

Well if we restrict the problem to modern gfx terminals, there are lots
of possibilities :
- background images
- yellow notification bar ? la firefox
- etc, etc

This would take care of na?ve users since they are not likely to dig out
an old term like rxvt or xterm and will stick to gnome-terminal/kterm

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/dfd0348c/attachment.sig>

From steve at silug.org  Thu Dec  9 20:52:59 2004
From: steve at silug.org (Steven Pritchard)
Date: Thu, 9 Dec 2004 14:52:59 -0600
Subject: enabling selinux
Message-ID: <20041209205259.GA25318@osiris.silug.org>

Excuse me for a stupid selinux question...

Is there something I have to do when packaging a daemon to make
selinux policy apply to it?

I have an OpenVPN package in the fedora.us QA queue
(https://bugzilla.fedora.us/show_bug.cgi?id=1531).  I noticed that
selinux-policy-targeted-sources includes a file openvpn.fc, but I have
no idea how to connect the dots to make it all work...

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From Hugh_Caley at affymetrix.com  Thu Dec  9 21:11:04 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Thu, 09 Dec 2004 13:11:04 -0800
Subject: Slow X on x86_64
Message-ID: <1102626664.3768.39.camel@puglia.ev.affymetrix.com>

Relevant log entries below.

I note that I have no /dev/dri directory.  Created one, but it's gone on
reboot.  My 32-bit machine has these entries in dmesg, but the 64-bit
machine does not:

agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode



Hugh

x86_64

dmesg:

agpgart: Detected AMD 8151 AGP Bridge rev B3
agpgart: Maximum main memory to use for agp memory: 7956M
agpgart: AGP aperture is 128M @ 0xf0000000
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

Linux agpgart interface v0.100 (c) Dave Jones

vesafb: probe of vesafb0 failed with error -6



Xorg.0.log:

(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib64/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
(II) MGA(0): [drm] bpp: 32 depth: 24
(II) MGA(0): [drm] Sarea 2200+664: 2864
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
[drm] failed to load kernel module "mga"
(II) MGA(0): [drm] drmOpen failed
(EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI.



> Re: Slow X on x86_64
> 
> ______________________________________________________________________
>       * From: Alan Cox <alan redhat com>
>       * To: Development discussions related to Fedora Core <fedora-
>         devel-list redhat com>
>       * Subject: Re: Slow X on x86_64
>       * Date: Wed, 8 Dec 2004 18:21:54 -0500
> 
> ______________________________________________________________________
> On Wed, Dec 08, 2004 at 02:45:54PM -0800, Hugh Caley wrote:
> > I'm having a problem with an install of FC3 on an Opteron machine.  The
> > X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
> > similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
> > same with both a Matrox G550 and an ATI Radeon 9200 card.
> 
> Maxtrox at least was 32bit only for DRI until very recently. Radeon should
> be working. Mine does anyway 8)
> 
> > Anyone else seeing this?
> 
> Logs ?
> 



From dhollis at davehollis.com  Thu Dec  9 21:54:26 2004
From: dhollis at davehollis.com (David Hollis)
Date: Thu, 09 Dec 2004 16:54:26 -0500
Subject: enabling selinux
In-Reply-To: <20041209205259.GA25318@osiris.silug.org>
References: <20041209205259.GA25318@osiris.silug.org>
Message-ID: <1102629266.4158.16.camel@dhollis-lnx.centricconsulting.com>

On Thu, 2004-12-09 at 14:52 -0600, Steven Pritchard wrote:
> Excuse me for a stupid selinux question...
> 
> Is there something I have to do when packaging a daemon to make
> selinux policy apply to it?
> 
> I have an OpenVPN package in the fedora.us QA queue
> (https://bugzilla.fedora.us/show_bug.cgi?id=1531).  I noticed that
> selinux-policy-targeted-sources includes a file openvpn.fc, but I have
> no idea how to connect the dots to make it all work...

Looking into it a bit, I found that the openvpn.fc sets up the file
contexts so that the openvpn files can be confined to an openvpn
specific domain.  Unfortunately, there isn't an openvpn domain specified
at this point.  The openvpn.fc file is essentially ignored (with a
targeted policy anyway) since there is not an associated
domains/program/openvpn.te file to define the domain.

As far as the RPM itself goes, I don't think that there is anything
specific that you would need to do for OpenVPN.  If/when the selinux
policies are updated to include a definition for an OpenVPN domain, the
files should get labeled properly (either via filesystem relabeling or
openvpn rpm upgrade/install).

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/55cf57ae/attachment.sig>

From walters at redhat.com  Thu Dec  9 22:35:42 2004
From: walters at redhat.com (Colin Walters)
Date: Thu, 09 Dec 2004 17:35:42 -0500
Subject: enabling selinux
In-Reply-To: <20041209205259.GA25318@osiris.silug.org>
References: <20041209205259.GA25318@osiris.silug.org>
Message-ID: <1102631742.10785.31.camel@nexus.verbum.private>

On Thu, 2004-12-09 at 14:52 -0600, Steven Pritchard wrote:
> Excuse me for a stupid selinux question...
> 
> Is there something I have to do when packaging a daemon to make
> selinux policy apply to it?

Nothing in the daemon RPM itself; but you should make sure that your
file locations, etc. conform to the shipped policy.  

> I have an OpenVPN package in the fedora.us QA queue
> (https://bugzilla.fedora.us/show_bug.cgi?id=1531).  I noticed that
> selinux-policy-targeted-sources includes a file openvpn.fc, but I have
> no idea how to connect the dots to make it all work...

There is an openvpn.te; it's just not shipped in 
selinux-policy-targeted-sources.  The spec file does:

for i in apache.te dhcpd.te ldconfig.te mailman.te mysqld.te mta.te named.te nscd.te ntpd.te  portmap.te postgresql.te snmpd.te squid.te syslogd.te ypbind.te; do
mv domains/program/unused/$i domains/program/

If you just add openvpn.te to that it should work.  BTW, I wrote
openvpn.te very quickly while I was experimenting with VPN software a
while ago; it's only been lightly tested :)





From steve at silug.org  Thu Dec  9 22:38:05 2004
From: steve at silug.org (Steven Pritchard)
Date: Thu, 9 Dec 2004 16:38:05 -0600
Subject: enabling selinux
In-Reply-To: <1102629266.4158.16.camel@dhollis-lnx.centricconsulting.com>
References: <20041209205259.GA25318@osiris.silug.org>
	<1102629266.4158.16.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <20041209223805.GA25706@osiris.silug.org>

On Thu, Dec 09, 2004 at 04:54:26PM -0500, David Hollis wrote:
> Looking into it a bit, I found that the openvpn.fc sets up the file
> contexts so that the openvpn files can be confined to an openvpn
> specific domain.  Unfortunately, there isn't an openvpn domain specified
> at this point.  The openvpn.fc file is essentially ignored (with a
> targeted policy anyway) since there is not an associated
> domains/program/openvpn.te file to define the domain.

Ah, so this is needed:

  http://www.nsa.gov/selinux/list-archive/0407/7704.cfm

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From ronny-vlug at vlugnet.org  Thu Dec  9 22:36:08 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Thu, 9 Dec 2004 23:36:08 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102611252.19119.7.camel@ulysse.olympe.o2t>
References: <20041208180222.97612.qmail@web8502.mail.in.yahoo.com>
	<1102610691.3547.7.camel@morbo>
	<1102611252.19119.7.camel@ulysse.olympe.o2t>
Message-ID: <200412092336.08645.ronny-vlug@vlugnet.org>

On Thursday 09 December 2004 17:54, Nicolas Mailhot wrote:
> > FWIW, the only reason I change my prompt is so that when I have multiple
> > terminal sessions open, some root, some non-, I can more easily
> > distinguish between them.  I found that the # wasn't enough to catch my
> > eye.  It doesn't really serve as a warning to me that I'm in a root
> > session, it's more just an identifier.
>
> Well if we restrict the problem to modern gfx terminals, there are lots
> of possibilities :
> - background images
> - yellow notification bar ? la firefox
> - etc, etc
How will this work with su?

-- 
http://LinuxWiki.org/RonnyBuchmann



From ronny-vlug at vlugnet.org  Thu Dec  9 22:42:27 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Thu, 9 Dec 2004 23:42:27 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <1102587189.22606.73.camel@localhost.localdomain>
References: <20041208170302.GI5322@redhat.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102587189.22606.73.camel@localhost.localdomain>
Message-ID: <200412092342.27818.ronny-vlug@vlugnet.org>

On Thursday 09 December 2004 11:13, David Woodhouse wrote:
> I really don't see the point in changing colours in the prompt. If the
> user is unaware of the distinction and the danger of doing things as
> root, changing the colour of the prompt isn't going to help. If the user
> _is_ aware of the difference, then the standard $/# indicator is
> sufficient.
>
> Adding an extra line of warning beforehand is slightly less obnoxious,
> but really only slightly so. I can just about manage at the moment to
> put up with the 'new' ([\u@\h \W]\\$; introduced circa 1996?) prompt
> when I'm root, but if such a change is made I'll actually have to go and
> change it on all the machines I run. The hash sign is perfectly
> sufficient.
If you have several terminals opened (some root, some user) you will easily 
distinguish by $/#?
Have you never been in a hurry?

I find it very heplfull if root/non-root prompt can be more easily 
distinguished. (I would prefer a two-liner for root)

-- 
http://LinuxWiki.org/RonnyBuchmann



From dhollis at davehollis.com  Thu Dec  9 23:10:34 2004
From: dhollis at davehollis.com (David Hollis)
Date: Thu, 09 Dec 2004 18:10:34 -0500
Subject: enabling selinux
In-Reply-To: <1102631742.10785.31.camel@nexus.verbum.private>
References: <20041209205259.GA25318@osiris.silug.org>
	<1102631742.10785.31.camel@nexus.verbum.private>
Message-ID: <1102633834.4158.21.camel@dhollis-lnx.centricconsulting.com>

On Thu, 2004-12-09 at 17:35 -0500, Colin Walters wrote:
> 
> There is an openvpn.te; it's just not shipped in 
> selinux-policy-targeted-sources.  The spec file does:
> 
> for i in apache.te dhcpd.te ldconfig.te mailman.te mysqld.te mta.te named.te nscd.te ntpd.te  portmap.te postgresql.te snmpd.te squid.te syslogd.te ypbind.te; do
> mv domains/program/unused/$i domains/program/
> 
> If you just add openvpn.te to that it should work.  BTW, I wrote
> openvpn.te very quickly while I was experimenting with VPN software a
> while ago; it's only been lightly tested :)
> 

Doesn't drop in cleanly with the targeted policy.  It also wants the
ifconfig, which wants proc_net_t and run_init_t stuff that isn't in the
targeted policy.  I've wrapped the call to ifconfig_exec_t in an if
('ifconfig.te....') call so that it builds properly with the targeted
policy.  It builds, and labels the files, so thats a start!  Next
question is if it actually works :)
 

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
#DESC OpenVPN - Firewall-friendly SSL-based VPN
#
# Author: Colin Walters <walters at verbum.org>
#
########################################
#

daemon_domain(openvpn)
etcdir_domain(openvpn)

type openvpn_port_t, port_type;

allow openvpn_t { etc_t etc_runtime_t }:{ file lnk_file } r_file_perms;

allow openvpn_t { random_device_t urandom_device_t }:chr_file { read getattr };
allow openvpn_t devpts_t:dir { search getattr };
allow openvpn_t tun_tap_device_t:chr_file rw_file_perms;
allow openvpn_t proc_t:file { getattr read };

allow openvpn_t self:unix_dgram_socket create_socket_perms;
allow openvpn_t self:unix_stream_socket create_stream_socket_perms;
allow openvpn_t self:unix_dgram_socket sendto;
allow openvpn_t self:unix_stream_socket connectto;
allow openvpn_t self:capability net_admin;
r_dir_file(openvpn_t, sysctl_net_t)

can_network(openvpn_t)
allow openvpn_t openvpn_port_t:udp_socket name_bind;

# OpenVPN executes a lot of helper programs and scripts
allow openvpn_t { bin_t sbin_t }:dir { search getattr };
allow openvpn_t bin_t:lnk_file { getattr read };
can_exec(openvpn_t, { bin_t sbin_t shell_exec_t })
# Do not transition to ifconfig_t, since then it needs
# permission to access openvpn_t:udp_socket, which seems
# worse.
ifdef(`ifconfig.te',
`can_exec(openvpn_t, ifconfig_exec_t)')

# The Fedora init script iterates over /etc/openvpn/*.conf, and
# starts a daemon for each file.
r_dir_file(initrc_t, openvpn_etc_t)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/6860feb8/attachment.sig>

From dhollis at davehollis.com  Thu Dec  9 23:15:00 2004
From: dhollis at davehollis.com (David Hollis)
Date: Thu, 09 Dec 2004 18:15:00 -0500
Subject: enabling selinux
In-Reply-To: <1102633834.4158.21.camel@dhollis-lnx.centricconsulting.com>
References: <20041209205259.GA25318@osiris.silug.org>
	<1102631742.10785.31.camel@nexus.verbum.private>
	<1102633834.4158.21.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <1102634100.4158.23.camel@dhollis-lnx.centricconsulting.com>

On Thu, 2004-12-09 at 18:10 -0500, David Hollis wrote:
> 
> Doesn't drop in cleanly with the targeted policy.  It also wants the
> ifconfig, which wants proc_net_t and run_init_t stuff that isn't in the
> targeted policy.  I've wrapped the call to ifconfig_exec_t in an if
> ('ifconfig.te....') call so that it builds properly with the targeted
> policy.  It builds, and labels the files, so thats a start!  Next
> question is if it actually works :)
>  
> 

A quick test turns up that I need to change the line for self:capability
to:

allow openvpn_t self:capability { net_admin setgid setuid };

To allow the daemon to switch to the nobody user.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041209/579746cf/attachment.sig>

From cra at WPI.EDU  Thu Dec  9 23:46:31 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Thu, 9 Dec 2004 18:46:31 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412092342.27818.ronny-vlug@vlugnet.org>
References: <20041208170302.GI5322@redhat.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102587189.22606.73.camel@localhost.localdomain>
	<200412092342.27818.ronny-vlug@vlugnet.org>
Message-ID: <20041209234631.GF27024@angus.ind.WPI.EDU>

On Thu, Dec 09, 2004 at 11:42:27PM +0100, Ronny Buchmann wrote:
> If you have several terminals opened (some root, some user) you will easily 
> distinguish by $/#?
> Have you never been in a hurry?
> 
> I find it very heplfull if root/non-root prompt can be more easily 
> distinguished. (I would prefer a two-liner for root)

People should get in the habit of using sudo wherever possible instead 
of opening a root shell.



From rahulsundaram at yahoo.co.in  Fri Dec 10 00:19:25 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 9 Dec 2004 16:19:25 -0800 (PST)
Subject: setting up sudo(was : RFC: root/non-root bash prompts different
	colours?)
In-Reply-To: <20041209234631.GF27024@angus.ind.WPI.EDU>
Message-ID: <20041210001925.4264.qmail@web8501.mail.in.yahoo.com>

Hi

> People should get in the habit of using sudo
> wherever possible instead 
> of opening a root shell.


how about encouraging that concept by default with a
setup similar to Mac OS X or ubuntu. I have used both
and it really makes sense for desktop users. since
fedora isnt targetted towards mission critical
environments its more likely used as a desktop


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From mattdm at mattdm.org  Fri Dec 10 01:20:36 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 9 Dec 2004 20:20:36 -0500
Subject: setting up sudo(was : RFC: root/non-root bash prompts different
	colours?)
In-Reply-To: <20041210001925.4264.qmail@web8501.mail.in.yahoo.com>
References: <20041209234631.GF27024@angus.ind.WPI.EDU>
	<20041210001925.4264.qmail@web8501.mail.in.yahoo.com>
Message-ID: <20041210012036.GA5238@jadzia.bu.edu>

On Thu, Dec 09, 2004 at 04:19:25PM -0800, Rahul Sundaram wrote:
> how about encouraging that concept by default with a
> setup similar to Mac OS X or ubuntu. I have used both
> and it really makes sense for desktop users. since
> fedora isnt targetted towards mission critical
> environments its more likely used as a desktop

Try this in FC3:

1) add yourself to the 'wheel' group
2) add the line "UGROUPS=wheel" to each file in 
   /etc/sysconfig/console.apps

Now, you have sudo-like access to all of these programs -- you need to
authenticate, but with your own password, not the root password. And for
sudo itself, of course, uncomment the "%wheel ALL=(ALL) ALL" line in
/etc/sudoers.

For BU Linux, we do this by default, and I've patched system-config-users to 
include an easy way to add wheel group membership (and made it display in
its own column in the normal view, so it's obvious who's got it).

When one logs in as root with the "Default" environment (instead of
explicitly picking Gnome or KDE), one gets a minimalist environment running
system-config-users, with instructions on how to create an admin user in the
wheel group.

Furthermore, we set it up so all mail destined for root is sent to members
of 'wheel', to increase the chances of it actually being seen by a human.

All or some of this may be good for Fedora Core. (Getting UGROUPS into
usermode was the first step -- cool.)

Also, by the way, you can use the UGROUPS thing in a more fine-grained way,
too, if you want: you could make a "printadmin" group and use the line
"UGROUPS=printadmin" (or UGROUPS="wheel,printadmin", even).

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From zcerza at redhat.com  Fri Dec 10 03:38:15 2004
From: zcerza at redhat.com (Zack Cerza)
Date: Thu, 09 Dec 2004 22:38:15 -0500
Subject: Wine/Cedega and fedora 3
In-Reply-To: <1102530487.4257.129.camel@support02.civic.twp.ypsilanti.mi.us>
References: <20041208180700.70503.qmail@web8501.mail.in.yahoo.com>
	<1102530487.4257.129.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <1102649895.17742.20.camel@localhost>

On Wed, 2004-12-08 at 13:28 -0500, Sean Middleditch wrote:
> On Wed, 2004-12-08 at 10:07 -0800, Rahul Sundaram wrote:
> > Hi
> > 
> > 
> >  There are libraries that Red Hat
> > > packages which are clearly
> > > capable of being parallel installed and otherwise
> > > working beautifully,
> > > but Red Hat's packages cause artificial
> > > incompatibilities.
> > > 
> > > Take the libcurl examples from the other thread.
> > 
> > have you filed a bug report?
> 
> Of course.

It's this one:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130251

Zack



From jwz at jwz.org  Fri Dec 10 07:57:21 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Thu, 09 Dec 2004 23:57:21 -0800
Subject: how do I make lsof be useful again in fc3?
Message-ID: <41B956E1.544F4214@jwz.org>

In FC3, lsof only seems to work properly if you are root.

For example: the "ssh-agent" process is running as "jwz" and has the
file "/tmp/ssh-rZlWVC4461/agent.4461" open.

If I run "lsof -p `pidof ssh-agent`" as root, it shows me this; if I run
it as jwz, it does not.  This is wrong, since all processes and files
are owned by the same non-root user.

I assume this is because of newly-paranoid permissions on
/proc/*/fd (in FC3, those are all owned by root instead of the
user running the process.)

How do I fix it?

"Log in as root" is not a good answer, because I need to do this sort of
thing from various scripts that are run non-interactively (and not as
root.)

-- 
Jamie Zawinski
jwz at jwz.org             http://www.jwz.org/
jwz at dnalounge.com       http://www.dnalounge.com/



From tmraz at redhat.com  Fri Dec 10 08:31:51 2004
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 10 Dec 2004 09:31:51 +0100
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <41B956E1.544F4214@jwz.org>
References: <41B956E1.544F4214@jwz.org>
Message-ID: <1102667511.3738.14.camel@perun.redhat.usu>

On Thu, 2004-12-09 at 23:57 -0800, Jamie Zawinski wrote:
> In FC3, lsof only seems to work properly if you are root.
> 
> For example: the "ssh-agent" process is running as "jwz" and has the
> file "/tmp/ssh-rZlWVC4461/agent.4461" open.
> 
> If I run "lsof -p `pidof ssh-agent`" as root, it shows me this; if I run
> it as jwz, it does not.  This is wrong, since all processes and files
> are owned by the same non-root user.
I can confirm this too and it seems to me to be a bug.

> I assume this is because of newly-paranoid permissions on
> /proc/*/fd (in FC3, those are all owned by root instead of the
> user running the process.)
Not all processes have these owned by root. I think it happens only on
such processes which changed it's uid from root during their lives.
The question is if this change was intentional and what was the reason
for it if yes.

-- 
Tomas Mraz <tmraz at redhat.com>



From feliciano.matias at free.fr  Fri Dec 10 09:00:28 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Fri, 10 Dec 2004 10:00:28 +0100
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <1102667511.3738.14.camel@perun.redhat.usu>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
Message-ID: <1102669228.20610.9.camel@one.myworld>

Le vendredi 10 d?cembre 2004 ? 09:31 +0100, Tomas Mraz a ?crit :
> On Thu, 2004-12-09 at 23:57 -0800, Jamie Zawinski wrote:
> > In FC3, lsof only seems to work properly if you are root.
> > 
> > For example: the "ssh-agent" process is running as "jwz" and has the
> > file "/tmp/ssh-rZlWVC4461/agent.4461" open.
> > 
> > If I run "lsof -p `pidof ssh-agent`" as root, it shows me this; if I run
> > it as jwz, it does not.  This is wrong, since all processes and files
> > are owned by the same non-root user.
> I can confirm this too and it seems to me to be a bug.
> 
> > I assume this is because of newly-paranoid permissions on
> > /proc/*/fd (in FC3, those are all owned by root instead of the
> > user running the process.)
> Not all processes have these owned by root. I think it happens only on
> such processes which changed it's uid

$ ll /usr/bin/ssh-agent
-rwxr-sr-x  1 root nobody 58332 sep 21 06:56 /usr/bin/ssh-agent
         ^
Why ?

Come from the .spec file :
%attr(2755,root,nobody) %{_bindir}/ssh-agent

>  from root during their lives.
> The question is if this change was intentional and what was the reason
> for it if yes.
> 

Because the process can read files with group == nobody.

> -- 
> Tomas Mraz <tmraz at redhat.com>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041210/84409bda/attachment.sig>

From feliciano.matias at free.fr  Fri Dec 10 09:05:19 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Fri, 10 Dec 2004 10:05:19 +0100
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <1102669228.20610.9.camel@one.myworld>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld>
Message-ID: <1102669519.20610.12.camel@one.myworld>

Le vendredi 10 d?cembre 2004 ? 10:00 +0100, F?liciano Matias a ?crit :
> $ ll /usr/bin/ssh-agent
> -rwxr-sr-x  1 root nobody 58332 sep 21 06:56 /usr/bin/ssh-agent
>          ^
> Why ?

openssh-3.9p1/contrib/redhat/openssh.spec
        * Wed Oct 01 2002 Damien Miller <djm at mindrot.org>
        - Install ssh-agent setgid nobody to prevent ptrace() key theft
        attacks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041210/268b6c12/attachment.sig>

From jakub at redhat.com  Fri Dec 10 09:09:46 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Fri, 10 Dec 2004 04:09:46 -0500
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <1102669519.20610.12.camel@one.myworld>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld>
	<1102669519.20610.12.camel@one.myworld>
Message-ID: <20041210090945.GF10340@devserv.devel.redhat.com>

On Fri, Dec 10, 2004 at 10:05:19AM +0100, F?liciano Matias wrote:
> Le vendredi 10 d?cembre 2004 ? 10:00 +0100, F?liciano Matias a ?crit :
> > $ ll /usr/bin/ssh-agent
> > -rwxr-sr-x  1 root nobody 58332 sep 21 06:56 /usr/bin/ssh-agent
> >          ^
> > Why ?
> 
> openssh-3.9p1/contrib/redhat/openssh.spec
>         * Wed Oct 01 2002 Damien Miller <djm at mindrot.org>
>         - Install ssh-agent setgid nobody to prevent ptrace() key theft
>         attacks

Then it shouldn't be setgid nobody, but setgid sshagentgrp
or something else nothing else uses.
Or in FC3+ a SELinux policy can be added for ssh-agent.

	Jakub



From jwz at jwz.org  Fri Dec 10 09:28:45 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Fri, 10 Dec 2004 01:28:45 -0800
Subject: how do I make lsof be useful again in fc3?
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld>
Message-ID: <41B96C4D.21C4D30C@jwz.org>

Filiciano Matias wrote:
> 
> -rwxr-sr-x  1 root nobody 58332 sep 21 06:56 /usr/bin/ssh-agent
>          ^
> Why ?

Hmm, if I take off the setgid bit, I get the same behavior:

  -rwxr-xr-x  1 root nobody 58332 Sep 20 21:56 /usr/bin/ssh-agent
  dr-x------  2 root root       0 Dec 10 01:22 /proc/6039/fd
  dr-xr-xr-x  3 jwz  jwz        0 Dec 10 01:26 /proc/6039

-- 
Jamie Zawinski
jwz at jwz.org             http://www.jwz.org/
jwz at dnalounge.com       http://www.dnalounge.com/



From dwmw2 at infradead.org  Fri Dec 10 10:06:04 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Dec 2004 10:06:04 +0000
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412092342.27818.ronny-vlug@vlugnet.org>
References: <20041208170302.GI5322@redhat.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102587189.22606.73.camel@localhost.localdomain>
	<200412092342.27818.ronny-vlug@vlugnet.org>
Message-ID: <1102673164.11421.45.camel@baythorne.infradead.org>

On Thu, 2004-12-09 at 23:42 +0100, Ronny Buchmann wrote:
> If you have several terminals opened (some root, some user) you will easily 
> distinguish by $/#?

Yes. It's _right_ there in front of me; the last character of the
prompt. It would be hard to miss it.

> Have you never been in a hurry?

Of the _many_ stupid things I've done when I've been in a hurry, almost
all of them were done when I was root and I _knew_ it.

-- 
dwmw2




From feliciano.matias at free.fr  Fri Dec 10 10:34:20 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Fri, 10 Dec 2004 11:34:20 +0100
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <41B96C4D.21C4D30C@jwz.org>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld>  <41B96C4D.21C4D30C@jwz.org>
Message-ID: <1102674861.20610.21.camel@one.myworld>

Le vendredi 10 d?cembre 2004 ? 01:28 -0800, Jamie Zawinski a ?crit :
> Filiciano Matias wrote:
> > 
> > -rwxr-sr-x  1 root nobody 58332 sep 21 06:56 /usr/bin/ssh-agent
> >          ^
> > Why ?
> 
> Hmm, if I take off the setgid bit, I get the same behavior:

Sure ?

What does this command :
$ cat /proc/`/sbin/pidof ssh-agent`/status | egrep "^Gid"
Gid:    100     100     99      100
                                 ^ 99 : nobody

Have you kill the previous ssh-agent process ?
> 
>   -rwxr-xr-x  1 root nobody 58332 Sep 20 21:56 /usr/bin/ssh-agent
>   dr-x------  2 root root       0 Dec 10 01:22 /proc/6039/fd
>   dr-xr-xr-x  3 jwz  jwz        0 Dec 10 01:26 /proc/6039
> 
> -- 
> Jamie Zawinski
> jwz at jwz.org             http://www.jwz.org/
> jwz at dnalounge.com       http://www.dnalounge.com/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041210/5b21c058/attachment.sig>

From jwz at jwz.org  Fri Dec 10 10:49:44 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Fri, 10 Dec 2004 02:49:44 -0800
Subject: how do I make lsof be useful again in fc3?
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld> <41B96C4D.21C4D30C@jwz.org>
	<1102674861.20610.21.camel@one.myworld>
Message-ID: <41B97F48.59ADB1EB@jwz.org>

Filiciano Matias wrote:
> 
> What does this command :
> $ cat /proc/`/sbin/pidof ssh-agent`/status | egrep "^Gid"
> Gid:    100     100     99      100
>                                  ^ 99 : nobody
> 
> Have you kill the previous ssh-agent process ?

Yes, defintely.

    Gid:	500	500	500	500

500 = user jwz and group jwz.

-- 
Jamie Zawinski
jwz at jwz.org             http://www.jwz.org/
jwz at dnalounge.com       http://www.dnalounge.com/



From feliciano.matias at free.fr  Fri Dec 10 11:36:04 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Fri, 10 Dec 2004 12:36:04 +0100
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <41B97F48.59ADB1EB@jwz.org>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld> <41B96C4D.21C4D30C@jwz.org>
	<1102674861.20610.21.camel@one.myworld>  <41B97F48.59ADB1EB@jwz.org>
Message-ID: <1102678564.3795.4.camel@one.myworld>

Le vendredi 10 d?cembre 2004 ? 02:49 -0800, Jamie Zawinski a ?crit :
> Filiciano Matias wrote:
> > 
> > What does this command :
> > $ cat /proc/`/sbin/pidof ssh-agent`/status | egrep "^Gid"
> > Gid:    100     100     99      100
> >                                  ^ 99 : nobody
> > 
> > Have you kill the previous ssh-agent process ?
> 
> Yes, defintely.
> 
>     Gid:	500	500	500	500
> 
> 500 = user jwz and group jwz.
> 

"chmod g-s /usr/bin/ssh-agent" and add this patch :
        diff -urN openssh-3.9p1.orig/ssh-agent.c openssh-3.9p1/ssh-agent.c
        --- openssh-3.9p1.orig/ssh-agent.c	2004-08-13 13:18:01.000000000 +0200
        +++ openssh-3.9p1/ssh-agent.c	2004-12-10 12:10:36.267810158 +0100
        @@ -1022,11 +1022,6 @@
         	setegid(getgid());
         	setgid(getgid());
         
        -#if defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE)
        -	/* Disable ptrace on Linux without sgid bit */
        -	prctl(PR_SET_DUMPABLE, 0);
        -#endif
        -
         	SSLeay_add_all_algorithms();
         
         	__progname = ssh_get_progname(av[0]);


Perhaps it's not a good idea.

from linux/prctl.h :
        /* Get/set current->mm->dumpable */
        #define PR_GET_DUMPABLE   3
        #define PR_SET_DUMPABLE   4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041210/5ff4ef51/attachment.sig>

From cmadams at hiwaay.net  Fri Dec 10 12:05:08 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 10 Dec 2004 06:05:08 -0600
Subject: how do I make lsof be useful again in fc3?
In-Reply-To: <41B96C4D.21C4D30C@jwz.org>
References: <41B956E1.544F4214@jwz.org>
	<1102667511.3738.14.camel@perun.redhat.usu>
	<1102669228.20610.9.camel@one.myworld> <41B96C4D.21C4D30C@jwz.org>
Message-ID: <20041210120508.GA1433375@hiwaay.net>

Once upon a time, Jamie Zawinski <jwz at jwz.org> said:
> Hmm, if I take off the setgid bit, I get the same behavior:
> 
>   -rwxr-xr-x  1 root nobody 58332 Sep 20 21:56 /usr/bin/ssh-agent
>   dr-x------  2 root root       0 Dec 10 01:22 /proc/6039/fd
>   dr-xr-xr-x  3 jwz  jwz        0 Dec 10 01:26 /proc/6039

It isn't actually supposed to be setgid on Linux; see ssh-agent.c:

#if defined(HAVE_SYS_PRCTL_H)
#include <sys/prctl.h>	/* For prctl() and PR_SET_DUMPABLE */
#endif
...
#if defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE)
	/* Disable ptrace on Linux without sgid bit */
	prctl(PR_SET_DUMPABLE, 0);
#endif

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From sds at epoch.ncsc.mil  Fri Dec 10 13:03:40 2004
From: sds at epoch.ncsc.mil (Stephen Smalley)
Date: Fri, 10 Dec 2004 08:03:40 -0500
Subject: enabling selinux
In-Reply-To: <1102629266.4158.16.camel@dhollis-lnx.centricconsulting.com>
References: <20041209205259.GA25318@osiris.silug.org>
	<1102629266.4158.16.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <1102683820.1628.5.camel@moss-spartans.epoch.ncsc.mil>

On Thu, 2004-12-09 at 16:54, David Hollis wrote:
> Looking into it a bit, I found that the openvpn.fc sets up the file
> contexts so that the openvpn files can be confined to an openvpn
> specific domain.  Unfortunately, there isn't an openvpn domain specified
> at this point.  The openvpn.fc file is essentially ignored (with a
> targeted policy anyway) since there is not an associated
> domains/program/openvpn.te file to define the domain.
> 
> As far as the RPM itself goes, I don't think that there is anything
> specific that you would need to do for OpenVPN.  If/when the selinux
> policies are updated to include a definition for an OpenVPN domain, the
> files should get labeled properly (either via filesystem relabeling or
> openvpn rpm upgrade/install).

openvpn domain exists in the strict policy.  Domains are migrated from
strict to targeted based on demand and impact on useability, I think.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency



From buildsys at redhat.com  Fri Dec 10 13:13:45 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 10 Dec 2004 08:13:45 -0500
Subject: rawhide report: 20041210 changes
Message-ID: <200412101313.iBADDjj01765@porkchop.devel.redhat.com>

 

 
Updated Packages:

a2ps-4.13b-43
-------------
* Thu Dec 09 2004 Tim Waugh <twaugh at redhat.com> 4.13b-43
- Fixed font path (bug #142294).
- Fixed problems in make_fonts_map script (bug #142299).  Patch from
  Michal Jaegermann.

anaconda-10.2.0.6-1
-------------------
* Wed Dec 08 2004 Jeremy Katz <katzj at redhat.com> - 10.2.0.6-1
- Write out wepkey better (#140645)
- Try to skip source isos with nfsiso (#106017)
- Don't traceback for bad/missing / in fstab (nasrat, #141174)
- Include pesize in generated ks.cfg (#141370)
- Loop less on shutdown
- Better handling of partial volume groups (#139058)

bzip2-1.0.2-14
--------------
* Thu Dec 09 2004 Jiri Ryska <jryska at redhat.com>
- changed temp file creation in bzdiff #92444

diskdumputils-0.6.2-1
---------------------
* Thu Dec 09 2004 Phil Knirsch <pknirsch at redhat.com> 0.6.2-1
- Tiny Requires fix for correct package ordering

dosfstools-2.10-1
-----------------
* Thu Dec 09 2004 Peter Vrabec <pvrabec at redhat.com>  2.10-1
- updated to 2.10

gdm-1:2.6.0.5-10
----------------
* Thu Dec 09 2004 Dan Walsh <dwalsh at redhat.com> 1:2.6.0.5-10
- Remove pam_selinux from gdmsetup pam file

ghostscript-7.07-36
-------------------
* Thu Dec 09 2004 Tim Waugh <twaugh at redhat.com> 7.07-36
- Remove VFlib2 bits (bug #120498).

logrotate-3.7.1-3
-----------------
* Mon Dec 06 2004 Peter Vrabec <pvrabec at redhar.com>
- compressed logfiles and logrotate (#140353)

ltrace-0.3.36-2
---------------
* Thu Dec 09 2004 Jakub Jelinek <jakub at redhat.com> 0.3.36-2
- make x86_64 ltrace trace both 32-bit and 64-bit binaries (#141955,
  IT#55600)
- fix tracing across execve
- fix printf-style format handling on 64-bit arches

mc-1:4.6.1a-0.1
---------------
* Thu Dec 09 2004 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.1
- update from CVS
- sync UTF-8 patches with upstream
- drop upstreamed badsize, growbuf patches
- faster FISH upload support (#140750) - from Dmitry Butskoj

* Mon Dec 06 2004 Jindrich Novy <jnovy at redhat.com>
- add msglen patch to calculate message length correctly in UTF-8 (#141875)
  (thanks to Nickolay V. Shmyrev)
- convert hints for ru, uk, zh, man page conversion fix

rpmdb-fedora-1:4-0.20041210
---------------------------

selinux-policy-strict-1.19.12-1
-------------------------------
* Wed Dec 08 2004 Dan Walsh <dwalsh at redhat.com> 1.19-12-1
- Update latest from NSA
- Add single_user_file_type tunable.

tcl-8.4.9-1
-----------
* Thu Dec 09 2004 Jens Petersen <petersen at redhat.com> - 8.4.9-1
- new stable release

tk-8.4.9-1
----------
* Thu Dec 09 2004 Jens Petersen <petersen at redhat.com> - 8.4.9-1
- latest stable release

* Wed Nov 24 2004 Jens Petersen <petersen at redhat.com> - 8.4.8-1
- update to latest release



From kumarabhijit at gmail.com  Fri Dec 10 14:14:25 2004
From: kumarabhijit at gmail.com (abhijit kumar)
Date: Fri, 10 Dec 2004 06:14:25 -0800
Subject: where will i get logfiles of sched.c?
Message-ID: <3c7f53f00412100614f66f44e@mail.gmail.com>

sir!
  I am using sevral "printk" commands to understand the kernel
scheduling using "sched.c" of kernel -2.4.26 . But, i am n't able to
locate any printed messages. where will i get it? the
"/var/log/messages" does n't show messages about it. my klogd and
syslogd is running.

waiting for ur replies.

Abhijit



From rjune at bravegnuworld.com  Fri Dec 10 14:43:20 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Fri, 10 Dec 2004 09:43:20 -0500
Subject: setting up sudo(was : RFC: root/non-root bash prompts different
	colours?)
In-Reply-To: <20041210012036.GA5238@jadzia.bu.edu>
References: <20041209234631.GF27024@angus.ind.WPI.EDU>
	<20041210001925.4264.qmail@web8501.mail.in.yahoo.com>
	<20041210012036.GA5238@jadzia.bu.edu>
Message-ID: <200412100943.23746.rjune@bravegnuworld.com>

On Thursday 09 December 2004 20:20, Matthew Miller wrote:
> On Thu, Dec 09, 2004 at 04:19:25PM -0800, Rahul Sundaram wrote:
> > how about encouraging that concept by default with a
> > setup similar to Mac OS X or ubuntu. I have used both
> > and it really makes sense for desktop users. since
> > fedora isnt targetted towards mission critical
> > environments its more likely used as a desktop
>
> Try this in FC3:
>
> 1) add yourself to the 'wheel' group
> 2) add the line "UGROUPS=wheel" to each file in
>    /etc/sysconfig/console.apps
>
> Now, you have sudo-like access to all of these programs -- you need to
> authenticate, but with your own password, not the root password. And for
> sudo itself, of course, uncomment the "%wheel ALL=(ALL) ALL" line in
> /etc/sudoers.
This  is a great idea. and I think it should be either implemented as the 
default. *or* a setting in sysconfig-securitylevel.

> For BU Linux, we do this by default, and I've patched system-config-users
> to include an easy way to add wheel group membership (and made it display
> in its own column in the normal view, so it's obvious who's got it).
>
> When one logs in as root with the "Default" environment (instead of
> explicitly picking Gnome or KDE), one gets a minimalist environment running
> system-config-users, with instructions on how to create an admin user in
> the wheel group.
>
> Furthermore, we set it up so all mail destined for root is sent to members
> of 'wheel', to increase the chances of it actually being seen by a human.
>
> All or some of this may be good for Fedora Core. (Getting UGROUPS into
> usermode was the first step -- cool.)
>
> Also, by the way, you can use the UGROUPS thing in a more fine-grained way,
> too, if you want: you could make a "printadmin" group and use the line
> "UGROUPS=printadmin" (or UGROUPS="wheel,printadmin", even).
>
> --
> Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
> Boston University Linux      ------>                <http://linux.bu.edu/>

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041210/7c9e5e33/attachment.sig>

From shiva at sewingwitch.com  Fri Dec 10 16:32:08 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Fri, 10 Dec 2004 08:32:08 -0800
Subject: [Dump-users] preliminary EA/ACL support in dump/restore (fwd)
Message-ID: <5F2F7D1B397F97B6984D1334@[10.169.6.246]>

FYI, particularly for the SELinux people:

------------ Forwarded Message ------------
Date: Friday, December 10, 2004 5:13 PM +0100
From: Stelian Pop <stelian at popies.net>
To: dump-announce at lists.sourceforge.net
Cc: dump-users at lists.sourceforge.net, dump-devel at lists.sourceforge.net
Subject: [Dump-users] preliminary EA/ACL support in dump/restore

Hi everybody.

Support of ACLs is a feature requested by many for a long time and I
finally got the time to implement it. Since on Linux ACLs are only
a particular case of EAs (Extended Attributes), I implemented full
EA support, meaning that even security labels set (for example) by
SELinux will be backuped.

You can download a patch (against the current CVS dump) here:
	http://dump.sourceforge.net/dump-ea.patch.bz2

Some notes:
	* the patch is complete, meaning that everything is supposed to
	  work: dumping, extraction, comparing, in all modes etc.

	* the patch modifies some key areas of restore, so pay
	  attention and verify that you can reread your backups
	  before relying on them.

	* the tape format changed a bit and you will need the patched
	  restore to extract the files.(*)

Please test this and report back if there are any issues.

I plan to release a new version of dump (0.4b38) in the next few
days, but I will NOT include the EA patch in it, because it really
needs more testing.

But as soon as I get enough positive replies on the EA patch
I will include it in the official mainline.

Thanks,

Stelian.
	
(*) In fact is a bit more complicated:
- if no EAs are backuped, dump format should remain the same as in
  the old versions, so you can use whatever restore you want.
- if EAs are backuped but never on directory inodes, then a reasonable
  recent version of restore should be happy and just skip over the
  extended attributes data.
- if EAs are backuped for directory inodes, older restores will fail
  to extract with some 'directory corrupted' error.

-- 
Stelian Pop <stelian at popies.net>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Dump-users mailing list
Dump-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dump-users

---------- End Forwarded Message ----------






From dragoran at feuerpokemon.de  Fri Dec 10 16:36:36 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Fri, 10 Dec 2004 17:36:36 +0100
Subject: Why is k3b still at 0.11.14?
Message-ID: <41B9D094.60201@feuerpokemon.de>

Why is k3b 0.11.17 still not in rawhide?



From fherrera at onirica.com  Fri Dec 10 16:52:00 2004
From: fherrera at onirica.com (Fernando Herrera)
Date: Fri, 10 Dec 2004 17:52:00 +0100
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041208170302.GI5322@redhat.com>
References: <20041208170302.GI5322@redhat.com>
Message-ID: <1102697520.7934.7.camel@dyckola>

El mi?, 08-12-2004 a las 17:03 +0000, Tim Waugh escribi?:
> See:
> 
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139628
> 
> Should we implement a scheme to differentiate root/non-root bash
> prompts by colour?

	As the most common scenario of a root bash shell that needs to be
differenciated should be a terminal with multiple tabs or so, maybe
shipping a "root profile" with gnome-terminal would be better idea. See 
	
	http://bugzilla.gnome.org/show_bug.cgi?id=82200

Salu2




From mattdm at mattdm.org  Fri Dec 10 17:03:16 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 10 Dec 2004 12:03:16 -0500
Subject: Why is k3b still at 0.11.14?
In-Reply-To: <41B9D094.60201@feuerpokemon.de>
References: <41B9D094.60201@feuerpokemon.de>
Message-ID: <20041210170316.GA31629@jadzia.bu.edu>

On Fri, Dec 10, 2004 at 05:36:36PM +0100, dragoran wrote:
> Why is k3b 0.11.17 still not in rawhide?

Because your rawhide mirror is out of date?


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From mattdm at mattdm.org  Fri Dec 10 17:11:37 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 10 Dec 2004 12:11:37 -0500
Subject: Expermental OpenAFS 1.3.75 packages for Fedora Core
Message-ID: <20041210171137.GA32309@jadzia.bu.edu>

I'm working on making OpenAFS RPM packages for Fedora Core, and I've got
updated versions for 1.3.75 at:

  <http://www.mattdm.org/misc/openafs/>

These packages are based slightly on the old openafs.org RPMs, and somewhat
on my own older work, but mostly they're all new. See the readme on the
above site for more information.

Your feedback is very valued. Thanks.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From dwalsh at redhat.com  Fri Dec 10 18:26:37 2004
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 10 Dec 2004 13:26:37 -0500
Subject: enabling selinux
In-Reply-To: <1102634100.4158.23.camel@dhollis-lnx.centricconsulting.com>
References: <20041209205259.GA25318@osiris.silug.org>	<1102631742.10785.31.camel@nexus.verbum.private>	<1102633834.4158.21.camel@dhollis-lnx.centricconsulting.com>
	<1102634100.4158.23.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <41B9EA5D.5000409@redhat.com>

David Hollis wrote:

>On Thu, 2004-12-09 at 18:10 -0500, David Hollis wrote:
>  
>
>>Doesn't drop in cleanly with the targeted policy.  It also wants the
>>ifconfig, which wants proc_net_t and run_init_t stuff that isn't in the
>>targeted policy.  I've wrapped the call to ifconfig_exec_t in an if
>>('ifconfig.te....') call so that it builds properly with the targeted
>>policy.  It builds, and labels the files, so thats a start!  Next
>>question is if it actually works :)
>> 
>>
>>    
>>
>
>A quick test turns up that I need to change the line for self:capability
>to:
>
>allow openvpn_t self:capability { net_admin setgid setuid };
>
>To allow the daemon to switch to the nobody user.
>
>  
>
I added this to the Rawhide policy.   If you are going to be 
experimenting with targeted policy, you might want to
grab the one in rawhide, since this would have the proc_net stuff in 
it.  Basically FC3 is somewhat frozen for stability
purposes.  The new experimental stuff is in rawhide (Rewrite of 
can_network patches, additional proc_*_t ...)

Dan



From carlos.efr at mail.telepac.pt  Sat Dec 11 03:05:09 2004
From: carlos.efr at mail.telepac.pt (Carlos Rodrigues)
Date: Sat, 11 Dec 2004 03:05:09 +0000
Subject: selinux on JFS/ReiserFS
Message-ID: <41BA63E5.6070105@mail.telepac.pt>

Hi!

I understand that SELinux is not supported by JFS and ReiserFS. I was 
wondering if this is because these filesystems just can't handle it, 
fedora's kernel is missing some patches that provide this functionality, 
  or the support is actually there but it doesn't work properly/nobody 
trusts it?

Carlos Rodrigues



From davej at redhat.com  Sat Dec 11 03:07:58 2004
From: davej at redhat.com (Dave Jones)
Date: Fri, 10 Dec 2004 22:07:58 -0500
Subject: selinux on JFS/ReiserFS
In-Reply-To: <41BA63E5.6070105@mail.telepac.pt>
References: <41BA63E5.6070105@mail.telepac.pt>
Message-ID: <20041211030758.GD31829@redhat.com>

On Sat, Dec 11, 2004 at 03:05:09AM +0000, Carlos Rodrigues wrote:

 > I understand that SELinux is not supported by JFS and ReiserFS. I was 
 > wondering if this is because these filesystems just can't handle it, 
 > fedora's kernel is missing some patches that provide this functionality, 
 >  or the support is actually there but it doesn't work properly/nobody 
 > trusts it?

The necessary attribute support is missing from these filesystems.
There is some work happening upstream on reiserfs at least, so a
future version of the Fedora kernel would inherit those changes.

Usual caveats about reiserfs being unsupported apply.

		Dave



From dragoran at feuerpokemon.de  Sat Dec 11 07:09:30 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Sat, 11 Dec 2004 08:09:30 +0100
Subject: Why is k3b still at 0.11.14?
In-Reply-To: <20041210170316.GA31629@jadzia.bu.edu>
References: <41B9D094.60201@feuerpokemon.de>
	<20041210170316.GA31629@jadzia.bu.edu>
Message-ID: <41BA9D2A.8000807@feuerpokemon.de>

Matthew Miller schrieb:

>On Fri, Dec 10, 2004 at 05:36:36PM +0100, dragoran wrote:
>  
>
>>Why is k3b 0.11.17 still not in rawhide?
>>    
>>
>
>Because your rawhide mirror is out of date?
>
>
>  
>
sorry I found it....



From buildsys at redhat.com  Sat Dec 11 12:46:04 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 11 Dec 2004 07:46:04 -0500
Subject: rawhide report: 20041211 changes
Message-ID: <200412111246.iBBCk4r24738@porkchop.devel.redhat.com>

 

 
Updated Packages:

ghostscript-7.07-37
-------------------
* Fri Dec 10 2004 Tim Waugh <twaugh at redhat.com> 7.07-37
- Fixed missing return statement (bug #136757).

gimp-2:2.2-0.0.pre2.2
---------------------
* Fri Dec 10 2004 Nils Philippsen <nphilipp at redhat.com>
- use xsane plugin (un)install script if available

hal-0.4.2.cvs20041210-1
-----------------------
* Sun Dec 12 2004 David Zeuthen <davidz at redhat,com> 0.4.2.cvs20041210-1
- Snapshot from stable branch of upstream CVS

* Tue Oct 26 2004 David Zeuthen <davidz at redhat,com> 0.4.0-8
- Forgot to add some diffs in hal-0.4.0-pcmcia-net-support.patch

* Tue Oct 26 2004 David Zeuthen <davidz at redhat,com> 0.4.0-7
- Change default policy such that non-hotpluggable fixed disks are not
  added to the /etc/fstab file because a) ATARAID detection in hal is
  incomplete (e.g. RAID members from ATARAID controllers might be added
  to /etc/fstab); and b) default install wont corrupt multiboot 
  systems on fixed drives (#137072)

hpoj-0.91-11
------------
* Fri Dec 10 2004 Tim Waugh <twaugh at rehdat.com> 0.91-11
- Ship CUPS backend in the right directory to avoid the need for a symbolic
  link (bug #123589).

lvm2-2.00.30-1.0
----------------
* Fri Dec 10 2004 Alasdair Kergon <agk at redhat.com> - 2.00.30-1.0
- Additional debugging code.
- Some trivial man page corrections.

mtools-3.9.9-10
---------------
* Fri Dec 10 2004 Tim Waugh <twaugh at redhat.com> 3.9.9-10
- Fixed mpartition --help output (bug #65293).

net-snmp-5.2-1
--------------
* Tue Nov 30 2004 Radek Vokal <rvokal at redhat.com> 5.2-1
- net-snmp-5.2, patch clean-up

rpmdb-fedora-1:4-0.20041211
---------------------------

sane-backends-1.0.15-8
----------------------
* Fri Dec 10 2004 Tim Waugh <twaugh at redhat.com> 1.0.15-8
- Further small fixes to libusbscanner script.

* Fri Dec 03 2004 Tim Waugh <twaugh at redhat.com>
- Ship the correct libsane.usermap (part of bug #135802).

* Wed Dec 01 2004 Tim Waugh <twaugh at redhat.com>
- No longer need ep2400 patch.

selinux-policy-strict-1.19.12-2
-------------------------------
* Fri Dec 10 2004 Dan Walsh <dwalsh at redhat.com> 1.19-12-2
- Add support for winbindd from nscd

system-config-kickstart-2.5.18-1
--------------------------------
* Fri Dec 10 2004 Chris Lumens <clumens at redhat.com> - 2.5.18-1
- Get package group lists and their translations out of the comps.xml file
  instead of reying on a built-in (and out of date) list.
- Added an "Install Everything" button (#134679).

* Thu Dec 02 2004 Chris Lumens <clumens at redhat.com> - 2.5.17-1
- Remove obsolete dependency resolution radio buttons.

* Tue Nov 23 2004 Chris Lumens <clumens at redhat.com> - 2.5.16-1
- Fix display in indic locale (#138310) and (#138601)
- Monitor order (#127477)
- Translation of RAID message (#127687)
- Unencrypted root passwords (#134678)
- Broken nfs line parsing (#134681)

system-config-printer-0.6.119-1
-------------------------------
* Fri Dec 10 2004 Tim Waugh <twaugh at redhat.com>
- Purge magicfilter references (bug #45687).
- 0.6.119:
  - Purge magicfilter references (bug #45687).
  - Avoid traceback when there is no IEEE 1284 ID (bug #141430).

util-linux-2.12j-1
------------------
* Fri Dec 10 2004 Elliot Lee <sopwith at redhat.com> 2.12j-1
- Update to util-linux-2.12j



From buildsys at redhat.com  Sat Dec 11 15:53:57 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 11 Dec 2004 10:53:57 -0500
Subject: rawhide report: 20041206 changes
Message-ID: <200412111553.iBBFrvK28374@porkchop.devel.redhat.com>



From s.ellis at fastmail.co.uk  Sat Dec 11 21:15:21 2004
From: s.ellis at fastmail.co.uk (Stuart Ellis)
Date: Sat, 11 Dec 2004 21:15:21 +0000
Subject: setting up sudo(was : RFC: root/non-root bash prompts different
 colours?)
In-Reply-To: <20041210012036.GA5238@jadzia.bu.edu>
References: <20041209234631.GF27024@angus.ind.WPI.EDU>
	<20041210001925.4264.qmail@web8501.mail.in.yahoo.com>
	<20041210012036.GA5238@jadzia.bu.edu>
Message-ID: <1102799721.23495.210592720@webmail.messagingengine.com>

On Thu, 9 Dec 2004 20:20:36 -0500, "Matthew Miller" <mattdm at mattdm.org>
said:
> Try this in FC3:
> 
> 1) add yourself to the 'wheel' group
> 2) add the line "UGROUPS=wheel" to each file in 
>    /etc/sysconfig/console.apps
> 
> Now, you have sudo-like access to all of these programs -- you need to
> authenticate, but with your own password, not the root password. And for
> sudo itself, of course, uncomment the "%wheel ALL=(ALL) ALL" line in
> /etc/sudoers.
> 
> For BU Linux, we do this by default, and I've patched system-config-users
> to 
> include an easy way to add wheel group membership (and made it display in
> its own column in the normal view, so it's obvious who's got it).

This sounds like a very useful setup.  When documenting
this-requires-root commands I ended up using the format su -c 'command'
because I can't assume that sudo is in place, and I didn't want the
reader to have to think about logging in as root.  Since su and sudo
aren't exposed in the graphical interface or explained in a well-known
document ATM, it's probable that a lot of new users will login as root
to perform admin tasks unless/until they happen on something that gives
them clues.

FWIW, there is also a 'sys' group for CUPS.  In the default Fedora
config only members of that group can use the admin functions of the Web
interface.

> Furthermore, we set it up so all mail destined for root is sent to
> members
> of 'wheel', to increase the chances of it actually being seen by a human.

This would also be really useful.  I've never seen any documentation
that tells new users to alias root to get status mails.  I suspect that
many users don't know that these features exist.
--

Stuart Ellis
s.ellis at fastmail.co.uk



From jerone at gmail.com  Sun Dec 12 01:11:28 2004
From: jerone at gmail.com (Jerone Young)
Date: Sun, 12 Dec 2004 19:11:28 +1800
Subject: selinux on JFS/ReiserFS
In-Reply-To: <20041211030758.GD31829@redhat.com>
References: <41BA63E5.6070105@mail.telepac.pt>
	<20041211030758.GD31829@redhat.com>
Message-ID: <9f50a7a00412111711363c16ec@mail.gmail.com>

JFS support is upstream as well. Will be in 2.6.10-rc3-mm1 kernel.
There is a post on the offical SELinux mailing list with the JFS
kernel patch so SELinux will work.


On Fri, 10 Dec 2004 22:07:58 -0500, Dave Jones <davej at redhat.com> wrote:
> On Sat, Dec 11, 2004 at 03:05:09AM +0000, Carlos Rodrigues wrote:
> 
>  > I understand that SELinux is not supported by JFS and ReiserFS. I was
>  > wondering if this is because these filesystems just can't handle it,
>  > fedora's kernel is missing some patches that provide this functionality,
>  >  or the support is actually there but it doesn't work properly/nobody
>  > trusts it?
> 
> The necessary attribute support is missing from these filesystems.
> There is some work happening upstream on reiserfs at least, so a
> future version of the Fedora kernel would inherit those changes.
> 
> Usual caveats about reiserfs being unsupported apply.
> 
>                 Dave
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From buildsys at redhat.com  Sun Dec 12 13:02:23 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 12 Dec 2004 08:02:23 -0500
Subject: rawhide report: 20041212 changes
Message-ID: <200412121302.iBCD2Nf28484@porkchop.devel.redhat.com>

 

 
Updated Packages:




From fedora at wir-sind-cool.org  Sun Dec 12 20:22:15 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sun, 12 Dec 2004 21:22:15 +0100
Subject: First rpm packaging attempt: OpenMOIV
In-Reply-To: <d5ad214704120902256bc690ec@mail.gmail.com>
References: <d5ad214704120902256bc690ec@mail.gmail.com>
Message-ID: <20041212212215.03acefd9.fedora@wir-sind-cool.org>

On Thu, 9 Dec 2004 11:25:17 +0100, Gianluca Sforna wrote:

> I finally managed to file in bugzilla.fedura.us my first rpm package.
> 
> https://bugzilla.fedora.us/show_bug.cgi?id=2329
> 
> Is there any other additional step I should take now??

Since nobody else has replied yet, the documentation in the Wiki
recommends that packagers exchange reviews with other packages.

The process of posting utilisable votes/approvals is quite informal,
except that every approval must be GPG clearsigned and contain at
least the MD5 checksum of the reviewed src.rpm and preferably the
checksum of the included source archive. This is explained here:

http://fedoraproject.org/wiki/index.cgi/PackageSubmissionQAPolicy#review

-- 
Some fun stats about bugzilla.fedora.us: On average, a ticket has 8
comments. Only 3% of all tickets have more comments. 11.2% of all
tickets have more than 20 comments. The highest numbers of comments
per ticket seen so far: 162 110 92 90 78 76 74 71 69 62



From riel at redhat.com  Sun Dec 12 23:26:20 2004
From: riel at redhat.com (Rik van Riel)
Date: Sun, 12 Dec 2004 18:26:20 -0500 (EST)
Subject: Xen in rawhide
In-Reply-To: <20041209164742.GA24437@osiris.silug.org>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
Message-ID: <Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>

On Thu, 9 Dec 2004, Steven Pritchard wrote:
> On Thu, Dec 09, 2004 at 04:53:58PM +0100, Florian La Roche wrote:
>> I've seen rpm packages on http://people.redhat.com/riel/
>
> That's exactly what I was looking for.  Thanks.  :-)
>
> Are these other bits likely to be added to rawhide any time soon?

I'm working on it.

Note that for some reason the network bridging to the unprivileged
domains isn't working right on my Xen test system, I suspect I must
have set a config option wrong somewhere in the kernel RPM.

I want to try and get the most important things fixed and Xen into
rawhide before the christmas holidays, so people get an opportunity
to really play with it.

Any help in getting the network routing to unprivileged domains
working again is appreciated.  Hmmm, maybe I should publish my
TODO list ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



From dpaun at rogers.com  Mon Dec 13 01:40:15 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Sun, 12 Dec 2004 20:40:15 -0500
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
Message-ID: <20041213014015.GC5747@rogers.com>

On Sun, Dec 12, 2004 at 06:26:20PM -0500, Rik van Riel wrote:
> Any help in getting the network routing to unprivileged domains
> working again is appreciated.  Hmmm, maybe I should publish my
> TODO list ?

Yes, that would be nice. Having a working Xen setup would be
more then cool.

-- 
Dimi.



From steve at silug.org  Mon Dec 13 04:07:59 2004
From: steve at silug.org (Steven Pritchard)
Date: Sun, 12 Dec 2004 22:07:59 -0600
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
Message-ID: <20041213040759.GA9285@osiris.silug.org>

On Sun, Dec 12, 2004 at 06:26:20PM -0500, Rik van Riel wrote:
> I want to try and get the most important things fixed and Xen into
> rawhide before the christmas holidays, so people get an opportunity
> to really play with it.

In the mean time, is there any chance you could run createrepo on
people.redhat.com/riel/?  :-)

> Any help in getting the network routing to unprivileged domains
> working again is appreciated.  Hmmm, maybe I should publish my
> TODO list ?

About the best I can do is help with testing, but the TODO list would
be interesting anyway.

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From riel at redhat.com  Mon Dec 13 04:08:16 2004
From: riel at redhat.com (Rik van Riel)
Date: Sun, 12 Dec 2004 23:08:16 -0500 (EST)
Subject: Xen in rawhide
In-Reply-To: <20041213014015.GC5747@rogers.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
Message-ID: <Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>

On Sun, 12 Dec 2004, Dimitrie O. Paun wrote:
> On Sun, Dec 12, 2004 at 06:26:20PM -0500, Rik van Riel wrote:
>> Any help in getting the network routing to unprivileged domains
>> working again is appreciated.  Hmmm, maybe I should publish my
>> TODO list ?
>
> Yes, that would be nice. Having a working Xen setup would be
> more then cool.

Well, at this stage of the project I've only got few items on
my TODO list:

- figure out why network routing to unprivileged domains
   does not work right (probably a config option)
- teach grubby to make xen + xenolinux bootable entries
   in grub.conf
- get Xen packages into rawhide
- talk with the installer people, to figure out the best
   way of allowing anaconda to install a virtual host

Once these things are done, IMHO the Xen development should
happen in the upstream Xen community, which is where I hope
to help out.

One of the things I would like to do there is work on the
light-weight Xen daemon x2d2, which should allow Fedora
developers to run a lighter-weight guest 0, with more memory
remaining for their unprivileged guests - good for developers
who want to run every version of Fedora on their build system. ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



From dpaun at rogers.com  Mon Dec 13 05:05:24 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 13 Dec 2004 00:05:24 -0500
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
Message-ID: <20041213050524.GA6919@rogers.com>

On Sun, Dec 12, 2004 at 11:08:16PM -0500, Rik van Riel wrote:
> One of the things I would like to do there is work on the
> light-weight Xen daemon x2d2, which should allow Fedora
> developers to run a lighter-weight guest 0, with more memory
> remaining for their unprivileged guests - good for developers
> who want to run every version of Fedora on their build system. ;)

Another cool thing would be to integrate Xen with Linux to the
point where it can *dynamically* detect if it's running under
Xen or not, and run the appropriate version.

I was told that a simple way (and quite effective from a practical
standpoint I might add) of doing so would be to simply have two
versions of the kernel (the regular i386 build and the xen build)
packaged together, and somehow pick the right one to run at boot
time.

That would be a nice and easy way to handle installation. It would
also be easier to support, because you know the two versions are
in lockstep, so support should be simpler.

-- 
Dimi. 



From buildsys at redhat.com  Mon Dec 13 12:57:08 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 13 Dec 2004 07:57:08 -0500
Subject: rawhide report: 20041213 changes
Message-ID: <200412131257.iBDCv8Q23671@porkchop.devel.redhat.com>

 

 
Updated Packages:

audit-0.5.5-1
-------------
* Fri Dec 10 2004 Steve Grubb <sgrubb at redhat.com> 0.5.5-1
- New version

dbh-1:1.0.20-1
--------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 1:1.0.20-1
- update to 1.0.20

kdebase-6:3.3.2-0.1
-------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.1
- update to 3.3.2
- remove unneeded kdebase-3.3.1-cvs.patch, kdebase-3.3.1-sidebar.patch
- add CVS patch, that fixes a konsole crash

kdepim-6:3.3.2-0.2
------------------
* Sat Dec 04 2004 Than Ngo <than at redhat.com> 3.3.2-0.2
- add CVS patch to fix kmail crash when deleting mails in a folder, #141457

* Fri Dec 03 2004 Than Ngo <than at redhat.com> 3.3.2-0.1
- update to 3.3.2
- get rid of the kdepim-3.3.1-cvs.patch, kdepim-3.3.0-holiday.patch,
  both are included in 3.3.2

kernel-2.6.9-1.1032_FC4
-----------------------
* Sun Dec 12 2004 Dave Jones <davej at redhat.com>
- fix false ECHILD result from wait* with zombie group leader.

* Sat Dec 11 2004 Dave Jones <davej at redhat.com>
- Workaround broken pci posting in AGPGART.
- Compile 686 kernel tuned for pentium4.
  | Needs benchmarking across various CPUs under
  | various workloads to find out if its worth keeping.
- Make sure VC resizing fits in s16.

* Fri Dec 10 2004 Dave Jones <davej at redhat.com>
- Prevent block device queues from being shared in viocd. (#139018)
- Libata updates. (#132848, #138405)
- aacraid: remove aac_handle_aif (#135527)
- fix uninitialized variable in waitid(2). (#142505)
- Fix CMSG validation checks wrt. signedness.
- Fix memory leak in ip_conntrack_ftp
- [IPV4]: Do not leak IP options.
- ppc64: Align PACA buffer for hypervisor's use. (#141817)
- ppc64: Indicate that the veth link is always up. (#135402)
- ppc64: Quiesce OpenFirmware stdin device at boot. (#142009)
- SELinux: Fix avc_node_update oops. (#142353)
- Fix CCISS ioctl return code.
- Make ppc64's pci_alloc_consistent() conform to documentation. (#140047)
- Enable EDD
- Enable ETH1394. (#138497)
- Workaround E1000 post-maturely writing back to TX descriptors. (#133261)
- Fix the previous E1000 errata workaround.
- Several IDE fixes from 2.6.9-ac
- vm pageout throttling. (#133858)
- Fix Tux from oopsing. (#140918)
- Fix Tux/SELinux incompatability (#140916)
- Fix Tux/IPV6 problem. (#140916)
- ide: Fix possible oops on boot.
- Make spinlock debugging panic instead of printk.
- Update Emulex lpfc driver to 8.0.16
- Selected patches from 2.6.9-ac12
- ppc64: Fix inability to find space for TCE table (#138844)
- Fix compat fcntl F_GETLK{,64} (#141680)
- blkdev_get_blocks(): handle eof
- Another card reader for the whitelist. (#134094)
- Disable tiglusb module. (#142102)
- E1000 64k-alignment fix. (#140047)
- Disable tiglusb module. (#142102)
- ID updates for cciss driver.
- Fix overflows in USB Edgeport-IO driver. (#142258)
- Fix wrong TASK_SIZE for 32bit processes on x86-64. (#141737)
- Fix ext2/ext3 xattr/mbcache race. (#138951)
- Fix bug where __getblk_slow can loop forever when pages are partially mapped. (#140424)
- Add missing cache flushes in agpgart code.

libxfce4mcs-4.1.99.1-1
----------------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 4.1.99.1-1
- update to 4.2 rc1

libxfce4util-4.1.99.1-1
-----------------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 4.1.99.1-1
- update to 4.2 rc1

libxfcegui4-4.1.99.1-1
----------------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 4.1.99.1-1
- update to 4.2 rc1

lvm2-2.00.31-1.0
----------------
* Sun Dec 12 2004 Alasdair Kergon <agk at redhat.com> - 2.00.31-1.0
- Fix pvcreate install issues.

m4-1.4.2-1
----------
* Sun Dec 12 2004 Miloslav Trmac <mitr at redhat.com> - 1.4.2-1
- Update to m4-1.4.2

perl-PDL-2.4.1-8
----------------
* Sun Dec 12 2004 Miloslav Trmac <mitr at redhat.com> - 2.4.1-8
- Fix more bugs on 64-bit platforms
- BuildRequires: gsl-devel

rpmdb-fedora-1:4-0.20041213
---------------------------

xfce-mcs-manager-4.1.99.1-1
---------------------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 4.1.99.1-1
- update to 4.2 rc1

xfce-mcs-plugins-4.1.99.1-1
---------------------------
* Wed Dec 08 2004 Than Ngo <than at redhat.com> 4.1.99.1-1
- update to 4.2 rc1



From P at draigBrady.com  Mon Dec 13 15:01:08 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Mon, 13 Dec 2004 15:01:08 +0000
Subject: ubuntu boot poster challenge
Message-ID: <41BDAEB4.2080704@draigBrady.com>

Some very interesting optimization work done
by Daniel Stone and Thom May at the ubuntu conference.
In summary they halved the original boot of 60s.

http://www.fooishbar.org/blog//tech/ubuntu/fastBootMiniBoF-2004-12-09-13-45.html
http://www.planetarytramp.net/bootchart/bootchart-20041210-1934.png

P?draig.



From ziga.mahkovec at klika.si  Mon Dec 13 15:23:54 2004
From: ziga.mahkovec at klika.si (Ziga Mahkovec)
Date: Mon, 13 Dec 2004 16:23:54 +0100
Subject: ubuntu boot poster challenge
In-Reply-To: <41BDAEB4.2080704@draigBrady.com>
References: <41BDAEB4.2080704@draigBrady.com>
Message-ID: <1102951434.3295.54.camel@serenity.klika.si>

On Mon, 2004-12-13 at 15:01 +0000, P at draigBrady.com wrote:
> Some very interesting optimization work done
> by Daniel Stone and Thom May at the ubuntu conference.
> In summary they halved the original boot of 60s.

Looks like some healthy competition is along the way:

http://www.netsplit.com/blog/tech/the_race_to_x.html

-- 
Ziga



From daly at rio.sci.ccny.cuny.edu  Mon Dec 13 15:06:30 2004
From: daly at rio.sci.ccny.cuny.edu (Tim Daly)
Date: Mon, 13 Dec 2004 10:06:30 -0500
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <20041209234631.GF27024@angus.ind.WPI.EDU> (cra@WPI.EDU)
References: <20041208170302.GI5322@redhat.com>
	<7ebb24d104120810001239d037@mail.gmail.com>
	<1102587189.22606.73.camel@localhost.localdomain>
	<200412092342.27818.ronny-vlug@vlugnet.org>
	<20041209234631.GF27024@angus.ind.WPI.EDU>
Message-ID: <200412131506.iBDF6US10030@rio.sci.ccny.cuny.edu>

Methinks you need to stop trying to "mother" the users.

If you share a computer then it is potentially a disaster to destroy 
a machine by making a mistake as root. However if it is a single-user
system and the user loses his machine because of mistyping then there
is an educational moment happening. Besides learning that typos are
more costly as root they learn that backups are sometimes useful.

root.



From sam at progeny.com  Mon Dec 13 16:57:15 2004
From: sam at progeny.com (Sam Hart)
Date: Mon, 13 Dec 2004 11:57:15 -0500
Subject: FC3 install and grub failure on HP Proliant DL380, kernel issue?
Message-ID: <1102957035.11866.154.camel@prickly-pear.progeny.com>

When installing FC3 on an HP Proliant DL380 w/ HP SmartArray 5i
controller grub fails to install successfully (leaving the system unable
to boot). In essence, when Anaconda is nearly finished and gets to the
grub install, grub fails and Anaconda does not report it (instead it
gives you the "Reboot" screen saying installation is complete).

However, by switching the proper console (5, as I recall) you can see
the actual error:
http://hackers.progeny.com/~sam/ZZ-Images/hp_bug.png

As you can see, grub identifies the filesystem type, but cannot actually
read any files from it (there it is failing to read stage1, but I have
verified it can't read any files on the system).

Now, I haven't filed this as a bug in Bugzilla yet because this seems to
be a problem well beyond just FC3. I have verified that other distros
exhibit the same behavior.

Also, I have isolated it down to some sort of kernel issue. In checking
with some custom FC2-based distros, I've verified that the problem only
occurs with kernel versions after 2.6.5. I have tried both stock and
patched Fedora kernels.

Has anyone else encountered this problem? Note that if you install FC2
on the machine and then upgrade, everything works except for future Grub
installs ;-) To see the bug the installer must be running on a kernel
newer than 2.6.5.

Since this is not really a FC3 bug, does it even have a place in RH's
bugzilla? FWIW, I would wager that RHEL would have the same problem,
even though I have not verified it myself.

BTW, since this is grub-legacy, I'm yet to find anyone in the grub
community who's willing to diagnose it ;-)

Here are the outputs of dmesg/lspci from the machine after a successful
FC2 install:
http://hackers.progeny.com/~sam/ZZ-Docs/dmesg.out
http://hackers.progeny.com/~sam/ZZ-Docs/lspci.out

-- 
                                            '''''''''''''''''''''''''
.O.                                         Sam Hart, sam at progeny.com
..O                                        Progeny Linux Systems, Inc
OOO                                         <http://www.progeny.com/>



From rahulsundaram at yahoo.co.in  Mon Dec 13 17:03:33 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Mon, 13 Dec 2004 09:03:33 -0800 (PST)
Subject: RFC: root/non-root bash prompts different colours?
In-Reply-To: <200412131506.iBDF6US10030@rio.sci.ccny.cuny.edu>
Message-ID: <20041213170333.64418.qmail@web8508.mail.in.yahoo.com>


--- Tim Daly <daly at rio.sci.ccny.cuny.edu> wrote:

> Methinks you need to stop trying to "mother" the
> users.

the discussion is already over. nobody is trying to
"mother" anyone here. please stop being rude.


> 
> If you share a computer then it is potentially a
> disaster to destroy 
> a machine by making a mistake as root. However if it
> is a single-user
> system and the user loses his machine because of
> mistyping then there
> is an educational moment happening.

no. its still a disaster




=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 



From ottohaliburton at comcast.net  Mon Dec 13 18:26:01 2004
From: ottohaliburton at comcast.net (Otto Haliburton)
Date: Mon, 13 Dec 2004 12:26:01 -0600
Subject: FC3 install and grub failure on HP Proliant DL380, kernel issue?
In-Reply-To: <1102957035.11866.154.camel@prickly-pear.progeny.com>
References: <1102957035.11866.154.camel@prickly-pear.progeny.com>
Message-ID: <1102962361.4816.11.camel@c515816-a>

On Mon, 2004-12-13 at 11:57 -0500, Sam Hart wrote:
> When installing FC3 on an HP Proliant DL380 w/ HP SmartArray 5i
> controller grub fails to install successfully (leaving the system unable
> to boot). In essence, when Anaconda is nearly finished and gets to the
> grub install, grub fails and Anaconda does not report it (instead it
> gives you the "Reboot" screen saying installation is complete).
> 
> However, by switching the proper console (5, as I recall) you can see
> the actual error:
> http://hackers.progeny.com/~sam/ZZ-Images/hp_bug.png
> 
> As you can see, grub identifies the filesystem type, but cannot actually
> read any files from it (there it is failing to read stage1, but I have
> verified it can't read any files on the system).
> 
> Now, I haven't filed this as a bug in Bugzilla yet because this seems to
> be a problem well beyond just FC3. I have verified that other distros
> exhibit the same behavior.
> 
> Also, I have isolated it down to some sort of kernel issue. In checking
> with some custom FC2-based distros, I've verified that the problem only
> occurs with kernel versions after 2.6.5. I have tried both stock and
> patched Fedora kernels.
> 
> Has anyone else encountered this problem? Note that if you install FC2
> on the machine and then upgrade, everything works except for future Grub
> installs ;-) To see the bug the installer must be running on a kernel
> newer than 2.6.5.
> 
> Since this is not really a FC3 bug, does it even have a place in RH's
> bugzilla? FWIW, I would wager that RHEL would have the same problem,
> even though I have not verified it myself.
> 
> BTW, since this is grub-legacy, I'm yet to find anyone in the grub
> community who's willing to diagnose it ;-)
> 
> Here are the outputs of dmesg/lspci from the machine after a successful
> FC2 install:
> http://hackers.progeny.com/~sam/ZZ-Docs/dmesg.out
> http://hackers.progeny.com/~sam/ZZ-Docs/lspci.out
> 
> -- 
>                                             '''''''''''''''''''''''''
> .O.                                         Sam Hart, sam at progeny.com
> ..O                                        Progeny Linux Systems, Inc
> OOO                                         <http://www.progeny.com/>
> 
It failed to read the file type.  I'm confused though you see grub gets
installed in the installation process and it is there that stage1 is
written to the MBR.  so when the boot occurs is when stage1 is executed
to either read stage1.5 or stage2.  I'm not sure what you have here.
And your exclamation is not clear to me.  I have not ever gotten this
sort of thing with GRUB, but it maybe an incompatibility with your
computer.  But I can see where you might have problems having people
diagnose it because, your explanation and the info supplied doesn't come
close to anything I have seen with grub.

The first question I have is that you seem to be suppling info from a
grub-install.  Is that true?

Anyway, Try to give a clearer picture including the command you are
executing to get the info you are suppling.
-- 
Otto Haliburton <ottohaliburton at comcast.net>



From sam at progeny.com  Mon Dec 13 19:08:42 2004
From: sam at progeny.com (Sam Hart)
Date: Mon, 13 Dec 2004 14:08:42 -0500
Subject: FC3 install and grub failure on HP Proliant DL380, kernel issue?
In-Reply-To: <1102962361.4816.11.camel@c515816-a>
References: <1102957035.11866.154.camel@prickly-pear.progeny.com>
	<1102962361.4816.11.camel@c515816-a>
Message-ID: <1102964922.11842.175.camel@prickly-pear.progeny.com>

On Mon, 2004-12-13 at 12:26 -0600, Otto Haliburton wrote:
> It failed to read the file type.  I'm confused though you see grub gets
> installed in the installation process and it is there that stage1 is
> written to the MBR.

This is the end of the installation process. Here grub never is written
to the MBR.

>   so when the boot occurs is when stage1 is executed
> to either read stage1.5 or stage2.  I'm not sure what you have here.
> And your exclamation is not clear to me.  I have not ever gotten this
> sort of thing with GRUB, but it maybe an incompatibility with your
> computer.  But I can see where you might have problems having people
> diagnose it because, your explanation and the info supplied doesn't come
> close to anything I have seen with grub.

This occurs during installation. It occurs only on the hardware I
mentioned, namely:
 * HP Proliant DL380
 * HP SmartArray 5i RAID controller card

When you install FC3 on this hardware (or any Linux distro using a
kernel later than 2.6.5) grub fails to be able to read the stage1 file
from the disk when writing it to the MBR. Thus, grub is not installed,
and the system will not boot.

Specifically on FC3, Anaconda does not mention this failure. Instead,
Anaconda finishes its duties and reports that the install was successful
(ejecting the CD, and waiting for the user to select "Reboot").

Now I know this is a bizarre problem. I have gone back and checked and
have discovered that when this stopped working was immediately after
kernel 2.6.5. I am not sure how much clearer I can make it.

> The first question I have is that you seem to be suppling info from a
> grub-install.  Is that true?

Like I said before, this is not grub-install nor any user-typed command.
This is Anaconda. This is during the FC3 installer.

After Anaconda finishes installing the various RPMs on the machine, and
after it finishes setting up various configuration files on the machine,
Anaconda calls grub in batch mode. There, it passes the following to
grub:
  root (hd0,0)
  install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf

It is here that the failure occurs. After "root (hd0,0)", grub responds
with:
  Filesystem type is ext2fs, partition type is 0x83

(which tells me that grub can, at least, identify the file system).
After the "install" line, grub responds:
  Error 2: Bad file or directory type

So grub is able to determine the partition type, but it cannot actually
read any files from that partition (here it is failing on "stage1").

> Anyway, Try to give a clearer picture including the command you are
> executing to get the info you are suppling.

As I said in my original post (and in the subject of the message) this
is during the FC3 install itself. I am not executing any command. This
is the FC3 Anaconda install.

I am pretty certain that it is a kernel issue, like I said before. The
reason I am certain is we have a custom FC2 (soon to be FC3) based
distro which needs to run on this hardware. In essence, I have built FC2
installers using all of the updated FC2 kernels, and this problem only
occurs in kernels after 2.6.5. Since FC3 CD install is 2.6.9, FC3 has
the same problem.

BTW, the image I posted (and the above error) is from a stock FC3
install.

I know it's complicated, feel free to message me (criswell on
freenode.net, criswell4069 on Yahoo! and AIM) for more info.

-- 
                                            '''''''''''''''''''''''''
.O.                                         Sam Hart, sam at progeny.com
..O                                        Progeny Linux Systems, Inc
OOO                                         <http://www.progeny.com/>



From mike at navi.cx  Mon Dec 13 20:40:26 2004
From: mike at navi.cx (Mike Hearn)
Date: Mon, 13 Dec 2004 20:40:26 +0000
Subject: Xen in rawhide
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
Message-ID: <pan.2004.12.13.20.40.26.344013@navi.cx>

On Sun, 12 Dec 2004 23:08:16 -0500, Rik van Riel wrote:
> good for developers
> who want to run every version of Fedora on their build system. ;)

Useful definitely, but if this is going to become some sort of semi-formal
recommendation then I'd be pretty disappointed. You shouldn't need a VM
and lots of Fedora installs to produce RPMs!



From rdieter at math.unl.edu  Mon Dec 13 20:45:14 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 13 Dec 2004 14:45:14 -0600 (CST)
Subject: Xen in rawhide
In-Reply-To: <pan.2004.12.13.20.40.26.344013@navi.cx>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
	<pan.2004.12.13.20.40.26.344013@navi.cx>
Message-ID: <Pine.LNX.4.61.0412131444530.16562@math.unl.edu>

On Mon, 13 Dec 2004, Mike Hearn wrote:

> On Sun, 12 Dec 2004 23:08:16 -0500, Rik van Riel wrote:
>> good for developers
>> who want to run every version of Fedora on their build system. ;)
>
> Useful definitely, but if this is going to become some sort of semi-formal
> recommendation then I'd be pretty disappointed. You shouldn't need a VM
> and lots of Fedora installs to produce RPMs!

Not only to build, but also to *test* them.  (-:

-- Rex



From kyrre at solution-forge.net  Mon Dec 13 20:46:17 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Mon, 13 Dec 2004 21:46:17 +0100
Subject: Status on that intel GFX chip?
Message-ID: <1102970777.27996.8.camel@kyrre>

Hello

I just wonder, and i know it has been brought up a zillion times - but
what are the current status of the intel gfx (i815?) xorg driver? Any
updates (rpms) that could be easily pushed into my net via admin-script?

The vesa driver works - but it refuses to do anything more than a bare
minimum resolution, and the intel driver has some... funny... side
effects. Not anything i would like to expose my users to, really

Kyrre



From turnip at turnipspatch.com  Mon Dec 13 20:59:15 2004
From: turnip at turnipspatch.com (Jonathan Leighton [Turnip])
Date: Mon, 13 Dec 2004 20:59:15 +0000
Subject: Self-Introduction: Jonathan Leighton
Message-ID: <41BE02A3.7050302@turnipspatch.com>

Hi,

I'm Jonathan David Leighton. I live near Reading in England. Currently 
I'm in the final year of compulsary education, which means I will be 
taking my GCSE exams next summer. I go to Theale Green Community School, 
their (terrible) website is here: http://www.thealegreen.org.uk/.

My main purpose here is to get Inkscape (http://inkscape.org/) 
published. I'm not interested in doing QA or anything else currently, 
but I may be in the future.

I've not worked on any open source projects (yet?). I'm not a programmer 
(also may change in the future), my main interests lie in web 
development (you might want to look at my website, 
http://turnipspatch.com/). I'm fluent in XHTML, CSS and JavaScript. I'm 
familiar with XML (just the concepts, I haven't actually had much use 
for it yet), and I'm starting to use PHP more and more (I started with 
using ASP, but PHP is quite obviously 10 times better). There is 
absolutely no reason why you should trust me, but if nobody trusted 
anybody then Open Source software wouldn't work. That said, I am aware 
that trust is earned rather than given.

Here is my textbook-style deliverance of my GPG fingerprint:

[turnip at localhost ~]$ gpg --fingerprint 1DA5B286B9A48D3A
pub  1024D/B9A48D3A 2004-12-13 Jonathan Leighton <turnip at turnipspatch.com>
     Key fingerprint = A8DB 456C 4952 6432 6AD8  8356 1DA5 B286 B9A4 8D3A
sub  1024g/02351BC6 2004-12-13

Cheers

-- 
Regards,
Jonathan Leighton [Turnip]

Get Thunderbird - Reclaim Your Inbox
http://www.mozilla.org/products/thunderbird



From fedora at wir-sind-cool.org  Mon Dec 13 21:11:21 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 13 Dec 2004 22:11:21 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <41BE02A3.7050302@turnipspatch.com>
References: <41BE02A3.7050302@turnipspatch.com>
Message-ID: <20041213221121.2f66d6a7.fedora@wir-sind-cool.org>

On Mon, 13 Dec 2004 20:59:15 +0000, Jonathan Leighton [Turnip] wrote:

> I'm Jonathan David Leighton. I live near Reading in England. Currently 
> I'm in the final year of compulsary education, which means I will be 
> taking my GCSE exams next summer. I go to Theale Green Community School, 
> their (terrible) website is here: http://www.thealegreen.org.uk/.
> 
> My main purpose here is to get Inkscape (http://inkscape.org/) 
> published. I'm not interested in doing QA or anything else currently, 
> but I may be in the future.

FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
version 0.40.

-- 
Some fun stats about bugzilla.fedora.us: On average, a ticket has 8
comments. 32.8% of all tickets have more comments. 8.9% of all tickets
have more than 20 comments. The highest numbers of comments per ticket
seen so far: 162 110 92 90 78 76 74 71 69 62



From turnip at turnipspatch.com  Mon Dec 13 21:21:14 2004
From: turnip at turnipspatch.com (Jonathan Leighton [Turnip])
Date: Mon, 13 Dec 2004 21:21:14 +0000
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
Message-ID: <41BE07CA.3020008@turnipspatch.com>

Michael Schwendt wrote:

>On Mon, 13 Dec 2004 20:59:15 +0000, Jonathan Leighton [Turnip] wrote:
>
>  
>
>>I'm Jonathan David Leighton. I live near Reading in England. Currently 
>>I'm in the final year of compulsary education, which means I will be 
>>taking my GCSE exams next summer. I go to Theale Green Community School, 
>>their (terrible) website is here: http://www.thealegreen.org.uk/.
>>
>>My main purpose here is to get Inkscape (http://inkscape.org/) 
>>published. I'm not interested in doing QA or anything else currently, 
>>but I may be in the future.
>>    
>>
>
>FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
>version 0.40.
>
Really? Could you give me a link please? Maybe I'm looking in the wrong 
places, but I can't find any packages greater than version 0.39.

Thanks

-- 
Regards,
Jonathan Leighton [Turnip]

Get Thunderbird - Reclaim Your Inbox
http://www.mozilla.org/products/thunderbird



From riel at redhat.com  Mon Dec 13 21:27:51 2004
From: riel at redhat.com (Rik van Riel)
Date: Mon, 13 Dec 2004 16:27:51 -0500 (EST)
Subject: Xen in rawhide
In-Reply-To: <pan.2004.12.13.20.40.26.344013@navi.cx>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
	<pan.2004.12.13.20.40.26.344013@navi.cx>
Message-ID: <Pine.LNX.4.61.0412131627050.22945@chimarrao.boston.redhat.com>

On Mon, 13 Dec 2004, Mike Hearn wrote:

> Useful definitely, but if this is going to become some sort of 
> semi-formal recommendation then I'd be pretty disappointed. You 
> shouldn't need a VM and lots of Fedora installs to produce RPMs!

A chroot is enough for building.  As Rex Dieter pointed out,
you may need more than a chroot for testing though, especially
when testing daemons that listen on network ports, or when
testing untrusted programs.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



From riel at redhat.com  Mon Dec 13 21:28:38 2004
From: riel at redhat.com (Rik van Riel)
Date: Mon, 13 Dec 2004 16:28:38 -0500 (EST)
Subject: Xen in rawhide
In-Reply-To: <20041213050524.GA6919@rogers.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
	<20041213050524.GA6919@rogers.com>
Message-ID: <Pine.LNX.4.61.0412131628130.22945@chimarrao.boston.redhat.com>

On Mon, 13 Dec 2004, Dimitrie O. Paun wrote:

> I was told that a simple way (and quite effective from a practical
> standpoint I might add) of doing so would be to simply have two
> versions of the kernel (the regular i386 build and the xen build)
> packaged together, and somehow pick the right one to run at boot
> time.

The user can choose the right one at boot time, from
the boot loader menu.  Or is this not what you mean ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



From rjune at bravegnuworld.com  Mon Dec 13 21:41:14 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Mon, 13 Dec 2004 16:41:14 -0500
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
Message-ID: <200412131641.18303.rjune@bravegnuworld.com>

> FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> version 0.40.
Really? I'm running fc3 and would love to have inkscape RPMs from Fedora 
Extras. where can I download them?
-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041213/655e9b2f/attachment.sig>

From rahulsundaram at yahoo.co.in  Mon Dec 13 21:42:52 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Mon, 13 Dec 2004 13:42:52 -0800 (PST)
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412131627050.22945@chimarrao.boston.redhat.com>
Message-ID: <20041213214252.3191.qmail@web8504.mail.in.yahoo.com>

Hi


> A chroot is enough for building.  As Rex Dieter
> pointed out,
> you may need more than a chroot for testing though,
> especially
> when testing daemons that listen on network ports,
> or when
> testing untrusted programs.

is there anyway we can improve existing practises to
avoid this. Mike?


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From kyrre at solution-forge.net  Mon Dec 13 21:46:43 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Mon, 13 Dec 2004 22:46:43 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <200412131641.18303.rjune@bravegnuworld.com>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<200412131641.18303.rjune@bravegnuworld.com>
Message-ID: <1102974402.27996.10.camel@kyrre>

man, 13.12.2004 kl. 22.41 skrev Richard June:
> > FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> > version 0.40.
> Really? I'm running fc3 and would love to have inkscape RPMs from Fedora 
> Extras. where can I download them?

There is no extras for fc3 yet... Who knows when there will be.



From rjune at bravegnuworld.com  Mon Dec 13 21:57:54 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Mon, 13 Dec 2004 16:57:54 -0500
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102974402.27996.10.camel@kyrre>
References: <41BE02A3.7050302@turnipspatch.com>
	<200412131641.18303.rjune@bravegnuworld.com>
	<1102974402.27996.10.camel@kyrre>
Message-ID: <200412131657.57658.rjune@bravegnuworld.com>

On Monday 13 December 2004 16:46, Kyrre Ness Sjobak wrote:
> man, 13.12.2004 kl. 22.41 skrev Richard June:
> > > FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> > > version 0.40.
> >
> > Really? I'm running fc3 and would love to have inkscape RPMs from Fedora
> > Extras. where can I download them?
>
> There is no extras for fc3 yet... Who knows when there will be.
Right now I'm betting slightly after FC4 is released.

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041213/af2a61be/attachment.sig>

From fedora at wir-sind-cool.org  Mon Dec 13 22:00:29 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 13 Dec 2004 23:00:29 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <41BE07CA.3020008@turnipspatch.com>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
Message-ID: <20041213230029.7c76afd5.fedora@wir-sind-cool.org>

On Mon, 13 Dec 2004 21:21:14 +0000, Jonathan Leighton [Turnip] wrote:

> >FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> >version 0.40.
> >
> Really?

Yes, really.

> Could you give me a link please? Maybe I'm looking in the wrong 
> places, but I can't find any packages greater than version 0.39.

That is is because of this:
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html

This is also the reason why fedora.us does not provide any packages for
FC3. No rebuilds for FC3 have been planned or started. But package
development has not come to a complete halt. Though the current
situation is a major hindrance for all package developers and
contributors at fedora.us.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3
loadavg: 2.45 2.24 2.13



From jos at xos.nl  Mon Dec 13 22:06:37 2004
From: jos at xos.nl (Jos Vos)
Date: Mon, 13 Dec 2004 23:06:37 +0100
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412131627050.22945@chimarrao.boston.redhat.com>;
	from riel@redhat.com on Mon, Dec 13, 2004 at 04:27:51PM -0500
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
	<pan.2004.12.13.20.40.26.344013@navi.cx>
	<Pine.LNX.4.61.0412131627050.22945@chimarrao.boston.redhat.com>
Message-ID: <20041213230637.B8872@xos037.xos.nl>

On Mon, Dec 13, 2004 at 04:27:51PM -0500, Rik van Riel wrote:

> On Mon, 13 Dec 2004, Mike Hearn wrote:
> 
> > Useful definitely, but if this is going to become some sort of 
> > semi-formal recommendation then I'd be pretty disappointed. You 
> > shouldn't need a VM and lots of Fedora installs to produce RPMs!
> 
> A chroot is enough for building.  As Rex Dieter pointed out,
> you may need more than a chroot for testing though, especially
> when testing daemons that listen on network ports, or when
> testing untrusted programs.

Yes, a chroot *should* be enough, although I'm personally to
paranoid to trust that.  But even when chroot'ing, you have an OS
install for every "target environment".

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From giallu at gmail.com  Mon Dec 13 22:08:55 2004
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 13 Dec 2004 23:08:55 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
Message-ID: <d5ad21470412131408c531dfa@mail.gmail.com>

On Mon, 13 Dec 2004 22:11:21 +0100, Michael Schwendt
<fedora at wir-sind-cool.org> wrote:
> 
> FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> version 0.40.

In bugzilla the latest I can find is 0.39:

https://bugzilla.fedora.us/show_bug.cgi?id=2029

am I missing something?



From turnip at turnipspatch.com  Mon Dec 13 22:09:59 2004
From: turnip at turnipspatch.com (Jonathan Leighton [Turnip])
Date: Mon, 13 Dec 2004 22:09:59 +0000
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213230029.7c76afd5.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
Message-ID: <41BE1337.2030704@turnipspatch.com>



Michael Schwendt wrote:

>On Mon, 13 Dec 2004 21:21:14 +0000, Jonathan Leighton [Turnip] wrote:
>
>  
>
>>>FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
>>>version 0.40.
>>>
>>>      
>>>
>>Really?
>>    
>>
>
>Yes, really.
>  
>
Rhetorical question ;-)

>  
>
>>Could you give me a link please? Maybe I'm looking in the wrong 
>>places, but I can't find any packages greater than version 0.39.
>>    
>>
>
>That is is because of this:
>http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html
>
>This is also the reason why fedora.us does not provide any packages for
>FC3. No rebuilds for FC3 have been planned or started. But package
>development has not come to a complete halt. Though the current
>situation is a major hindrance for all package developers and
>contributors at fedora.us.
>
So, correct me if I am wrong, but inkscape 0.40 has already been built, 
but just not released? As there is a list of these packages somewhere?

Thanks

-- 
Regards,
Jonathan Leighton [Turnip]

Get Thunderbird - Reclaim Your Inbox
http://www.mozilla.org/products/thunderbird



From perbj at stanford.edu  Mon Dec 13 22:11:08 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 13 Dec 2004 14:11:08 -0800
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <41BE07CA.3020008@turnipspatch.com>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
Message-ID: <1102975869.3480.32.camel@localhost.localdomain>

On Mon, 2004-12-13 at 21:21 +0000, Jonathan Leighton [Turnip] wrote:
> Michael Schwendt wrote:

> >FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> >version 0.40.
> >
> Really? Could you give me a link please? Maybe I'm looking in the wrong 
> places, but I can't find any packages greater than version 0.39.

Me neither, nothing on http://download.fedora.us nor in Fedora.us
bugzilla as far as I can see. Do my bugzilla skills suck that badly?

Perhaps I should also warn potential users that it is absolutely crucial
to have the gtkmm stack (libsigc++, glibmm, gtkmm) compiled with GCC 3.4
and linked against the corresponding libstdc++ in order to get Inkscape
to run after compiling it with GCC 3.4. This is an example of when the
Fedora.us packages for FC2 don't work well on FC3 (of course, you could
compile Inkscape on FC2 and it should work fine though.) It seems
fundamentally wrong from a packaging point of view to force-build the
Inkscape RPM using the compat-* toolchain.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From kyrre at solution-forge.net  Mon Dec 13 22:09:25 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Mon, 13 Dec 2004 23:09:25 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213230029.7c76afd5.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
Message-ID: <1102975764.27996.12.camel@kyrre>

man, 13.12.2004 kl. 23.00 skrev Michael Schwendt:
> On Mon, 13 Dec 2004 21:21:14 +0000, Jonathan Leighton [Turnip] wrote:
> 
> > >FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> > >version 0.40.
> > >
> > Really?
> 
> Yes, really.
> 
> > Could you give me a link please? Maybe I'm looking in the wrong 
> > places, but I can't find any packages greater than version 0.39.
> 
> That is is because of this:
> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html
> 
> This is also the reason why fedora.us does not provide any packages for
> FC3. No rebuilds for FC3 have been planned or started. But package
> development has not come to a complete halt. Though the current
> situation is a major hindrance for all package developers and
> contributors at fedora.us.
> 

But where are the "old" (fc2) build arcitecture? Cant that be used until
you get those new, fancy build servers running?



From rjune at bravegnuworld.com  Mon Dec 13 22:13:14 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Mon, 13 Dec 2004 17:13:14 -0500
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213230029.7c76afd5.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
Message-ID: <200412131713.17726.rjune@bravegnuworld.com>

> That is is because of this:
> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.htm
That was three weeks ago. please, tell me if I'm wrong, but surely something 
has happened in three weeks.
-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041213/cdb14509/attachment.sig>

From perbj at stanford.edu  Mon Dec 13 22:15:04 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 13 Dec 2004 14:15:04 -0800
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213230029.7c76afd5.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
Message-ID: <1102976104.3480.37.camel@localhost.localdomain>

On Mon, 2004-12-13 at 23:00 +0100, Michael Schwendt wrote:

> That is is because of this:
> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html
> 
> This is also the reason why fedora.us does not provide any packages for
> FC3. No rebuilds for FC3 have been planned or started. But package
> development has not come to a complete halt. Though the current
> situation is a major hindrance for all package developers and
> contributors at fedora.us.

Yes, but shouldn't there at least be a bugzilla entry in the fedora.us
bugzilla? How else is anyone supposed to know what is in the pipeline?
Knowing that is quite essential for avoiding duplicate work.

http://bugzilla.fedora.us/buglist.cgi?short_desc_type=allwordssubstr&short_desc=inkscape&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
seems to be all I can find on Inkscape, including closed bugs. No sign
of 0.40.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From czar at czarc.net  Mon Dec 13 22:19:29 2004
From: czar at czarc.net (Gene C.)
Date: Mon, 13 Dec 2004 17:19:29 -0500
Subject: FC3 install and grub failure on HP Proliant DL380, kernel issue?
In-Reply-To: <1102964922.11842.175.camel@prickly-pear.progeny.com>
References: <1102957035.11866.154.camel@prickly-pear.progeny.com>
	<1102962361.4816.11.camel@c515816-a>
	<1102964922.11842.175.camel@prickly-pear.progeny.com>
Message-ID: <200412131719.29314.czar@czarc.net>

On Monday 13 December 2004 14:08, Sam Hart wrote:
> This occurs during installation. It occurs only on the hardware I
> mentioned, namely:
> ?* HP Proliant DL380
> ?* HP SmartArray 5i RAID controller card

Having recently completed beating my head against the wall to get FC3 
installed and running on a Proliant DL360 G2 ... have you set the system type 
to "Linux"?  Untill I realized that this needed to be done, it was a lot of 
pain.

If the Dl380 is anything like the DL360 G2, you need to hit F9 during the 
initial stuff the system goes through (it is toward the end), this will bring 
up configuration of the BIOS stuff where you can select system type.  I found 
that it needed to be set BEFORE you did the install.  Why the Compaq/HP 
Proliant needs to know the system type it will be running is a puzzle to me.
-- 
Gene



From giallu at gmail.com  Mon Dec 13 22:21:19 2004
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 13 Dec 2004 23:21:19 +0100
Subject: First rpm packaging attempt: OpenMOIV
In-Reply-To: <20041212212215.03acefd9.fedora@wir-sind-cool.org>
References: <d5ad214704120902256bc690ec@mail.gmail.com>
	<20041212212215.03acefd9.fedora@wir-sind-cool.org>
Message-ID: <d5ad214704121314215220f3c1@mail.gmail.com>

On Sun, 12 Dec 2004 21:22:15 +0100, Michael Schwendt
<fedora at wir-sind-cool.org> wrote:
> Since nobody else has replied yet, the documentation in the Wiki
> recommends that packagers exchange reviews with other packages.

Yep, I figured it... 

> 
> The process of posting utilisable votes/approvals is quite informal,
> except that every approval must be GPG clearsigned and contain at
> least the MD5 checksum of the reviewed src.rpm and preferably the
> checksum of the included source archive. This is explained here:
> 
> http://fedoraproject.org/wiki/index.cgi/PackageSubmissionQAPolicy#review

Thank you, I already tried to give an useful review for the Zope package:
https://bugzilla.fedora.us/show_bug.cgi?id=1701
I hope to find a volunteer for reviewing the package soon :)



From ed at eh3.com  Mon Dec 13 22:31:31 2004
From: ed at eh3.com (Ed Hill)
Date: Mon, 13 Dec 2004 17:31:31 -0500
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <200412131713.17726.rjune@bravegnuworld.com>
References: <41BE02A3.7050302@turnipspatch.com>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
	<200412131713.17726.rjune@bravegnuworld.com>
Message-ID: <1102977092.26733.94.camel@localhost.localdomain>

On Mon, 2004-12-13 at 17:13 -0500, Richard June wrote:
> > That is is because of this:
> > http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.htm
> That was three weeks ago. please, tell me if I'm wrong, but surely something 
> has happened in three weeks.


Richard's question is a fair and reasonable inquiry.  And we're all
(especially those of us submitting packages) aware that Warren's message
clearly says "don't ask for ETA."

Could someone @redhat.com please give us an idea of how things are
progressing with FE?  Will we see a FE "release" before the new year?

- Ed "impatiently awaiting the new FE, whatever it is" Hill

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464



From fedora at wir-sind-cool.org  Mon Dec 13 22:38:30 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 13 Dec 2004 23:38:30 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102976104.3480.37.camel@localhost.localdomain>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
	<1102976104.3480.37.camel@localhost.localdomain>
Message-ID: <20041213233830.37575463.fedora@wir-sind-cool.org>

On Mon, 13 Dec 2004 14:15:04 -0800, Per Bjornsson wrote:

[Inkscape 0.40]

> Yes, but shouldn't there at least be a bugzilla entry in the fedora.us
> bugzilla?

No.

Using bugzilla for package submissions and package updates has been
considered extra burden for package maintainers. Hence for several
months, trusted developers can update/upgrade their packagers without
needing to wait for QA in bugzilla. With fedora.us' infrastructure
they would open a ticket as a build request for a src.rpm. But since
FC3 builds are not done at fedora.us, the Inkscape packager didn't
open such a ticket.

> How else is anyone supposed to know what is in the pipeline?
> Knowing that is quite essential for avoiding duplicate work.

Well, the current situation is exceptional. With packages being
maintained in CVS, you would use different means of monitoring package
development.

In either case, though, you would never know what's _planned_ until
you talked to the packager and participated in the planning actively.
You would only see actual changes when they are applied and before
something would be built.

And currently at fedora.us, all new packages are still tracked in
bugzilla. So, there is no duplicate work unless you worked on somebody
else's packages while he is preparing updates himself. In that case,
you can't really avoid any human-to-human communication.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3
loadavg: 1.84 2.27 2.21



From fedora at wir-sind-cool.org  Mon Dec 13 22:43:25 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 13 Dec 2004 23:43:25 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102975869.3480.32.camel@localhost.localdomain>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<1102975869.3480.32.camel@localhost.localdomain>
Message-ID: <20041213234325.19a4fff8.fedora@wir-sind-cool.org>

On Mon, 13 Dec 2004 14:11:08 -0800, Per Bjornsson wrote:

[Inkscape 0.40]

> Perhaps I should also warn potential users that it is absolutely crucial
> to have the gtkmm stack (libsigc++, glibmm, gtkmm) compiled with GCC 3.4
> and linked against the corresponding libstdc++ in order to get Inkscape
> to run after compiling it with GCC 3.4.

The Gtkmm stacks is up-to-date. Denis Leroy, who maintains it at
fedora.us, has done two updates recently, which will build just fine
on FC3 whenever that will be done.

> This is an example of when the
> Fedora.us packages for FC2 don't work well on FC3 

There are other examples. For instance, libid3 from FC2 breaks k3b-mp3
on FC3 silently. And I doubt, many people try to run the FC2 packages
on FC3 actually, because it looks so questionable to do that.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3
loadavg: 1.00 1.08 1.50



From perbj at stanford.edu  Mon Dec 13 22:54:01 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 13 Dec 2004 14:54:01 -0800
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213234325.19a4fff8.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<1102975869.3480.32.camel@localhost.localdomain>
	<20041213234325.19a4fff8.fedora@wir-sind-cool.org>
Message-ID: <1102978441.3480.57.camel@localhost.localdomain>

On Mon, 2004-12-13 at 23:43 +0100, Michael Schwendt wrote:
> The Gtkmm stacks is up-to-date. Denis Leroy, who maintains it at
> fedora.us, has done two updates recently, which will build just fine
> on FC3 whenever that will be done.

Sorry, indeed the SRPMS in the FC2 download area build and appear to
work just fine - when I rebuilt them I didn't change the specfile at
all. I was just trying to warn people about attempting to build Inkscape
against the FC2 _binary_ packages; running Inkscape gives you a somewhat
impenetrable error message. I certainly didn't mean to slander Dennis's
fine work with the packages; I'm sorry if it came across that way.

> > This is an example of when the
> > Fedora.us packages for FC2 don't work well on FC3 
> 
> There are other examples. For instance, libid3 from FC2 breaks k3b-mp3
> on FC3 silently. And I doubt, many people try to run the FC2 packages
> on FC3 actually, because it looks so questionable to do that.

Well, if you upgrade a computer from FC2 to FC3 and you use Fedora.us,
there can be plenty of packages lying around. Since there's no FC3
Extras repo to point yum to there's no automatic upgrade path, you'd
have to go through and rebuild manually. So I don't really think that
it's all that unusual to have FC2 Fedora.us packages lying around. The
gtkmm case is probably exceptionally problematic though because of the C
++ ABI break.

/Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From denisleroy at yahoo.com  Mon Dec 13 23:25:21 2004
From: denisleroy at yahoo.com (Denis Leroy)
Date: Mon, 13 Dec 2004 15:25:21 -0800 (PST)
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102978441.3480.57.camel@localhost.localdomain>
Message-ID: <20041213232522.6837.qmail@web60703.mail.yahoo.com>


--- Per Bjornsson <perbj at stanford.edu> wrote:
> Sorry, indeed the SRPMS in the FC2 download area build and appear to
> work just fine - when I rebuilt them I didn't change the specfile at
> all. I was just trying to warn people about attempting to build
> Inkscape
> against the FC2 _binary_ packages; running Inkscape gives you a
> somewhat
> impenetrable error message. I certainly didn't mean to slander
> Dennis's
> fine work with the packages; I'm sorry if it came across that way.

It did not :-)

> 
> 
> The
> gtkmm case is probably exceptionally problematic though because of
> the C
> ++ ABI break.

Right, FC2 default g++ is based on libstdc++.so.5, while FC3's is
libstdc++.so.6...

-denis



From arne at subaru.naoj.org  Tue Dec 14 01:41:53 2004
From: arne at subaru.naoj.org (Arne Grimstrup)
Date: Mon, 13 Dec 2004 15:41:53 -1000
Subject: Stateless kickstart problem
Message-ID: <41BE44E1.3070708@subarutelescope.org>

Christopher Hotchkiss wrote:
> I got back to work trying to get this up and running today. I ran into
> the following problem, I needed a proxy to download the stateless
> packages properly, the section of the kickstart is below.
> 
>     f.close()
>     def do_chroot (commands):
>         quoted = re.sub ("'", "'\\''", commands)
>         os.system ("chroot /mnt/sysimage sh -c '%s'" % quoted)
>     do_chroot ("http_proxy=\"http://192.168.0.246:3128\"; yum -c
> /tmp/stateless.yum.conf install stateless-client")

I had trouble with RPM and GPG signature checking.  I had to add:

do_chroot("rpm --import http://fedora.redhat.com/about/security/4F2A6FD2.txt")

before the yum command to work around it.

> ### Now launch the real bootstrap
>     sys.path.append ('/mnt/sysimage/usr/share/stateless/')
>     import bootstrap
>     bootstrap.run('aware-of-vacuity.boston.redhat.com', 'Test42')

Does this work for you?  When I run the script, python throws an exception 
saying that it can't import gtk.glade.  As near as I can tell, Glade isn't being 
used in the script.

> Is this correct? Secondly, what I replace the boston.redhat.com line with?

I'd like to know the answer to this one too.  My guess is that it should point 
to my LDAP server, but I'm not sure.

Regards,

Arne Grimstrup
Software Engineer
Subaru Telescope




From mpeters at mac.com  Tue Dec 14 03:13:56 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 14 Dec 2004 03:13:56 +0000
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <200412131657.57658.rjune@bravegnuworld.com> (from
	rjune@bravegnuworld.com on Mon Dec 13 13:57:54 2004)
References: <41BE02A3.7050302@turnipspatch.com>
	<200412131641.18303.rjune@bravegnuworld.com>
	<1102974402.27996.10.camel@kyrre>
	<200412131657.57658.rjune@bravegnuworld.com>
Message-ID: <1102994036l.16698l.2l@devel.mpeters.us>

On 12/13/2004 01:57:54 PM, Richard June wrote:
> On Monday 13 December 2004 16:46, Kyrre Ness Sjobak wrote:
> > man, 13.12.2004 kl. 22.41 skrev Richard June:
> > > > FYI, Inkscape is included in fedora.us/Fedora Extras, currently
> at
> > > > version 0.40.
> > >
> > > Really? I'm running fc3 and would love to have inkscape RPMs from
> Fedora
> > > Extras. where can I download them?
> >
> > There is no extras for fc3 yet... Who knows when there will be.
> Right now I'm betting slightly after FC4 is released.

Why so optimistic? ;)

-=-
Really - Fedora.us imho should not have stopped building until Fedora  
Extras was deployed. That's like removing your chains in the middle of  
winter before your snow tires have arrived.




From rjune at bravegnuworld.com  Tue Dec 14 04:05:10 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Mon, 13 Dec 2004 23:05:10 -0500
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102994036l.16698l.2l@devel.mpeters.us>
References: <41BE02A3.7050302@turnipspatch.com>
	<200412131657.57658.rjune@bravegnuworld.com>
	<1102994036l.16698l.2l@devel.mpeters.us>
Message-ID: <200412132305.14937.rjune@bravegnuworld.com>

> -=-
> Really - Fedora.us imho should not have stopped building until Fedora
> Extras was deployed. That's like removing your chains in the middle of
> winter before your snow tires have arrived.
And you don't have any idea when they'll get there, only that the tire store 
announced that they have the mfg plant "almost built"

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041213/c829b3f6/attachment.sig>

From rc040203 at freenet.de  Tue Dec 14 04:47:06 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Dec 2004 05:47:06 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <200412132305.14937.rjune@bravegnuworld.com>
References: <41BE02A3.7050302@turnipspatch.com>
	<200412131657.57658.rjune@bravegnuworld.com>
	<1102994036l.16698l.2l@devel.mpeters.us>
	<200412132305.14937.rjune@bravegnuworld.com>
Message-ID: <1102999627.4869.124.camel@mccallum.corsepiu.local>

On Mon, 2004-12-13 at 23:05 -0500, Richard June wrote:
> > -=-
> > Really - Fedora.us imho should not have stopped building until Fedora
> > Extras was deployed.
Seconded.

I'd like to ask Fedora.US to seriously reconsider this decision unless
RH can give an affirmative ETA for a RH-driven FE to arrive.

>  That's like removing your chains in the middle of
> > winter before your snow tires have arrived.
> And you don't have any idea when they'll get there, only that the tire store 
> announced that they have the mfg plant "almost built"
That's what they already said 2 years ago ... ;)

Ralf




From perbj at stanford.edu  Tue Dec 14 06:53:04 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 13 Dec 2004 22:53:04 -0800
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <20041213233830.37575463.fedora@wir-sind-cool.org>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
	<1102976104.3480.37.camel@localhost.localdomain>
	<20041213233830.37575463.fedora@wir-sind-cool.org>
Message-ID: <1103007184.4771.48.camel@ferrari.localdomain>

On Mon, 2004-12-13 at 23:38 +0100, Michael Schwendt wrote:
> Using bugzilla for package submissions and package updates has been
> considered extra burden for package maintainers. Hence for several
> months, trusted developers can update/upgrade their packagers without
> needing to wait for QA in bugzilla. With fedora.us' infrastructure
> they would open a ticket as a build request for a src.rpm. But since
> FC3 builds are not done at fedora.us, the Inkscape packager didn't
> open such a ticket.

OK. I thought that the process still involved a bugzilla entry even
though it could be effectively self-approved by 
> 
> > How else is anyone supposed to know what is in the pipeline?
> > Knowing that is quite essential for avoiding duplicate work.
> 
> Well, the current situation is exceptional. With packages being
> maintained in CVS, you would use different means of monitoring package
> development.
> 
> In either case, though, you would never know what's _planned_ until
> you talked to the packager and participated in the planning actively.
> You would only see actual changes when they are applied and before
> something would be built.

True. In this case I probably ahd a mistaken idea of who was packaging
it, I forgot to check the old RPM and sort of remembered Peter Linell
dealing with it earlier. I was under the impression that he was on the
Inkscape list where the packaging has been bandied about a bit, so I
didn't realize that there could be a package in the pipeline.

Now (and this is of course directed more generally to anyone in the
know), since there apparently is a Fedora package of Inkscape 0.40, is
there anywhere I and other interested parties can get hold of the SRPM?
A public dump of the SRPMs somewhere would be fantastic.

> And currently at fedora.us, all new packages are still tracked in
> bugzilla. So, there is no duplicate work unless you worked on somebody
> else's packages while he is preparing updates himself. In that case,
> you can't really avoid any human-to-human communication.

;) Boy, I didn't really mean to sound like I didn't want to talk to
anyone. Sorry about that. It seems to me that an easy way to figure out
who's working on what sounds useful to me - . Actually, it just struck
me that perhaps something like Debian's ITP system (as far as I can tell
it pretty much means that when you're planning to package something you
send an e-mail to a mailing list) might be a good idea for Fedora
Extras?

No hard feelings I hope,
Per




From christopher.hotchkiss at gmail.com  Tue Dec 14 07:23:11 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 14 Dec 2004 02:23:11 -0500
Subject: Stateless kickstart problem
In-Reply-To: <41BE44E1.3070708@subarutelescope.org>
References: <41BE44E1.3070708@subarutelescope.org>
Message-ID: <7f48492a04121323234036bb49@mail.gmail.com>

Well to put it nicely I kinda gave up on the complexity of the
Stateless Project. Instead I rolled my own "stateless" via a pxe
kickstart install that checks out a snapshot via rsync. It works
better easier and quicker to be quite honest. If you want I can post
how I exactly did it.
-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From alan at balclutha.org  Tue Dec 14 07:41:29 2004
From: alan at balclutha.org (Alan Milligan)
Date: Tue, 14 Dec 2004 18:41:29 +1100
Subject: Zope/Plone on Fedora
Message-ID: <41BE9929.4020004@balclutha.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There've been a couple of posts regarding this over the last couple of
months on this list, and we'd like to take this opportunity to
coordinate interested parties.

We are about to begin promoting BastionLinux,
https://linux.last-bastion.net as a niche Linux distro for enterprise
Zope/Plone customers.

We've already an infrastructure comparible to the RHN to make this
happen, and this goes much beyond releasing a solitary zope package.

We are intending to offer this to distro providers along the lines of
the jpackage.org model if there's interest (we've been promoting the
resolution of the python rpm macro bug, 120635, as the first step to
facilitating this).

If anybody has any queries or is interested in particating at any level,
then please get in touch with me to coordinate our efforts.

Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBvpkpCfroLk4EZpkRAu2gAJ9mR2scWRvkwyBcBHl3+An93FsLiQCfeUft
QXOQUW4CpZMq+E+DJm5Df7o=
=sNcR
-----END PGP SIGNATURE-----



From skvidal at phy.duke.edu  Tue Dec 14 08:05:24 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 14 Dec 2004 03:05:24 -0500
Subject: Fedora Extras Status - WAS: Re: Self-Introduction: Jonathan Leighton
In-Reply-To: <1102977092.26733.94.camel@localhost.localdomain>
References: <41BE02A3.7050302@turnipspatch.com>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
	<200412131713.17726.rjune@bravegnuworld.com>
	<1102977092.26733.94.camel@localhost.localdomain>
Message-ID: <1103011524.6137.88.camel@cutter>


> 
> Richard's question is a fair and reasonable inquiry.  And we're all
> (especially those of us submitting packages) aware that Warren's message
> clearly says "don't ask for ETA."
> 
> Could someone @redhat.com please give us an idea of how things are
> progressing with FE?  Will we see a FE "release" before the new year?
> 
> - Ed "impatiently awaiting the new FE, whatever it is" Hill

Hi,
 I'm not @redhat.com but I'm involved in the process in various ways.
Mostly by being annoying and sysadminning certain servers :)

Here is a status report:
- cristian gafton, the technical lead of the fedora project, is working
on making the build system 'just work'. He's trying to get it right and
happy so things do what we expect. He tends to be less talkative than a
lot of people might want but he's doing a lot of head down work that,
quite frankly, is painfully complex to do right. 

- cvs is open, commits are occurring, websites are up and people are
fixing up packages. It's a bright new day that's vaguely foggy. :)

- many of the packages have been built and a pre-extras repository will
probably be unleashed on the unwitting public very soon. (mark my words)

- the other infrastructure bits that need to be ready first:
  - 'extras' gpg key for signing packages needs to be made
  - bugzilla needs to know about extras and about the package owners
  - extras needs to be dealt with vis-a-vis the mirroring systems
  - some release timing issues need to get worked out.

There is a smallish group of not-terribly-talkative people working on
these problems and, believe it or not, they're making some headway.

I'll post more as I know it/come across it. And I'll post more and a
little more detail soon.

Hope this helps.

-sv




From j.w.r.degoede at hhs.nl  Tue Dec 14 08:12:02 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 14 Dec 2004 09:12:02 +0100
Subject: Status on that intel GFX chip?
In-Reply-To: <1102970777.27996.8.camel@kyrre>
References: <1102970777.27996.8.camel@kyrre>
Message-ID: <41BEA052.7080008@hhs.nl>

Huh,

I've a 865G at work and that works fine even the 3D is ok.

Regards,

Hans


Kyrre Ness Sjobak wrote:
> Hello
> 
> I just wonder, and i know it has been brought up a zillion times - but
> what are the current status of the intel gfx (i815?) xorg driver? Any
> updates (rpms) that could be easily pushed into my net via admin-script?
> 
> The vesa driver works - but it refuses to do anything more than a bare
> minimum resolution, and the intel driver has some... funny... side
> effects. Not anything i would like to expose my users to, really
> 
> Kyrre
> 



From kyrre at solution-forge.net  Tue Dec 14 10:30:41 2004
From: kyrre at solution-forge.net (kyrre at solution-forge.net)
Date: Tue, 14 Dec 2004 11:30:41 +0100 (CET)
Subject: Status on that intel GFX chip?
In-Reply-To: <41BEA052.7080008@hhs.nl>
References: <1102970777.27996.8.camel@kyrre> <41BEA052.7080008@hhs.nl>
Message-ID: <32833.81.191.130.121.1103020241.squirrel@solution-forge.net>

Which driver (xorg.conf) and xorg verson is that?

> Huh,
>
> I've a 865G at work and that works fine even the 3D is ok.
>
> Regards,
>
> Hans
>
>
> Kyrre Ness Sjobak wrote:
>> Hello
>>
>> I just wonder, and i know it has been brought up a zillion times - but
>> what are the current status of the intel gfx (i815?) xorg driver? Any
>> updates (rpms) that could be easily pushed into my net via admin-script?
>>
>> The vesa driver works - but it refuses to do anything more than a bare
>> minimum resolution, and the intel driver has some... funny... side
>> effects. Not anything i would like to expose my users to, really
>>
>> Kyrre
>>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From j.w.r.degoede at hhs.nl  Tue Dec 14 10:36:07 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 14 Dec 2004 11:36:07 +0100
Subject: Status on that intel GFX chip?
In-Reply-To: <32833.81.191.130.121.1103020241.squirrel@solution-forge.net>
References: <1102970777.27996.8.camel@kyrre> <41BEA052.7080008@hhs.nl>
	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>
Message-ID: <41BEC217.40208@hhs.nl>

kyrre at solution-forge.net wrote:
> Which driver (xorg.conf) and xorg verson is that?
> 

Erm I'm not behind that machine right now, but its an FC2 install with 
xorg upgraded from rawhide somewhere during FC3 testing. I'm using the 
i810 driver afaik. The only problem I had was that the later xorg want 
to load i915.o as drm module for the kernel and that wasn't shipped by 
fedora at that time. I've filed a bug about this and later kernels have 
it. I'm usign the latest kernel from FC2-updates.

BTW The reason for going to the rawhide xorg was that the FC2 xorg 
crashes whenever a 3d screensaver kicks in, or maybe it was a powersave 
problem, either way the current FC3 xorg should be fixed also.

Regards,

Hans



> 
>>Huh,
>>
>>I've a 865G at work and that works fine even the 3D is ok.
>>
>>Regards,
>>
>>Hans
>>
>>
>>Kyrre Ness Sjobak wrote:
>>
>>>Hello
>>>
>>>I just wonder, and i know it has been brought up a zillion times - but
>>>what are the current status of the intel gfx (i815?) xorg driver? Any
>>>updates (rpms) that could be easily pushed into my net via admin-script?
>>>
>>>The vesa driver works - but it refuses to do anything more than a bare
>>>minimum resolution, and the intel driver has some... funny... side
>>>effects. Not anything i would like to expose my users to, really
>>>
>>>Kyrre
>>>
>>
>>--
>>fedora-devel-list mailing list
>>fedora-devel-list at redhat.com
>>http://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
> 
> 



From hugh.mcguirk at propylon.com  Tue Dec 14 10:39:13 2004
From: hugh.mcguirk at propylon.com (Hugh McGuirk)
Date: Tue, 14 Dec 2004 10:39:13 +0000
Subject: Status on that intel GFX chip?
In-Reply-To: <1102970777.27996.8.camel@kyrre>
References: <1102970777.27996.8.camel@kyrre>
Message-ID: <1103020753.3291.11.camel@localhost.localdomain>

On Mon, 2004-12-13 at 21:46 +0100, Kyrre Ness Sjobak wrote:
> Hello
> 
> I just wonder, and i know it has been brought up a zillion times - but
> what are the current status of the intel gfx (i815?) xorg driver? Any
> updates (rpms) that could be easily pushed into my net via admin-script?
> 
> The vesa driver works - but it refuses to do anything more than a bare
> minimum resolution, and the intel driver has some... funny... side
> effects. Not anything i would like to expose my users to, really
> 
> Kyrre
> 

Ive a DELL laptop running a i830M chip, and it works fine, including
accelerated 3D.

I'm unsure about the current xorg driver, but on this laptop, previous
XFree86 drivers had problems if certain BIOS versions were used. The
latest BIOS's did not return correct memory size information, so only
the lowest resolutions worked, as it defaulted to 1MB memory available
to graphics. 

The solution was to downgrade the BIOS by a few revisions.

Hugh.



From rjune at bravegnuworld.com  Tue Dec 14 11:29:13 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Tue, 14 Dec 2004 06:29:13 -0500
Subject: Fedora Extras Status - WAS: Re: Self-Introduction: Jonathan
	Leighton
In-Reply-To: <1103011524.6137.88.camel@cutter>
References: <41BE02A3.7050302@turnipspatch.com>
	<1102977092.26733.94.camel@localhost.localdomain>
	<1103011524.6137.88.camel@cutter>
Message-ID: <200412140629.17077.rjune@bravegnuworld.com>

>  I'm not @redhat.com but I'm involved in the process in various ways.
> Mostly by being annoying and sysadminning certain servers :)
>
> Here is a status report:
> - cristian gafton, the technical lead of the fedora project, is working
> on making the build system 'just work'. He's trying to get it right and
> happy so things do what we expect. He tends to be less talkative than a
> lot of people might want but he's doing a lot of head down work that,
> quite frankly, is painfully complex to do right.
>
> - cvs is open, commits are occurring, websites are up and people are
> fixing up packages. It's a bright new day that's vaguely foggy. :)
>
> - many of the packages have been built and a pre-extras repository will
> probably be unleashed on the unwitting public very soon. (mark my words)
>
> - the other infrastructure bits that need to be ready first:
>   - 'extras' gpg key for signing packages needs to be made
>   - bugzilla needs to know about extras and about the package owners
>   - extras needs to be dealt with vis-a-vis the mirroring systems
>   - some release timing issues need to get worked out.
>
> There is a smallish group of not-terribly-talkative people working on
> these problems and, believe it or not, they're making some headway.
>
> I'll post more as I know it/come across it. And I'll post more and a
> little more detail soon.
helps is somewhat speculative, but I do appreciate the info. I'm aware of the 
trouble that goes into setting up a build environment (at least my troubles 
with it).

-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041214/39ff8e42/attachment.sig>

From buildsys at redhat.com  Tue Dec 14 12:53:58 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 14 Dec 2004 07:53:58 -0500
Subject: rawhide report: 20041214 changes
Message-ID: <200412141253.iBECrwN26145@porkchop.devel.redhat.com>

New package xen
	Xen is a virtual machine monitor


 
Updated Packages:

abiword-1:2.2.2-1
-----------------
* Mon Dec 13 2004 Caolan McNamara <caolanm at redhat.com> - 1:2.2.2-1
- bump to new version

arts-8:1.3.2-0.1
----------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 8:1.3.2-0.1
- update to KDE 3.3.2

* Fri Nov 19 2004 Than Ngo <than at redhat.com> 8:1.3.1-4
- alsa as default

audit-0.5.6-1
-------------
* Fri Dec 17 2004 Steve Grubb <sgrubb at redhat.com> 0.5.6-1
- New version

gzip-1.3.3-15
-------------
* Mon Dec 13 2004 Ivana Varekova <varekova at redhat.com>
- fix patch - remove brackets

* Mon Dec 13 2004 Ivana Varekova <varekova at redhat.com>
- fix bug #106551 problem with zmore which requires the suffix .gz in file name

kdegames-6:3.3.2-0.1
--------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.1
-  update to 3.3.2

* Mon Oct 18 2004 Than Ngo <than at redhat.com> 6:3.3.1-2
- add missing klickety icons #135614

kdevelop-9:3.1.2-0.1
--------------------
* Sun Dec 05 2004 Than Ngo <than at redhat.com> 9:3.1.2-0.1
- update to 3.1.2

* Sun Oct 24 2004 Warren Togami <wtogami at redhat.com>
- req libtool used by kdevelop

* Sat Oct 16 2004 Than Ngo <than at redhat.com> 9:3.1.1-2
- rhel rebuilt

libglade-java-2.8.2-2
---------------------
* Mon Dec 13 2004 Ben Konrath <bkonrath at redhat.com> 2.8.2-2
- Add signal-connect.patch to fix upstream bug
  (http://bugzilla.gnome.org/show_bug.cgi?id=161190)

libuser-0.53.1-1
----------------
* Mon Dec 13 2004 Miloslav Trmac <mitr at redhat.com> - 0.53.1-1
- Export UT_NAMESIZE from <utmp.h> to Python (#141273)

logrotate-3.7.1-5
-----------------
* Mon Dec 13 2004 Peter Vrabec <pvrabec at redhat.com> - 3.7.1-5
- Add section to logrotate.conf for "/var/log/btmp" (#117844)

* Mon Dec 13 2004 Peter Vrabec <pvrabec at redhat.com> - 3.7.1-4
- Typo and missing information in man page (#139346)

* Mon Dec 06 2004 Peter Vrabec <pvrabec at redhat.com> - 3.7.1-3
- compressed logfiles and logrotate (#140353)

lsof-4.73-1
-----------
* Mon Dec 13 2004 Karel Zak <kzak at redhat.com> 4.73-1
- update to 4.73
- remove lsof_4.72-sock.patch, already in the upstream code

make-1:3.80-6
-------------
* Mon Dec 13 2004 Jakub Jelinek <jakub at redhat.com> 3.80-6
- refuse -jN where N is bigger than PIPE_BUF (#142691, #17374)

mikmod-3.1.6-31
---------------
* Mon Dec 13 2004 Bill Nottingham <notting at redhat.com> 3.1.6-31
- move mikmod binary back to main package (#142668)

mrtg-2.11.0-1
-------------
* Mon Dec 13 2004 Miloslav Trmac <mitr at redhat.com> - 2.11.0-1
- Update to mrtg-2.11.0
- Don't install HTML documentation to /var/www/mrtg
- Clean up %install a bit

ntp-4.2.0.a.20040617-5
----------------------
* Mon Dec 13 2004 Harald Hoyer <harald at redhat.com> - 4.2.0.a.20040617-5
- patched ntp to build with -D_FORTIFYSOURCE=2 -Wall -Wextra -Werror

psmisc-21.5-1
-------------
* Mon Dec 13 2004 Karel Zak <kzak at redhat.com> 21.5-1
- Updated to new upstream version 21.5
- Ported SELinux patch forward as psmisc-21.5-selinux.patch
- Added psmisc-21.5-term.patch that fix termcap.h and term.h conflicts

rpmdb-fedora-1:4-0.20041214
---------------------------

system-config-date-1.7.15-1
---------------------------
* Mon Dec 13 2004 Nils Philippsen <nphilipp at redhat.com> 1.7.15-1
- don't lookup names or IP addresses as this may result in hangs (#142583)

udev-048-1
----------
* Mon Dec 13 2004 Harald Hoyer <harald at redhat.com> - 048-1
- version 048
- major specfile cleanup

vnc-4.0-11
----------
* Mon Dec 13 2004 Tim Waugh <twaugh at redhat.com> 4.0-11
- Create /tmp/.X11-unix if it doesn't already exist.

xemacs-21.4.16-1
----------------
* Mon Dec 13 2004 Jens Petersen <petersen at redhat.com> - 21.4.16-1
- update to new stable release
  - no longer need configure-ppc-ldscript.patch and
    xemacs-21.4.15-pui-120437.patch
- default to unified diff in .xemacs/init.el

xorg-x11-6.8.1-24
-----------------
* Mon Dec 13 2004 Kristian H??gsberg <krh at redhat.com> 6.8.1-24
- Bump version.

* Sun Dec 12 2004 Kristian H??gsberg <krh at redhat.com>
- Drop xorg-libICE-remove-bogus-delay.patch as this was resolved in
  6.8.0 (https://bugs.freedesktop.org/show_bug.cgi?id=306)
- Drop XFree86-4.3.0-Xserver-xf86PciInfo-updates.patch, most of these
  - XFree86-4.3.0-redhat-xlib-linux-fix-avoiding-substance-abuse-job.patch
  is no longer needed since the crack code is only enabled when __sparcv9
  is #define'd.
- Remove XFree86-4.2.0-xtermresources.patch from cvs.
- Use /etc/ld.so.conf.d/xorg-x11.conf instead of editing
  /etc/ld.so.conf in %post (#124077).
- Remove XFree86-4.3.0-Xserver-dix-xkb-key-repeating-bug-CVS-backport.patch
  since the problem is now fixed upstream.
- Remove XFree86-4.3.0-xcursorgen-check-malloc-return.patch since it
  would only make xcursorgen fail differently in case of OOM.

* Thu Dec 09 2004 Soeren Sandmann <sandmann at redhat.com>
- Add disabled-by-default "dri" option to radeon driver.



From cra at WPI.EDU  Tue Dec 14 14:10:37 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Tue, 14 Dec 2004 09:10:37 -0500
Subject: FC4 ISO suggestion
In-Reply-To: <200412141257.56846@-mr700>
References: <200412121643.31583.czar@czarc.net>
	<1102902366l.6759l.1l@devel.mpeters.us> <200412141257.56846@-mr700>
Message-ID: <20041214141037.GF8764@angus.ind.WPI.EDU>

On Tue, Dec 14, 2004 at 12:57:56PM +0200, Doncho N. Gunchev wrote:
>     Is there a RFE in bugzilla about this? I would like to see jigdo
> in fedora too... I extract the rpms from the iso files, but without
> jigdoI see no way to do CDs <-> DVD, rpms -> CDs and rpms -> DVD.
> The mirrors can also save about 2/3 of the download if I get the
> idea right...

Now there is:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142816

Should I add this to the FC4 tracker bug?



From fedora at wir-sind-cool.org  Tue Dec 14 14:13:06 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 14 Dec 2004 15:13:06 +0100
Subject: Self-Introduction: Jonathan Leighton
In-Reply-To: <1103007184.4771.48.camel@ferrari.localdomain>
References: <41BE02A3.7050302@turnipspatch.com>
	<20041213221121.2f66d6a7.fedora@wir-sind-cool.org>
	<41BE07CA.3020008@turnipspatch.com>
	<20041213230029.7c76afd5.fedora@wir-sind-cool.org>
	<1102976104.3480.37.camel@localhost.localdomain>
	<20041213233830.37575463.fedora@wir-sind-cool.org>
	<1103007184.4771.48.camel@ferrari.localdomain>
Message-ID: <20041214151306.2c7837fa.fedora@wir-sind-cool.org>

On Mon, 13 Dec 2004 22:53:04 -0800, Per Bjornsson wrote:

> > Using bugzilla for package submissions and package updates has been
> > considered extra burden for package maintainers. Hence for several
> > months, trusted developers can update/upgrade their packagers without
> > needing to wait for QA in bugzilla. With fedora.us' infrastructure
> > they would open a ticket as a build request for a src.rpm. But since
> > FC3 builds are not done at fedora.us, the Inkscape packager didn't
> > open such a ticket.
> 
> OK. I thought that the process still involved a bugzilla entry even
> though it could be effectively self-approved by 

Yes. As I wrote above [in the last sentence], _if_ fedora.us built for
FC3 or if there were a request to build the package for FC2/FC1, the
packager would have opened a build request ticket.

> who's working on what sounds useful to me - . Actually, it just struck
> me that perhaps something like Debian's ITP system (as far as I can tell
> it pretty much means that when you're planning to package something you
> send an e-mail to a mailing list) might be a good idea for Fedora
> Extras?

Well, fedora-devel-list does exist and is pretty low-traffic. A
separate list specific to Fedora Extras might be helpful if people
became much more active. But since almost no details of Fedora Extras
have been announced, it remains unknown to which level the package
submission procedure might change. I always thought that while Fedora
Extras is being worked on, the community would work on fedora.us,
improve it where deficiences are determined, and use it to practise
maintaining packages.

-- 
The "Fedora Extras" infrastructure: http://img.web.de/c/00/55/4D/B2.420



From riel at redhat.com  Tue Dec 14 14:41:37 2004
From: riel at redhat.com (Rik van Riel)
Date: Tue, 14 Dec 2004 09:41:37 -0500 (EST)
Subject: Xen in rawhide
In-Reply-To: <20041213040759.GA9285@osiris.silug.org>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213040759.GA9285@osiris.silug.org>
Message-ID: <Pine.LNX.4.61.0412140940380.2271@chimarrao.boston.redhat.com>

On Sun, 12 Dec 2004, Steven Pritchard wrote:

> In the mean time, is there any chance you could run createrepo on 
> people.redhat.com/riel/?  :-)

Yesterday the packages from my people page were added to
rawhide, so there shouldn't be a need for anybody to keep
downloading stuff from my page.

Once the rawhide mirrors are all synced up, I'll remove
the (now old) RPMs from my people page.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



From ndbecker2 at verizon.net  Tue Dec 14 14:56:58 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Tue, 14 Dec 2004 09:56:58 -0500
Subject: trac is awesome
Message-ID: <cpmuvq$oi8$1@sea.gmane.org>

trac http://projects.edgewall.com/trac/ is really awesome SCM/project
management.  I installed it easily on FC3 using packages from DAG
repository.  I highly recommend adding this!  It is GPL, of course.



From ssahni at gmail.com  Tue Dec 14 15:15:33 2004
From: ssahni at gmail.com (Simarjeet Sahni)
Date: Tue, 14 Dec 2004 10:15:33 -0500
Subject: Stateless kickstart problem
In-Reply-To: <7f48492a04121323234036bb49@mail.gmail.com>
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
Message-ID: <45b47df30412140715639beb4d@mail.gmail.com>

I think everyone would appreciate it if you could kindly post your
steps either to this thread or a url.


On Tue, 14 Dec 2004 02:23:11 -0500, Christopher Hotchkiss
<christopher.hotchkiss at gmail.com> wrote:
> Well to put it nicely I kinda gave up on the complexity of the
> Stateless Project. Instead I rolled my own "stateless" via a pxe
> kickstart install that checks out a snapshot via rsync. It works
> better easier and quicker to be quite honest. If you want I can post
> how I exactly did it.
> --
> Christopher Hotchkiss
> (813)960-9273
> http://www.post227.org
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
Regards,

Simarjeet Sahni



From dpaun at rogers.com  Tue Dec 14 16:50:23 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Tue, 14 Dec 2004 11:50:23 -0500
Subject: Xen in rawhide
In-Reply-To: <Pine.LNX.4.61.0412131628130.22945@chimarrao.boston.redhat.com>
References: <20041209140821.GA23850@osiris.silug.org>
	<20041209155358.GA5932@dudweiler.stuttgart.redhat.com>
	<20041209164742.GA24437@osiris.silug.org>
	<Pine.LNX.4.61.0412121823450.27482@chimarrao.boston.redhat.com>
	<20041213014015.GC5747@rogers.com>
	<Pine.LNX.4.61.0412122259220.27482@chimarrao.boston.redhat.com>
	<20041213050524.GA6919@rogers.com>
	<Pine.LNX.4.61.0412131628130.22945@chimarrao.boston.redhat.com>
Message-ID: <20041214165023.GA25079@rogers.com>

On Mon, Dec 13, 2004 at 04:28:38PM -0500, Rik van Riel wrote:
> The user can choose the right one at boot time, from
> the boot loader menu.  Or is this not what you mean ?

Yes, I do. Thanks!

-- 
Dimi.



From dmahurin at dma.org  Tue Dec 14 17:54:49 2004
From: dmahurin at dma.org (Don Mahurin)
Date: Tue, 14 Dec 2004 09:54:49 -0800
Subject: Can we fix the backspace key?
Message-ID: <41BF28E9.2050608@dma.org>


Is there any way that we can undo the backwards backspace/delete key 
bindings that were introduced in Redhat 6.2?

http://web.purplefrog.com/~thoth/philosophy/backspace-delete.html

So we could again have the standard bindings of Backspace=^H and Delete=^?



From uraeus at gnome.org  Tue Dec 14 18:11:51 2004
From: uraeus at gnome.org (Christian Fredrik Kalager Schaller)
Date: Tue, 14 Dec 2004 19:11:51 +0100
Subject: Putting Flumotion into Fedora 4
Message-ID: <1103047912.11655.14.camel@localhost.localdomain>

Hi everyone,
I would like to propose putting Flumotion into Fedora 4.

Flumotion is for those who doesn't know it a Streaming Media server
with a GTK+ configuration and administration interface available under
the GPL license. It uses GStreamer and Twisted as its underlaying
libraries. Its designed for running on Linux with support for input from
webcams, tvcards, soundcards and Firewire devices under Linux. Homepage
to be found on http://www.flumotion.net

I had originally planed on waiting with this proposal a little to let
the server mature and grow more popularity first, but problems with
how Fedora works made me think that proposing it sooner would be an idea
to give distro developer more time to figure out how to solve the issues
needing solving to make Flumotion run smoothly on Fedora.

In the bug report linked below I have outlined the problems with making
Flumotion run nicely on Fedora today, but as you also will see from the
Bug report Bill Nothingham basically says fixing these issues will not
happen before Flumotion ships with Fedora: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853

The group proposal from that bugzilla is how Debian and Mandrake solves
the problem and the packages for these platforms already implements it.

So I would like to get some Feedback from Fedora developers on this
proposal and what I/we can do to help make this happen.
Christian



From enrico.scholz at informatik.tu-chemnitz.de  Tue Dec 14 18:27:48 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 14 Dec 2004 19:27:48 +0100
Subject: Can we fix the backspace key?
In-Reply-To: <41BF28E9.2050608@dma.org> (Don Mahurin's message of "Tue, 14
	Dec 2004 09:54:49 -0800")
References: <41BF28E9.2050608@dma.org>
Message-ID: <871xds20rf.fsf@kosh.ultra.csn.tu-chemnitz.de>

dmahurin at dma.org (Don Mahurin) writes:

> Is there any way that we can undo the backwards backspace/delete key
> bindings that were introduced in Redhat 6.2?
>
> http://web.purplefrog.com/~thoth/philosophy/backspace-delete.html
>
> So we could again have the standard bindings of Backspace=^H and Delete=^?

Please not... Doing this, would make it impossible to differ between C-h
and backspace (first combination is used e.g. by (X)Emacs).



Enrico



From cra at WPI.EDU  Tue Dec 14 18:29:21 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Tue, 14 Dec 2004 13:29:21 -0500
Subject: Can we fix the backspace key?
In-Reply-To: <41BF28E9.2050608@dma.org>
References: <41BF28E9.2050608@dma.org>
Message-ID: <20041214182921.GP27024@angus.ind.WPI.EDU>

On Tue, Dec 14, 2004 at 09:54:49AM -0800, Don Mahurin wrote:
> So we could again have the standard bindings of Backspace=^H and Delete=^?

What about the Linux console?  Linus designed the kernel keymap to
have the "Backspace" key emit "^?" to mimic the VT100 terminal.



From si at bananas.hopto.org  Tue Dec 14 18:42:13 2004
From: si at bananas.hopto.org (Si Jones)
Date: Tue, 14 Dec 2004 18:42:13 +0000
Subject: k3b build error on x86_64
Message-ID: <1103049734.972.4.camel@apple.bananas.hopto.org>

Hi All,

Am having a few problems building things, the first was mplayer, and now
it seems like k3b is having the exact same thing.

When it comes to finding the X stuff it looks in the wrong place, in
this case the error seems to point out that configure is actually not
finding the correct X lib64 directory.

Could someone point me in the direction to correct this error, or
someway of checking a config somewhere, I have checked the spec file and
it does not contain anything relating to X.


======================================================================

Error building k3b

======================================================================

checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for IceConnectionNumber in -lICE... no
checking for libXext... no
configure: error: We need a working libXext to proceed. Since configure
can't find it itself, we stop here assuming that make wouldn't find
them either.
error: Bad exit status from /var/tmp/rpm-tmp.23463 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.23463 (%build)




From mpeters at mac.com  Tue Dec 14 18:49:34 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 14 Dec 2004 18:49:34 +0000
Subject: Putting Flumotion into Fedora 4
In-Reply-To: <1103047912.11655.14.camel@localhost.localdomain> (from
	uraeus@gnome.org on Tue Dec 14 10:11:51 2004)
References: <1103047912.11655.14.camel@localhost.localdomain>
Message-ID: <1103050174l.7257l.0l@devel.mpeters.us>

On 12/14/2004 10:11:51 AM, Christian Fredrik Kalager Schaller wrote:

> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853
>

>From the Bugzilla -

>> We are wondering if the correct solution is for Fedora to set up a  
>> new
>> group, called media for instance, which also had the rights to  
>> access
>> the hardware.

I would agree with that - the only alternative I could think of is to  
have %post sed the console.perms file, but I don't think I personally  
would like an rpm that changes existing settings in there.

That would also benefit other apps that might need the devices when  
user not logged in at console as well, and should be just as secure if  
no users belong to the group if flumotion is not installed.

I personally always change my console.perms for /dev/dsp anyway so I  
can have cron record my favorite radio show while I'm at school - I  
expect others as well do this sort of thing already anyway for similar  
situations.




From perbj at stanford.edu  Tue Dec 14 19:16:18 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Tue, 14 Dec 2004 11:16:18 -0800
Subject: Putting Flumotion into Fedora 4
In-Reply-To: <1103050174l.7257l.0l@devel.mpeters.us>
References: <1103047912.11655.14.camel@localhost.localdomain>
	<1103050174l.7257l.0l@devel.mpeters.us>
Message-ID: <1103051779.3446.54.camel@localhost.localdomain>

On Tue, 2004-12-14 at 18:49 +0000, Michael A. Peters wrote:
> On 12/14/2004 10:11:51 AM, Christian Fredrik Kalager Schaller wrote:
> 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853
> >
> 
> >From the Bugzilla -
> 
> >> We are wondering if the correct solution is for Fedora to set up a  
> >> new
> >> group, called media for instance, which also had the rights to  
> >> access
> >> the hardware.

Maybe "multimedia"? The "media" word got so overloaded when CD-ROMs
started getting mounted in /media/cdrom etc...

> I would agree with that - the only alternative I could think of is to  
> have %post sed the console.perms file, but I don't think I personally  
> would like an rpm that changes existing settings in there.

Doesn't that sound like a complete and utter disaster? Permissions
changing willy-nilly depending on what you happen to install? And what
if the administrator actually wants to do something site-specific there
- I think that having local configuration in the console.perms seems
somewhat sane, doesn't it?

> That would also benefit other apps that might need the devices when  
> user not logged in at console as well, and should be just as secure if  
> no users belong to the group if flumotion is not installed.
> 
> I personally always change my console.perms for /dev/dsp anyway so I  
> can have cron record my favorite radio show while I'm at school - I  
> expect others as well do this sort of thing already anyway for similar  
> situations.

Absolutely. Think e.g. PVR applications - well, I guess that's pretty
much what your cron job is at the moment in some sense! ;) OK, so there
aren't any PVRs included in Fedora Core, but it would be som much easier
to get this done right if the core includes the potential to do it and
it's _very_ hard to do it in a non-hacky way without universal buy-in.

I don't think I understand Bill's comment in the bugzilla report about
the problems with the group solution - why could a new group not be
added on a distro upgrade?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853#c6

Cheers,
Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From kyrre at solution-forge.net  Tue Dec 14 19:17:02 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 14 Dec 2004 20:17:02 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <41BEC217.40208@hhs.nl>
References: <1102970777.27996.8.camel@kyrre> <41BEA052.7080008@hhs.nl>
	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>
	<41BEC217.40208@hhs.nl>
Message-ID: <1103051821.18333.2.camel@kyrre>

tir, 14.12.2004 kl. 11.36 skrev Hans de Goede:
> kyrre at solution-forge.net wrote:
> > Which driver (xorg.conf) and xorg verson is that?
> > 
> 
> Erm I'm not behind that machine right now, but its an FC2 install with 
> xorg upgraded from rawhide somewhere during FC3 testing. I'm using the 
> i810 driver afaik. The only problem I had was that the later xorg want 
> to load i915.o as drm module for the kernel and that wasn't shipped by 
> fedora at that time. I've filed a bug about this and later kernels have 
> it. I'm usign the latest kernel from FC2-updates.
> 
> BTW The reason for going to the rawhide xorg was that the FC2 xorg 
> crashes whenever a 3d screensaver kicks in, or maybe it was a powersave 
> problem, either way the current FC3 xorg should be fixed also.
> 
> Regards,
> 
> Hans
> 
> 

So you can confirm that rawhide xorg + newest stable kernel (then fc3
should work as well) works? Any news from those people actually doing
the driver development/testing/packaging?

I have checked bugzilla, but nothing of interest.

Same basically goes to the rage 128 (?), which also seems broken. The
vesa driver works there, though.

> 
> > 
> >>Huh,
> >>
> >>I've a 865G at work and that works fine even the 3D is ok.
> >>
> >>Regards,
> >>
> >>Hans
> >>
> >>
> >>Kyrre Ness Sjobak wrote:
> >>
> >>>Hello
> >>>
> >>>I just wonder, and i know it has been brought up a zillion times - but
> >>>what are the current status of the intel gfx (i815?) xorg driver? Any
> >>>updates (rpms) that could be easily pushed into my net via admin-script?
> >>>
> >>>The vesa driver works - but it refuses to do anything more than a bare
> >>>minimum resolution, and the intel driver has some... funny... side
> >>>effects. Not anything i would like to expose my users to, really
> >>>
> >>>Kyrre
> >>>
> >>
> >>--
> >>fedora-devel-list mailing list
> >>fedora-devel-list at redhat.com
> >>http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >>
> > 
> > 



From rahulsundaram at yahoo.co.in  Tue Dec 14 19:22:16 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Tue, 14 Dec 2004 11:22:16 -0800 (PST)
Subject: Putting Flumotion into Fedora 4
In-Reply-To: <1103051779.3446.54.camel@localhost.localdomain>
Message-ID: <20041214192216.70345.qmail@web8508.mail.in.yahoo.com>

Hi

> I don't think I understand Bill's comment in the
> bugzilla report about
> the problems with the group solution - why could a
> new group not be
> added on a distro upgrade?
>
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853#c6
> 

If I understand it correctly this has something to do
with anaconda design and rpm. It probably is easier to
do this is some particular package that requires it


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From rdieter at math.unl.edu  Tue Dec 14 19:26:34 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 14 Dec 2004 13:26:34 -0600 (CST)
Subject: k3b build error on x86_64
In-Reply-To: <1103049734.972.4.camel@apple.bananas.hopto.org>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
Message-ID: <Pine.LNX.4.61.0412141325360.5839@math.unl.edu>

On Tue, 14 Dec 2004, Si Jones wrote:
>
> Am having a few problems building things, the first was mplayer, and now
> it seems like k3b is having the exact same thing.
....
> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> checking for libXext... no
> configure: error: We need a working libXext to proceed. Since configure
> can't find it itself, we stop here assuming that make wouldn't find

Try
./configure --with-extra-libs=/usr/X11R6/%{_lib}

-- Rex



From si at bananas.hopto.org  Tue Dec 14 20:05:59 2004
From: si at bananas.hopto.org (Si Jones)
Date: Tue, 14 Dec 2004 20:05:59 +0000
Subject: k3b build error on x86_64
In-Reply-To: <Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
Message-ID: <1103054759.972.6.camel@apple.bananas.hopto.org>

On Tue, 2004-12-14 at 13:26 -0600, Rex Dieter wrote:
> On Tue, 14 Dec 2004, Si Jones wrote:
> >
> > Am having a few problems building things, the first was mplayer, and now
> > it seems like k3b is having the exact same thing.
> ....
> > checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> > checking for libXext... no
> > configure: error: We need a working libXext to proceed. Since configure
> > can't find it itself, we stop here assuming that make wouldn't find
> 
> Try
> ./configure --with-extra-libs=/usr/X11R6/%{_lib}
> 
> -- Rex
> 

am building it with the line

rpmbuild -bb /usr/src/redhat/SPECS/k3b.spec

is there anyway of passing that line to configure? or is there a config
for configure?



From rdieter at math.unl.edu  Tue Dec 14 20:09:26 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 14 Dec 2004 14:09:26 -0600 (CST)
Subject: k3b build error on x86_64
In-Reply-To: <1103054759.972.6.camel@apple.bananas.hopto.org>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
Message-ID: <Pine.LNX.4.61.0412141408440.20548@math.unl.edu>

On Tue, 14 Dec 2004, Si Jones wrote:

> On Tue, 2004-12-14 at 13:26 -0600, Rex Dieter wrote:
>> Try
>> ./configure --with-extra-libs=/usr/X11R6/%{_lib}
>
> am building it with the line
>
> rpmbuild -bb /usr/src/redhat/SPECS/k3b.spec
>
> is there anyway of passing that line to configure? or is there a config
> for configure?

Edit the k3b.spec and add
--with-extra-libs=/usr/X11R6/%{_lib}
to the %configure line

-- Rex



From si at bananas.hopto.org  Tue Dec 14 20:26:55 2004
From: si at bananas.hopto.org (Si Jones)
Date: Tue, 14 Dec 2004 20:26:55 +0000
Subject: k3b build error on x86_64
In-Reply-To: <Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
Message-ID: <1103056015.972.11.camel@apple.bananas.hopto.org>

On Tue, 2004-12-14 at 14:09 -0600, Rex Dieter wrote:

> Edit the k3b.spec and add
> --with-extra-libs=/usr/X11R6/%{_lib}
> to the %configure line
> 
> -- Rex
> 

Tried that and it's still the same path.

I also tried editing the configure file and ran the configure manually,
this seemed to change the path but still got the error about libXext....





From perbj at stanford.edu  Tue Dec 14 20:39:21 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Tue, 14 Dec 2004 12:39:21 -0800
Subject: k3b build error on x86_64
In-Reply-To: <1103056015.972.11.camel@apple.bananas.hopto.org>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
	<1103056015.972.11.camel@apple.bananas.hopto.org>
Message-ID: <1103056761.3446.73.camel@localhost.localdomain>

On Tue, 2004-12-14 at 20:26 +0000, Si Jones wrote:
> Tried that and it's still the same path.
> 
> I also tried editing the configure file and ran the configure manually,
> this seemed to change the path but still got the error about libXext....

You do have the xorg-X11-devel RPM installed, right? There may be a
missing BuildRequires in the k3b specfile that makes it fail instead of
complaining that this this package isn't installed. (I can't find that
BuildRequires in the specfile so I think that might be the problem.)

Good luck!
Per

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University



From rdieter at math.unl.edu  Tue Dec 14 20:45:43 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 14 Dec 2004 14:45:43 -0600 (CST)
Subject: k3b build error on x86_64
In-Reply-To: <1103056015.972.11.camel@apple.bananas.hopto.org>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
	<1103056015.972.11.camel@apple.bananas.hopto.org>
Message-ID: <Pine.LNX.4.61.0412141445200.2904@math.unl.edu>

On Tue, 14 Dec 2004, Si Jones wrote:

> On Tue, 2004-12-14 at 14:09 -0600, Rex Dieter wrote:
>
>> Edit the k3b.spec and add
>> --with-extra-libs=/usr/X11R6/%{_lib}
>> to the %configure line
>
> Tried that and it's still the same path.
>
> I also tried editing the configure file and ran the configure manually,
> this seemed to change the path but still got the error about libXext....

Time to send them a bug report then.  (-:
http://bugs.kde.org/

-- Rex



From si at bananas.hopto.org  Tue Dec 14 20:56:23 2004
From: si at bananas.hopto.org (Si Jones)
Date: Tue, 14 Dec 2004 20:56:23 +0000
Subject: k3b build error on x86_64
In-Reply-To: <1103056761.3446.73.camel@localhost.localdomain>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
	<1103056015.972.11.camel@apple.bananas.hopto.org>
	<1103056761.3446.73.camel@localhost.localdomain>
Message-ID: <1103057783.3603.0.camel@apple.bananas.hopto.org>

On Tue, 2004-12-14 at 12:39 -0800, Per Bjornsson wrote:

> You do have the xorg-X11-devel RPM installed, right? There may be a
> missing BuildRequires in the k3b specfile that makes it fail instead of
> complaining that this this package isn't installed. (I can't find that
> BuildRequires in the specfile so I think that might be the problem.)

Well hopefully this confirms it....

[root at apple ~]# rpm -qa | grep xorg-x11-devel
xorg-x11-devel-6.8.1-12.FC3.21
[root at apple ~]#

Cheers,



From si at bananas.hopto.org  Tue Dec 14 21:00:08 2004
From: si at bananas.hopto.org (Si Jones)
Date: Tue, 14 Dec 2004 21:00:08 +0000
Subject: k3b build error on x86_64
In-Reply-To: <Pine.LNX.4.61.0412141445200.2904@math.unl.edu>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
	<1103056015.972.11.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141445200.2904@math.unl.edu>
Message-ID: <1103058008.3603.5.camel@apple.bananas.hopto.org>


> Time to send them a bug report then.  (-:
> http://bugs.kde.org/
> 
> -- Rex
> 

I would do that but i don't belive that it is a bug as I have other
builds that fail on the same thing...

Regards,



From rdieter at math.unl.edu  Tue Dec 14 21:08:59 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 14 Dec 2004 15:08:59 -0600
Subject: k3b build error on x86_64
In-Reply-To: <1103058008.3603.5.camel@apple.bananas.hopto.org>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>	<1103054759.972.6.camel@apple.bananas.hopto.org>	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>	<1103056015.972.11.camel@apple.bananas.hopto.org>	<Pine.LNX.4.61.0412141445200.2904@math.unl.edu>
	<1103058008.3603.5.camel@apple.bananas.hopto.org>
Message-ID: <41BF566B.8040307@math.unl.edu>

Si Jones wrote:
>>Time to send them a bug report then.  (-:
>>http://bugs.kde.org/

> I would do that but i don't belive that it is a bug as I have other
> builds that fail on the same thing...

You'd be surprised how much software out there isn't (very) 
x86-aware/friendly (yet).


-- Rex



From otaylor at redhat.com  Tue Dec 14 21:08:00 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Tue, 14 Dec 2004 16:08:00 -0500
Subject: Can we fix the backspace key?
In-Reply-To: <41BF28E9.2050608@dma.org>
References: <41BF28E9.2050608@dma.org>
Message-ID: <1103058480.647.51.camel@localhost.localdomain>

On Tue, 2004-12-14 at 09:54 -0800, Don Mahurin wrote:
> Is there any way that we can undo the backwards backspace/delete key 
> bindings that were introduced in Redhat 6.2?
> 
> http://web.purplefrog.com/~thoth/philosophy/backspace-delete.html
> 
> So we could again have the standard bindings of Backspace=^H and Delete=^?

Fedora follows the Debian backspace configuration:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.8

has details and rationale. It will not be changed. Inconsistent 
configuration is far worse than any consistent configuration.

Regards,
							Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041214/29dd5d5e/attachment.sig>

From kyrre at solution-forge.net  Tue Dec 14 21:29:33 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 14 Dec 2004 22:29:33 +0100
Subject: Was: Re: trac is awesome - Is: things for core - gyum?
In-Reply-To: <cpmuvq$oi8$1@sea.gmane.org>
References: <cpmuvq$oi8$1@sea.gmane.org>
Message-ID: <1103059772.18333.24.camel@kyrre>

tir, 14.12.2004 kl. 15.56 skrev Neal D. Becker:
> trac http://projects.edgewall.com/trac/ is really awesome SCM/project
> management.  I installed it easily on FC3 using packages from DAG
> repository.  I highly recommend adding this!  It is GPL, of course.

As i am reading this list, i see more and more people recomending their
"favorite toy" (please dont misunderstand) - while no "important"
improvements for everyone are made. Many of the programs that are
recomended looks really great, and should definitively be in extras.

But then there is gyum. Even if i must admit that i have not tested it
very much (as my main platform is still FC2), i must admit that this
might give fedora and yum an edge it dosn't have today. And it does
(According to screenshots - i only have an old computer with XFCE
running fc3) have a panel aplet that can replace that poor old up2date
thing. It won't be a moment to late...

Only problem i have noticed with gyum so far, is that it does *appear*
to be hanging while getting the package list. That's an UI problem...

I would guess tchung is also on this list - is this due for fixing?

Comments from anybody else, that migth have more experience than me
using the app?

Kyrre Ness Sj?b?k



From kyrre at solution-forge.net  Tue Dec 14 21:33:07 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 14 Dec 2004 22:33:07 +0100
Subject: Was: Re: trac is awesome - Is: things for core - gyum?
In-Reply-To: <1103059772.18333.24.camel@kyrre>
References: <cpmuvq$oi8$1@sea.gmane.org>  <1103059772.18333.24.camel@kyrre>
Message-ID: <1103059986.18333.26.camel@kyrre>

Sorry for answering myself, the link:
http://fedoranews.org/tchung/gyum/2.0/



From christopher.hotchkiss at gmail.com  Tue Dec 14 21:46:06 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 14 Dec 2004 16:46:06 -0500
Subject: Stateless kickstart problem
In-Reply-To: <41BF2E4C.1000000@subarutelescope.org>
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
	<41BF2E4C.1000000@subarutelescope.org>
Message-ID: <7f48492a0412141346146a080e@mail.gmail.com>

Okay here is how I setup my basic stateless network. Please note that
I am still adding more functionality to it, but for the basics it does
work.

1. Requirements:
A server capable of serving rsync, dhcp, nfs, apache. They do not have
to be the same machine, you just need to have access.
A set of workstations, optimally one that has already been completely
setup. Meaning it allows for authentication across the network.

2. Workstation Setup
Setup a workstation with any *NIX style os, Fedora, FreeBSD, Gentoo,
etc.. I would highly recommend you setup nfs home directories, on a
server. Also an authentication scheme would be highly advisable.

3. Setup a snapshot on a rsync server.
An example rsyncd.conf file follows.
[code]
[stateless]
path=/srv/Workstation
comment=Post Workstation
uid=0
[/code]

Here is an example rsync command to do the copy.
[code]rsync -e ssh -av --exclude '/proc/*' --exclude '/sys/*'
IP-address-of-test-machine:/ /srv/Workstation
[/code]

4. Next setup a Fedora install tree and export it via nfs.

5. Make available the attached kickstart file via a web server. Please
remember to change the address of the install tree, and the address of
the snapshot.

6. You now have a choice, you can setup a dhcp server and use a pxe
boot to start the kickstart or you can make a kickstart install cd as
described at the following link.
http://fedora.redhat.com/docs/stateless/sn-caching-clients.html

That should be enough to get you guys going. I have also attached the
client-server program I use to individualize each computer after they
boot. I am still working on a set of scripts to make the snapshot
process a little more automated. It isn't that hard however to change
the rsyncd.conf and copy a directory, so it may not occur.

Happy Hacking and e-mail me if there are any problems with this.
-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ks-bootstrap.cfg
Type: application/octet-stream
Size: 2947 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041214/96b74b7c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netexec-client
Type: application/octet-stream
Size: 4075 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041214/96b74b7c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netexec-server
Type: application/octet-stream
Size: 8146 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041214/96b74b7c/attachment-0002.obj>

From no-reply-gw at fcp.homelinux.org  Tue Dec 14 22:01:35 2004
From: no-reply-gw at fcp.homelinux.org (=?iso-8859-1?B?VGhvbWFzIENodW5nICh0Y2h1bmcp?=)
Date: Tue, 14 Dec 2004 23:01:35 +0100
Subject: Was: Re: trac is awesome - Is: things for core - gyum?
In-Reply-To: <1103059772.18333.24.camel@kyrre>
Message-ID: <fc5efa84b5644ab906ee90614ec30ab1@fcp.homelinux.org>

> 
> Kyrre Ness Sjobak wrote:
> ...
> But then there is gyum. Even if i must admit that i have not tested it
> very much (as my main platform is still FC2)
> ...


Here is pre-built rpms for fc2:
http://fedoranews.org/tchung/gyum/2.0/fc2/


> 
> Kyrre Ness Sjobak wrote:
> ...
> Only problem i have noticed with gyum so far, is that it does *appear*
> to be hanging while getting the package list. That's an UI problem
> ...
> 


No, it's just slow. That's all. :)

Thomas Chung
FedoraNEWS.ORG





-- 
This is an email sent via the webforum on http://fcp.homelinux.org



From christopher.hotchkiss at gmail.com  Tue Dec 14 22:06:29 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 14 Dec 2004 17:06:29 -0500
Subject: Stateless kickstart problem
In-Reply-To: <7f48492a0412141346146a080e@mail.gmail.com>
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
	<41BF2E4C.1000000@subarutelescope.org>
	<7f48492a0412141346146a080e@mail.gmail.com>
Message-ID: <7f48492a041214140667257001@mail.gmail.com>

The only problem with this method, is that unless you are physically
present to tell the workstation to pxe boot, you must find a grub-pxe
bootloader. Then you can use the netexec program to switch the
defaults on the boot, to force a reinstall.

Granted this is not an elegant way but it does work, either physically
present, or the grub switch trick.
-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From kyrre at solution-forge.net  Tue Dec 14 22:22:16 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 14 Dec 2004 23:22:16 +0100
Subject: Was: Re: trac is awesome - Is: things for core - gyum?
In-Reply-To: <fc5efa84b5644ab906ee90614ec30ab1@fcp.homelinux.org>
References: <fc5efa84b5644ab906ee90614ec30ab1@fcp.homelinux.org>
Message-ID: <1103062936.18333.29.camel@kyrre>

tir, 14.12.2004 kl. 23.01 skrev Thomas Chung (tchung):
> > 
> > Kyrre Ness Sjobak wrote:
> > ...
> > But then there is gyum. Even if i must admit that i have not tested it
> > very much (as my main platform is still FC2)
> > ...
> 
> 
> Here is pre-built rpms for fc2:
> http://fedoranews.org/tchung/gyum/2.0/fc2/
> 
> 

My mind suddenly discovered that my test-pc is running fc3... and XFCE.

> > 
> > Kyrre Ness Sjobak wrote:
> > ...
> > Only problem i have noticed with gyum so far, is that it does *appear*
> > to be hanging while getting the package list. That's an UI problem
> > ...
> > 
> 
> 
> No, it's just slow. That's all. :)
> 

And that's a UI problem. It gets unresponsive while being slow, and
stupid people who think yum is a nice brand of noudle soup, x'es it, and
gnome come and offer to kill the chrashed app.

> Thomas Chung
> FedoraNEWS.ORG
> 
> 
> 
> 
> 
> -- 
> This is an email sent via the webforum on http://fcp.homelinux.org



From rgorosito at comarb.gov.ar  Tue Dec 14 21:59:35 2004
From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito)
Date: Tue, 14 Dec 2004 18:59:35 -0300
Subject: RFEs for PHP
Message-ID: <41BF6247.3070204@comarb.gov.ar>

Why soap is not enabled in php5 ? php5 without soap/wsdl is php4.99 ;-)
Any chance about get php built with --enable-pcntl to enable Process 
Control Functions in CLI ?

Thanks, Ricardo.-



From jspaleta at gmail.com  Tue Dec 14 22:32:25 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 14 Dec 2004 17:32:25 -0500
Subject: RFEs for PHP
In-Reply-To: <41BF6247.3070204@comarb.gov.ar>
References: <41BF6247.3070204@comarb.gov.ar>
Message-ID: <604aa7910412141432239e2411@mail.gmail.com>

On Tue, 14 Dec 2004 18:59:35 -0300, Ricardo Ariel Gorosito
<rgorosito at comarb.gov.ar> wrote:
> Why soap is not enabled in php5 ? php5 without soap/wsdl is php4.99 ;-)
> Any chance about get php built with --enable-pcntl to enable Process
> Control Functions in CLI ?

you filed this RFE in bugzilla right?

-jef



From rgorosito at comarb.gov.ar  Tue Dec 14 22:50:32 2004
From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito)
Date: Tue, 14 Dec 2004 19:50:32 -0300
Subject: RFEs for PHP
In-Reply-To: <604aa7910412141432239e2411@mail.gmail.com>
References: <41BF6247.3070204@comarb.gov.ar>
	<604aa7910412141432239e2411@mail.gmail.com>
Message-ID: <41BF6E38.7030007@comarb.gov.ar>

sorry, now yes.

#142901 RFE for SOAP support
#142903 RFE for PCNTL in CLI

Ricardo.-

Jeff Spaleta wrote:

>On Tue, 14 Dec 2004 18:59:35 -0300, Ricardo Ariel Gorosito
><rgorosito at comarb.gov.ar> wrote:
>  
>
>>Why soap is not enabled in php5 ? php5 without soap/wsdl is php4.99 ;-)
>>Any chance about get php built with --enable-pcntl to enable Process
>>Control Functions in CLI ?
>>    
>>
>
>you filed this RFE in bugzilla right?
>
>-jef
>
>  
>



From jamesaharrisonuk at yahoo.co.uk  Wed Dec 15 01:14:30 2004
From: jamesaharrisonuk at yahoo.co.uk (James Harrison)
Date: Tue, 14 Dec 2004 17:14:30 -0800 (PST)
Subject: Making yum relocateable
Message-ID: <20041215011430.23469.qmail@web25309.mail.ukl.yahoo.com>

Hi,

Ive sucessfully installed yum-2.0.8 to /opt/yum-2.0.8/.

However, some paths inside certain files are still hardcoded in place:
/etc/yum.conf, /usr/share/yum ....

Is there some compile option that sets these paths to be under the --prefix
path?

I sure this seems odd, bit I want to keep yum program/config files in a yum
directory.

(Wasnt sure where to send this email too - sorry if its in the wrong place)

Thanks for any help.

James


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 



From nbargnesi at gmail.com  Wed Dec 15 03:20:42 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Tue, 14 Dec 2004 22:20:42 -0500
Subject: k3b build error on x86_64
In-Reply-To: <41BF566B.8040307@math.unl.edu>
References: <1103049734.972.4.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141325360.5839@math.unl.edu>
	<1103054759.972.6.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141408440.20548@math.unl.edu>
	<1103056015.972.11.camel@apple.bananas.hopto.org>
	<Pine.LNX.4.61.0412141445200.2904@math.unl.edu>
	<1103058008.3603.5.camel@apple.bananas.hopto.org>
	<41BF566B.8040307@math.unl.edu>
Message-ID: <3077b8a0041214192020caad6d@mail.gmail.com>

>From k3b source, I use:
./configure --prefix=/usr --libdir=/usr/lib64 --enable-libsuffix=64
--disable-debug --with-qt-dir=/usr/lib64/qt-3.3
--with-qt-libraries=/usr/lib64/qt-3.3/lib
and everything works fine.
-Nick




On Tue, 14 Dec 2004 15:08:59 -0600, Rex Dieter <rdieter at math.unl.edu> wrote:
> Si Jones wrote:
> >>Time to send them a bug report then.  (-:
> >>http://bugs.kde.org/
> 
> > I would do that but i don't belive that it is a bug as I have other
> > builds that fail on the same thing...
> 
> You'd be surprised how much software out there isn't (very)
> x86-aware/friendly (yet).
> 
> 
> -- Rex
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From parklee_sel at yahoo.com  Wed Dec 15 03:59:52 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Tue, 14 Dec 2004 19:59:52 -0800 (PST)
Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358)
Message-ID: <20041215035952.17633.qmail@web51507.mail.yahoo.com>

Hi,

  Now, I'm using FC2 (linux-2.6.5-1.358), for some
reason, I need to disable CONFIG_KALLSYMS for kernel
development.

In /usr/src/linux/.config, we can see that
"CONFIG_KALLSYMS=y" is included in the General setup
section like the following: 
 
#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HOTPLUG=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 
But, when we run 'make menuconfig', we can only see
that the General setup section only contains the
following items:
  
  [*] Support for paging of anonymous memory (swap)  
  [*] System V IPC                                 
  [*] POSIX Message Queues                         
  [*] BSD Process Accounting                          
  [*] Sysctl support                                  
  [*] Auditing support                                
  [*]   Enable system-call auditing support           
  (17) Kernel log buffer size (16 => 64KB, 17 =>
128KB)        
  [*] Support for hot-pluggable devices               
  [ ] Kernel .config support                          
  [*] Configure standard kernel features (for small
systems)  ---> 
  [*] Optimize for size                               
 
Then, It seems that there is no place to disable
CONFIG_KALLSYMS (i.e. turn 'CONFIG_KALLSYMS=y' to
'CONFIG_KALLSYMS is not set'), How can I turn off the
'CONFIG_KALLSYMS' item?? Is CONFIG_KALLSYMS=y set
automatically by system?

Thanks,



=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From davej at redhat.com  Wed Dec 15 06:29:32 2004
From: davej at redhat.com (Dave Jones)
Date: Wed, 15 Dec 2004 01:29:32 -0500
Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358)
In-Reply-To: <20041215035952.17633.qmail@web51507.mail.yahoo.com>
References: <20041215035952.17633.qmail@web51507.mail.yahoo.com>
Message-ID: <20041215062932.GA9018@redhat.com>

On Tue, Dec 14, 2004 at 07:59:52PM -0800, Park Lee wrote:
 > Hi,
 > 
 >   Now, I'm using FC2 (linux-2.6.5-1.358), for some
 > reason, I need to disable CONFIG_KALLSYMS for kernel
 > development.
 > 
 > In /usr/src/linux/.config, we can see that
 > "CONFIG_KALLSYMS=y" is included in the General setup
 > section like the following: 
 >  
 >  
 > Then, It seems that there is no place to disable
 > CONFIG_KALLSYMS (i.e. turn 'CONFIG_KALLSYMS=y' to
 > 'CONFIG_KALLSYMS is not set'), How can I turn off the
 > 'CONFIG_KALLSYMS' item?? Is CONFIG_KALLSYMS=y set
 > automatically by system?

There was a missing initcall. Get the latest 2.6.9 errata
kernel for FC2, and use that instead.

		Dave



From parklee_sel at yahoo.com  Wed Dec 15 06:46:47 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Tue, 14 Dec 2004 22:46:47 -0800 (PST)
Subject: Differences between the kernel source in FC2 and the kernel source
	obtained from kernel.org?
Message-ID: <20041215064647.14650.qmail@web51506.mail.yahoo.com>

Hi,
  Is there any difference between the kernel source in
FC2(version 2.6.5-1.358) and the kernel source
(version 2.6.5)obtained from kernel.org?
  Can I also download a 2.6.5 (or higher)version
kernel source from kernel.org to replace the FC2's
origianl kernel source and compile the new downloaded
kernel source to yield a vmlinuz and run it as FC2's
kernel without any conflict? 
  Thank you.

=====
Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From j.w.r.degoede at hhs.nl  Wed Dec 15 07:10:20 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 15 Dec 2004 08:10:20 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <1103051821.18333.2.camel@kyrre>
References: <1102970777.27996.8.camel@kyrre>
	<41BEA052.7080008@hhs.nl>	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>	<41BEC217.40208@hhs.nl>
	<1103051821.18333.2.camel@kyrre>
Message-ID: <41BFE35C.8030309@hhs.nl>

Kyrre Ness Sjobak wrote:
> 
> So you can confirm that rawhide xorg + newest stable kernel (then fc3
> should work as well) works? Any news from those people actually doing
> the driver development/testing/packaging?
> 

Yes,

Although its an older rawhide xorg:
xorg-x11-6.7.99.902-4
With the following kernel:
kernel-2.6.9-1.6_FC2

Regards,

Hans



From parklee_sel at yahoo.com  Wed Dec 15 07:08:52 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Tue, 14 Dec 2004 23:08:52 -0800 (PST)
Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358)
In-Reply-To: <20041215062932.GA9018@redhat.com>
Message-ID: <20041215070852.95964.qmail@web51504.mail.yahoo.com>

On Wed, 15 Dec 2004 at 01:29, Dave Jones wrote:
>
> On Tue, Dec 14, 2004 at 07:59:52PM -0800, Park Lee 
> wrote:
> > Then, It seems that there is no place to disable
> > CONFIG_KALLSYMS (i.e. turn 'CONFIG_KALLSYMS=y' to
> > 'CONFIG_KALLSYMS is not set'), How can I turn off 
> > the 'CONFIG_KALLSYMS' item?? Is CONFIG_KALLSYMS=y 
> > set automatically by system?
>
> There was a missing initcall. Get the latest 2.6.9 
> errata kernel for FC2, and use that instead.

As FC2 originally use the 2.6.5 kernel, If I directly
use the latest 2.6.9 kernel in FC2, Will it cause some
conflict? (i.e. Can I safely update the original 2.6.5
kernel to the latest 2.6.9 kernel in FC2 without any
problem).

Thank you.


=====
Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From j.w.r.degoede at hhs.nl  Wed Dec 15 07:19:44 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 15 Dec 2004 08:19:44 +0100
Subject: Can we fix the backspace key?
In-Reply-To: <1103058480.647.51.camel@localhost.localdomain>
References: <41BF28E9.2050608@dma.org>
	<1103058480.647.51.camel@localhost.localdomain>
Message-ID: <41BFE590.4090304@hhs.nl>

Owen Taylor wrote:
> On Tue, 2004-12-14 at 09:54 -0800, Don Mahurin wrote:
> 
>>Is there any way that we can undo the backwards backspace/delete key 
>>bindings that were introduced in Redhat 6.2?
>>
>>http://web.purplefrog.com/~thoth/philosophy/backspace-delete.html
>>
>>So we could again have the standard bindings of Backspace=^H and Delete=^?
> 
> 
> Fedora follows the Debian backspace configuration:
> 
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.8
> 
> has details and rationale. It will not be changed. Inconsistent 
> configuration is far worse than any consistent configuration.
> 
> Regards,
> 							Owen
> 
> 

If we still follow the debian backspace configuration then why is kbs 
for xterm ^H according to ncurses?

Don't get me wqrong I think its a fine idea to follow the debian keyb 
guidelines as we've done for a while, but with FC3 we are not following 
them consistently.

Afaik gnome-terminal and konsole send ascii-del for backspace, but xterm 
sends ctrl-H and ncurses contains ctrl-H for the xterm terminfo entry.

So that is NOT consistent.

Regards,

Hans





From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 15 09:56:41 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 15 Dec 2004 10:56:41 +0100
Subject: Can we fix the backspace key?
In-Reply-To: <41BFE590.4090304@hhs.nl> (Hans de Goede's message of "Wed, 15
	Dec 2004 08:19:44 +0100")
References: <41BF28E9.2050608@dma.org>
	<1103058480.647.51.camel@localhost.localdomain>
	<41BFE590.4090304@hhs.nl>
Message-ID: <87sm67zxye.fsf@kosh.ultra.csn.tu-chemnitz.de>

j.w.r.degoede at hhs.nl (Hans de Goede) writes:

>>> Is there any way that we can undo the backwards backspace/delete
>>> key bindings that were introduced in Redhat 6.2?
> ...
> If we still follow the debian backspace configuration then why is kbs
> for xterm ^H according to ncurses?

I think the current misbehavior of xterm is caused by

| * Fr Jun 18 2004 Mike A. Harris <mharris at redhat.com> 191-1
| - Disabled xterm-resources-redhat.patch to see what if anything breaks, as
|   it no longer applies cleanly.  Hopefully we can just ship stock xterm
|   resources now, although I realize that is more likely to be a pie in the
|   sky fantasy once the bug reports trickle in from this change.  ;o)


Using

| XTerm.ttyModes:         erase ^?
| XTerm*metaSendsEscape:  true

fixes most of the issues.



Enrico



From kumarabhijit at gmail.com  Wed Dec 15 10:05:57 2004
From: kumarabhijit at gmail.com (abhijit kumar)
Date: Wed, 15 Dec 2004 15:35:57 +0530
Subject: effect of parameter in scheduling of kernel2.4.26
Message-ID: <3c7f53f00412150205168b2d18@mail.gmail.com>

Dear Developers!
    I have introdued a new SCHEDULING POLICY in my linux kerenel-2.4.26.

My scheduling algorithm is different than SCHED_OTHER policy in following ways?

1. Time slice is 100 ms in place of 50 ms. (kernel/sched.c TICK_SCALE
is redefined)
2. Stack limit is 16 mb in place of 8mb.(linux/sched.h #define
_STK_LIM	(16*1024*1024) )
3.Max_COUNTER is for 400ms (linux/sched.h)
4.I am giving more weight to process running in current data segment.
( if (p->mm == this_mm || !p->mm)
			weight += 5; /* I am giving significant advantage to the current MM */ )
5.i am giving significant weight to SCHED_MY process so even a real
time process may loose slight advantage.so in forking processes change
scheduling policy of one process as SCHED_RR.It may be good to
generate similar programme with four different SCHED algorithm and
compare their time got by struct rusage fields.
6.It leads to preemption even the current process priority is as good
as next process. (preemption_goodness subroutine)
7.Timeout is also defined in case of
SCHED_MY(#define	MAX_SCHEDULE_TIMEOUT	2*LONG_MAX /linux/sched.h)
  Make the current task sleep until @timeout jiffies have elapsed.It
also assures that Task will be in TASK_RUNNING after
schedule_timeout() has occured.
8. move an exhausted  process to be last in runqueue.Inspired by SCHED_RR.

                                      I am n't clear about what should
be the effect of following changes on actual scheduling.Please explain
me the importance of these parameters and, also suggest some
application running which I can notice the changes. I am usung
"getrusage( )" function to see different parametter values.

Eagerly waiting for your reply!

Thanking You
Abhijit Kumar



From kyrre at solution-forge.net  Wed Dec 15 11:52:15 2004
From: kyrre at solution-forge.net (kyrre at solution-forge.net)
Date: Wed, 15 Dec 2004 12:52:15 +0100 (CET)
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <41BFE35C.8030309@hhs.nl>
References: <1102970777.27996.8.camel@kyrre><41BEA052.7080008@hhs.nl>	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>	<41BEC217.40208@hhs.nl><1103051821.18333.2.camel@kyrre>
	<41BFE35C.8030309@hhs.nl>
Message-ID: <32845.81.191.130.121.1103111535.squirrel@solution-forge.net>

> Kyrre Ness Sjobak wrote:
>>
>> So you can confirm that rawhide xorg + newest stable kernel (then fc3
>> should work as well) works? Any news from those people actually doing
>> the driver development/testing/packaging?
>>
>
> Yes,
>
> Although its an older rawhide xorg:
> xorg-x11-6.7.99.902-4
> With the following kernel:
> kernel-2.6.9-1.6_FC2
>

Great!
Ill try it out tomorrow. (ill go with the newest...)

Any official stable updates yet?



From j.w.r.degoede at hhs.nl  Wed Dec 15 12:08:05 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 15 Dec 2004 13:08:05 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <32845.81.191.130.121.1103111535.squirrel@solution-forge.net>
References: <1102970777.27996.8.camel@kyrre><41BEA052.7080008@hhs.nl>	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>	<41BEC217.40208@hhs.nl><1103051821.18333.2.camel@kyrre>	<41BFE35C.8030309@hhs.nl>
	<32845.81.191.130.121.1103111535.squirrel@solution-forge.net>
Message-ID: <41C02925.6000600@hhs.nl>

kyrre at solution-forge.net wrote:
>>Kyrre Ness Sjobak wrote:
>>
>>>So you can confirm that rawhide xorg + newest stable kernel (then fc3
>>>should work as well) works? Any news from those people actually doing
>>>the driver development/testing/packaging?
>>>
>>
>>Yes,
>>
>>Although its an older rawhide xorg:
>>xorg-x11-6.7.99.902-4
>>With the following kernel:
>>kernel-2.6.9-1.6_FC2
>>
> 
> 
> Great!
> Ill try it out tomorrow. (ill go with the newest...)
> 
> Any official stable updates yet?
> 

I just upgraded to the latest rawhide xorg, still works fine, warning: 
you do need to also upgrade your glibc!

Regards,

Hans




From buildsys at redhat.com  Wed Dec 15 13:20:27 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 15 Dec 2004 08:20:27 -0500
Subject: rawhide report: 20041215 changes
Message-ID: <200412151320.iBFDKRx07965@porkchop.devel.redhat.com>

 

 
Updated Packages:

binutils-2.15.92.0.2-11
-----------------------
* Tue Dec 14 2004 Jakub Jelinek <jakub at redhat.com> 2.15.92.0.2-11
- fix a longstanding -z relro bug

* Mon Dec 13 2004 Jakub Jelinek <jakub at redhat.com> 2.15.92.0.2-10
- avoid unnecessary gap with -z relro showing on i686 libc.so
- ppc64 --emit-relocs fix (Alan Modra)
- don't crash if STT_SECTION symbol has incorrect st_shndx (e.g. SHN_ABS,
  as created by nasm; #142181)
- don't try to make absptr LSDAs relative if they don't have relocations
  against them (Alan Modra, #141162)

* Wed Oct 27 2004 Jakub Jelinek <jakub at redhat.com> 2.15.92.0.2-5.EL4
- fix ar xo (#104344)

gcc-3.4.3-10
------------
* Mon Dec 13 2004 Jakub Jelinek  <jakub at redhat.com> 3.4.3-10
- update from gcc-3_4-branch
  - PRs target/18932, target/17025, c++/18731
- fix _Jv_{Start,End}OfInterpreter computation (Andrew Haley, #142611,
  PRs java/18036, java/13468)
- avoid multiple evaluation of sqrt and other math builtins when
  not -ffast-math (#142603, PR middle-end/18951)
- remove leading underscore from /usr/libexec/getconf/default
  symlink target

gcc4-4.0.0-0.15
---------------
* Tue Dec 14 2004 Jakub Jelinek  <jakub at redhat.com> 4.0.0-0.15
- update from trunk
  - fix tree inlining related ICE (Alexandre Oliva, #141145)
- avoid multiple evaluation of sqrt and other math builtins when
  not -ffast-math (#142603, PR middle-end/18951)

glibc-2.3.3-92
--------------
* Tue Dec 14 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-92
- update from CVS
- fix /usr/libexec/getconf filenames generation

* Tue Dec 14 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-91
- update from CVS
  - double buffer size in getXXbyYY or getXXent on ERANGE
    instead of adding BUFLEN (#142617)
  - avoid busy loop in malloc if another thread is doing fork
    (#142214)
  - some more realloc corruption checks
  - fix getconf _POSIX_V6_WIDTH_RESTRICTED_ENVS output,
    tweak /usr/libexec/getconf/ filenames

grep-2.5.1-42
-------------
* Tue Dec 14 2004 Tim Waugh <twaugh at redhat.com> 2.5.1-42
- Further UTF-8 processing avoided since a '\n' byte is always an
  end-of-line character in that encoding.

kdelibs-6:3.3.2-0.3
-------------------
* Tue Dec 14 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.3
- apply the patch to fix Konqueror Window Injection Vulnerability #142510
  CAN-2004-1158,  Thanks to KDE security team
- Security Advisory: plain text password exposure, #142487
  thanks to KDE security team

kdemultimedia-6:3.3.2-0.1
-------------------------
* Sun Dec 05 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.1
- update to 3.3.2

* Sat Oct 16 2004 Than Ngo <than at redhat.com> 6:3.3.1-2
- rhel rebuilt

parted-1.6.19-2
---------------
* Tue Dec 14 2004 Jeremy Katz <katzj at redhat.com> - 1.6.19-2
- add support for Promise SX8 devices

psmisc-21.5-2
-------------
* Tue Dec 14 2004 Karel Zak <kzak at redhat.com> 21.5-2
- use other way for psmisc-21.5-term.patch

pyparted-1.6.9-2
----------------
* Tue Dec 14 2004 Jeremy Katz <katzj at redhat.com> - 1.6.9-2
- add support for sx8 devices

readline-4.3-14
---------------
* Mon Nov 29 2004 Tim Waugh <twaugh at redhat.com> 4.3-14
- Added URL tag (bug #141106).

rpmdb-fedora-1:4-0.20041215
---------------------------

selinux-policy-strict-1.19.13-1
-------------------------------
* Sat Dec 11 2004 Dan Walsh <dwalsh at redhat.com> 1.19-13-1
- Update latest from NSA

tcl-8.4.9-2
-----------
* Tue Dec 14 2004 Jens Petersen <petersen at redhat.com> - 8.4.9-2
- move tclConfig.sh into -devel (Axel Thimm, 142724)

tk-8.4.9-2
----------
* Tue Dec 14 2004 Jens Petersen <petersen at redhat.com> - 8.4.9-2
- move tkConfig.sh into -devel (Axel Thimm, 142724)

vsftpd-2.0.1-7
--------------
* Tue Dec 14 2004 Radek Vokal <rvokal at redhat.com> 2.0.1-7
- fixing directory in vsftpd.pam file (#142805)



From fedora-devel at camperquake.de  Wed Dec 15 13:56:57 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Wed, 15 Dec 2004 14:56:57 +0100
Subject: rawhide report: 20041213 changes
In-Reply-To: <200412131257.iBDCv8Q23671@porkchop.devel.redhat.com>
References: <200412131257.iBDCv8Q23671@porkchop.devel.redhat.com>
Message-ID: <20041215145657.24b08a09@nausicaa.camperquake.de>

Hi.

Build System <buildsys at redhat.com> wrote:

> * Sat Dec 11 2004 Dave Jones <davej at redhat.com>
> - Workaround broken pci posting in AGPGART.

Dave, I already read about this (and the associated can of worms) in your
blog. Are these bugs performance critical, i.e. does fixing them make AGP
faster?

-- 
"Anonymous CVS heisst: Kein Einchecken, nur Auschecken. So eine Art
inverses Hotel California."                          -- Kristian Koehntopp



From otaylor at redhat.com  Wed Dec 15 14:42:52 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Wed, 15 Dec 2004 09:42:52 -0500
Subject: Can we fix the backspace key?
In-Reply-To: <41BFE590.4090304@hhs.nl>
References: <41BF28E9.2050608@dma.org>
	<1103058480.647.51.camel@localhost.localdomain>
	<41BFE590.4090304@hhs.nl>
Message-ID: <1103121772.647.83.camel@localhost.localdomain>

On Wed, 2004-12-15 at 08:19 +0100, Hans de Goede wrote:
> Owen Taylor wrote:
> > On Tue, 2004-12-14 at 09:54 -0800, Don Mahurin wrote:
> > 
> >>Is there any way that we can undo the backwards backspace/delete key 
> >>bindings that were introduced in Redhat 6.2?
> >>
> >>http://web.purplefrog.com/~thoth/philosophy/backspace-delete.html
> >>
> >>So we could again have the standard bindings of Backspace=^H and Delete=^?
> > 
> > 
> > Fedora follows the Debian backspace configuration:
> > 
> > http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.8
> > 
> > has details and rationale. It will not be changed. Inconsistent 
> > configuration is far worse than any consistent configuration.
> > 
> > Regards,
> > 							Owen
> > 
> > 
> 
> If we still follow the debian backspace configuration then why is kbs 
> for xterm ^H according to ncurses?
> 
> Don't get me wqrong I think its a fine idea to follow the debian keyb 
> guidelines as we've done for a while, but with FC3 we are not following 
> them consistently.
> 
> Afaik gnome-terminal and konsole send ascii-del for backspace, but xterm 
> sends ctrl-H and ncurses contains ctrl-H for the xterm terminfo entry.
> 
> So that is NOT consistent.

Well, you are proving the point here of why sticking to a consistent
policy here is essential. If there was no policy, people might start
changing apps to match xterm, and the whole tower of cards would
come crashing down again.

If you find bugs please file them.

Thanks,
							Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041215/479f9e78/attachment.sig>

From jmrenoua at alcove.fr  Wed Dec 15 15:27:10 2004
From: jmrenoua at alcove.fr (Jean-Marie Renouard)
Date: Wed, 15 Dec 2004 16:27:10 +0100
Subject: Stateless livecd problem
In-Reply-To: <7f48492a041214140667257001@mail.gmail.com>
References: <41BE44E1.3070708@subarutelescope.org>	<7f48492a04121323234036bb49@mail.gmail.com>	<41BF2E4C.1000000@subarutelescope.org>	<7f48492a0412141346146a080e@mail.gmail.com>
	<7f48492a041214140667257001@mail.gmail.com>
Message-ID: <41C057CE.3080807@alcove.fr>

Hello,

I try to make a liveCD from a fresh installed Fedora Core 3.
The CD boots, the hardware is well detected.
1) I have some SELinux error messages ( normal ?)

2) As the filesystem is mount in read only mode, none of the services 
running on my original system
can start.
They try to write locks under /var/locks/subsys according to their 
/etc/init.d scripts but they can't.

How can we solve this problem in order to be able to restart a server 
from a livecd with the same services running ?
How can we set up or mount /var in a read/write mode and keep original 
data available too ?

Best regards,
Jean-Marie Renouard



From strange at nsk.no-ip.org  Wed Dec 15 15:31:17 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 15 Dec 2004 15:31:17 +0000
Subject: Stateless livecd problem
In-Reply-To: <41C057CE.3080807@alcove.fr>
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
	<41BF2E4C.1000000@subarutelescope.org>
	<7f48492a0412141346146a080e@mail.gmail.com>
	<7f48492a041214140667257001@mail.gmail.com>
	<41C057CE.3080807@alcove.fr>
Message-ID: <20041215153117.GB31637@nsk.no-ip.org>

On Wed, Dec 15, 2004 at 04:27:10PM +0100, Jean-Marie Renouard wrote:
> Hello,
> 
> I try to make a liveCD from a fresh installed Fedora Core 3.
> The CD boots, the hardware is well detected.
> 1) I have some SELinux error messages ( normal ?)
> 
> 2) As the filesystem is mount in read only mode, none of the services 
> running on my original system
> can start.
> They try to write locks under /var/locks/subsys according to their 
> /etc/init.d scripts but they can't.
> 
> How can we solve this problem in order to be able to restart a server 
> from a livecd with the same services running ?
> How can we set up or mount /var in a read/write mode and keep original 
> data available too ?

Make, on boot, /var a tmpfs filesystem and populate it with the var
files on cd.

Regards,
Luciano Rocha



From fedora-devel at camperquake.de  Wed Dec 15 15:31:18 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Wed, 15 Dec 2004 16:31:18 +0100
Subject: Stateless livecd problem
In-Reply-To: <41C057CE.3080807@alcove.fr>;
	from jmrenoua@alcove.fr on Wed, Dec 15, 2004 at 04:27:10PM +0100
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
	<41BF2E4C.1000000@subarutelescope.org>
	<7f48492a0412141346146a080e@mail.gmail.com>
	<7f48492a041214140667257001@mail.gmail.com>
	<41C057CE.3080807@alcove.fr>
Message-ID: <20041215163118.A16067@ryoko.camperquake.de>

On Wed, Dec 15, 2004 at 04:27:10PM +0100, Jean-Marie Renouard wrote:

> How can we solve this problem in order to be able to restart a server 
> from a livecd with the same services running ?
> How can we set up or mount /var in a read/write mode and keep original 
> data available too ?

The usual approach is to mount the directories needed as tmpfs (/var/run,
for example). Most of it is volatile data anyway, so it does not matter if
the contents disappear when rebooting.



From kyrre at solution-forge.net  Wed Dec 15 16:26:22 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 15 Dec 2004 17:26:22 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <41C02925.6000600@hhs.nl>
References: <1102970777.27996.8.camel@kyrre><41BEA052.7080008@hhs.nl>
	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>
	<41BEC217.40208@hhs.nl><1103051821.18333.2.camel@kyrre>
	<41BFE35C.8030309@hhs.nl>
	<32845.81.191.130.121.1103111535.squirrel@solution-forge.net>
	<41C02925.6000600@hhs.nl>
Message-ID: <1103127982.2711.0.camel@kyrre>

ons, 15.12.2004 kl. 13.08 skrev Hans de Goede:
> kyrre at solution-forge.net wrote:
> >>Kyrre Ness Sjobak wrote:
> >>
> >>>So you can confirm that rawhide xorg + newest stable kernel (then fc3
> >>>should work as well) works? Any news from those people actually doing
> >>>the driver development/testing/packaging?
> >>>
> >>
> >>Yes,
> >>
> >>Although its an older rawhide xorg:
> >>xorg-x11-6.7.99.902-4
> >>With the following kernel:
> >>kernel-2.6.9-1.6_FC2
> >>
> > 
> > 
> > Great!
> > Ill try it out tomorrow. (ill go with the newest...)
> > 
> > Any official stable updates yet?
> > 
> 
> I just upgraded to the latest rawhide xorg, still works fine, warning: 
> you do need to also upgrade your glibc!
> 
> Regards,
> 
> Hans
> 

Hokay. It's a production machine, altough a workstation, so it it goes
to **** it would only be a reinstall. No data lost...



From mike at navi.cx  Wed Dec 15 16:57:54 2004
From: mike at navi.cx (Mike Hearn)
Date: Wed, 15 Dec 2004 16:57:54 +0000
Subject: Making yum relocateable
References: <20041215011430.23469.qmail@web25309.mail.ukl.yahoo.com>
Message-ID: <pan.2004.12.15.16.57.54.181816@navi.cx>

On Tue, 14 Dec 2004 17:14:30 -0800, James Harrison wrote:
> Ive sucessfully installed yum-2.0.8 to /opt/yum-2.0.8/.
> 
> However, some paths inside certain files are still hardcoded in place:
> /etc/yum.conf, /usr/share/yum ....
> 
> Is there some compile option that sets these paths to be under the --prefix
> path?

Ideally you wouldn't need to be sedding the sources or having a file/env
var telling a program where it is. It'd just know. 

This is possible with ELF binaries because they can read /proc/self/exe or
parse /proc/self/maps, but with scripts I'm not sure it works. You can do
something like the Perl Findbin module which involves examining argv[0]
and possibly scanning the path, but this is a rather nasty hack.

I'd like the kernel to provide some way for scripts to locate their
absolute path when run using a shebang line but I have no idea how hard
that'd be to implement ...

thanks -mike



From davej at redhat.com  Wed Dec 15 17:44:02 2004
From: davej at redhat.com (Dave Jones)
Date: Wed, 15 Dec 2004 12:44:02 -0500
Subject: rawhide report: 20041213 changes
In-Reply-To: <20041215145657.24b08a09@nausicaa.camperquake.de>
References: <200412131257.iBDCv8Q23671@porkchop.devel.redhat.com>
	<20041215145657.24b08a09@nausicaa.camperquake.de>
Message-ID: <20041215174402.GB11271@redhat.com>

On Wed, Dec 15, 2004 at 02:56:57PM +0100, Ralf Ertzinger wrote:
 
 > > * Sat Dec 11 2004 Dave Jones <davej at redhat.com>
 > > - Workaround broken pci posting in AGPGART.
 > 
 > Dave, I already read about this (and the associated can of worms) in your
 > blog. Are these bugs performance critical, i.e. does fixing them make AGP
 > faster?

No, purely a stability problem.  There's very little code in the agpgart
driver thats actually performance critical, as most of it is just used
during startup. The ioctl is the only thing thats used outside of that,
which sets up a bunch of tables, and points hw registers at them.
The hardware does most of the work.

		Dave



From j.w.r.degoede at hhs.nl  Wed Dec 15 18:13:54 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 15 Dec 2004 19:13:54 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <1103127982.2711.0.camel@kyrre>
References: <1102970777.27996.8.camel@kyrre><41BEA052.7080008@hhs.nl>	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>	<41BEC217.40208@hhs.nl><1103051821.18333.2.camel@kyrre>	<41BFE35C.8030309@hhs.nl>	<32845.81.191.130.121.1103111535.squirrel@solution-forge.net>	<41C02925.6000600@hhs.nl>
	<1103127982.2711.0.camel@kyrre>
Message-ID: <41C07EE2.9040206@hhs.nl>



Kyrre Ness Sjobak wrote:
> ons, 15.12.2004 kl. 13.08 skrev Hans de Goede:
> 
>>kyrre at solution-forge.net wrote:
>>
>>>>Kyrre Ness Sjobak wrote:
>>>>
>>>>
>>>>>So you can confirm that rawhide xorg + newest stable kernel (then fc3
>>>>>should work as well) works? Any news from those people actually doing
>>>>>the driver development/testing/packaging?
>>>>>
>>>>
>>>>Yes,
>>>>
>>>>Although its an older rawhide xorg:
>>>>xorg-x11-6.7.99.902-4
>>>>With the following kernel:
>>>>kernel-2.6.9-1.6_FC2
>>>>
>>>
>>>
>>>Great!
>>>Ill try it out tomorrow. (ill go with the newest...)
>>>
>>>Any official stable updates yet?
>>>
>>
>>I just upgraded to the latest rawhide xorg, still works fine, warning: 
>>you do need to also upgrade your glibc!
>>
>>Regards,
>>
>>Hans
>>
> 
> 
> Hokay. It's a production machine, altough a workstation, so it it goes
> to **** it would only be a reinstall. No data lost...
> 
Another option should be the FC3 xorg, my previous rawhide version was 
from before the FC3 release.

Regards,

Hans



From parklee_sel at yahoo.com  Wed Dec 15 18:30:14 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Wed, 15 Dec 2004 10:30:14 -0800 (PST)
Subject: How to disable CONFIG_KALLSYMS in FC2 (kernel 2.6.5-1.358)
In-Reply-To: <1103101834.19649.74.camel@tudor.e.kth.se>
Message-ID: <20041215183014.49450.qmail@web51503.mail.yahoo.com>

On Wed, 15 Dec 2004 at 10:10, Alexander Bostr?m wrote:
>
> Dave refers to the latest FC2 update kernel, not 
> the latest kernel from kernel.org. It is designed 
> to work with FC2. You will get the latest update 
> kernel along with a lot of other official FC2 
> update packages by running up2date, which is 
> strongly recommended.

Thanks a lot.

But, Would you please tell me where I can get it?
(i.e. the latest FC2 update kernel. that is, the
latest 2.6.9 errata kernel for FC2)


=====
Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From kyrre at solution-forge.net  Wed Dec 15 19:09:12 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Wed, 15 Dec 2004 20:09:12 +0100
Subject: Status on that intel GFX chip? + r128
In-Reply-To: <41C07EE2.9040206@hhs.nl>
References: <1102970777.27996.8.camel@kyrre><41BEA052.7080008@hhs.nl>
	<32833.81.191.130.121.1103020241.squirrel@solution-forge.net>
	<41BEC217.40208@hhs.nl><1103051821.18333.2.camel@kyrre>
	<41BFE35C.8030309@hhs.nl>
	<32845.81.191.130.121.1103111535.squirrel@solution-forge.net>
	<41C02925.6000600@hhs.nl> <1103127982.2711.0.camel@kyrre>
	<41C07EE2.9040206@hhs.nl>
Message-ID: <1103137751.2711.20.camel@kyrre>

ons, 15.12.2004 kl. 19.13 skrev Hans de Goede:
> Kyrre Ness Sjobak wrote:
> > ons, 15.12.2004 kl. 13.08 skrev Hans de Goede:
> > 
> >>kyrre at solution-forge.net wrote:
> >>
> >>>>Kyrre Ness Sjobak wrote:
> >>>>
> >>>>
> >>>>>So you can confirm that rawhide xorg + newest stable kernel (then fc3
> >>>>>should work as well) works? Any news from those people actually doing
> >>>>>the driver development/testing/packaging?
> >>>>>
> >>>>
> >>>>Yes,
> >>>>
> >>>>Although its an older rawhide xorg:
> >>>>xorg-x11-6.7.99.902-4
> >>>>With the following kernel:
> >>>>kernel-2.6.9-1.6_FC2
> >>>>
> >>>
> >>>
> >>>Great!
> >>>Ill try it out tomorrow. (ill go with the newest...)
> >>>
> >>>Any official stable updates yet?
> >>>
> >>
> >>I just upgraded to the latest rawhide xorg, still works fine, warning: 
> >>you do need to also upgrade your glibc!
> >>
> >>Regards,
> >>
> >>Hans
> >>
> > 
> > 
> > Hokay. It's a production machine, altough a workstation, so it it goes
> > to **** it would only be a reinstall. No data lost...
> > 
> Another option should be the FC3 xorg, my previous rawhide version was 
> from before the FC3 release.
> 
> Regards,
> 
> Hans

It has a (not fully) up2date fc3 xorg. Hmm... Maybe i should just try
whatever happens to be in yum right now, and if that don't work, try
rawhide?

...

Kyrre



From linuxromeo at yahoo.com  Wed Dec 15 19:41:02 2004
From: linuxromeo at yahoo.com (linux romeo)
Date: Wed, 15 Dec 2004 11:41:02 -0800 (PST)
Subject: mysql 4
In-Reply-To: <41BF6E38.7030007@comarb.gov.ar>
Message-ID: <20041215194102.58848.qmail@web90105.mail.scd.yahoo.com>

hello list,
          I have recently started using fc2 moving
from mandrake 10 ......I want to ask why fc still has
mysql 3.323 .....I tried to install mysql 4 rpm but
gave me lots dep problem.....it there any any fc rpm
for that ...i tried seraching for it but could'nt find
4...

rgds,
romeo

=====



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail



From rahulsundaram at yahoo.co.in  Wed Dec 15 19:44:23 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 15 Dec 2004 11:44:23 -0800 (PST)
Subject: mysql 4
In-Reply-To: <20041215194102.58848.qmail@web90105.mail.scd.yahoo.com>
Message-ID: <20041215194423.44080.qmail@web8502.mail.in.yahoo.com>


--- linux romeo <linuxromeo at yahoo.com> wrote:

> hello list,
>           I have recently started using fc2 moving
> from mandrake 10 ......I want to ask why fc still
> has
> mysql 3.323 .....

this question has been asked and answered both in this
list and the users list multiple times. Please search
the archives. 


=====
Regards
Rahul Sundaram


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail



From linuxromeo at yahoo.com  Wed Dec 15 19:47:42 2004
From: linuxromeo at yahoo.com (linux romeo)
Date: Wed, 15 Dec 2004 11:47:42 -0800 (PST)
Subject: fc3 display bug ?
In-Reply-To: <32845.81.191.130.121.1103111535.squirrel@solution-forge.net>
Message-ID: <20041215194742.73339.qmail@web90110.mail.scd.yahoo.com>


hello list ,
            I recently tried to upgrade fc2 to fc3
using a dvd but as soon i enter graphical install my
screen freezes...i then tried installing thru expert
install though i was successful ...i am not able start
x it hangs there !! is it known bug ? or some othe
problem my mo is vesta (not sure abt model no...i got
3 yrs back) with 733  mhz celeron
in this pc fc2 was running fine 

rgds,
romeo

=====



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From rahulsundaram at yahoo.co.in  Wed Dec 15 19:54:23 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 15 Dec 2004 11:54:23 -0800 (PST)
Subject: fc3 display bug ?
In-Reply-To: <20041215194742.73339.qmail@web90110.mail.scd.yahoo.com>
Message-ID: <20041215195423.18417.qmail@web8507.mail.in.yahoo.com>


--- linux romeo <linuxromeo at yahoo.com> wrote:

> 
> hello list ,
>             I recently tried to upgrade fc2 to fc3
> using a dvd but as soon i enter graphical install my
> screen freezes...i then tried installing thru expert
> install though i was successful ...i am not able
> start
> x it hangs there !! 

ask in the users list.

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250



From linuxromeo at yahoo.com  Wed Dec 15 19:56:26 2004
From: linuxromeo at yahoo.com (linux romeo)
Date: Wed, 15 Dec 2004 11:56:26 -0800 (PST)
Subject: fc3 display bug ?
In-Reply-To: <20041215195423.18417.qmail@web8507.mail.in.yahoo.com>
Message-ID: <20041215195626.4094.qmail@web90109.mail.scd.yahoo.com>

ok rahul
sorry it seems i joined wrong list :-)

--- Rahul Sundaram <rahulsundaram at yahoo.co.in> wrote:

> 
> --- linux romeo <linuxromeo at yahoo.com> wrote:
> 
> > 
> > hello list ,
> >             I recently tried to upgrade fc2 to fc3
> > using a dvd but as soon i enter graphical install
> my
> > screen freezes...i then tried installing thru
> expert
> > install though i was successful ...i am not able
> > start
> > x it hangs there !! 
> 
> ask in the users list.
> 
> =====
> Regards
> Rahul Sundaram
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - now with 250MB free storage. Learn
> more.
> http://info.mail.yahoo.com/mail_250
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
>
http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


=====



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250



From shiva at sewingwitch.com  Wed Dec 15 20:34:05 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 15 Dec 2004 12:34:05 -0800
Subject: mysql 4
In-Reply-To: <20041215194423.44080.qmail@web8502.mail.in.yahoo.com>
References: <20041215194423.44080.qmail@web8502.mail.in.yahoo.com>
Message-ID: <51CE4A4E0D68E451E3A9FB41@[10.169.6.246]>

--On Wednesday, December 15, 2004 11:44 AM -0800 Rahul Sundaram 
<rahulsundaram at yahoo.co.in> wrote:

> this question has been asked and answered both in this
> list and the users list multiple times. Please search
> the archives.

And bugzilla.




From nbargnesi at gmail.com  Wed Dec 15 20:41:16 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Wed, 15 Dec 2004 20:41:16 +0000
Subject: fc3 display bug ?
In-Reply-To: <20041215195626.4094.qmail@web90109.mail.scd.yahoo.com>
References: <20041215195423.18417.qmail@web8507.mail.in.yahoo.com>
	<20041215195626.4094.qmail@web90109.mail.scd.yahoo.com>
Message-ID: <3077b8a004121512412245befe@mail.gmail.com>

Didn't "For developers, developers, developers..." give it away?


On Wed, 15 Dec 2004 11:56:26 -0800 (PST), linux romeo
<linuxromeo at yahoo.com> wrote:
> ok rahul
> sorry it seems i joined wrong list :-)
> 
> --- Rahul Sundaram <rahulsundaram at yahoo.co.in> wrote:
> 
> >
> > --- linux romeo <linuxromeo at yahoo.com> wrote:
> >
> > >
> > > hello list ,
> > >             I recently tried to upgrade fc2 to fc3
> > > using a dvd but as soon i enter graphical install
> > my
> > > screen freezes...i then tried installing thru
> > expert
> > > install though i was successful ...i am not able
> > > start
> > > x it hangs there !!
> >
> > ask in the users list.
> >
> > =====
> > Regards
> > Rahul Sundaram
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - now with 250MB free storage. Learn
> > more.
> > http://info.mail.yahoo.com/mail_250
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> >
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> 
> =====
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From Philip.R.Schaffner at nasa.gov  Wed Dec 15 22:37:24 2004
From: Philip.R.Schaffner at nasa.gov (Phil Schaffner)
Date: Wed, 15 Dec 2004 17:37:24 -0500
Subject: Inkscape 0.40 [was Re: Self-Introduction: Jonathan Leighton]
In-Reply-To: <200412131641.18303.rjune@bravegnuworld.com>
References: KMail/1.7.1  <200412131641.18303.rjune@bravegnuworld.com>
Message-ID: <1103150244.24302.33.camel@localhost.localdomain>

On Mon, 2004-12-13 at 15:41 -0600, Richard June wrote:
> > FYI, Inkscape is included in fedora.us/Fedora Extras, currently at
> > version 0.40.
> Really? I'm running fc3 and would love to have inkscape RPMs from
> Fedora 
> Extras. where can I download them?

The FC2 SRPM
http://download.fedora.us/fedora/fedora/2/i386/SRPMS.stable/inkscape-0.39-0.fdr.1.2.src.rpm

builds/runs fine under FC3 (x86_64).  Required libsigc++-devel

http://download.fedora.us/fedora/fedora/2/i386/SRPMS.stable/libsigc++-1.2.5-0.fdr.5.2.src.rpm

Building 0.40 was a considerable diversion.  Required the following non-
FC3 packages to be built to satisfy dependencies.

libgc-6.2
libsigc++20-2.0.6
gtkmm2-2.4.6
glibmm-2.4.5
inkscape-0.40

Don't have a public site to dump packages, but spec files are attached
if they may be helpful.

Phil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: inkscape-0.40specs.tgz
Type: application/x-compressed-tar
Size: 6134 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041215/d6c7eebd/attachment.bin>

From warren at togami.com  Wed Dec 15 23:17:23 2004
From: warren at togami.com (Warren Togami)
Date: Wed, 15 Dec 2004 13:17:23 -1000
Subject: fc3 display bug ?
In-Reply-To: <20041215194742.73339.qmail@web90110.mail.scd.yahoo.com>
References: <20041215194742.73339.qmail@web90110.mail.scd.yahoo.com>
Message-ID: <41C0C603.3090202@togami.com>

linux romeo wrote:
> hello list ,
>             I recently tried to upgrade fc2 to fc3
> using a dvd but as soon i enter graphical install my
> screen freezes...i then tried installing thru expert
> install though i was successful ...i am not able start
> x it hangs there !! is it known bug ? or some othe
> problem my mo is vesta (not sure abt model no...i got
> 3 yrs back) with 733  mhz celeron
> in this pc fc2 was running fine 
> 

http://fedoraproject.org/wiki/PostIsOffTopic
Please know that your posts are off-topic.  fedora-devel-list is for 
developer discussion only.



From rahulsundaram at yahoo.co.in  Wed Dec 15 23:20:44 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 15 Dec 2004 15:20:44 -0800 (PST)
Subject: Inkscape 0.40 [was Re: Self-Introduction: Jonathan Leighton]
In-Reply-To: <1103150244.24302.33.camel@localhost.localdomain>
Message-ID: <20041215232044.27484.qmail@web8503.mail.in.yahoo.com>


--- Phil Schaffner <Philip.R.Schaffner at nasa.gov>
wrote:

> On Mon, 2004-12-13 at 15:41 -0600, Richard June
> wrote:
> > > FYI, Inkscape is included in fedora.us/Fedora
> Extras, currently at
> > > version 0.40.
> > Really? I'm running fc3 and would love to have
> inkscape RPMs from
> > Fedora 
> > Extras. where can I download them?

try the experimental autopackage posted to their devel list

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 



From carlos.efr at mail.telepac.pt  Thu Dec 16 00:38:54 2004
From: carlos.efr at mail.telepac.pt (Carlos Rodrigues)
Date: Thu, 16 Dec 2004 00:38:54 +0000
Subject: Thunderbird 1.0
Message-ID: <41C0D91E.9020800@mail.telepac.pt>

Hi!

It's been some days since Thunderbird 1.0 was released. I can't resist 
to ask: Is there an update from 0.9 to 1.0 planned for FC3?

Carlos Rodrigues

-- 
url: http://tudo-sobre-nada.blogspot.com



From mark at mitre.org  Thu Dec 16 01:01:59 2004
From: mark at mitre.org (Mark Heslep)
Date: Wed, 15 Dec 2004 20:01:59 -0500
Subject: Stateless kickstart problem
In-Reply-To: <7f48492a041214140667257001@mail.gmail.com>
References: <41BE44E1.3070708@subarutelescope.org>	<7f48492a04121323234036bb49@mail.gmail.com>	<41BF2E4C.1000000@subarutelescope.org>	<7f48492a0412141346146a080e@mail.gmail.com>
	<7f48492a041214140667257001@mail.gmail.com>
Message-ID: <41C0DE87.7000200@mitre.org>

Christopher Hotchkiss wrote:

>The only problem with this method, is that unless you are physically
>present to tell the workstation to pxe boot, you must find a grub-pxe
>bootloader. Then you can use the netexec program to switch the
>defaults on the boot, to force a reinstall.
>
>  
>
Set the primary BIOS boot device to NIC-PXE?  Works here on Dell gear.

-Mark



From terraformers at gmx.net  Thu Dec 16 02:07:55 2004
From: terraformers at gmx.net (Lars)
Date: Thu, 16 Dec 2004 03:07:55 +0100
Subject: Thunderbird 1.0
References: <41C0D91E.9020800@mail.telepac.pt>
Message-ID: <cpqqlr$udv$1@sea.gmane.org>

Carlos Rodrigues wrote:

> Hi!
> 
> It's been some days since Thunderbird 1.0 was released. I can't resist
> to ask: Is there an update from 0.9 to 1.0 planned for FC3?
> 
> Carlos Rodrigues
> 

try
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/thunderbird-1.0-1.i386.rpm

L

-- 
No Software Patents! http://nosoftwarepatents.com
Datenschutz - Ihr gutes Recht! http://datenschutz.de
Get Firefox! http://spreadfirefox.com





From skvidal at phy.duke.edu  Thu Dec 16 05:44:08 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 00:44:08 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
Message-ID: <1103175848.14792.82.camel@cutter>

Want to be REAL sure you notice this:


http://www.redhat.com/magazine/002dec04/departments/fedora_status/


That's Right CVS is open - you need to  run, don't walk, to:

http://cvs.fedora.redhat.com


It's all exciting - except for the boring parts.

Tomorrow morning we will have another exciting item for you but I'm busy
typing things and colin is on an airplane and all the other slackers are
sleeping or some such nonsense as that so you'll have to wait until the
morning.

Deal.

It's a bright, shiny, new day. But the fog isn't quite lifted yet.

-sv




From rahulsundaram at yahoo.co.in  Thu Dec 16 07:21:31 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 15 Dec 2004 23:21:31 -0800 (PST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103175848.14792.82.camel@cutter>
Message-ID: <20041216072131.71354.qmail@web8501.mail.in.yahoo.com>


--- seth vidal <skvidal at phy.duke.edu> wrote:

> Want to be REAL sure you notice this:
> 
> 
>
http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> 
> 
> That's Right CVS is open - you need to  run, don't
> walk, to:
> 
> http://cvs.fedora.redhat.com
> 
> 

great work

=====
Regards
Rahul Sundaram


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail



From jmrenoua at alcove.fr  Thu Dec 16 08:14:33 2004
From: jmrenoua at alcove.fr (Jean-Marie Renouard)
Date: Thu, 16 Dec 2004 09:14:33 +0100
Subject: Stateless livecd problem
In-Reply-To: <20041215153117.GB31637@nsk.no-ip.org>
References: <41BE44E1.3070708@subarutelescope.org>	<7f48492a04121323234036bb49@mail.gmail.com>	<41BF2E4C.1000000@subarutelescope.org>	<7f48492a0412141346146a080e@mail.gmail.com>	<7f48492a041214140667257001@mail.gmail.com>	<41C057CE.3080807@alcove.fr>
	<20041215153117.GB31637@nsk.no-ip.org>
Message-ID: <41C143E9.3090604@alcove.fr>

Hello and thanks for your quick answers.

I just want to know where can I add (bash code) in the readonly-root 
files to be able to
have a working livecd !


We just want to be able to boot on a machine and running the same services.
At least SSH daemon, nfs, samba ...

Where in thoses scripts could we change it to be able to mount /var and 
populate this data automatically.
/usr/sbin/diskless-mkinitrd
/usr/share/readonly-root/livecd-linuxrc
/usr/share/readonly-root/mklivecd

And How can I submit those changes ?

Best regards,
Jean-Marie Renouard
 
Luciano Miguel Ferreira Rocha wrote:

>On Wed, Dec 15, 2004 at 04:27:10PM +0100, Jean-Marie Renouard wrote:
>  
>
>>Hello,
>>
>>I try to make a liveCD from a fresh installed Fedora Core 3.
>>The CD boots, the hardware is well detected.
>>1) I have some SELinux error messages ( normal ?)
>>
>>2) As the filesystem is mount in read only mode, none of the services 
>>running on my original system
>>can start.
>>They try to write locks under /var/locks/subsys according to their 
>>/etc/init.d scripts but they can't.
>>
>>How can we solve this problem in order to be able to restart a server 
>>from a livecd with the same services running ?
>>How can we set up or mount /var in a read/write mode and keep original 
>>data available too ?
>>    
>>
>
>Make, on boot, /var a tmpfs filesystem and populate it with the var
>files on cd.
>
>Regards,
>Luciano Rocha
>
>  
>



From rc040203 at freenet.de  Thu Dec 16 08:31:25 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Dec 2004 09:31:25 +0100
Subject: mknod: xxx: Operation not permitted
Message-ID: <1103185886.4931.67.camel@mccallum.corsepiu.local>

Hi,

Trying to create a char-device as ordinary user, results into this:
# mknod /var/tmp/bla-1.0.0/etc/udev/devices/bla01 c 212 0
mknod: `/var/tmp/bla-1.0.0/etc/udev/devices/bla01': Operation not permitted

Any explanation for this behavior?

Is it mknod trying to be overly clever or is it an selinux bug (This is
on a FC3 system with selinux-policy-targeted)?

This issue prevents one from being able to build rpms containing special
devices as ordinary users.

Ralf




From rhally at mindspring.com  Thu Dec 16 08:43:42 2004
From: rhally at mindspring.com (Richard Hally)
Date: Thu, 16 Dec 2004 03:43:42 -0500
Subject: mknod: xxx: Operation not permitted
In-Reply-To: <1103185886.4931.67.camel@mccallum.corsepiu.local>
References: <1103185886.4931.67.camel@mccallum.corsepiu.local>
Message-ID: <41C14ABE.2020900@mindspring.com>

Ralf Corsepius wrote:

>Hi,
>
>Trying to create a char-device as ordinary user, results into this:
># mknod /var/tmp/bla-1.0.0/etc/udev/devices/bla01 c 212 0
>mknod: `/var/tmp/bla-1.0.0/etc/udev/devices/bla01': Operation not permitted
>
>Any explanation for this behavior?
>
>Is it mknod trying to be overly clever or is it an selinux bug (This is
>on a FC3 system with selinux-policy-targeted)?
>
>This issue prevents one from being able to build rpms containing special
>devices as ordinary users.
>
>Ralf
>
>
>  
>
The first thing to look for if you suspect SELinux is acv denied 
messages in /var/log/messages. Another thing to try is to "setenforce 0" 
and try the command again to see if you get different results.
HTH
Richard Hally



From rc040203 at freenet.de  Thu Dec 16 09:40:47 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Dec 2004 10:40:47 +0100
Subject: mknod: xxx: Operation not permitted
In-Reply-To: <41C14ABE.2020900@mindspring.com>
References: <1103185886.4931.67.camel@mccallum.corsepiu.local>
	<41C14ABE.2020900@mindspring.com>
Message-ID: <1103190047.4931.75.camel@mccallum.corsepiu.local>

On Thu, 2004-12-16 at 03:43 -0500, Richard Hally wrote:
> Ralf Corsepius wrote:

> >Trying to create a char-device as ordinary user, results into this:
> ># mknod /var/tmp/bla-1.0.0/etc/udev/devices/bla01 c 212 0
> >mknod: `/var/tmp/bla-1.0.0/etc/udev/devices/bla01': Operation not permitted
> >
> >Any explanation for this behavior?
> >
> >Is it mknod trying to be overly clever or is it an selinux bug (This is
> >on a FC3 system with selinux-policy-targeted)?
> >
> >This issue prevents one from being able to build rpms containing special
> >devices as ordinary users.

> The first thing to look for if you suspect SELinux is acv denied 
> messages in /var/log/messages.
None such message.

>  Another thing to try is to "setenforce 0" 
Tried, it didn't change anything. I also tried on a system booted with
selinux=0.

> and try the command again to see if you get different results.
I fear the culprit is the mknod syscall, i.e. glibc.

stracing show mknod(2) returning EPERM and man 2 mknod says:
       EPERM  mode  requested  creation  of  something  other than a regular file, FIFO
              (named pipe), or Unix domain socket, and the caller is not the superuser;

=> Building rpms as ordinary user can not work for packages wanting to
provide special files (Typically kernel drivers).

I am stumped - This is pretty severe security issue as far as rpms are
concerned.

Ralf




From arjanv at redhat.com  Thu Dec 16 09:44:10 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 16 Dec 2004 10:44:10 +0100
Subject: mknod: xxx: Operation not permitted
In-Reply-To: <1103185886.4931.67.camel@mccallum.corsepiu.local>
References: <1103185886.4931.67.camel@mccallum.corsepiu.local>
Message-ID: <1103190250.4136.8.camel@laptopd505.fenrus.org>

On Thu, 2004-12-16 at 09:31 +0100, Ralf Corsepius wrote:
> Hi,
> 
> Trying to create a char-device as ordinary user, results into this:
> # mknod /var/tmp/bla-1.0.0/etc/udev/devices/bla01 c 212 0
> mknod: `/var/tmp/bla-1.0.0/etc/udev/devices/bla01': Operation not permitted
> 
> Any explanation for this behavior?

yes
if you allow non-root to create a device-node, then that non-root user
automatically has access to the device. At which point the game is over,
he's effectively root.


> This issue prevents one from being able to build rpms containing special
> devices as ordinary users.

then the rpm in question is buggy.
First of all, RPM has a directive to do this properly (%device iirc),
that way it gets created in the cpio properly but doesn't have to be on
the filesystem
Second of all, it's quite suspect that you want to package a device node
in an rpm since most of them are dynamic numbers nowadays... are you
sure your device is registered with LANANA ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/a92f354c/attachment.sig>

From arjanv at redhat.com  Thu Dec 16 09:55:52 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 16 Dec 2004 10:55:52 +0100
Subject: mknod: xxx: Operation not permitted
In-Reply-To: <1103190047.4931.75.camel@mccallum.corsepiu.local>
References: <1103185886.4931.67.camel@mccallum.corsepiu.local>
	<41C14ABE.2020900@mindspring.com>
	<1103190047.4931.75.camel@mccallum.corsepiu.local>
Message-ID: <1103190952.4136.14.camel@laptopd505.fenrus.org>

On Thu, 2004-12-16 at 10:40 +0100, Ralf Corsepius wrote:
> => Building rpms as ordinary user can not work for packages wanting to
> provide special files (Typically kernel drivers).

proper kernel drivers get their device nodes added automatically with
udev nowadays...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/4765e060/attachment.sig>

From rc040203 at freenet.de  Thu Dec 16 09:57:37 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Dec 2004 10:57:37 +0100
Subject: mknod: xxx: Operation not permitted
In-Reply-To: <1103190250.4136.8.camel@laptopd505.fenrus.org>
References: <1103185886.4931.67.camel@mccallum.corsepiu.local>
	<1103190250.4136.8.camel@laptopd505.fenrus.org>
Message-ID: <1103191058.4931.80.camel@mccallum.corsepiu.local>

On Thu, 2004-12-16 at 10:44 +0100, Arjan van de Ven wrote:
> On Thu, 2004-12-16 at 09:31 +0100, Ralf Corsepius wrote:
> > Hi,
> > 
> > Trying to create a char-device as ordinary user, results into this:
> > # mknod /var/tmp/bla-1.0.0/etc/udev/devices/bla01 c 212 0
> > mknod: `/var/tmp/bla-1.0.0/etc/udev/devices/bla01': Operation not permitted

> > This issue prevents one from being able to build rpms containing special
> > devices as ordinary users.
> 
> then the rpm in question is buggy.
Quite likely, I am at trying to get the rpm spec shipped with a
proprietary device driver working.

> First of all, RPM has a directive to do this properly (%device iirc),
Thanks, that's news to me. I will try to investigate (I recall there is
a %dev, but I haven't used it, yet).

> Second of all, it's quite suspect that you want to package a device node
> in an rpm since most of them are dynamic numbers nowadays... are you
> sure your device is registered with LANANA ?
The example above used arbitrarily chosen numbers. I don't know if the
actual devices-numbers have been registered with LANANA. As this is a
closed source driver, I would not bet.

Ralf




From j.w.r.degoede at hhs.nl  Thu Dec 16 10:44:08 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Dec 2004 11:44:08 +0100
Subject: Fwd for Peter Dedecker: stateless-snapshooter problems
Message-ID: <41C166F8.8000403@hhs.nl>

I'm forwarding this for Peter Dedecker because he as problem sending to 
the list.

Regards,

Hans

---

Hi,

We (the fedora stateless team at UGent, 
http://blog.eikke.com/index.php/fedorastateless) setted up a stateless 
server, but we are having problems creating snapshots.  When we use 
stateless-snapshooter, it seems that we need pyGTK (and thus X).  On a 
server, we normally don't install X on servers, so shouldn't it be 
better to make a real command line tool from stateless-snapshooter so X 
isn't required anymore?  Thanks!


-- 
Peter Dedecker                      VTK Gent vzw
Studentenvertegenwoordiger          J. Plateaustraat 22 - Gent
VTK Computerpraeses 2004-2005       Tel&Fax: 09/264.37.26
VTK Penningmeester 2003-2004        GSM: 0486/15.23.20
Peter.Dedecker at VTK.UGent.be         http://www.VTK.UGent.be



From buildsys at redhat.com  Thu Dec 16 12:18:09 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 16 Dec 2004 07:18:09 -0500
Subject: rawhide report: 20041216 changes
Message-ID: <200412161218.iBGCI9S24116@porkchop.devel.redhat.com>

 

 
Updated Packages:

ethereal-0.10.8-1
-----------------
* Wed Dec 15 2004 Radek Vokal <rvokal at redhat.com> 0.10.8-1
- update to 0.10.8 due to security issues (#142952)
- default font changed

evolution-2.0.3-1
-----------------
* Wed Dec 15 2004 David Malcolm <dmalcolm at redhat.com> - 2.0.3-1
- Update from upstream 2.0.2 to 2.0.3 with these bug fixes:
 * Addressbook
   XB67656 - almost the same email address are considrered identical (Siva)
   XB69079 - Data repeated after save with bad date format (Siva)
   XB66854 - Some strings are missed to translation (Rodney)

 * Calendar 	
   XB47529 - Date in reminder window appears in UTF-8 in non-UTF-8 locale (Rodney)
   XB68707 - Events ending at 12:00 AM show as ending at 12:00 pm (JP)
   XB67403 - wrong alarm time displayed (Rodrigo)
   XB68077 - appointment dialog re-size (Rodrigo)
   - leak fixes (Chen)
   - sensitize menu items in list view properly (JP)
   - redraw display when 24hr time setting changes (JP)

 * Mail
   XB69533 - Unable to subscribe to the alt hierarchy (Michael)
   XB69776 - Signed Mail with attachments displays everything with multipart/boundaries stuff (Michael)
   XB69615 - delete certificate after viewing smime message (Michael)
   XB69109 - EHLO or HELO with ip addresses does not conform rfc 821  (Michael)
   XB69982 - During Newsgroup list refresh, it crashes (Michael) 
   XB69446 - Mail shown as attachment if some headers are upper case (S. Caglar Onur) 
   XB68556 - NNTP with SSL won't work, even with stunnel (Michael) 
   XB69145 - toplevel message/rfc822 parts are broken for IMAP (Michael)
   XB69241 - base64 attachement holding PGP block (Jeff)
   XB67895 - nntp support not asking for password (Michael)
   XB67898 - Use of symbolic port-names is not guaranteed to work everywhere (Michael)
   XB69851 - remember password check doesn't stick (Michael)
   XB69623 - Moving a message from an IMAP INBOX to an IMAP folder caused crash (Radek)
   XB69339 - postscript and some other attachments not visable (Michael)
   XB69579 - vFoldersXBUNMATCHED generates errors (Michael)
   XB68958 - current message forgotten in vfolders (Michael)
   XB68974 - Wizard doesn't store smtp auth settings (Michael)
   XB67496 - html email not rendered in preview pane (Michael)
   XB67014 - Checking supported auth types doesn't work with new SSL certificate (Michael)
   XB68006 - Evo crashed after viewing previously-sent email and copying URL from it (Michael)
   XB68787 - Crash when migrating 1.4 data to 2.0.2 (Michael)
   XB67622 - SMTP auth usernames containing % character fail (Jeff)
   - fix pthread_key_delete args (Julio M. Merino Vidal)
- Removed patch for "Unmatched" vfolder properties dialog (#141458) as this is now in upstream tarball (XB69579 above)
- Update dependency on e-d-s from 1.0.2 to 1.0.3
- Update dependency on libgal2 from 2.2.3 to 2.2.4

* Wed Dec 01 2004 David Malcolm <dmalcolm at redhat.com> - 2.0.2-6
- Fix broken properties dialog for "Unmatched" vfolder (#141458)

* Wed Oct 27 2004 Christopher Aillon <caillon at redhat.com> - 2.0.2-4
- Re-enable s390(x)

evolution-connector-2.0.3-1
---------------------------
* Wed Dec 15 2004 David Malcolm <dmalcolm at redhat.com> - 2.0.3-1
- Update from upstream 2.0.2 to 2.0.3
- The fix for bugs #139134 and #141419 is now in the upstream tarball; removing the patch

evolution-data-server-1.0.3-2
-----------------------------
* Wed Dec 15 2004 David Malcolm <dmalcolm at redhat.com> - 1.0.3-2
- fixed packaging of translation files to reflect upstream change to GETTEXT_PACKAGE being evolution-data-server-1.0 rather than -1.5

* Wed Dec 15 2004 David Malcolm <dmalcolm at redhat.com> - 1.0.3-1
- update from upstream 1.0.2 to 1.0.3:
  * Address Book
    - prevent e_book_commit_contact from crashing on multiple calls (Diego Gonzalez)
    - prevent file backend from crashing if uid of vcard is NULL (Diego Gonzalez)

  * Calendar
            - fix libical build for automake 1.9 (Rodney)
    - fix putenv usage for portability (Julio M. Merino Vidal)

  * Updated Translations:
    - sv (Christian Rose)

- Removed patches to fix build on x86_64 and calendar optimisation for XB59004 as these are in the upstream tarball

glibc-2.3.3-93
--------------
* Wed Dec 15 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-93
- update from CVS
  - ppc/ppc64 clone without CLONE_THREAD getpid () adjustement
  - fix MALLOC_CHECK_={1,2,3} for non-contiguous main arena
    (BZ#457)
  - fix sysconf (_POSIX_V6_*) for other ABI environments in
    bi-arch setups
- s390/s390x clone without CLONE_THREAD getpid () adjustement

gnumeric-1:1.4.1-1
------------------
* Wed Dec 15 2004 Caolan McNamara <caolanm at redhat.com> 1.4.1-1
- bump to new version
- drop integrated 64bit patch
- drop integrated desktop.in patch
- drop integrated latex patch
- drop disable bonobo patch
- add enable perl configure patch
- add quickfix for help being searched for in wrong place #gnome161404#

gsl-1.5-2
---------
* Wed Dec 15 2004 Ivana Varekova <varekova at redhat.com>
- fix bug #142696 gsl-config outputs invalid flags on multilib 64-bit 
architectures

kde-i18n-1:3.3.2-0.1
--------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 1:3.3.2-0.1
- update to 3.3.2

* Sat Oct 16 2004 Than Ngo <than at redhat.com> 1:3.3.1-2
- rhel rebuilt

kdeaddons-3.3.2-0.1
-------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 3.3.2-0.1
- update to 3.3.2

* Mon Oct 18 2004 Than Ngo <than at redhat.com> 3.3.1-2
- rebuilt

kdeadmin-7:3.3.2-0.1
--------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 7:3.3.2-0.1
- update to 3.3.2

* Mon Oct 18 2004 Than Ngo <than at redhat.com> 7:3.3.1-2
- rebuilt

kdeartwork-3.3.2-0.3
--------------------
* Wed Dec 15 2004 Than Ngo <than at redhat.com> 3.3.2-0.3
- fix buildreq on xscreensaver-base

* Mon Dec 06 2004 Than Ngo <than at redhat.com> 3.3.2-0.2
- add correct paths for xscreensaver, xscreensaver-4.18-14 stores the
  config files and graphic hacks in /usr/lib64/xscreensaver/config/hacks
  and /usr/libexec/xscreensaver/hacks/

* Fri Dec 03 2004 Than Ngo <than at redhat.com> 3.3.2-0.1
- update to 3.3.2
- remove kdeartwork-3.3.1-kaleidescope.patch, it's included in 3.3.2

kdebase-6:3.3.2-0.2
-------------------
* Tue Dec 14 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.2
- apply the patch to fix Konqueror Window Injection Vulnerability #142510
  CAN-2004-1158,  Thanks to KDE security team

kdebindings-3.3.2-0.1
---------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 3.3.2-0.1
- update to 3.3.2

kdegraphics-7:3.3.2-0.1
-----------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 7:3.3.2-0.1
- update to 3.3.2
- remove kdegraphics-3.3.1-tiff.patch, it's included in 3.3.2

kdelibs-6:3.3.2-0.4
-------------------
* Wed Dec 15 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.4
- get rid of broken AltiVec instructions on ppc

kdenetwork-7:3.3.2-0.2
----------------------
* Tue Dec 07 2004 Than Ngo <than at redhat.com> 7:3.3.2-0.2
- add missing return statement, bug #142097
- remove kdenetwork-3.3.0-kget.patch, it's included in 3.3.2
- add CVS patch to fix memory leak

* Fri Dec 03 2004 Than Ngo <than at redhat.com> 7:3.3.2-0.1
- update to 3.3.2
- remove kdenetwork-3.3.1-kppp-cb.patch, it's included in 3.3.2

* Mon Nov 15 2004 Than Ngo <than at redhat.com> 7:3.3.1-3
- increased length of callback number

kdesdk-3.3.2-0.1
----------------
* Sun Dec 05 2004 Than Ngo <than at redhat.com> 3:3.3.2-0.1
- update to 3.3.2

kdetoys-7:3.3.2-0.1
-------------------
* Sun Dec 05 2004 Than Ngo <than at redhat.com> 7:3.3.2-0.1
- update to 3.3.2

* Mon Oct 18 2004 Than Ngo <than at redhat.com> 7:3.3.1-2
- rebuilt

kdeutils-6:3.3.2-0.1
--------------------
* Sun Dec 05 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.1
- update to 3.3.2
- get rid of kdeutils-3.3.1-kdf-locale.patch, it's included in 3.3.2

kdewebdev-6:3.3.2-0.1
---------------------
* Fri Dec 03 2004 Than Ngo <than at redhat.com> 6:3.3.2-0.1
- update to 3.3.2
- add missing tidy for HTML syntax checking #140970

* Mon Oct 18 2004 Than Ngo <than at redhat.com> 6:3.3.1-2
- rebuilt

kudzu-1.1.102-1
---------------
* Wed Dec 15 2004 Bill Nottingham <notting at redhat.com> - 1.1.102-1
- tweak network device detection algorithm (#141338)

libgal2-2:2.2.4-1
-----------------
* Wed Dec 15 2004 David Malcolm <dmalcolm at redhat.com> - 2:2.2.4-1
- update from upstream 2.2.3 to 2.2.4:
  - focus focus chaining (JP)
  - fix category focus handling (Hao Sheng)
  - Updated translations: gu (Ankit Patel)

man-pages-ja-20041215-1
-----------------------
* Wed Dec 15 2004 Akira TAGOH <tagoh at redhat.com> - 20041215-1
- updates to 20041215.

mc-1:4.6.1a-0.2
---------------
* Wed Dec 15 2004 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.2
- update from CVS - problem in uzip.in fixed by upstream (#141844)
- fix msglen patch to deal with wide UTF-8 characters (#141875)

ncpfs-2.2.4-5
-------------
* Wed Dec 15 2004 Jiri Ryska <jryska at redhat.com>
- Fixed buffer overflow CAN-2004-1079; #141185

rpmdb-fedora-1:4-0.20041216
---------------------------

selinux-policy-targeted-1.19.13-1
---------------------------------
* Sat Dec 11 2004 Dan Walsh <dwalsh at redhat.com> 1.19-13-1
- Update latest from NSA

* Fri Dec 10 2004 Dan Walsh <dwalsh at redhat.com> 1.19-12-2
- Add support for winbindd from nscd

* Wed Dec 08 2004 Dan Walsh <dwalsh at redhat.com> 1.19-12-1
- Update latest from NSA



From dries at ulyssis.org  Thu Dec 16 15:03:55 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Thu, 16 Dec 2004 16:03:55 +0100
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <1103175848.14792.82.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
Message-ID: <200412161603.55840.dries@ulyssis.org>


Hello,

I would like to know how we could get a login for this CVS repository? Is 
there also maybe a mailinglist with the commit logs or is it possible to add 
this? Is there a document with policies for committers?

kind regards,
Dries Verachtert



From jmrenoua at alcove.fr  Thu Dec 16 15:32:23 2004
From: jmrenoua at alcove.fr (Jean-Marie Renouard)
Date: Thu, 16 Dec 2004 16:32:23 +0100
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <200412161603.55840.dries@ulyssis.org>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
Message-ID: <41C1AA87.5000109@alcove.fr>

Hello,

There is a documentation about developpement policy for rpm at :
http://fedora.redhat.com/participate/developers-guide/

Best regards,
Jean-Marie Renouard
Dries Verachtert wrote:

>Hello,
>
>I would like to know how we could get a login for this CVS repository? Is 
>there also maybe a mailinglist with the commit logs or is it possible to add 
>this? Is there a document with policies for committers?
>
>kind regards,
>Dries Verachtert
>  
>



From skvidal at phy.duke.edu  Thu Dec 16 15:33:40 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 10:33:40 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <200412161603.55840.dries@ulyssis.org>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
Message-ID: <1103211220.7474.19.camel@opus.phy.duke.edu>

On Thu, 2004-12-16 at 16:03 +0100, Dries Verachtert wrote:
> Hello,
> 
> I would like to know how we could get a login for this CVS repository? Is 
> there also maybe a mailinglist with the commit logs or is it possible to add 
> this? Is there a document with policies for committers?
> 


I don't think it's documented entirely yet. I thought it was (as I
talked to you about on irc) but I was wrong.

Right now there are two main questions:
1. how to establish trust for someone to be given commit access?
2. the legal process.

now for #2 I know the red hat folks have gotten that one ironed out.

The people I, personally, know of with commit access outside of
@redhat.com are:

Michael Schwendt
Matthias Saou
Ville Skytt?

The only reason I know of them is b/c of the commits mailing list and I
saw their names. :)

The mailing list you want to see for commits is here:
https://www.redhat.com/mailman/listinfo/fedora-extras-commits


So for #1 of above - I think that still needs some discussion. I'll bug
the various powers-that-be who give out access to cvs (@redhat.com
folks, obviously) and see if we have any general guidelines yet.

That's what I've got for now. I'll let you know if I hear more.

Fair enough?

Thanks,
-sv




From katzj at redhat.com  Thu Dec 16 15:43:38 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Dec 2004 10:43:38 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <200412161603.55840.dries@ulyssis.org>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
Message-ID: <1103211818.13602.58.camel@bree.local.net>

On Thu, 2004-12-16 at 16:03 +0100, Dries Verachtert wrote:
> I would like to know how we could get a login for this CVS repository? Is 
> there also maybe a mailinglist with the commit logs or is it possible to add 
> this? Is there a document with policies for committers?

Disclaimer: This is not an official statement.  It's based on my current
understanding of things.  I don't have on an official Red Hat hat and
instead am wearing my community member fedora :)

At this point, the exact policies around how to get a (non-anonymous)
login for Extras CVS haven't fully formed.  It's basically going to end
up being a lot like the policies for a lot of other repositories (think
cvs.gnome.org, etc).  Basically, you start doing some work, gain some
degree of trust and then get an account.  Which will probably basically
be "show some body of work (fixes, new packages, etc) via
mail/bugzilla/something" and then an account gets added.

As for commit logs, http://www.redhat.com/mailman/listinfo/fedora-
extras-commits has what you're looking for.

Policy-wise, that'll come at the same time as we start doing the first.
But it'll probably end up being something mostly along the lines of be
smart, make good packages and there won't be huge problems.

I expect that all of this will start coalescing a lot better over
Christmas and into the new year.  It was just better to start getting
things out instead of waiting for everything to be perfect.  

Jeremy



From katzj at redhat.com  Thu Dec 16 15:45:10 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Dec 2004 10:45:10 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <1103211220.7474.19.camel@opus.phy.duke.edu>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
	<1103211220.7474.19.camel@opus.phy.duke.edu>
Message-ID: <1103211910.13602.61.camel@bree.local.net>

On Thu, 2004-12-16 at 10:33 -0500, seth vidal wrote:
> The people I, personally, know of with commit access outside of
> @redhat.com are:
> 
> Michael Schwendt
> Matthias Saou
> Ville Skytt?

For completeness sake, the list of those with commit access right this
minute also includes:
Dams Nade
Thomas Vander Stichele
Phillip Compton

Jeremy



From tiemann at redhat.com  Thu Dec 16 16:01:03 2004
From: tiemann at redhat.com (Michael Tiemann)
Date: Thu, 16 Dec 2004 11:01:03 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <1103211818.13602.58.camel@bree.local.net>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
	<1103211818.13602.58.camel@bree.local.net>
Message-ID: <1103212862.4791.36.camel@localhost.localdomain>

On Thu, 2004-12-16 at 10:43, Jeremy Katz wrote:
> On Thu, 2004-12-16 at 16:03 +0100, Dries Verachtert wrote:
> > I would like to know how we could get a login for this CVS repository? Is 
> > there also maybe a mailinglist with the commit logs or is it possible to add 
> > this? Is there a document with policies for committers?
> 
> Disclaimer: This is not an official statement.  It's based on my current
> understanding of things.  I don't have on an official Red Hat hat and
> instead am wearing my community member fedora :)

Let me jump in with a slightly more authoritative statement...

> At this point, the exact policies around how to get a (non-anonymous)
> login for Extras CVS haven't fully formed.  It's basically going to end
> up being a lot like the policies for a lot of other repositories (think
> cvs.gnome.org, etc).  Basically, you start doing some work, gain some
> degree of trust and then get an account.  Which will probably basically
> be "show some body of work (fixes, new packages, etc) via
> mail/bugzilla/something" and then an account gets added.

This stuff is forming actively, right now.  For those of you who
remember my strawman postings this summer
(https://www.redhat.com/archives/fedora-devel-list/2004-July/msg01325.html)...well the internal blockages have been cleared.  gdk and I have it solidly on our plate to form these policies by actively building consensus and documenting that consensus right now.  Our goal will be that there will be an official Fedora document that tells you just what you need to do, and people you can go to, who are accountable to you and to the project, to let you in or keep you out based on objective tests.

> Policy-wise, that'll come at the same time as we start doing the first.
> But it'll probably end up being something mostly along the lines of be
> smart, make good packages and there won't be huge problems.

Right.  And if you think you have a particular contribution to make
regarding policy, governance, or the nomination of a person to a role
you think is vital, please make sure you send that to gdk and myself. 
I'm hoping to have a draft governance document (with roles populated) by
this time next week, for discussion.

> I expect that all of this will start coalescing a lot better over
> Christmas and into the new year.  It was just better to start getting
> things out instead of waiting for everything to be perfect.  

What he said.

M



From dries at ulyssis.org  Thu Dec 16 16:07:42 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Thu, 16 Dec 2004 17:07:42 +0100
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <1103211818.13602.58.camel@bree.local.net>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
	<1103211818.13602.58.camel@bree.local.net>
Message-ID: <200412161707.42820.dries@ulyssis.org>

On Thursday 16 December 2004 16:43, you wrote:

> At this point, the exact policies around how to get a (non-anonymous)
> login for Extras CVS haven't fully formed.  It's basically going to end
> up being a lot like the policies for a lot of other repositories (think
> cvs.gnome.org, etc).  Basically, you start doing some work, gain some
> degree of trust and then get an account.  Which will probably basically
> be "show some body of work (fixes, new packages, etc) via
> mail/bugzilla/something" and then an account gets added.

Ok some work of me: i make packages for Aurora Linux (that's fedora for sparc 
basically), Red Hat Enterprise Linux and for Fedora Core 1, 2 and 3. You can 
find them on http://dries.ulyssis.org/ayo/   They should all be signed with 
my public key and my key can also be found on that site.
About fixes: i wrote quite some patches to get stuff working on aurora or the 
newer gcc of fc3 but most of them get included in programs after mailing the 
author: so most of them are gone :-)

> As for commit logs, http://www.redhat.com/mailman/listinfo/fedora-
> extras-commits has what you're looking for.

Thanks i'm subscribed and maybe it's interesting to add this list to the page 
http://fedora.redhat.com/participate/communicate/ ? 

> Policy-wise, that'll come at the same time as we start doing the first.
> But it'll probably end up being something mostly along the lines of be
> smart, make good packages and there won't be huge problems.

Ok but for example: is each spec file 'owned' by 1 person who is responsible 
for that spec file? Or is the responsibility divided by version of fedora 
core or is everyone equally responsible for all spec files?  I don't expect 
you to write a complete document about the policy but maybe some lines with 
some general guidelines might be interesting for everyone on this list who 
would like to participate?

kind regards,
Dries Verachtert



From mattdm at mattdm.org  Thu Dec 16 16:35:36 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 16 Dec 2004 11:35:36 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103175848.14792.82.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
Message-ID: <20041216163536.GA14002@jadzia.bu.edu>

On Thu, Dec 16, 2004 at 12:44:08AM -0500, seth vidal wrote:
> http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> That's Right CVS is open - you need to  run, don't walk, to:
> http://cvs.fedora.redhat.com

Whooo! Thanks!


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From ed at eh3.com  Thu Dec 16 16:57:31 2004
From: ed at eh3.com (Ed Hill)
Date: Thu, 16 Dec 2004 11:57:31 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <1103212862.4791.36.camel@localhost.localdomain>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
	<1103211818.13602.58.camel@bree.local.net>
	<1103212862.4791.36.camel@localhost.localdomain>
Message-ID: <1103216252.3710.21.camel@localhost.localdomain>

On Thu, 2004-12-16 at 11:01 -0500, Michael Tiemann wrote:
> On Thu, 2004-12-16 at 10:43, Jeremy Katz wrote:
> > At this point, the exact policies around how to get a (non-anonymous)
> > login for Extras CVS haven't fully formed.  It's basically going to end
> > up being a lot like the policies for a lot of other repositories (think
> > cvs.gnome.org, etc).  Basically, you start doing some work, gain some
> > degree of trust and then get an account.  Which will probably basically
> > be "show some body of work (fixes, new packages, etc) via
> > mail/bugzilla/something" and then an account gets added.
> 
> This stuff is forming actively, right now.  For those of you who
> remember my strawman postings this summer
> (https://www.redhat.com/archives/fedora-devel-list/2004-July/msg01325.html)...well the internal blockages have been cleared.  gdk and I have it solidly on our plate to form these policies by actively building consensus and documenting that consensus right now.  Our goal will be that there will be an official Fedora document that tells you just what you need to do, and people you can go to, who are accountable to you and to the project, to let you in or keep you out based on objective tests.


This is great news!

A framework that helps to grow the packaging community by helping
newbies (like me) create, test, review, modify, and eventually get their
"niche" packages working conveniently within Fedora.  This rocks!

Many thanks to everyone (both @redhat and volunteers) who are making
this happen!

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464



From ellson at research.att.com  Thu Dec 16 18:06:19 2004
From: ellson at research.att.com (John Ellson)
Date: Thu, 16 Dec 2004 13:06:19 -0500
Subject: Will there be a Bugzilla for Extras? (was Re: Fedora Extras, Fedora
 Core CVS Open!)
In-Reply-To: <1103175848.14792.82.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
Message-ID: <41C1CE9B.7060000@research.att.com>

How can we reach the package maintainers of the packages in Extras?
Will there be a Bugzilla area for Extras packages?

John Ellson



From skvidal at phy.duke.edu  Thu Dec 16 18:08:44 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 13:08:44 -0500
Subject: Will there be a Bugzilla for Extras? (was Re: Fedora Extras,
	Fedora Core CVS Open!)
In-Reply-To: <41C1CE9B.7060000@research.att.com>
References: <1103175848.14792.82.camel@cutter>
	<41C1CE9B.7060000@research.att.com>
Message-ID: <1103220524.7474.47.camel@opus.phy.duke.edu>

On Thu, 2004-12-16 at 13:06 -0500, John Ellson wrote:
> How can we reach the package maintainers of the packages in Extras?
> Will there be a Bugzilla area for Extras packages?
> 

http://bugzilla.redhat.com

look there now.

Chockful of extras goodness.


announcement soon.
-sv




From ellson at research.att.com  Thu Dec 16 18:08:47 2004
From: ellson at research.att.com (John Ellson)
Date: Thu, 16 Dec 2004 13:08:47 -0500
Subject: Will there be a Bugzilla for Extras? (was Re: Fedora Extras,
 Fedora Core CVS Open!)
In-Reply-To: <41C1CE9B.7060000@research.att.com>
References: <1103175848.14792.82.camel@cutter>
	<41C1CE9B.7060000@research.att.com>
Message-ID: <41C1CF2F.3000900@research.att.com>

John Ellson wrote:

> How can we reach the package maintainers of the packages in Extras?
> Will there be a Bugzilla area for Extras packages?
>
> John Ellson
>
Never mind - its there now.   Thanks.



From rahulsundaram at yahoo.co.in  Thu Dec 16 18:13:02 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 10:13:02 -0800 (PST)
Subject: svn or arch
Message-ID: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>

Hi

Is there any discussions about using Subversion or GNU
arch/Bazaar (http://bazaar.canonical.com/) instead of
cvs for the repositories.



=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 



From skvidal at phy.duke.edu  Thu Dec 16 18:16:30 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 13:16:30 -0500
Subject: svn or arch
In-Reply-To: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
Message-ID: <1103220990.7474.53.camel@opus.phy.duke.edu>

On Thu, 2004-12-16 at 10:13 -0800, Rahul Sundaram wrote:
> Hi
> 
> Is there any discussions about using Subversion or GNU
> arch/Bazaar (http://bazaar.canonical.com/) instead of
> cvs for the repositories.
> 

Yes - Cristian Gafton did months of extensive testing to see if either
could stand up to the load of internal and external checkins on the
scale red hat does with distributions.

He found that cvs was the only one to stand up to the load.

-sv




From rahulsundaram at yahoo.co.in  Thu Dec 16 18:21:22 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 10:21:22 -0800 (PST)
Subject: svn or arch
In-Reply-To: <1103220990.7474.53.camel@opus.phy.duke.edu>
Message-ID: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>

Hi

> Yes - Cristian Gafton did months of extensive
> testing to see if either
> could stand up to the load of internal and external
> checkins on the
> scale red hat does with distributions.
> 
> He found that cvs was the only one to stand up to
> the load.

Ok thanks for the quick reply. are the results
available anywhere. It would be nice to let the
svn/arch developers know about this. I am pretty sure
they would be interested

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



From skvidal at phy.duke.edu  Thu Dec 16 18:25:39 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 13:25:39 -0500
Subject: svn or arch
In-Reply-To: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
Message-ID: <1103221540.1763.1.camel@cutter>

On Thu, 2004-12-16 at 10:21 -0800, Rahul Sundaram wrote:
> Hi
> 
> > Yes - Cristian Gafton did months of extensive
> > testing to see if either
> > could stand up to the load of internal and external
> > checkins on the
> > scale red hat does with distributions.
> > 
> > He found that cvs was the only one to stand up to
> > the load.
> 
> Ok thanks for the quick reply. are the results
> available anywhere. It would be nice to let the
> svn/arch developers know about this. I am pretty sure
> they would be interested

You can ask - but i'm not sure they are.

I know of them anecdotally - However, from what I know of Gafton he had
good reason for saying what he said.

-sv




From feliciano.matias at free.fr  Thu Dec 16 18:27:00 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Thu, 16 Dec 2004 19:27:00 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103175848.14792.82.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
Message-ID: <1103221621.8566.2.camel@one.myworld>

Le jeudi 16 d?cembre 2004 ? 00:44 -0500, seth vidal a ?crit :
> Want to be REAL sure you notice this:
> 
> 
> http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> 
> 
> That's Right CVS is open - you need to  run, don't walk, to:
> 
> http://cvs.fedora.redhat.com
> 

RHEL extras ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/00e65484/attachment.sig>

From katzj at redhat.com  Thu Dec 16 18:26:36 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Dec 2004 13:26:36 -0500
Subject: Fedora Extras CVS: how to get a login?
In-Reply-To: <200412161707.42820.dries@ulyssis.org>
References: <1103175848.14792.82.camel@cutter>
	<200412161603.55840.dries@ulyssis.org>
	<1103211818.13602.58.camel@bree.local.net>
	<200412161707.42820.dries@ulyssis.org>
Message-ID: <1103221596.13602.75.camel@bree.local.net>

On Thu, 2004-12-16 at 17:07 +0100, Dries Verachtert wrote:
> > As for commit logs, http://www.redhat.com/mailman/listinfo/fedora-
> > extras-commits has what you're looking for.
> 
> Thanks i'm subscribed and maybe it's interesting to add this list to the page 
> http://fedora.redhat.com/participate/communicate/ ? 

Yeah, probably.  But since none of the CVS stuff is listed on the web
site right now, not having the list on there is the least of my
concerns :-)

> > Policy-wise, that'll come at the same time as we start doing the first.
> > But it'll probably end up being something mostly along the lines of be
> > smart, make good packages and there won't be huge problems.
> 
> Ok but for example: is each spec file 'owned' by 1 person who is responsible 
> for that spec file? Or is the responsibility divided by version of fedora 
> core or is everyone equally responsible for all spec files?  I don't expect 
> you to write a complete document about the policy but maybe some lines with 
> some general guidelines might be interesting for everyone on this list who 
> would like to participate?

Oh, I definitely agree that some general guidelines will need to be
written up.  We'll get there.  My hunch is basically per-package owners
with the intent that in most cases, changes for a package go through the
owner.

Jeremy



From skvidal at phy.duke.edu  Thu Dec 16 18:33:05 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 13:33:05 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103221621.8566.2.camel@one.myworld>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld>
Message-ID: <1103221985.1763.4.camel@cutter>

On Thu, 2004-12-16 at 19:27 +0100, F?liciano Matias wrote:
> Le jeudi 16 d?cembre 2004 ? 00:44 -0500, seth vidal a ?crit :
> > Want to be REAL sure you notice this:
> > 
> > 
> > http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> > 
> > 
> > That's Right CVS is open - you need to  run, don't walk, to:
> > 
> > http://cvs.fedora.redhat.com
> > 
> 
> RHEL extras ?

That's decidedly off-topic for this list.

Ask on taroon list.


-sv




From feliciano.matias at free.fr  Thu Dec 16 18:44:18 2004
From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias)
Date: Thu, 16 Dec 2004 19:44:18 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103221985.1763.4.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld> <1103221985.1763.4.camel@cutter>
Message-ID: <1103222658.8566.10.camel@one.myworld>

Le jeudi 16 d?cembre 2004 ? 13:33 -0500, seth vidal a ?crit :
> On Thu, 2004-12-16 at 19:27 +0100, F?liciano Matias wrote:
> > Le jeudi 16 d?cembre 2004 ? 00:44 -0500, seth vidal a ?crit :
> > > Want to be REAL sure you notice this:
> > > 
> > > 
> > > http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> > > 
> > > 
> > > That's Right CVS is open - you need to  run, don't walk, to:
> > > 
> > > http://cvs.fedora.redhat.com
> > > 
> > 
> > RHEL extras ?
> 
> That's decidedly off-topic for this list.
> 
> Ask on taroon list.

Or nahan list.

btw :
Whoooooo, thanks ! :-)

Is there any plan to add a /etc/yum.repo.d/fedora-extras.repo in the
fedora-release package (perhaps disabled by default) ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/3ec0a4be/attachment.sig>

From skvidal at fedoraproject.org  Thu Dec 16 19:00:26 2004
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 16 Dec 2004 14:00:26 -0500
Subject: Fedora Project launches Pre-Extras
Message-ID: <1103223626.1763.18.camel@cutter>

The Fedora Project is officially launching Fedora Pre-Extras, to work
alongside Fedora Core 3 for i386 and x86_64 based platforms.

What is Pre-Extras?
It is our way of showing you that we've been working hard, as many
packages have been built, and are ready for distribution. 

We are working very hard to make the build system work well, and the
infrastructure for this is almost ready, it just has a few kinks that we
are ironing out. As a measure of good faith, CVS for both Core and
Extras has already been opened.

While waiting for Extras to officially launch, use Pre-Extras today!

Where did all these packages come from?
These were packages from the now-merged Fedora.us repository as well as
freshrpms.net repository. So they maintain the same high quality
standards that was imposed previously.

So how do I get it?
Pre-Extras is currently hosted on the FedoraProject.org website, and is
available at:

	http://fedoraproject.org/pre-extras/3/

It is available as a YUM repository, and an entry like the following
would suffice (in /etc/yum.conf):

[pre-extras]
name=Pre Extras
baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
gpgcheck=1

There is a temporary Pre Extras GPG key, which all packages are signed
with. The fingerprint:

pub  1024D/1AC70CE6 2004-12-14 Fedora Pre Extras Release <pre-extras at fedoraproject.org>
     Key fingerprint = 5389 DD00 C5BC 5168 12B4  3272 82ED 9504 1AC7 0CE6
sub  1024g/4E1A9D43 2004-12-14

To import the key:
	
 rpm --import http://fedoraproject.org/pre-extras/RPM-GPG-KEY-Fedora-Pre-Extras

What about bugs?
If you find bugs in the packages, report them at the Fedora Extras
Bugzilla:

	http://bugzilla.redhat.com/beta/

A cautionary note...
To paraphrase a Fedora Project contributor, Jef Spaleta, these packages
could eat babies; that is to say, they are built, signed, and ready for
use, but they have not gone through the rigorous QA testing that would
be expected normally from Extras. So if they break, submit a bug report,
but there are no implied warranties or guarantees that they will work.
Use these packages at your own risk!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/b29dfe34/attachment.sig>

From skvidal at phy.duke.edu  Thu Dec 16 19:04:32 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 14:04:32 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103222658.8566.10.camel@one.myworld>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld> <1103221985.1763.4.camel@cutter>
	<1103222658.8566.10.camel@one.myworld>
Message-ID: <1103223872.1763.20.camel@cutter>


> Is there any plan to add a /etc/yum.repo.d/fedora-extras.repo in the
> fedora-release package (perhaps disabled by default) ?

Once extras is opened regularly, it'd be a good idea.

We're getting there.

Gafton's been refining the automation so it's just some button pushing
away. :)

-sv





From ndbecker2 at verizon.net  Thu Dec 16 19:48:10 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Thu, 16 Dec 2004 14:48:10 -0500
Subject: svn or arch
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter>
Message-ID: <cpsopq$scj$1@sea.gmane.org>

seth vidal wrote:

> On Thu, 2004-12-16 at 10:21 -0800, Rahul Sundaram wrote:
>> Hi
>> 
>> > Yes - Cristian Gafton did months of extensive
>> > testing to see if either
>> > could stand up to the load of internal and external
>> > checkins on the
>> > scale red hat does with distributions.
>> > 
>> > He found that cvs was the only one to stand up to
>> > the load.
>> 
>> Ok thanks for the quick reply. are the results
>> available anywhere. It would be nice to let the
>> svn/arch developers know about this. I am pretty sure
>> they would be interested
> 
> You can ask - but i'm not sure they are.
> 
> I know of them anecdotally - However, from what I know of Gafton he had
> good reason for saying what he said.
> 
> -sv
> 
> 

You might want to look at darcs.  This one looks the most promising, in it's
design.  Only disadvantage, it's written in Haskell.



From kyrre at solution-forge.net  Thu Dec 16 19:47:49 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Thu, 16 Dec 2004 20:47:49 +0100
Subject: svn or arch
In-Reply-To: <cpsopq$scj$1@sea.gmane.org>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter>  <cpsopq$scj$1@sea.gmane.org>
Message-ID: <1103226469.4514.3.camel@kyrre>

tor, 16.12.2004 kl. 20.48 skrev Neal D. Becker:
> seth vidal wrote:
> 
> > On Thu, 2004-12-16 at 10:21 -0800, Rahul Sundaram wrote:
> >> Hi
> >> 
> >> > Yes - Cristian Gafton did months of extensive
> >> > testing to see if either
> >> > could stand up to the load of internal and external
> >> > checkins on the
> >> > scale red hat does with distributions.
> >> > 
> >> > He found that cvs was the only one to stand up to
> >> > the load.
> >> 
> >> Ok thanks for the quick reply. are the results
> >> available anywhere. It would be nice to let the
> >> svn/arch developers know about this. I am pretty sure
> >> they would be interested
> > 
> > You can ask - but i'm not sure they are.
> > 
> > I know of them anecdotally - However, from what I know of Gafton he had
> > good reason for saying what he said.
> > 
> > -sv
> > 
> > 
> 
> You might want to look at darcs.  This one looks the most promising, in it's
> design.  Only disadvantage, it's written in Haskell.

In WHAT?



From balay at fastmail.fm  Thu Dec 16 20:01:34 2004
From: balay at fastmail.fm (Satish Balay)
Date: Thu, 16 Dec 2004 14:01:34 -0600 (CST)
Subject: svn or arch
In-Reply-To: <cpsopq$scj$1@sea.gmane.org>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter> <cpsopq$scj$1@sea.gmane.org>
Message-ID: <Pine.LNX.4.61.0412161358520.14188@asterix>

On Thu, 16 Dec 2004, Neal D. Becker wrote:

> You might want to look at darcs.  This one looks the most promising,
> in it's design.  Only disadvantage, it's written in Haskell.

Looking at the 'users manual' the interface looks pretty close to
bitkeeper - (which is a +1 for darcs from my POV)

But I guess - now that CVS is already choosen - it will be a very-very
long time - before any change is contemplated.

Satish



From j.w.r.degoede at hhs.nl  Thu Dec 16 20:12:32 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Dec 2004 21:12:32 +0100
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <1103223626.1763.18.camel@cutter>
References: <1103223626.1763.18.camel@cutter>
Message-ID: <41C1EC30.6070308@hhs.nl>

I noticed xv is also included, does that mean that it is ok to package 
not 100% oss software, I'm especially thinking about free (as in 
beer)/gratis, with sourcecode, but not for commercial use, without any 
further redistribution limitations.

Examples of things I would _really_ like to package:
xmame x.mame.net
d1x   d1x.warpcore.org (linux port of the clasic descent game based on
                         source released by the original autors)
d1x-shareware-datafiles

Things which I might like to add:
wolf3d, doom, heretic, quake, etc :)

So basicly games games games, because I always get the complaint of 
friends that there are no games for linux, and because I like retro gaming.



Regards,

Hans



From j.w.r.degoede at hhs.nl  Thu Dec 16 20:23:58 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Dec 2004 21:23:58 +0100
Subject: Me stupid: lost password for gpg
Message-ID: <41C1EEDE.1080202@hhs.nl>

Hi,

Some time ago I've done attempts of packages for svgalib on yodl, before 
this I didn't really have a need for pgp, so I didn't use gpg. I've done 
a few (signed) test releases of packages for svgalib and yodl, but those 
got stuck in the QA queue. After this I turned my attention to some 
other projects (xmame mainly).

Then some time ago I decided that I wanted to try again to get those 
package through the QA queue, and ... oops I forgot my gpg password :|

See I thought, hmm this is going to be an important password letts think 
up a new one (mistake!), used it a couple of times then didn't use it 
for a few months and now BUMMER!

Seeing how Fedora-Extras is really shaping up now I really would like to 
  become an active community member (not a good start this) and do some 
packaging.

Now I've already submitted my gpg key to: pgp.mit.edu.
I could ofcourse just nuke my current .gpg dir and start from scratch 
since not many people have my public key already, but then my old key 
would still be registered at pgp.mit.edu .

The faq at pgp.mit.edu also doesn't make me happy (at all) anything I 
can do?

I'm already quite embaressed about this as it is, so no that is SO 
stupid replies please.

Thanks & Regards,

Hans



From fedora at wir-sind-cool.org  Thu Dec 16 20:29:48 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 16 Dec 2004 21:29:48 +0100
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <41C1EC30.6070308@hhs.nl>
References: <1103223626.1763.18.camel@cutter>
	<41C1EC30.6070308@hhs.nl>
Message-ID: <20041216212948.642d7eee.fedora@wir-sind-cool.org>

On Thu, 16 Dec 2004 21:12:32 +0100, Hans de Goede wrote:

> I noticed xv is also included, does that mean that it is ok to package 
> not 100% oss software, I'm especially thinking about free (as in 
> beer)/gratis, with sourcecode, but not for commercial use, without any 
> further redistribution limitations.

https://www.redhat.com/archives/fedora-extras-commits/2004-December/msg00084.html



From denisleroy at yahoo.com  Thu Dec 16 20:32:46 2004
From: denisleroy at yahoo.com (Denis Leroy)
Date: Thu, 16 Dec 2004 12:32:46 -0800 (PST)
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <20041216212948.642d7eee.fedora@wir-sind-cool.org>
Message-ID: <20041216203246.66164.qmail@web60705.mail.yahoo.com>

What is going to happen to bugzilla.fedora.us ? Should new package
requests now be filed at bugzilla.redhat.com ?

-denis



From skvidal at phy.duke.edu  Thu Dec 16 20:35:36 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 15:35:36 -0500
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <20041216203246.66164.qmail@web60705.mail.yahoo.com>
References: <20041216203246.66164.qmail@web60705.mail.yahoo.com>
Message-ID: <1103229337.5795.0.camel@cutter>

On Thu, 2004-12-16 at 12:32 -0800, Denis Leroy wrote:
> What is going to happen to bugzilla.fedora.us ? Should new package
> requests now be filed at bugzilla.redhat.com ?

Yes.

bugzilla.fedora.us - will eventually freeze and eventually go away.

-sv




From rahulsundaram at yahoo.co.in  Thu Dec 16 20:44:17 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 12:44:17 -0800 (PST)
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <1103223626.1763.18.camel@cutter>
Message-ID: <20041216204417.27974.qmail@web8502.mail.in.yahoo.com>

Hi

> Where did all these packages come from?
> These were packages from the now-merged Fedora.us
> repository as well as
> freshrpms.net repository. So they maintain the same
> high quality
> standards that was imposed previously.


does that mean fedora extras will work in a compatible
way with freshrpms.net or did you just import the
packages that are known to work well?

In other words is there any mutual coordination


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250



From rahulsundaram at yahoo.co.in  Thu Dec 16 20:47:45 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 12:47:45 -0800 (PST)
Subject: svn or arch
In-Reply-To: <Pine.LNX.4.61.0412161358520.14188@asterix>
Message-ID: <20041216204745.27505.qmail@web8504.mail.in.yahoo.com>


--- Satish Balay <balay at fastmail.fm> wrote:

> On Thu, 16 Dec 2004, Neal D. Becker wrote:
> 
> > You might want to look at darcs.  This one looks
> the most promising,
> > in it's design.  Only disadvantage, it's written
> in Haskell.
> 
> Looking at the 'users manual' the interface looks
> pretty close to
> bitkeeper - (which is a +1 for darcs from my POV)


there are major design differences though. you might
want to read the recent blogs on planet and a
interview done with the developer(google knows better)


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 



From kyrre at solution-forge.net  Thu Dec 16 20:52:46 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Thu, 16 Dec 2004 21:52:46 +0100
Subject: Choice of default fonts in webrowsers
Message-ID: <1103230340.4702.5.camel@kyrre>

Hello

After reading to much forums, i can se "everyone" is complaing about
"the default font in (put your favorite web browser here) is so ugly, it
is hardly readable!"

Then the reply is "use Bitstream vera (sans) instead" and then "oh! that
was better! it was really readable! nice!"

Why is it so? Why is those fonts, which it seem like "everyone" thinks
are really ugly are used, when better fonts are shipped?

I would guess there are more people than me who has opinions on this.

Disclaimer: i am forwarding a "general feeling" from parts of the
comunity, as not everyone are on this list. But after changing my
default fonts in firefox, i must say i agree. This was *much* better!

Kyrre Ness Sj?b?k



From kyrre at solution-forge.net  Thu Dec 16 20:54:36 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Thu, 16 Dec 2004 21:54:36 +0100
Subject: Me stupid: lost password for gpg
In-Reply-To: <41C1EEDE.1080202@hhs.nl>
References: <41C1EEDE.1080202@hhs.nl>
Message-ID: <1103230476.4702.7.camel@kyrre>

tor, 16.12.2004 kl. 21.23 skrev Hans de Goede:
> Hi,
> 
> Some time ago I've done attempts of packages for svgalib on yodl, before 
> this I didn't really have a need for pgp, so I didn't use gpg. I've done 
> a few (signed) test releases of packages for svgalib and yodl, but those 
> got stuck in the QA queue. After this I turned my attention to some 
> other projects (xmame mainly).
> 
> Then some time ago I decided that I wanted to try again to get those 
> package through the QA queue, and ... oops I forgot my gpg password :|
> 
> See I thought, hmm this is going to be an important password letts think 
> up a new one (mistake!), used it a couple of times then didn't use it 
> for a few months and now BUMMER!
> 

sounds familiar

> Seeing how Fedora-Extras is really shaping up now I really would like to 
>   become an active community member (not a good start this) and do some 
> packaging.
> 
> Now I've already submitted my gpg key to: pgp.mit.edu.
> I could ofcourse just nuke my current .gpg dir and start from scratch 
> since not many people have my public key already, but then my old key 
> would still be registered at pgp.mit.edu .
> 
> The faq at pgp.mit.edu also doesn't make me happy (at all) anything I 
> can do?
> 
> I'm already quite embaressed about this as it is, so no that is SO 
> stupid replies please.
> 
> Thanks & Regards,
> 
> Hans

I'm in the same pos, only nobody exept RH translation project know about
my key...



From pri.rhl3 at iadonisi.to  Thu Dec 16 21:19:56 2004
From: pri.rhl3 at iadonisi.to (Paul Iadonisi)
Date: Thu, 16 Dec 2004 16:19:56 -0500
Subject: Me stupid: lost password for gpg
In-Reply-To: <41C1EEDE.1080202@hhs.nl>
References: <41C1EEDE.1080202@hhs.nl>
Message-ID: <1103231996.4704.7.camel@tuxpaq>

On Thu, 2004-12-16 at 21:23 +0100, Hans de Goede wrote:

[snip]

> See I thought, hmm this is going to be an important password letts think 
> up a new one (mistake!), used it a couple of times then didn't use it 
> for a few months and now BUMMER!

[snip]

> Now I've already submitted my gpg key to: pgp.mit.edu.
> I could ofcourse just nuke my current .gpg dir and start from scratch 
> since not many people have my public key already, but then my old key 
> would still be registered at pgp.mit.edu .

[snip]

> I'm already quite embaressed about this as it is, so no that is SO 
> stupid replies please.

  I feel your pain.  Once upon a time, I had three PGP 2.6.2 keys, but I
had only submitted one to pgp.mit.edu.  I wanted to revoke it, so I
revoked it in my local keychain, and extracted *the WRONG key* and
submitted it to pgp.mit.edu.  As luck would have it, it was the one out
of the three keys whose password I had long forgotten due to lack of
use.

  *sigh*

  Maybe the new dual Opteron box I just ordered can crack the passwords
for both our keys. ;-)

  I would *love* to find a way to remove my key from pgp.mit.edu as
well.  Any help to Hans would be appreciated over here as well.
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets



From mattdm at mattdm.org  Thu Dec 16 21:29:45 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 16 Dec 2004 16:29:45 -0500
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <1103229337.5795.0.camel@cutter>
References: <20041216203246.66164.qmail@web60705.mail.yahoo.com>
	<1103229337.5795.0.camel@cutter>
Message-ID: <20041216212945.GA24987@jadzia.bu.edu>

On Thu, Dec 16, 2004 at 03:35:36PM -0500, seth vidal wrote:
> > What is going to happen to bugzilla.fedora.us ? Should new package
> > requests now be filed at bugzilla.redhat.com ?
> bugzilla.fedora.us - will eventually freeze and eventually go away.

Thus bringning up the question: what about Fedora Legacy?

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From j.w.r.degoede at hhs.nl  Thu Dec 16 21:32:20 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Dec 2004 22:32:20 +0100
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <20041216212948.642d7eee.fedora@wir-sind-cool.org>
References: <1103223626.1763.18.camel@cutter>	<41C1EC30.6070308@hhs.nl>
	<20041216212948.642d7eee.fedora@wir-sind-cool.org>
Message-ID: <41C1FEE4.9090905@hhs.nl>



Michael Schwendt wrote:
> On Thu, 16 Dec 2004 21:12:32 +0100, Hans de Goede wrote:
> 
> 
>>I noticed xv is also included, does that mean that it is ok to package 
>>not 100% oss software, I'm especially thinking about free (as in 
>>beer)/gratis, with sourcecode, but not for commercial use, without any 
>>further redistribution limitations.
> 
> 
> https://www.redhat.com/archives/fedora-extras-commits/2004-December/msg00084.html
> 

Ah,

Thanks for the heads up, and what does this mean for other non 100% oss 
software not a chance or does it depend on the wording of the license, 
or .... ?

To bad xv will be removed again, xv is a great tool and I think many 
people would like it being available through yum.

Regards,

Hans



From rdieter at math.unl.edu  Thu Dec 16 21:31:56 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 16 Dec 2004 15:31:56 -0600
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <20041216212945.GA24987@jadzia.bu.edu>
References: <20041216203246.66164.qmail@web60705.mail.yahoo.com>	<1103229337.5795.0.camel@cutter>
	<20041216212945.GA24987@jadzia.bu.edu>
Message-ID: <41C1FECC.6010004@math.unl.edu>

Matthew Miller wrote:
> On Thu, Dec 16, 2004 at 03:35:36PM -0500, seth vidal wrote:
> 
>>>What is going to happen to bugzilla.fedora.us ? Should new package
>>>requests now be filed at bugzilla.redhat.com ?
>>
>>bugzilla.fedora.us - will eventually freeze and eventually go away.
> 
> 
> Thus bringning up the question: what about Fedora Legacy?

Why to you ask?  AFAIK, Fedora Legacy was/is (and will continue to be) 
separate from Fedora Extras (and redhat).

-- Rex



From skvidal at phy.duke.edu  Thu Dec 16 21:38:08 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 16 Dec 2004 16:38:08 -0500
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <41C1FEE4.9090905@hhs.nl>
References: <1103223626.1763.18.camel@cutter>	<41C1EC30.6070308@hhs.nl>
	<20041216212948.642d7eee.fedora@wir-sind-cool.org>
	<41C1FEE4.9090905@hhs.nl>
Message-ID: <1103233088.5795.8.camel@cutter>

On Thu, 2004-12-16 at 22:32 +0100, Hans de Goede wrote:
> 
> Michael Schwendt wrote:
> > On Thu, 16 Dec 2004 21:12:32 +0100, Hans de Goede wrote:
> > 
> > 
> >>I noticed xv is also included, does that mean that it is ok to package 
> >>not 100% oss software, I'm especially thinking about free (as in 
> >>beer)/gratis, with sourcecode, but not for commercial use, without any 
> >>further redistribution limitations.
> > 
> > 
> > https://www.redhat.com/archives/fedora-extras-commits/2004-December/msg00084.html
> > 
> 
> Ah,
> 
> Thanks for the heads up, and what does this mean for other non 100% oss 
> software not a chance or does it depend on the wording of the license, 
> or .... ?
> 
> To bad xv will be removed again, xv is a great tool and I think many 
> people would like it being available through yum.
> 

It's been removed now.

-sv




From j.w.r.degoede at hhs.nl  Thu Dec 16 21:38:33 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Dec 2004 22:38:33 +0100
Subject: Me stupid: lost password for gpg
In-Reply-To: <1103230476.4702.7.camel@kyrre>
References: <41C1EEDE.1080202@hhs.nl> <1103230476.4702.7.camel@kyrre>
Message-ID: <41C20059.7010701@hhs.nl>

Yes,

Got it, it turns out it was closer to one of my other passwords then I 
thought, so after trying lotts of exoting combinations I found it.

Please forget I ever mailed about this, I never forgot my password, 
thats all in your imgination .... :)

One very happy camper,

Hans


Kyrre Ness Sjobak wrote:
> tor, 16.12.2004 kl. 21.23 skrev Hans de Goede:
> 
>>Hi,
>>
>>Some time ago I've done attempts of packages for svgalib on yodl, before 
>>this I didn't really have a need for pgp, so I didn't use gpg. I've done 
>>a few (signed) test releases of packages for svgalib and yodl, but those 
>>got stuck in the QA queue. After this I turned my attention to some 
>>other projects (xmame mainly).
>>
>>Then some time ago I decided that I wanted to try again to get those 
>>package through the QA queue, and ... oops I forgot my gpg password :|
>>
>>See I thought, hmm this is going to be an important password letts think 
>>up a new one (mistake!), used it a couple of times then didn't use it 
>>for a few months and now BUMMER!
>>
> 
> 
> sounds familiar
> 
> 
>>Seeing how Fedora-Extras is really shaping up now I really would like to 
>>  become an active community member (not a good start this) and do some 
>>packaging.
>>
>>Now I've already submitted my gpg key to: pgp.mit.edu.
>>I could ofcourse just nuke my current .gpg dir and start from scratch 
>>since not many people have my public key already, but then my old key 
>>would still be registered at pgp.mit.edu .
>>
>>The faq at pgp.mit.edu also doesn't make me happy (at all) anything I 
>>can do?
>>
>>I'm already quite embaressed about this as it is, so no that is SO 
>>stupid replies please.
>>
>>Thanks & Regards,
>>
>>Hans
> 
> 
> I'm in the same pos, only nobody exept RH translation project know about
> my key...
> 



From mattdm at mattdm.org  Thu Dec 16 21:40:12 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 16 Dec 2004 16:40:12 -0500
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <41C1FECC.6010004@math.unl.edu>
References: <20041216203246.66164.qmail@web60705.mail.yahoo.com>
	<1103229337.5795.0.camel@cutter>
	<20041216212945.GA24987@jadzia.bu.edu>
	<41C1FECC.6010004@math.unl.edu>
Message-ID: <20041216214012.GA25635@jadzia.bu.edu>

On Thu, Dec 16, 2004 at 03:31:56PM -0600, Rex Dieter wrote:
> >>bugzilla.fedora.us - will eventually freeze and eventually go away.
> >Thus bringning up the question: what about Fedora Legacy?
> Why to you ask?  AFAIK, Fedora Legacy was/is (and will continue to be) 
> separate from Fedora Extras (and redhat).

They're currently using the fedora.us bugzilla. It would be *very* nice if
this were integrated with the main Fedora bugzilla, because then critical
bugs for legacy Fedora releases could be easily retargeted.


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From mike at navi.cx  Thu Dec 16 21:47:19 2004
From: mike at navi.cx (Mike Hearn)
Date: Thu, 16 Dec 2004 21:47:19 +0000
Subject: svn or arch
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter> <cpsopq$scj$1@sea.gmane.org>
Message-ID: <pan.2004.12.16.21.47.19.496147@navi.cx>

On Thu, 16 Dec 2004 14:48:10 -0500, Neal D. Becker wrote:
> You might want to look at darcs.  This one looks the most promising, in it's
> design.  Only disadvantage, it's written in Haskell.

Darcs also has scalability issues as admitted to by the author. So I guess
it would fail for the same reasons subversion and arch did. 

thanks -mike



From fedora at wir-sind-cool.org  Thu Dec 16 21:46:00 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 16 Dec 2004 22:46:00 +0100
Subject: Fedora Project launches Pre-Extras
In-Reply-To: <41C1FECC.6010004@math.unl.edu>
References: <20041216203246.66164.qmail@web60705.mail.yahoo.com>
	<1103229337.5795.0.camel@cutter>
	<20041216212945.GA24987@jadzia.bu.edu>
	<41C1FECC.6010004@math.unl.edu>
Message-ID: <20041216224600.78af90ba.fedora@wir-sind-cool.org>

On Thu, 16 Dec 2004 15:31:56 -0600, Rex Dieter wrote:

> Matthew Miller wrote:
> > On Thu, Dec 16, 2004 at 03:35:36PM -0500, seth vidal wrote:
> > 
> >>>What is going to happen to bugzilla.fedora.us ? Should new package
> >>>requests now be filed at bugzilla.redhat.com ?
> >>
> >>bugzilla.fedora.us - will eventually freeze and eventually go away.
> > 
> > 
> > Thus bringning up the question: what about Fedora Legacy?
> 
> Why to you ask?  AFAIK, Fedora Legacy was/is (and will continue to be) 
> separate from Fedora Extras (and redhat).

No, moving Fedora Legacy into Red Hat's bugzilla is planned, too.



From rahulsundaram at yahoo.co.in  Thu Dec 16 22:11:57 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 14:11:57 -0800 (PST)
Subject: Choice of default fonts in webrowsers
In-Reply-To: <1103230340.4702.5.camel@kyrre>
Message-ID: <20041216221157.72779.qmail@web8509.mail.in.yahoo.com>

Hi


> 
> Why is it so? Why is those fonts, which it seem like
> "everyone" thinks
> are really ugly are used, when better fonts are
> shipped?


I have heard before that this is because the default
fonts should be internationalised or something like
that which bitstream fonts arent

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From Nicolas.Mailhot at laPoste.net  Thu Dec 16 22:21:23 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Thu, 16 Dec 2004 23:21:23 +0100
Subject: Choice of default fonts in webrowsers
In-Reply-To: <20041216221157.72779.qmail@web8509.mail.in.yahoo.com>
References: <20041216221157.72779.qmail@web8509.mail.in.yahoo.com>
Message-ID: <1103235683.12071.5.camel@rousalka.dyndns.org>

Le jeudi 16 d?cembre 2004 ? 14:11 -0800, Rahul Sundaram a ?crit :
> Hi
> 
> 
> > 
> > Why is it so? Why is those fonts, which it seem like
> > "everyone" thinks
> > are really ugly are used, when better fonts are
> > shipped?
> 
> 
> I have heard before that this is because the default
> fonts should be internationalised or something like
> that which bitstream fonts arent

It might be worth taking a new look now that the deja variant of vera is
announcing new glyphs every other months. Of course we're far from full
unicode coverage, but fontconfig will fall back on Luxi if needed, so...

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/58df0524/attachment.sig>

From Nicolas.Mailhot at laPoste.net  Thu Dec 16 22:23:29 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Thu, 16 Dec 2004 23:23:29 +0100
Subject: Me stupid: lost password for gpg
In-Reply-To: <1103230476.4702.7.camel@kyrre>
References: <41C1EEDE.1080202@hhs.nl>  <1103230476.4702.7.camel@kyrre>
Message-ID: <1103235809.12071.8.camel@rousalka.dyndns.org>

Le jeudi 16 d?cembre 2004 ? 21:54 +0100, Kyrre Ness Sjobak a ?crit :
> tor, 16.12.2004 kl. 21.23 skrev Hans de Goede:
> > Hi,
> > 
> > Some time ago I've done attempts of packages for svgalib on yodl, before 
> > this I didn't really have a need for pgp, so I didn't use gpg. I've done 
> > a few (signed) test releases of packages for svgalib and yodl, but those 
> > got stuck in the QA queue. After this I turned my attention to some 
> > other projects (xmame mainly).
> > 
> > Then some time ago I decided that I wanted to try again to get those 
> > package through the QA queue, and ... oops I forgot my gpg password :|
> > 
> > See I thought, hmm this is going to be an important password letts think 
> > up a new one (mistake!), used it a couple of times then didn't use it 
> > for a few months and now BUMMER!
> > 
> 
> sounds familiar
> 
> > Seeing how Fedora-Extras is really shaping up now I really would like to 
> >   become an active community member (not a good start this) and do some 
> > packaging.
> > 
> > Now I've already submitted my gpg key to: pgp.mit.edu.
> > I could ofcourse just nuke my current .gpg dir and start from scratch 
> > since not many people have my public key already, but then my old key 
> > would still be registered at pgp.mit.edu .
> > 
> > The faq at pgp.mit.edu also doesn't make me happy (at all) anything I 
> > can do?
> > 
> > I'm already quite embaressed about this as it is, so no that is SO 
> > stupid replies please.
> > 
> > Thanks & Regards,
> > 
> > Hans
> 
> I'm in the same pos, only nobody exept RH translation project know about
> my key...

That's why you should always time-limit your keys. Extending them by
another year every 12 months is a lot easier than trying to rescue a
lost key.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/9e2b8ab5/attachment.sig>

From Hugh_Caley at affymetrix.com  Thu Dec 16 22:26:01 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Thu, 16 Dec 2004 14:26:01 -0800
Subject: drm/dri problem on FC3 (x86_64?)
Message-ID: <41C20B79.402@affymetrix.com>

I'm having a problem with an install of FC3 on an Opteron machine.  The
X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
same with both a Matrox G550 and an ATI Radeon 9200 card.

Seems to be a problem with drm and dri initialization.

Anyone else seeing this?

I've added to a bugzilla bug that seems to be on target.  There are
errors and xorg.conf snippets there.  Interestingly, it seems that it
isn't x86_64 specific. 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142105

Relevant log entries below.

I note that I have no /dev/dri directory.  Created one, but it's gone on
reboot.  My 32-bit machine has these entries in dmesg, but the 64-bit
machine does not:

i386:

agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode

x86_64:

dmesg:

agpgart: Detected AMD 8151 AGP Bridge rev B3
agpgart: Maximum main memory to use for agp memory: 7956M
agpgart: AGP aperture is 128M @ 0xf0000000
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

Linux agpgart interface v0.100 (c) Dave Jones

vesafb: probe of vesafb0 failed with error -6

Xorg.0.log:

(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib64/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
(II) MGA(0): [drm] bpp: 32 depth: 24
(II) MGA(0): [drm] Sarea 2200+664: 2864
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
[drm] failed to load kernel module "mga"
(II) MGA(0): [drm] drmOpen failed
(EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI.

Hugh

-- 
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley at affymetrix.com



From alan at redhat.com  Thu Dec 16 22:34:53 2004
From: alan at redhat.com (Alan Cox)
Date: Thu, 16 Dec 2004 17:34:53 -0500
Subject: drm/dri problem on FC3 (x86_64?)
In-Reply-To: <41C20B79.402@affymetrix.com>
References: <41C20B79.402@affymetrix.com>
Message-ID: <20041216223453.GA28118@devserv.devel.redhat.com>

On Thu, Dec 16, 2004 at 02:26:01PM -0800, Hugh Caley wrote:
> I'm having a problem with an install of FC3 on an Opteron machine.  The
> X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
> similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
> same with both a Matrox G550 and an ATI Radeon 9200 card.

Matrox DRI is not supported on x86_64 until about 2 weeks ago

> agpgart: Detected AMD 8151 AGP Bridge rev B3
> agpgart: Maximum main memory to use for agp memory: 7956M
> agpgart: AGP aperture is 128M @ 0xf0000000
> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

AGP is fine

> drmOpenDevice: Open failed
> [drm] failed to load kernel module "mga"
> (II) MGA(0): [drm] drmOpen failed
> (EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI.

As expected. Please post the Radeon traces however



From dag at wieers.com  Thu Dec 16 22:45:28 2004
From: dag at wieers.com (Dag Wieers)
Date: Thu, 16 Dec 2004 23:45:28 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103221985.1763.4.camel@cutter>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld>
	<1103221985.1763.4.camel@cutter>
Message-ID: <Pine.LNX.4.61.0412162339030.921@horsea.3ti.be>

On Thu, 16 Dec 2004, seth vidal wrote:

> On Thu, 2004-12-16 at 19:27 +0100, F?liciano Matias wrote:
> > Le jeudi 16 d?cembre 2004 ? 00:44 -0500, seth vidal a ?crit :
> > > Want to be REAL sure you notice this:
> > > 
> > > 
> > > http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> > > 
> > > 
> > > That's Right CVS is open - you need to  run, don't walk, to:
> > > 
> > > http://cvs.fedora.redhat.com
> > > 
> > 
> > RHEL extras ?
> 
> That's decidedly off-topic for this list.
> 
> Ask on taroon list.

In essence it's not off-topic. FC3 turns into RHEL4, it makes no sense to 
make the Extras Fedora-specific. Even when RHEL is not a community 
product.

Of course, Fedora Extras has a 6 months life-time and memory span, if you 
think about RHEL packages, you think about at least 5 years and at least 3 
concurrent versions to support.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

From dries at ulyssis.org  Thu Dec 16 23:33:43 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Fri, 17 Dec 2004 00:33:43 +0100
Subject: svn or arch
In-Reply-To: <1103226469.4514.3.camel@kyrre>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<cpsopq$scj$1@sea.gmane.org> <1103226469.4514.3.camel@kyrre>
Message-ID: <200412170033.43747.dries@ulyssis.org>

On Thursday 16 December 2004 20:47, Kyrre Ness Sjobak wrote:
> tor, 16.12.2004 kl. 20.48 skrev Neal D. Becker:
> > seth vidal wrote:
> > You might want to look at darcs.  This one looks the most promising, in
> > it's design.  Only disadvantage, it's written in Haskell.
>
> In WHAT?

Haskell is a functional programming language. A well known interpreter for 
Haskell on Linux is Hugs if you want to try it. You get to know stuff like 
list comprehensions and pattern matching and i think there's also an object 
oriented version for the freaks :-)

kind regards,
Dries Verachtert



From Hugh_Caley at affymetrix.com  Fri Dec 17 01:00:58 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Thu, 16 Dec 2004 17:00:58 -0800
Subject: drm/dri problem on FC3 (x86_64?)
Message-ID: <41C22FCA.3010706@affymetrix.com>

Here's the logs when using the ATI card.  At least /dev/dri/card0 is 
being created, although DRI still doesn't initialize.

dmesg:

agpgart: Detected AMD 8151 AGP Bridge rev B3
agpgart: Maximum main memory to use for agp memory: 7956M
agpgart: AGP aperture is 256M @ 0xe0000000

Xorg.O.log:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: Searching for BusID pci:0000:05:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci:0000:05:00.0
(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:05:00.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xffffff0000068000
(II) RADEON(0): [drm] mapped SAREA 0xffffff0000068000 to 0x2a9d718000
(II) RADEON(0): [drm] drmAddMap failed
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

Hugh

>         <fedora-devel-list at redhat.com>
> Message-ID: <20041216223453.GA28118 at devserv.devel.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Dec 16, 2004 at 02:26:01PM -0800, Hugh Caley wrote:
> > I'm having a problem with an install of FC3 on an Opteron machine.  The
> > X performance is deadly slow; glxgears gives me less than 53 FPS.  On a
> > similarly x86 32-bit machine I'm getting well over 500 FPS.  It's the
> > same with both a Matrox G550 and an ATI Radeon 9200 card.
>
> Matrox DRI is not supported on x86_64 until about 2 weeks ago
>
> > agpgart: Detected AMD 8151 AGP Bridge rev B3
> > agpgart: Maximum main memory to use for agp memory: 7956M
> > agpgart: AGP aperture is 128M @ 0xf0000000
> > PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
>
> AGP is fine

> > drmOpenDevice: Open failed
> > [drm] failed to load kernel module "mga"
> > (II) MGA(0): [drm] drmOpen failed
> > (EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI.
>
> As expected. Please post the Radeon traces however


-- 
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley at affymetrix.com



From ndbecker2 at verizon.net  Fri Dec 17 01:06:04 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Thu, 16 Dec 2004 20:06:04 -0500
Subject: svn or arch
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter> <cpsopq$scj$1@sea.gmane.org>
	<pan.2004.12.16.21.47.19.496147@navi.cx>
Message-ID: <cptbds$bqq$1@sea.gmane.org>

Mike Hearn wrote:

> On Thu, 16 Dec 2004 14:48:10 -0500, Neal D. Becker wrote:
>> You might want to look at darcs.  This one looks the most promising, in
>> it's
>> design.  Only disadvantage, it's written in Haskell.
> 
> Darcs also has scalability issues as admitted to by the author. So I guess
> it would fail for the same reasons subversion and arch did.
> 
> thanks -mike
> 

Yes, that's why I said the _design_ looks promising.  The implementation
still is immature.



From christopher.hotchkiss at gmail.com  Fri Dec 17 01:11:46 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Thu, 16 Dec 2004 20:11:46 -0500
Subject: Stateless kickstart problem
In-Reply-To: <41C0DE87.7000200@mitre.org>
References: <41BE44E1.3070708@subarutelescope.org>
	<7f48492a04121323234036bb49@mail.gmail.com>
	<41BF2E4C.1000000@subarutelescope.org>
	<7f48492a0412141346146a080e@mail.gmail.com>
	<7f48492a041214140667257001@mail.gmail.com>
	<41C0DE87.7000200@mitre.org>
Message-ID: <7f48492a0412161711714e450a@mail.gmail.com>

You can't do that for this. The problem is that when you set the
network to PXE boot by default, the box never comes up.  The box gets
trapped in a infinite loop. One way to solve this is to compile a grub
stage to allow for a grub pxe boot. So once the box is installed you
can set the grub file's default to be a pxe boot to force a reinstall.

I am thinking about using patch, netexec, and/or rsync to allow for
diffs to be made between snapshot versions. This will conserve
diskspace between slight changes. Finally i need to package netexec
into a rpm.

-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From wtogami at redhat.com  Fri Dec 17 01:14:40 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 16 Dec 2004 15:14:40 -1000
Subject: drm/dri problem on FC3 (x86_64?)
In-Reply-To: <41C20B79.402@affymetrix.com>
References: <41C20B79.402@affymetrix.com>
Message-ID: <41C23300.6000500@redhat.com>

http://fedoraproject.org/wiki/PostIsOffTopic

Please do not use fedora-devel-list for user support questions.

Warren Togami
wtogami at redhat.com



From Hugh_Caley at affymetrix.com  Fri Dec 17 01:20:23 2004
From: Hugh_Caley at affymetrix.com (Hugh Caley)
Date: Thu, 16 Dec 2004 17:20:23 -0800 (PST)
Subject: drm/dri problem on FC3 (x86_64?)
In-Reply-To: <41C23300.6000500@redhat.com>
Message-ID: <Pine.LNX.4.44.0412161719460.25728-100000@ls2.ev.affymetrix.com>

I'm not sure this is a user support question.  It seems to be a kernel 
issue, and Alan Cox thought it important enough to follow up on.

Hugh

--
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley at affymetrix.com

On Thu, 16 Dec 2004, Warren Togami wrote:

> Date: Thu, 16 Dec 2004 17:14:40 -0800
> From: Warren Togami <wtogami at redhat.com>
> To: Development discussions related to Fedora Core
>     <fedora-devel-list at redhat.com>
> Cc: "caley, hugh" <hugh_caley at affymetrix.com>
> Subject: Re: drm/dri problem on FC3 (x86_64?)
> 
> http://fedoraproject.org/wiki/PostIsOffTopic
> 
> Please do not use fedora-devel-list for user support questions.
> 
> Warren Togami
> wtogami at redhat.com
> 



From smooge at gmail.com  Fri Dec 17 01:22:19 2004
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Thu, 16 Dec 2004 18:22:19 -0700
Subject: Differences between the kernel source in FC2 and the kernel
	source obtained from kernel.org?
In-Reply-To: <20041215064647.14650.qmail@web51506.mail.yahoo.com>
References: <20041215064647.14650.qmail@web51506.mail.yahoo.com>
Message-ID: <80d7e4090412161722331a62ed@mail.gmail.com>

On Tue, 14 Dec 2004 22:46:47 -0800 (PST), Park Lee
<parklee_sel at yahoo.com> wrote:
> Hi,
>   Is there any difference between the kernel source in
> FC2(version 2.6.5-1.358) and the kernel source
> (version 2.6.5)obtained from kernel.org?
>   Can I also download a 2.6.5 (or higher)version
> kernel source from kernel.org to replace the FC2's
> origianl kernel source and compile the new downloaded
> kernel source to yield a vmlinuz and run it as FC2's
> kernel without any conflict?
>   Thank you.

There are probably several 'differences' and patches between the 2
kernels. THe best way to look at it would be to get the kernel.src.rpm
from Fedora tree and then do a rpm -ivh of it. Look at the spec file
and the patches to see what the differences are.

I have not heard of any problems with having straight source running
on a machine as long as some fundamental things are turned on in the
new kernel as they are in the Fedora version. I am guessing Selinux
would be one, but there are probably other.s

> 
> =====
> Best Regards,
> Park Lee
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From smooge at gmail.com  Fri Dec 17 01:25:36 2004
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Thu, 16 Dec 2004 18:25:36 -0700
Subject: mysql 4
In-Reply-To: <20041215194102.58848.qmail@web90105.mail.scd.yahoo.com>
References: <41BF6E38.7030007@comarb.gov.ar>
	<20041215194102.58848.qmail@web90105.mail.scd.yahoo.com>
Message-ID: <80d7e40904121617252aac6583@mail.gmail.com>

On Wed, 15 Dec 2004 11:41:02 -0800 (PST), linux romeo
<linuxromeo at yahoo.com> wrote:
> hello list,
>           I have recently started using fc2 moving
> from mandrake 10 ......I want to ask why fc still has
> mysql 3.323 .....I tried to install mysql 4 rpm but
> gave me lots dep problem.....it there any any fc rpm
> for that ...i tried seraching for it but could'nt find
> 4...
> 

Look in rawhide. THere are mysql4 RPMS there.. however you may need to
make a lot of changes to the working system (eg other packages from
rawhide) to get those to work.


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator



From tiemann at redhat.com  Fri Dec 17 01:37:00 2004
From: tiemann at redhat.com (Michael Tiemann)
Date: Thu, 16 Dec 2004 20:37:00 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412162339030.921@horsea.3ti.be>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld> <1103221985.1763.4.camel@cutter>
	<Pine.LNX.4.61.0412162339030.921@horsea.3ti.be>
Message-ID: <1103247420.4791.95.camel@localhost.localdomain>

It's 7 years, not 5.

M

On Thu, 2004-12-16 at 17:45, Dag Wieers wrote:
> On Thu, 16 Dec 2004, seth vidal wrote:
> 
> > On Thu, 2004-12-16 at 19:27 +0100, F?liciano Matias wrote:
> > > Le jeudi 16 d?cembre 2004 ? 00:44 -0500, seth vidal a ?crit :
> > > > Want to be REAL sure you notice this:
> > > > 
> > > > 
> > > > http://www.redhat.com/magazine/002dec04/departments/fedora_status/
> > > > 
> > > > 
> > > > That's Right CVS is open - you need to  run, don't walk, to:
> > > > 
> > > > http://cvs.fedora.redhat.com
> > > > 
> > > 
> > > RHEL extras ?
> > 
> > That's decidedly off-topic for this list.
> > 
> > Ask on taroon list.
> 
> In essence it's not off-topic. FC3 turns into RHEL4, it makes no sense to 
> make the Extras Fedora-specific. Even when RHEL is not a community 
> product.
> 
> Of course, Fedora Extras has a 6 months life-time and memory span, if you 
> think about RHEL packages, you think about at least 5 years and at least 3 
> concurrent versions to support.
> 
> --   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
> [all I want is a warm bed and a kind word and unlimited power]
> 
> ______________________________________________________________________
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list



From rahulsundaram at yahoo.co.in  Fri Dec 17 01:51:58 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 17:51:58 -0800 (PST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103247420.4791.95.camel@localhost.localdomain>
Message-ID: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>


--- Michael Tiemann <tiemann at redhat.com> wrote:

> It's 7 years, not 5.
> 

do you believe this is relevant to the current
discussions are not?


=====
Regards
Rahul Sundaram


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail



From dag at wieers.com  Fri Dec 17 02:32:19 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 03:32:19 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103247420.4791.95.camel@localhost.localdomain>
References: <1103175848.14792.82.camel@cutter>
	<1103221621.8566.2.camel@one.myworld>
	<1103221985.1763.4.camel@cutter>
	<Pine.LNX.4.61.0412162339030.921@horsea.3ti.be>
	<1103247420.4791.95.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61.0412170324150.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Michael Tiemann wrote:

> It's 7 years, not 5.

I know, but if you look at current RHEL 2.1 deployements, only few people 
look at recent software for those. In 4 years (RHEL 6 ?) I don't think 
many people will be looking for RHEL 3 extras software.

So maybe even 5 years is not pragmatic if people have subscriptions and 
compatibility is as good as now. It's more a demand issue to me.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From dag at wieers.com  Fri Dec 17 02:44:12 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 03:44:12 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Rahul Sundaram wrote:

> --- Michael Tiemann <tiemann at redhat.com> wrote:
> 
> > It's 7 years, not 5.
> 
> do you believe this is relevant to the current
> discussions are not?

It is. If you don't think about it now, it may be more trouble later.

I'm willing to commit a big chunk of my packages if SPEC files can be used 
for multiple distributions/releases and there's infrastructure to avoid 
having to fork SPEC files if unnecessary. (I don't care about a specific 
implementation and am open to discuss alternatives)

A big part of the packages don't require a mandatory fork or don't require 
dist-specific macros. And an even bigger part only has a few macros.

Fedora Extras has to decide whether it will allow those extra macros to 
make it easier to manage SPEC files or if they fork for each new Fedora 
release. There are a few drawbacks, but imnsho there are more advantages.
(less maintenance required, more communities/resources involved, RHEL 
users don't have to fork Fedora stuff and vice versa, ...)

Only fork SPEC files when the complexity of maintaining them becomes 
harder than the complexity of keeping things synchronised.

My estimate is that for 70% of the cases 1 SPEC file can rule them all.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From tiemann at redhat.com  Fri Dec 17 02:49:39 2004
From: tiemann at redhat.com (Michael Tiemann)
Date: Thu, 16 Dec 2004 21:49:39 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
Message-ID: <1103251779.4791.135.camel@localhost.localdomain>

On Thu, 2004-12-16 at 21:44, Dag Wieers wrote:

> Only fork SPEC files when the complexity of maintaining them becomes 
> harder than the complexity of keeping things synchronised.
> 
> My estimate is that for 70% of the cases 1 SPEC file can rule them all.

That would be _extremely_ cool.

M



From skvidal at fedoraproject.org  Thu Dec 16 19:00:26 2004
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 16 Dec 2004 14:00:26 -0500
Subject: Fedora Project launches Pre-Extras
Message-ID: <1103223626.1763.18.camel@cutter>

The Fedora Project is officially launching Fedora Pre-Extras, to work
alongside Fedora Core 3 for i386 and x86_64 based platforms.

What is Pre-Extras?
It is our way of showing you that we've been working hard, as many
packages have been built, and are ready for distribution. 

We are working very hard to make the build system work well, and the
infrastructure for this is almost ready, it just has a few kinks that we
are ironing out. As a measure of good faith, CVS for both Core and
Extras has already been opened.

While waiting for Extras to officially launch, use Pre-Extras today!

Where did all these packages come from?
These were packages from the now-merged Fedora.us repository as well as
freshrpms.net repository. So they maintain the same high quality
standards that was imposed previously.

So how do I get it?
Pre-Extras is currently hosted on the FedoraProject.org website, and is
available at:

	http://fedoraproject.org/pre-extras/3/

It is available as a YUM repository, and an entry like the following
would suffice (in /etc/yum.conf):

[pre-extras]
name=Pre Extras
baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
gpgcheck=1

There is a temporary Pre Extras GPG key, which all packages are signed
with. The fingerprint:

pub  1024D/1AC70CE6 2004-12-14 Fedora Pre Extras Release <pre-extras at fedoraproject.org>
     Key fingerprint = 5389 DD00 C5BC 5168 12B4  3272 82ED 9504 1AC7 0CE6
sub  1024g/4E1A9D43 2004-12-14

To import the key:
	
 rpm --import http://fedoraproject.org/pre-extras/RPM-GPG-KEY-Fedora-Pre-Extras

What about bugs?
If you find bugs in the packages, report them at the Fedora Extras
Bugzilla:

	http://bugzilla.redhat.com/beta/

A cautionary note...
To paraphrase a Fedora Project contributor, Jef Spaleta, these packages
could eat babies; that is to say, they are built, signed, and ready for
use, but they have not gone through the rigorous QA testing that would
be expected normally from Extras. So if they break, submit a bug report,
but there are no implied warranties or guarantees that they will work.
Use these packages at your own risk!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/b29dfe34/attachment-0001.sig>
-------------- next part --------------
-- 
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

From wtogami at redhat.com  Fri Dec 17 03:01:28 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 16 Dec 2004 17:01:28 -1000
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
Message-ID: <41C24C08.1050005@redhat.com>

Dag Wieers wrote:
> I'm willing to commit a big chunk of my packages if SPEC files can be used 
> for multiple distributions/releases and there's infrastructure to avoid 
> having to fork SPEC files if unnecessary. (I don't care about a specific 
> implementation and am open to discuss alternatives)
> 
> A big part of the packages don't require a mandatory fork or don't require 
> dist-specific macros. And an even bigger part only has a few macros.
> 
> Fedora Extras has to decide whether it will allow those extra macros to 
> make it easier to manage SPEC files or if they fork for each new Fedora 
> release. There are a few drawbacks, but imnsho there are more advantages.
> (less maintenance required, more communities/resources involved, RHEL 
> users don't have to fork Fedora stuff and vice versa, ...)

We can examine proposals for additional macros for technical merit after 
things settle down.  Right now I am skeptical, but willing to read and 
experiment later.  No promises though.

> 
> Only fork SPEC files when the complexity of maintaining them becomes 
> harder than the complexity of keeping things synchronised.

This is generally how the old fedora.us operated, but things are 
changing now.

With CVS I personally find it easy to maintain forks in a way similar to 
how I manage the gaim package in FC4/FC3/RHEL4/FC2/RHEL3.  Imposing hard 
coded distribution names and numbers in .spec makes things far more ugly 
IMHO.

Warren Togami
wtogami at redhat.com



From rahulsundaram at yahoo.co.in  Fri Dec 17 03:21:48 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Thu, 16 Dec 2004 19:21:48 -0800 (PST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103249000.4791.108.camel@localhost.localdomain>
Message-ID: <20041217032148.75372.qmail@web8504.mail.in.yahoo.com>


--- Michael Tiemann <tiemann at redhat.com> wrote:

> It's relevant in that I'm correcting something that
> was factually
> incorrect.  RHEL has a 7 year support lifecycle, not
> 5.
> 

I guess my question was vague. I was asking about the
possibility of RHEL extras

sorry for the confusion

I am curious but how is the community going to
contribute to RHEL extras.

Is it possible to build a rpm for RHEL in fedora. I
dont believe that a large part of the fedora user base
would have access RHEL itself.

a few people like dag can contribute the majority of
the packages I guess but the community needs to do
some of the QA and Redhat should be willing to make
some changes in the infrastructure if necessary to
facilitate something like this...

=====
Regards
Rahul Sundaram


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail



From dag at wieers.com  Fri Dec 17 03:42:27 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 04:42:27 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <41C24C08.1050005@redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<41C24C08.1050005@redhat.com>
Message-ID: <Pine.LNX.4.61.0412170420140.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Warren Togami wrote:

> Dag Wieers wrote:
> > 
> > Fedora Extras has to decide whether it will allow those extra macros to make
> > it easier to manage SPEC files or if they fork for each new Fedora release.
> > There are a few drawbacks, but imnsho there are more advantages.
> > (less maintenance required, more communities/resources involved, RHEL users
> > don't have to fork Fedora stuff and vice versa, ...)
> 
> We can examine proposals for additional macros for technical merit after
> things settle down.  Right now I am skeptical, but willing to read and
> experiment later.  No promises though.

My rule of thumb would be to not use macros if not necessary, use macros 
when (lack of) complexity allows it, otherwise fork/branch.


> > Only fork SPEC files when the complexity of maintaining them becomes harder
> > than the complexity of keeping things synchronised.
> 
> This is generally how the old fedora.us operated, but things are changing now.
> 
> With CVS I personally find it easy to maintain forks in a way similar to how I
> manage the gaim package in FC4/FC3/RHEL4/FC2/RHEL3.  Imposing hard coded
> distribution names and numbers in .spec makes things far more ugly IMHO.

In fact, the distribution-specific macros end up in a macros file per 
distribution and the SPEC file only has 'feature-macros', like
_with_mysql, _with_db4, _with_apache2, _with_freedesktop

And centrally you manage whether some distribution provides these features 
or not. This makes SPEC files readable and leaves distribution specific 
macros out. And it allows SPEC files to be build with --with mysql.

Where necessary (to work around build-problems) you can still override the 
centrally managed defaults awaiting an upstream fix.

I have a list of other 'technologies' we're actively using/developing with 
RPMforge (meta-tags for buildsystem, svn-id tagging, perl-oneliners and 
inline files instead of patches/sources, and buildtools/ideas of what 
would improve efficieny of packagers, per-package authority, per-package 
communities, per-dist/arch builders, SPEC pre-processing).

I'm not sure if Matthias already discussed some of these items, or if he 
cleaned the SPEC files before comitting :)


PS How do you manage the Gaim SPEC file now ? I don't require changes per 
distribution for Gaim, it builds fine from 1 SPEC file. How do you make 
sure the release is higher for newer distributions if there's a single 
release ? Will Fedora Extras pre-process SPEC files too ?

The current CVS structure honestly scares me, but there must be some 
cleverness that I don't understand to overcome the inherent 
per-distribution maintenance complexity :))

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From jspaleta at gmail.com  Fri Dec 17 03:49:25 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Dec 2004 22:49:25 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
Message-ID: <604aa79104121619495f4b1063@mail.gmail.com>

On Fri, 17 Dec 2004 03:44:12 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> Fedora Extras has to decide whether it will allow those extra macros to
> make it easier to manage SPEC files or if they fork for each new Fedora
> release. There are a few drawbacks, but imnsho there are more advantages.
> (less maintenance required, more communities/resources involved, RHEL
> users don't have to fork Fedora stuff and vice versa, ...)

Is this a hard constraint for you to be a package contributor?  If the
contributor process and build system is ready before a decision is
made on how to incorporate extra macros... are you willing to
contribute "some" packages that don't require extra macros?

I also would like to hear what you think the drawbacks are to allowing
the extra macros to constrast with the list advantages you see.

-jef



From dag at wieers.com  Fri Dec 17 04:34:30 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 05:34:30 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121619495f4b1063@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Jeff Spaleta wrote:

> On Fri, 17 Dec 2004 03:44:12 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> > Fedora Extras has to decide whether it will allow those extra macros to
> > make it easier to manage SPEC files or if they fork for each new Fedora
> > release. There are a few drawbacks, but imnsho there are more advantages.
> > (less maintenance required, more communities/resources involved, RHEL
> > users don't have to fork Fedora stuff and vice versa, ...)
> 
> Is this a hard constraint for you to be a package contributor?  If the
> contributor process and build system is ready before a decision is
> made on how to incorporate extra macros... are you willing to
> contribute "some" packages that don't require extra macros?

I would be less than keen to remove things that I may have to add later. 
But if you volunteer for that, I have no problem with it :) Again, a large 
part does not require extra macros or only have extra macros to provide 
'features' to rebuilders.

---
As I previously discussed with you, the only requirement to make my 
SPEC files work is a --define 'dist fc3' or for development nothing at 
all. (as the default is no definitions for the latest release) A little 
change in RPM or in a macros-file would even require nothing. So the cure 
is easier than the medicin.
---

In fact we've always had a very open policy and I don't mind if my SPEC 
files are used, although I'd prefer not to have to look on the net to find 
improvements to things that originated from mine. That's a waste of both 
(voluntary) resources, hence my interest in Fedora Extras (and a wider 
scope).

CVS (and a commit list) is already a big improvement to track changes and 
we've got a conceptual design that once implemented will help a lot of 
packagers and QA a lot. What's needed more than packagers is automation.


> I also would like to hear what you think the drawbacks are to allowing
> the extra macros to constrast with the list advantages you see.

Drawbacks:

 + They add a bit of complexity to those that are unfamiliar to macros

 + The syntax is less than optimal, I have some proposals for changes to 
   RPM to overcome most of those problems with limited impact (but JBJ 
   always wants consensus and I cannot give him that :))

 + Changes to macros are never backported, this is a major concern if you 
   have to support older distributions, again I have a simple change for 
   this to RPM but cannot give JBJ consensus

Advantages:

 + Less maintenance, less boring manual synchronising changes, packaging 
   is a very 'mechanical' process and if technology can reduce that we 
   should adopt it

 + Forking has a higher cost than macros in most cases, I can show you 
   some examples that you probably would consider ugly but they are very 
   efficient and safe a lot of work. I can build Xine from 1 SPEC file 
   for 11 distributions/archs (going back to RH7.3) even though the codec 
   support is different and we have alle build-requirements included

 + Gives builders/rebuilders the ability to fine-tune builds if they don't 
   like the default

But again, any technology that would allow to have the same 
functionality/advantages is fine by me, anything less will feel like 
typing with 2 fingers less on each hand. Something you'd prefer not to 
have to do for no obvious reason.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From jspaleta at gmail.com  Fri Dec 17 05:02:40 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 00:02:40 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
Message-ID: <604aa79104121621023f851b2c@mail.gmail.com>

On Fri, 17 Dec 2004 05:34:30 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> I would be less than keen to remove things that I may have to add later.
> But if you volunteer for that, I have no problem with it :) Again, a large
> part does not require extra macros or only have extra macros to provide
> 'features' to rebuilders.

Was that an answer to my question?  I was hoping you could give me a
simple yes or no.
Let me be clear. I want you actually using the buildsystem that Red
Hat has created asap so that any suggestions or changes you want to
make to the process comes from a position of experience with the
buildsystem in use by Fedora.

Is it really that difficult to say that you are willing to contribute
a few packages as an initial step towards becoming a contributor? I
know it would be really nice if all your packages that you currently
maintain could just drop into the fedora build system and expect to
work on the first try, I'm sure every contributor out there would like
that to happen with their packages as well.  I just don't see that as
realistic. What i think is realistic is that contributors make an
effort to work with the build system as early as possible with a small
number of packages and work towards importation of larger sets of
packages as the buildsystem evolves.

So let me try this again. Are you willing to contribute any
package(s), to the evolving Fedora contributor process, before the
extra macros issues are resolved?
If no  is your participation as a package contributor dependant on the
macros issue being resolved?

Or to ask a more general question, will you be waiting until you can
import your entire collection in one push?

-jef



From gafton at redhat.com  Fri Dec 17 05:21:06 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 00:21:06 -0500 (EST)
Subject: Updates on the Fedora CVS server
Message-ID: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>


We have opened to the public the anonymous access CVS server for Fedora 
Core and Fedora Extras. The server lives on http://cvs.fedora.redhat.com 
and it has been in use for quite some time now.

The CVS server currently hosts two major projects, with more headed its 
way:

1. Fedora Core read-only anonymous mirror for our internal Fedora 
development tree. Now you can follow through CVS every commit done by the 
Red Hat engineers to the Fedora Core development tree. You can quickly 
reference when, where and why certain changes have been inserted into your 
favorite packages.
 	CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist
 	export CVSROOT

2. Fedora Extras repository. Thanks to a group of very dedicated 
volunteers the repository has been updated to be compatible with the 
Fedora Core 3; we're working on getting an automated build system in place 
that will provide binary rpms for all out of this repository.
 	CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/extras
 	export CVSROOT

Detailed checkout instructions are available on the CVS server's home 
page, at http://cvs.fedora.redhat.com/


For those that do not want to read instructions and want to get to the 
"bleeding edge" as fast as possible, we have daily checkout snapshots 
available at http://cvs.fedora.redhat.com/webfiles/

After unpacking your download, you can issue a "cvs update" to bring the 
tree in sync with the latest changes since the archive was created. If 
this is the first time accessing the Fedora CVS server, you will need to 
do a "cvs login", hit Enter when asked for a password, and then attempt 
the "cvs update".


ViewCVS is also available for both of these repositories if you prefer to 
browse through the packages:
- Fedora Core: http://cvs.fedora.redhat.com/viewcvs/?root=core
- Fedora Extras: http://cvs.fedora.redhat.com/viewcvs/?root=extras


There are also CVS-related mailing lists that you can subscribe to. these 
mailing lists publish the CVS commits as they happen. If you are curious, 
you can sign up for the mailing lists at the following links:
- Fedora Core:
 	http://www.redhat.com/mailman/listinfo/fedora-cvs-commits
- Fedora Extras:
 	http://www.redhat.com/mailman/listinfo/fedora-extras-commits


Have fun,

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From symbiont at berlios.de  Fri Dec 17 05:33:27 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 17 Dec 2004 13:33:27 +0800
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121621023f851b2c@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
Message-ID: <200412171333.40021.symbiont@berlios.de>

Although it was pointed at Dag, I'll throw a couple comments in.

On Friday 17 December 2004 13:02, Jeff Spaleta wrote:
> I want you actually using the buildsystem that Red
> Hat has created asap so that any suggestions or changes you want to
> make to the process comes from a position of experience with the
> buildsystem in use by Fedora.

Can we download this and setup a local build system so we can contribute 
patches and system-level recommendations instead of using ethereal 
generics?  Would Redhat/Fedora be willing to open this up?

Most third party packagers have scripted up some systems to help in the 
build, web page generation, and distribution of packages.  But, each 
are very customized for each repo.  I'm certain these individuals can 
provide direct input on the system from a patch standpoint if a 
specific project were available for local test.

> [...]
> So let me try this again. Are you willing to contribute any
> package(s), to the evolving Fedora contributor process, before the
> extra macros issues are resolved?
> If no ?is your participation as a package contributor dependant on
> the macros issue being resolved?

I'm more than willing to provide packages from 
http://www.python.org/pyvault/.  It's stagnating a bit due to projects 
at work ramping up, but mainly due to my current build infrastructure 
really has hit some roadblocks in manageability.  For example, I have 
the computing resources, the source code control.  But, builds in mach 
roots and other synchronization issues have had serious problems that I 
just don't have the time to deal with right now.  (A Xen/SELinux combo 
managed by an external mach process would be the ultimate.)

That said, my repo is not "compliant" with all the Fedora policies 
because it uses a structure that allows for multiple versions of Python 
on the same system.  It's almost like Fedora Alternatives combined with 
Fedora Extras.  

But, I guess I could take the packages on a request basis and help with 
tweaking the SPEC to be buildable by the ethereal build system.  My 
biggest hang ups will be package naming conventions. I would presume 
that not many care about multi-python on the Extras side of the fence, 
and therefore, a "python23" name would become "python".  I have 
sufficient macros to deal with this, but it'd be nice to pipe this 
stuff through a build system locally before digging in on Redhat hosted 
infrastructure.

take care,
-- 
-jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041217/92d56fb3/attachment.sig>

From dag at wieers.com  Fri Dec 17 05:46:54 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 06:46:54 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121621023f851b2c@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com> 
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412170623550.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Jeff Spaleta wrote:

> On Fri, 17 Dec 2004 05:34:30 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> > I would be less than keen to remove things that I may have to add later.
> > But if you volunteer for that, I have no problem with it :) Again, a large
> > part does not require extra macros or only have extra macros to provide
> > 'features' to rebuilders.
> 
> Was that an answer to my question?  I was hoping you could give me a
> simple yes or no.

It was an answer to your question, a simple yes or no would be ignoring 
some important matters. I'm not requiring an immediate change to anything, 
I just need to know what the direction is and if it fits my longterm 
goals, goals that could easily be part of Fedora Extras.

I could say 'Yes' for those packages that don't have macros and require no 
change. I could say 'No' because for the packages that do use macros as 
I'm not interested to spend the extra time (I do not have). Besides I
can't give you a definitive fiat unless the project is outlined more.

Again, as I said on the Fedora ml, I wouldn't be spending my time here 
(and before with fedora.us) if I wasn't willing to work with Fedora Extras 
and Red Hat or did not see the potential. To be honest, he fact that you 
keep implying I have other intentions gives a sense of hostility.


> Or to ask a more general question, will you be waiting until you can
> import your entire collection in one push?

Of course not. You haven't read my previous mail very well :)

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From gafton at redhat.com  Fri Dec 17 05:46:02 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 00:46:02 -0500 (EST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
Message-ID: <Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Dag Wieers wrote:

> Fedora Extras has to decide whether it will allow those extra macros to
> make it easier to manage SPEC files or if they fork for each new Fedora
> release. There are a few drawbacks, but imnsho there are more advantages.
> (less maintenance required, more communities/resources involved, RHEL
> users don't have to fork Fedora stuff and vice versa, ...)

I can't speak for what is gonna happen to the Fedora Extras in this regard 
(although I can certainly recommend things :-), but having a single spec 
file that is capable of building on every possible combination of 
libraries and releases and compilers and whatnot has always been a great 
source of pride for whoever achieves that feat. I have done my share of 
those and it feels great, like the world is at your fingertips and you can 
rule it all because your single-specfile package builds everywhere, 
anywhere.

... An yet having worked on a good number of Linux releases since way 
back, those packages and spec files always end up being the biggest pain 
in the back. Probably not for as long as the author maintains interest in 
them and continues to maintain them, but when it comes the time to hand 
them over to somebody else, the struggle begins. They usually end up being 
chockfull of hacks for various corner scenarios that a new maintainer has 
never seen/imagined, they perform extra steps just to get the things "in 
sync" across all supported releases, etc. All that is knowledge intimate to 
the author of the super specfile, and it is completely foreign to a new 
maintainer.

This is why we use the structure that we use (fork for every release) for 
the Fedora Core and the Fedora Extras. As you can see from the CVS trees 
that are available, it allows somebody to play the game of a single spec 
file, if he/she so wishes; but it does not force it on everybody. This 
allowed us to clean up a good chunk of the macro infestation from the 
various spec files, improving readability and reducing the number of 
unintentional mistakes.

> Only fork SPEC files when the complexity of maintaining them becomes
> harder than the complexity of keeping things synchronised.

I would say the opposite is true as well: only maintain a complex spec 
file if the work required to maintain 3 simpler ones is overwhelming. That 
is because usually, after a release, 90% of the packages are rarely 
touched again for that release. And having the freedom of changing a spec 
file in the devel tree without worrying whether it will continue to build 
on an older release if you ever have to do a security errata speeds up the 
development - and that is because the older release has its own spec file 
that it is known to work as of the time that older release shipped.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From gafton at redhat.com  Fri Dec 17 05:56:05 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 00:56:05 -0500 (EST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103251779.4791.135.camel@localhost.localdomain>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<1103251779.4791.135.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61.0412170046320.2983@alien.devel.redhat.com>

On Thu, 16 Dec 2004, Michael Tiemann wrote:

>> Only fork SPEC files when the complexity of maintaining them becomes
>> harder than the complexity of keeping things synchronised.
>>
>> My estimate is that for 70% of the cases 1 SPEC file can rule them all.
>
> That would be _extremely_ cool.

There is more to maintaining packages that how cool you can make your 
specfiles... We can play the coolness game, we can even have some sort of 
competition for the coolest, wicked packaging job ever. But that won't do 
a bit to help maintain those packages over the long haul, or by a team of 
people with different coding styles and appetites for coolness.

When you ask the question of "how do you improve maintainability", this 
turns, unfortunately, into a game of lowest common denominator. The 
"_extremely_ cool" hack from somebody looks like a retarded spewage to 
somebody else. That's the advantage of a one man repository - there is one 
person deciding what's cool and what's not. When a team of folks from 
across all continents are involved, avoiding being cute works much better.

That should not stop us from attempting to raise the bar on the skillset 
required to be a package maintainer; it's just that we have to be careful 
where we place the "coolness fastor" on the list of goals.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From gafton at redhat.com  Fri Dec 17 06:04:34 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 01:04:34 -0500 (EST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <200412171333.40021.symbiont@berlios.de>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<200412171333.40021.symbiont@berlios.de>
Message-ID: <Pine.LNX.4.61.0412170102290.2983@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Jeff Pitman wrote:

> On Friday 17 December 2004 13:02, Jeff Spaleta wrote:
>> I want you actually using the buildsystem that Red
>> Hat has created asap so that any suggestions or changes you want to
>> make to the process comes from a position of experience with the
>> buildsystem in use by Fedora.
>
> Can we download this and setup a local build system so we can contribute
> patches and system-level recommendations instead of using ethereal
> generics?  Would Redhat/Fedora be willing to open this up?

I am putting together a set of scripts specifically for building the 
Fedora Extras and I will get those out as soon as possible. Given the fact 
that these are hacked together for this purpose, I believe that it is 
essential to get them out there as fast as possible and get other folks to 
contribute to them.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From jspaleta at gmail.com  Fri Dec 17 06:11:03 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 01:11:03 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <200412171333.40021.symbiont@berlios.de>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<200412171333.40021.symbiont@berlios.de>
Message-ID: <604aa79104121622116ed2167f@mail.gmail.com>

On Fri, 17 Dec 2004 13:33:27 +0800, Jeff Pitman <symbiont at berlios.de> wrote:
> Can we download this and setup a local build system so we can contribute
> patches and system-level recommendations instead of using ethereal
> generics?  Would Redhat/Fedora be willing to open this up?

Not unreasonable questions.  I very much want to be able to create a
local mock up of parts of the build process just so i can brutalize it
with very very bad spec files (the only ones i know how to make) and
watch how things break.  I have every hope that all of the automation
will be peer-reviewable so community experience will be able to
enhance the process once the initial buildsysstem is up. Remember to
ask this question again in late january and you might get an official
sounding answer.


> Most third party packagers have scripted up some systems to help in the
> build, web page generation, and distribution of packages.  But, each
> are very customized for each repo.  I'm certain these individuals can
> provide direct input on the system from a patch standpoint if a
> specific project were available for local test.

> That said, my repo is not "compliant" with all the Fedora policies
> because it uses a structure that allows for multiple versions of Python
> on the same system.  It's almost like Fedora Alternatives combined with
> Fedora Extras.

Without commenting on specific technical details, because I am not
qualified to do so....
I do think you are right in that a lot of niche repos do have very
customized setups that have grown-up as locally built solutions to
provide buildsystem. While I'm sure yours is artistically exotic in
its own right, i doubt its the most byzantine of the species and i
expect a lot of contributors to be faced with interesting special
needs that the Fedora build system needs to try to accomedate to make
it easier for that contributor to use both their local system and the
fedora build system with minimal pain. But i dont expect it to be a
zero-pain process getting there.  And the sooner contributors get
involved..even with a single package...the sooner there will be a body
of people with common experience using the same build system and can
start suggesting ways to make it more compatible with their local
build systems while at the same time they make changes to their local
build systems as well.  I sort of expect this process to require
everybody to try to meet half way. Both local build systems and the
fedora build system will have to evolve with based on experience
trying to interact as more and more contributors try to use the fedora
system.

> My biggest hang ups will be package naming conventions. I would presume
> that not many care about multi-python on the Extras side of the fence,
> and therefore, a "python23" name would become "python".  I have
> sufficient macros to deal with this, but it'd be nice to pipe this
> stuff through a build system locally before digging in on Redhat hosted
> infrastructure.

I'm not really sure if there will be a need for local prep to this
extent... it very much depends on the specifics of the fedora
buildsystem and how it interacts with the cvs server. And as the
annoucements over the last day or so have said... now that the cvs
server is up... the buildsystem specifics are now the target by fedora
leadership effort.

-jef



From gafton at redhat.com  Fri Dec 17 06:18:13 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 01:18:13 -0500 (EST)
Subject: svn or arch
In-Reply-To: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.61.0412170105050.2983@alien.devel.redhat.com>

On Thu, 16 Dec 2004, Rahul Sundaram wrote:

>> Yes - Cristian Gafton did months of extensive
>> testing to see if either
>> could stand up to the load of internal and external
>> checkins on the
>> scale red hat does with distributions.
>>
>> He found that cvs was the only one to stand up to
>> the load.
>
> Ok thanks for the quick reply. are the results
> available anywhere. It would be nice to let the
> svn/arch developers know about this. I am pretty sure
> they would be interested

Please note - this was happening quite a long time ago as far as the 
developers for those projects are concerned.

The first thing we had to do to enable this CVS repository was to redo the 
way we were handling the source packaging internally. That meant earlier 
this year making a decision about which source code management (SCM) 
platform offered the best mix of features, reliability, low cost of 
transition, performance and political acceptance. I looked at a lot of 
those SCMs.

It all boiled down back to CVS because, while having some major 
shortcomings, which I am sure that the proponents of SVN and/or arch will 
quickly point out, it had a unique quality: everybody knows what is wrong 
with it.

Plus, unlike traditional software projects, the needs for a packages/srpms 
repository are very few and somewhat fixed, so I could not grant bonus 
points for a lot of the more esotheric features of the other SCMs.

That, coupled with reliability and readiness issues of other solutions 
kind of locked us into CVS. I am sure that a lot of the issues I ran into 
are now fixed, but as you all know by now, replacing infrastructure bits 
while keeping the development going takes a lot of time.

It could very well be true that now the others are a better deal - but we 
asked that question back in January-March, we came out with this answer 
and we'll ride this one until it hits another critical point. At which 
point we will evaluate again and we will go through another season of 
pain...

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From dag at wieers.com  Fri Dec 17 06:19:55 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 07:19:55 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
Message-ID: <Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Cristian Gafton wrote:

> On Fri, 17 Dec 2004, Dag Wieers wrote:
> 
> > Fedora Extras has to decide whether it will allow those extra macros to
> > make it easier to manage SPEC files or if they fork for each new Fedora
> > release. There are a few drawbacks, but imnsho there are more advantages.
> > (less maintenance required, more communities/resources involved, RHEL
> > users don't have to fork Fedora stuff and vice versa, ...)
> 
> I can't speak for what is gonna happen to the Fedora Extras in this regard
> (although I can certainly recommend things :-), but having a single spec file
> that is capable of building on every possible combination of libraries and
> releases and compilers and whatnot has always been a great source of pride for
> whoever achieves that feat. I have done my share of those and it feels great,
> like the world is at your fingertips and you can rule it all because your
> single-specfile package builds everywhere, anywhere.

We don't do complex macro things and I would prefer simplicity over macros 
anytime. Complexity is not inherent to macros, sure you can abuse it. I 
have seen ugly unmaintanable SPEC files myself that did not include 
macros. Common sense and good policies will be required, especially if you 
allow anyone and her cat to join. :)


> ... An yet having worked on a good number of Linux releases since way back,
> those packages and spec files always end up being the biggest pain in the
> back. Probably not for as long as the author maintains interest in them and
> continues to maintain them, but when it comes the time to hand them over to
> somebody else, the struggle begins. They usually end up being chockfull of
> hacks for various corner scenarios that a new maintainer has never
> seen/imagined, they perform extra steps just to get the things "in sync"
> across all supported releases, etc. All that is knowledge intimate to the
> author of the super specfile, and it is completely foreign to a new
> maintainer.

Then I'm sure you have met the wrong packagers. Reading this makes me 
wonder whether there was any thought about maintainability at all. 
Bad examples don't make good decisions.


> > Only fork SPEC files when the complexity of maintaining them becomes
> > harder than the complexity of keeping things synchronised.
> 
> I would say the opposite is true as well: only maintain a complex spec file if
> the work required to maintain 3 simpler ones is overwhelming. 

Sure, I'm oposed to complexity as much as you. But having to keep 3 SPEC 
files in sync for a simple change can result in problems as well.

A simple example, FC1 does not have alsa, EL3 does not have alsa, fribidi, 
theora, like RH9 and RH8. RH7 misses gnomevfs as well. You'd need 7 
different SPEC files, while only a few BuildRequires differ. The overhead 
is immense. Of course if you look at Fedora's limited view, you only have 
FC3 and FC2 to consider.


> That is because
> usually, after a release, 90% of the packages are rarely touched again for
> that release. And having the freedom of changing a spec file in the devel tree
> without worrying whether it will continue to build on an older release if you
> ever have to do a security errata speeds up the development - and that is
> because the older release has its own spec file that it is known to work as of
> the time that older release shipped.

Either you don't need the older SPEC file, or you still have to keep it 
updated. If you don't need it anymore, branch it, fork it, I don't care. 
If you have to keep both in sync, you'll have to test both anyway.

You're right about devel, but why worry if it still builds on older 
releases if your premise is to not release a newer package for 
older releases anyway ? Either you care about releasing it for older 
distributions or you don't. If you don't, you're just developing and not 
releasing. As soon as you release, you _have_ to test, no matter if you 
have 3 SPEC files or one.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From gafton at redhat.com  Fri Dec 17 06:21:05 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 01:21:05 -0500 (EST)
Subject: svn or arch
In-Reply-To: <cpsopq$scj$1@sea.gmane.org>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<1103221540.1763.1.camel@cutter> <cpsopq$scj$1@sea.gmane.org>
Message-ID: <Pine.LNX.4.61.0412170118330.2983@alien.devel.redhat.com>

On Thu, 16 Dec 2004, Neal D. Becker wrote:

> You might want to look at darcs.  This one looks the most promising, in it's
> design.  Only disadvantage, it's written in Haskell.

Errr... I can not have a coolness contest for a piece of the 
infrastructure as critical as this. Yeah, I am boring that way. But then, 
after the kerberos server that authenticates the engineers, this is the 
most critical piece of infrastructure we have...

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From gafton at redhat.com  Fri Dec 17 06:25:03 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 01:25:03 -0500 (EST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>
Message-ID: <Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Dag Wieers wrote:

> You're right about devel, but why worry if it still builds on older
> releases if your premise is to not release a newer package for
> older releases anyway ? Either you care about releasing it for older
> distributions or you don't. If you don't, you're just developing and not

I care about being able to do a security update for an older release that 
doesn't necessarily force to to upgrade to the "latest and greatest". Call 
that a scar of RHEL maintenance... :-)

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From dag at wieers.com  Fri Dec 17 06:30:56 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 07:30:56 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170046320.2983@alien.devel.redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<1103251779.4791.135.camel@localhost.localdomain>
	<Pine.LNX.4.61.0412170046320.2983@alien.devel.redhat.com>
Message-ID: <Pine.LNX.4.61.0412170720100.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Cristian Gafton wrote:

> On Thu, 16 Dec 2004, Michael Tiemann wrote:
> 
> > > Only fork SPEC files when the complexity of maintaining them becomes
> > > harder than the complexity of keeping things synchronised.
> > > 
> > > My estimate is that for 70% of the cases 1 SPEC file can rule them all.
> > 
> > That would be _extremely_ cool.
> 
> There is more to maintaining packages that how cool you can make your
> specfiles... We can play the coolness game, we can even have some sort of
> competition for the coolest, wicked packaging job ever. But that won't do a
> bit to help maintain those packages over the long haul, or by a team of people
> with different coding styles and appetites for coolness.

http://dag.wieers.com/packages/xine-lib/xine-lib.spec

Now, imagine the distribution-specific stuff is in a macros file per 
distribution and consider the fact that if you don't do something 
likes this, you need either 8 different SPEC files or manage which SPEC 
files did build on what distribution and reduce it to 5.

Again, if Fedora Extras goal is to not care about more than 2 releases the 
discussion is over.


> When you ask the question of "how do you improve maintainability", this turns,
> unfortunately, into a game of lowest common denominator. The "_extremely_
> cool" hack from somebody looks like a retarded spewage to somebody else.
> That's the advantage of a one man repository - there is one person deciding
> what's cool and what's not. When a team of folks from across all continents
> are involved, avoiding being cute works much better.

It's not a hack. If it was part of RPM's standard (the %dist macro and 
infrastructure) you'd be using it. And if you make a clean policy around 
it, it would be simple, maintainable and efficient if used wisely.

Forking for a few BuildRequirements or forking because some distribution 
lacks something is adding double overhead for a file that's 99% the same.

It will cause people not to do updates for less important items just 
because they may have to do the same thing 2 or 3 times.

PS If you don't like macros, I'm sure you can come up with another 
solution that doesn't add more overhead and doesn't require needless 
forking. I'm not in a position to influence RPM development.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From symbiont at berlios.de  Fri Dec 17 06:27:27 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 17 Dec 2004 14:27:27 +0800
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121622116ed2167f@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<200412171333.40021.symbiont@berlios.de>
	<604aa79104121622116ed2167f@mail.gmail.com>
Message-ID: <200412171427.28525.symbiont@berlios.de>

On Friday 17 December 2004 14:11, Jeff Spaleta wrote:
> I have every hope that all of the
> automation will be peer-reviewable so community experience will be
> able to enhance the process once the initial buildsysstem is up.

I might point out that the PLD people have pld-builder with the new one 
based on python which is a rewrite from the previous 
CVS/Makefile/Perl/Autoconf system.  Also, efforts around mach should be 
well noted.  Barring a NIH syndrome, I hope that existing build systems 
do not go overlooked and we have this continuous cycle of reinventing 
the wheel.

take care,
-- 
-jeff



From dag at wieers.com  Fri Dec 17 06:40:19 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 07:40:19 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>
Message-ID: <Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Cristian Gafton wrote:

> On Fri, 17 Dec 2004, Dag Wieers wrote:
> 
> > You're right about devel, but why worry if it still builds on older
> > releases if your premise is to not release a newer package for
> > older releases anyway ? Either you care about releasing it for older
> > distributions or you don't. If you don't, you're just developing and not
> 
> I care about being able to do a security update for an older release that
> doesn't necessarily force to to upgrade to the "latest and greatest". Call
> that a scar of RHEL maintenance... :-)

Of course, but then you don't care about synchronizing things. You're 
ignoring examples as Gaim and most packages in fedora.us that were kept in 
sync for older distributions if they build fine and worked fine.

That's not a policy you want for Fedora Core, but that was the policy for 
fedora.us. If you release clamav, you want it all over the spectrum not 
just for the latest release.

If that's decided to be the future direction of Fedora Extras, than that's 
fine. But please say so now instead of speculating or giving unofficial 
opinions, because frankly, I don't know when it's an official position and 
when not. And a @redhat.com email makes every shared thought close to 
official :)

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From herrold at owlriver.com  Fri Dec 17 06:45:05 2004
From: herrold at owlriver.com (R P Herrold)
Date: Fri, 17 Dec 2004 01:45:05 -0500 (EST)
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121621023f851b2c@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>

On Fri, 17 Dec 2004, Jeff Spaleta wrote:

> Was that an answer to my question?  I was hoping you could 
> give me a simple yes or no.

> Let me be clear. I want you actually using the buildsystem that Red
> Hat has created asap so that any suggestions or changes you want to
> make to the process comes from a position of experience with the
> buildsystem in use by Fedora.

Where may I (or anyone not an insider) pull a copy of 'the 
buildsystem that Red Hat has created' today, so that I can try 
it before committing to it?  I missed the release notice.

Maybe if it released into the development bazaar, rather than 
promised of delivery as a cathedral, it would be fair to hope 
for a Yes or No answer.  Without seeing the tool, your query 
is not answerable in binary terms.

- Russ Herrold



From jspaleta at gmail.com  Fri Dec 17 07:05:20 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 02:05:20 -0500
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
Message-ID: <604aa7910412162305decff0@mail.gmail.com>

On Fri, 17 Dec 2004 01:45:05 -0500 (EST), R P Herrold
<herrold at owlriver.com> wrote:
> Where may I (or anyone not an insider) pull a copy of 'the
> buildsystem that Red Hat has created' today, so that I can try
> it before committing to it?  I missed the release notice.

Thank you for pointing out that I mispoke. I very much meant to
restrict my comment in that post to mean 'contributing' to the cvs
system and not the 'buildsystem' in full that will be put in place
over the next month or so which will feed on material in the cvs
server and spit out packages.  There are a fair number of examples to
look at in the now open cvs system.  Some of them even build on a
fully installed fc3 system.

-jef



From herrold at owlriver.com  Fri Dec 17 07:26:20 2004
From: herrold at owlriver.com (R P Herrold)
Date: Fri, 17 Dec 2004 02:26:20 -0500 (EST)
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa7910412162305decff0@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com> 
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
	<604aa7910412162305decff0@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412170220080.27891@swampfox.owlriver.com>

On Fri, 17 Dec 2004, Jeff Spaleta wrote:

> On Fri, 17 Dec 2004 01:45:05 -0500 (EST), R P Herrold
> <herrold at owlriver.com> wrote:
>> Where may I (or anyone not an insider) pull a copy of 'the
>> buildsystem that Red Hat has created' today, so that I can try
>> it before committing to it?  I missed the release notice.
>
> Thank you for pointing out that I mispoke. I very much meant to
> restrict my comment in that post to mean 'contributing' to the cvs
> system and not the 'buildsystem' in full that will be put in place
> over the next month or so which will feed on material in the cvs
> server and spit out packages.

Bottom line: no buildsystem -- not yet a fair question to 
expect a yes or no on.

In addition to dag's own tools, we have the approaches of PLD, 
Mezzanine, caos-1, the Tao scripts, the Centos scripts, 
http://www.autobuild.org/, http://www.scons.org/, 
http://www.luntsys.com/luntbuild/index.html, anthill.  heck, 
even RH's own Beehive already exist.

Why a closed design cathedral approach?

-- Russ Herrold



From wtogami at redhat.com  Fri Dec 17 07:29:03 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 16 Dec 2004 21:29:03 -1000
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>	<Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>	<Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>
Message-ID: <41C28ABF.6030900@redhat.com>

Dag Wieers wrote:
> 
> Of course, but then you don't care about synchronizing things. You're 
> ignoring examples as Gaim and most packages in fedora.us that were kept in 
> sync for older distributions if they build fine and worked fine.

"if they build fine and worked fine" is the key.  It was not fedora.us 
policy to keep them in sync.  On several occasions we did fork specs in 
order to simplify their maintenance.

> 
> That's not a policy you want for Fedora Core, but that was the policy for 
> fedora.us. If you release clamav, you want it all over the spectrum not 
> just for the latest release.

Only because it worked and was not significantly difficult to make it 
so, which was the case for the majority of fedora.us packages as they 
were mostly self-contained and not reliant on quickly moving target OS 
libraries.

Warren Togami
wtogami at redhat.com



From dag at wieers.com  Fri Dec 17 07:38:55 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 08:38:55 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <41C28ABF.6030900@redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170703230.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>
	<41C28ABF.6030900@redhat.com>
Message-ID: <Pine.LNX.4.61.0412170831460.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Warren Togami wrote:

> Dag Wieers wrote:
> > 
> > Of course, but then you don't care about synchronizing things. You're
> > ignoring examples as Gaim and most packages in fedora.us that were kept in
> > sync for older distributions if they build fine and worked fine.
> 
> "if they build fine and worked fine" is the key.  It was not fedora.us policy
> to keep them in sync.  On several occasions we did fork specs in order to
> simplify their maintenance.

Well, I'm not against forking per se. But forking as a standard because 
you want to avoid macros is the complete other end of what Cristian was 
implying.


> > That's not a policy you want for Fedora Core, but that was the policy for
> > fedora.us. If you release clamav, you want it all over the spectrum not just
> > for the latest release.
> 
> Only because it worked and was not significantly difficult to make it so,
> which was the case for the majority of fedora.us packages as they were mostly
> self-contained and not reliant on quickly moving target OS libraries.

Ok. So you prefer to build from the same SPEC file too because you admit 
forking has an additional maintenance cost. Then why not allow simple 
macros to avoid the same additional maintenance cost ?

I'm not talking about other reasons for forking. I'm specifically talking 
about forking for small changes that would otherwise not require a fork.

Most, if not all, of the examples where we use macros is exactly for this. 
And again, a large part does no require macros at all.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From symbiont at berlios.de  Fri Dec 17 07:45:29 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 17 Dec 2004 15:45:29 +0800
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170123300.2983@alien.devel.redhat.com>
	<Pine.LNX.4.61.0412170731500.921@horsea.3ti.be>
Message-ID: <200412171545.29653.symbiont@berlios.de>

On Friday 17 December 2004 14:40, Dag Wieers wrote:
> If that's decided to be the future direction of Fedora Extras, than
> that's fine. But please say so now instead of speculating or giving
> unofficial opinions, because frankly, I don't know when it's an
> official position and when not. And a @redhat.com email makes every
> shared thought close to official :)

So, is Extras' scope only Latest and Latest-1 release? Where does Fedora 
Legacy come into play?  Scope needs to be hashed out before a good 
conclusion to needed macros happens.

-- 
-jeff



From jspaleta at gmail.com  Fri Dec 17 07:58:20 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 02:58:20 -0500
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170220080.27891@swampfox.owlriver.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
	<604aa7910412162305decff0@mail.gmail.com>
	<Pine.LNX.4.61.0412170220080.27891@swampfox.owlriver.com>
Message-ID: <604aa79104121623586965471f@mail.gmail.com>

On Fri, 17 Dec 2004 02:26:20 -0500 (EST), R P Herrold
<herrold at owlriver.com> wrote:
> Bottom line: no buildsystem -- not yet a fair question to
> expect a yes or no on.

I think its perfectly fair to ask a vocal dissenting voice to commit
to attempting to use whatever the first presented process is for at
least one package... to work within the process instead of continuing
to stand outside of the process and comment.  I want every packager
who has been vocal about the flaws in the fedora.us process to stand
up and pledge they will atleast attempt to work inside the new process
contributing atleast ONE package as soon as its possible, instead of
waiting for the system to be perfect.


> Why a closed design cathedral approach?

This is a red herring... how quickly to do an initial release has
nothing to do with a cathedral approach. I think both Tiemmann and
Gafton have tried to comment about where the delay has been in terms
of internal Red Hat changes that have absolutely nothing to do with
the contributor facing bits. I have no doubt that the build scripts
will be made available and feedback will be incorporated. And Gafton
has made this intention clear in a post to this very list. He's
hacking something together to make publicly available for review
sooner rather than later now that the cvs server is up and running.  I
thought he was pretty clear about that.

-jef



From giallu at gmail.com  Fri Dec 17 07:59:17 2004
From: giallu at gmail.com (Gianluca Sforna)
Date: Fri, 17 Dec 2004 08:59:17 +0100
Subject: svn or arch
In-Reply-To: <Pine.LNX.4.61.0412170105050.2983@alien.devel.redhat.com>
References: <20041216182122.45559.qmail@web8501.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170105050.2983@alien.devel.redhat.com>
Message-ID: <d5ad214704121623596a31afb3@mail.gmail.com>

On Fri, 17 Dec 2004 01:18:13 -0500 (EST), Cristian Gafton
<gafton at redhat.com> wrote:
> The first thing we had to do to enable this CVS repository was to redo the
> way we were handling the source packaging internally. That meant earlier
> this year making a decision about which source code management (SCM)
> platform offered the best mix of features, reliability, low cost of
> transition, performance and political acceptance. I looked at a lot of
> those SCMs.
>

Yust out of curiosity (I mantain myself a CVS server for internal
projects): what are you using for generating the commit messages for
the mailing list?
I already tried some but they were either a PITA to install or did not
made useful reports of what is going on CVS.



From alan at balclutha.org  Fri Dec 17 08:22:33 2004
From: alan at balclutha.org (Alan Milligan)
Date: Fri, 17 Dec 2004 19:22:33 +1100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <20041217062511.A37BC74038@hormel.redhat.com>
References: <20041217062511.A37BC74038@hormel.redhat.com>
Message-ID: <41C29749.1010307@balclutha.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to nobody in particular, I'd just like to reiterate a couple of
points I've made regarding this over the last couple of months:

1.  Whilst RH has the responsibility of maintaining 5-7 years of code
base, no onus should be placed upon Fedora Core or Extra's maintainers
in this regard.  Surely you accepted this baggage when spinning off
Fedora!!!

2.  RH needs to take some clear leadership in regard to making it easy
for packagers to provide consistent, homogenious packages.  The clearest
place to start is by publishing (relatively) definitive macro files.
I've spent the last two months agitating for the resolution of bug
120635, Python macros - when will it finally occur to someone as to the
merits of this case ????


Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBwpdJCfroLk4EZpkRAnr8AJ9u8LDpSqxCIId2JUvGCmkMVl25rgCfVTcm
Pg7BBgDKq0EFtUCNkgIQGfQ=
=Whkl
-----END PGP SIGNATURE-----



From enrico.scholz at informatik.tu-chemnitz.de  Fri Dec 17 08:56:01 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Fri, 17 Dec 2004 09:56:01 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	(Cristian
	Gafton's message of "Fri, 17 Dec 2004 00:46:02 -0500 (EST)")
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
Message-ID: <87d5x92ti6.fsf@kosh.ultra.csn.tu-chemnitz.de>

gafton at redhat.com (Cristian Gafton) writes:

>> Only fork SPEC files when the complexity of maintaining them becomes
>> harder than the complexity of keeping things synchronised.
>
> I would say the opposite is true as well: only maintain a complex spec
> file if the work required to maintain 3 simpler ones is overwhelming.

The question is, if the complexity added by multi-arch support
overwhelms the base-complexity of the package. Unless there is only
one binary, you will (or better: should) probably end with multiple
subpackages. So, most packages have already a big base-complexity
and an additional '%{_with_fc2:BuildRequires: ...}' will not hurt.




Enrico



From rc040203 at freenet.de  Fri Dec 17 09:04:37 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 17 Dec 2004 10:04:37 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103251779.4791.135.camel@localhost.localdomain>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<1103251779.4791.135.camel@localhost.localdomain>
Message-ID: <1103274277.4931.178.camel@mccallum.corsepiu.local>

On Thu, 2004-12-16 at 21:49 -0500, Michael Tiemann wrote:
> On Thu, 2004-12-16 at 21:44, Dag Wieers wrote:
> 
> > Only fork SPEC files when the complexity of maintaining them becomes 
> > harder than the complexity of keeping things synchronised.
> > 
> > My estimate is that for 70% of the cases 1 SPEC file can rule them all.
> 
> That would be _extremely_ cool.
The emphasize is misplaced _would_ would have been correct. 

Being involved into packaging cross-distribution rpms for many years,
experience tells me, you can achieve a 90-percent solution this way
easily, however the rest is almost impossible to resolve.

Ralf
 



From huw-l at moving-picture.com  Fri Dec 17 09:22:39 2004
From: huw-l at moving-picture.com (Huw Lynes)
Date: Fri, 17 Dec 2004 09:22:39 +0000
Subject: Differences between the kernel source in FC2 and the kernel
 source obtained from kernel.org?
In-Reply-To: <80d7e4090412161722331a62ed@mail.gmail.com>
References: <20041215064647.14650.qmail@web51506.mail.yahoo.com>
	<80d7e4090412161722331a62ed@mail.gmail.com>
Message-ID: <20041217092239.20e657c2.huw-l@moving-picture.com>

On Thu, 16 Dec 2004 18:22:19 -0700
"Stephen J. Smoogen" <smooge at gmail.com> wrote:

> On Tue, 14 Dec 2004 22:46:47 -0800 (PST), Park Lee
> <parklee_sel at yahoo.com> wrote:
> > Hi,
> >   Is there any difference between the kernel source in
> > FC2(version 2.6.5-1.358) and the kernel source
> > (version 2.6.5)obtained from kernel.org?
> >   Can I also download a 2.6.5 (or higher)version
> > kernel source from kernel.org to replace the FC2's
> > origianl kernel source and compile the new downloaded
> > kernel source to yield a vmlinuz and run it as FC2's
> > kernel without any conflict?
> >   Thank you.
> 
The quickest route is to unpack the source for the version you want. Then copy
the config file for your running version (should be /boot/config-`uname -r`)
into the unpacked source tree as .config. Run make xconfig, save the config.
Then make,make modules, make modules_install as usual.


-- 
| Huw Lynes               | The Moving Picture Company  |
| System Administrator    | 127 Wardour Street          |
|.........................| London, W1F 0NL             | 




From Bernd.Bartmann at sohanet.de  Fri Dec 17 09:42:53 2004
From: Bernd.Bartmann at sohanet.de (Bernd Bartmann)
Date: Fri, 17 Dec 2004 10:42:53 +0100
Subject: Updates on the Fedora CVS server
In-Reply-To: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>
References: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>
Message-ID: <41C2AA1D.1050806@sohanet.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cristian Gafton wrote:
| There are also CVS-related mailing lists that you can subscribe to.
| these mailing lists publish the CVS commits as they happen. If you are
| curious, you can sign up for the mailing lists at the following links:
| - Fedora Core:
|     http://www.redhat.com/mailman/listinfo/fedora-cvs-commits
| - Fedora Extras:
|     http://www.redhat.com/mailman/listinfo/fedora-extras-commits

Hmm, I could subscribe to fedora-extras-commits, but fedora-cvs-commits
seems to have a config problem:

The original message was received at Fri, 17 Dec 2004 04:22:43 -0500
from rproxy.gmail.com [64.233.170.193]

~  ----- The following addresses had permanent fatal errors -----
<fedora-cvs-commits-request at redhat.com>
~   (reason: 550 5.1.1 <fedora-cvs-commits-request at redhat.com>... User
unknown)
~   (expanded from: <fedora-cvs-commits-request at redhat.com>)

~  ----- Transcript of session follows -----
... while talking to int-mx1.corp.redhat.com.:
|>> RCPT To:<fedora-cvs-commits-request at redhat.com>
<<< 550 5.1.1 <fedora-cvs-commits-request at redhat.com>... User unknown
550 5.1.1 <fedora-cvs-commits-request at redhat.com>... User unknown

Best regards.

- --
Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann at sohanet.de>
I.S. Security and Network Engineer
SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
Fon: +49 30 214783-44 / Fax: +49 30 214783-46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBwqodkQuIaHu84cIRAgJdAJ9WayLkRLT3VIVpewY6OHOwF4FR7QCfcSKA
7HmxYFnwBJ7J2sSTC+pUDmc=
=jdfK
-----END PGP SIGNATURE-----



From tmraz at redhat.com  Fri Dec 17 10:39:29 2004
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 17 Dec 2004 11:39:29 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
Message-ID: <1103279969.3791.26.camel@perun.redhat.usu>

On Fri, 2004-12-17 at 00:46 -0500, Cristian Gafton wrote:
> On Fri, 17 Dec 2004, Dag Wieers wrote:
> > Only fork SPEC files when the complexity of maintaining them becomes
> > harder than the complexity of keeping things synchronised.
> 
> I would say the opposite is true as well: only maintain a complex spec 
> file if the work required to maintain 3 simpler ones is overwhelming. That 
> is because usually, after a release, 90% of the packages are rarely 
> touched again for that release. And having the freedom of changing a spec 
> file in the devel tree without worrying whether it will continue to build 
> on an older release if you ever have to do a security errata speeds up the 
> development - and that is because the older release has its own spec file 
> that it is known to work as of the time that older release shipped.

I think that the problem is clear. Red Hat/Fedora Core have different
goals than independent repositories. The goal of Fedora Core is to have
a stable set of packages for a release which then don't evolve much - we
only fix bugs with security impact or other serious bugs. There aren't
many packages which will get new versions from upstream during the
updates cycle. So there is clearly no need to maintain complex spec
files because the old spec files are good enough and they aren't changed
much except adding patches. And it's clearly better to have forked spec
files to avoid regressions.

That's much different from independent repositories such as Dag's
because they have the goal to deliver packages of new versions of
various software to as many distributions as possible. For this it's
much better to have one spec file with macros.

So the question is, will Fedora Extras be more like independent
repository or more like the Fedora Core. Or it could depend on package.

-- 
Tomas Mraz <tmraz at redhat.com>



From dag at wieers.com  Fri Dec 17 11:04:44 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 12:04:44 +0100 (CET)
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121623586965471f@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
	<604aa7910412162305decff0@mail.gmail.com>
	<Pine.LNX.4.61.0412170220080.27891@swampfox.owlriver.com>
	<604aa79104121623586965471f@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412171156460.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Jeff Spaleta wrote:

> On Fri, 17 Dec 2004 02:26:20 -0500 (EST), R P Herrold
> <herrold at owlriver.com> wrote:
> > Bottom line: no buildsystem -- not yet a fair question to
> > expect a yes or no on.
> 
> I want every packager who has been vocal about the flaws in the 
> fedora.us process to stand up and pledge they will atleast attempt to 
> work inside the new process contributing atleast ONE package as soon as 
> its possible, instead of waiting for the system to be perfect.

Tell me how I can proceed to add my Yam package to Fedora Extras. If 
that's how I can show you my good faith, let's get it over with.

I will hereby solemly swear to maintain the Yam package in Fedora 
Extras until the end of my days.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From dag at wieers.com  Fri Dec 17 11:18:57 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 12:18:57 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121619495f4b1063@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0412171206290.921@horsea.3ti.be>

On Thu, 16 Dec 2004, Jeff Spaleta wrote:

> I also would like to hear what you think the drawbacks are to allowing
> the extra macros to constrast with the list advantages you see.

BTW Matthias sneaked in some macros from RPMforge exactly the way I would
like to too ! :) I thought I should mention it.

Maybe I shouldn't talk about it, but just do it and see what people think. 
Afterall it's not rocket science, it doesn't add complexity and it makes 
a lot of sense to do. But I have the clear feeling that talking about it 
abstractly does not get the right message through as people expect the 
worse to come out of it.

I feel I'm being punished for other people's ghosts :)

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From pmatilai at welho.com  Fri Dec 17 11:40:44 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 17 Dec 2004 13:40:44 +0200 (EET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412171206290.921@horsea.3ti.be>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412171206290.921@horsea.3ti.be>
Message-ID: <Pine.LNX.4.60.0412171336270.26232@chip.laiskiainen.org>

On Fri, 17 Dec 2004, Dag Wieers wrote:

> On Thu, 16 Dec 2004, Jeff Spaleta wrote:
>
>> I also would like to hear what you think the drawbacks are to allowing
>> the extra macros to constrast with the list advantages you see.
>
> BTW Matthias sneaked in some macros from RPMforge exactly the way I would
> like to too ! :) I thought I should mention it.
>
> Maybe I shouldn't talk about it, but just do it and see what people think.
> Afterall it's not rocket science, it doesn't add complexity and it makes
> a lot of sense to do. But I have the clear feeling that talking about it
> abstractly does not get the right message through as people expect the
> worse to come out of it.

Shock horror, many many RH's own packages have various switches, toggles 
and macros to deal with building on several distro versions. I don't think 
anybody is talking about *banning* using macros for that when it doesn't 
unnecessarily complicate the spec. The way I see it building for several 
distributions is simply not a *priority* because of the shortish lifespan,
and also it remains to be seen whether extras is going to be a "rolling 
release" or more like Core where not each and every package is updated 
once a new version comes out.

 	- Panu -



From dag at wieers.com  Fri Dec 17 12:46:35 2004
From: dag at wieers.com (Dag Wieers)
Date: Fri, 17 Dec 2004 13:46:35 +0100 (CET)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.60.0412171336270.26232@chip.laiskiainen.org>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412171206290.921@horsea.3ti.be>
	<Pine.LNX.4.60.0412171336270.26232@chip.laiskiainen.org>
Message-ID: <Pine.LNX.4.61.0412171341430.921@horsea.3ti.be>

On Fri, 17 Dec 2004, Panu Matilainen wrote:

> On Fri, 17 Dec 2004, Dag Wieers wrote:
> 
> > On Thu, 16 Dec 2004, Jeff Spaleta wrote:
> > 
> > > I also would like to hear what you think the drawbacks are to allowing
> > > the extra macros to constrast with the list advantages you see.
> > 
> > BTW Matthias sneaked in some macros from RPMforge exactly the way I would
> > like to too ! :) I thought I should mention it.
> > 
> > Maybe I shouldn't talk about it, but just do it and see what people think.
> > Afterall it's not rocket science, it doesn't add complexity and it makes
> > a lot of sense to do. But I have the clear feeling that talking about it
> > abstractly does not get the right message through as people expect the
> > worse to come out of it.
> 
> Shock horror, many many RH's own packages have various switches, toggles and
> macros to deal with building on several distro versions. I don't think anybody
> is talking about *banning* using macros for that when it doesn't unnecessarily
> complicate the spec.

Perfect.


> The way I see it building for several distributions is
> simply not a *priority* because of the shortish lifespan,

I never asked for Fedora Extras to build for several distributions, only 
to keep macros in that can allow others to do that. And this is not about 
distribution specific macros, but feature-specific macros (that are 
provided per distribution). Much like Matthias his proftpd package and the 
rpmforge xine-lib package.


> and also it remains to be seen whether extras is going to be a "rolling
> release" or more like Core where not each and every package is updated once a
> new version comes out.

That's indeed the most important factor in the whole equation.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



From buildsys at redhat.com  Fri Dec 17 13:09:25 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 17 Dec 2004 08:09:25 -0500
Subject: rawhide report: 20041217 changes
Message-ID: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>

 

 
Updated Packages:

cups-1:1.1.22-5
---------------
* Thu Dec 16 2004 Tim Waugh <twaugh at redhat.com> 1.1.22-5
- Fixed STR #1023 (part of bug #143086).
- Fixed STR #1024 (rest of bug #143086).

* Thu Dec 09 2004 Tim Waugh <twaugh at redhat.com>
- Not all files in the doc directory are pure documentation (bug #67337).

* Thu Dec 09 2004 Tim Waugh <twaugh at redhat.com>
- Fixed ioctl parameter size in usb backend.  Spotted by David A. Marlin.

desktop-printing-0.18-1
-----------------------
* Thu Dec 16 2004 Colin Walters <walters at redhat.com> 0.18-1
- New upstream version
  - Drop upstreamed patch int-gsize
  - Drop upstreamed patch no-help
  - Drop upstreamed patch use-usb-if-null
  - Drop upstreamed patch use-printer-uri

dump-0.4b37-2
-------------
* Thu Dec 09 2004 Dan Walsh <dwalsh at redhat.com> 0.4b37-2
- Added experimental dump patch from upstream to allow dump/restore of xattr.

exim-4.43-3
-----------
* Thu Dec 16 2004 David Woodhouse <dwmw2 at redhat.com> 4.43-3
- Demonstrate SASL auth configuration in default config file
- Enable TLS and provide certificate if necessary
- Don't reject all GB2312 charset mail by default

firefox-0:1.0-6
---------------
* Wed Dec 15 2004 Christopher Aillon <caillon at redhat.com> 0:1.0-6
- Don't have downloads "disappear" when downloading to desktop (#139015)
- Add RPM version to the useragent
- BuildRequires pango-devel

inn-2.4.1-1
-----------
* Wed Dec 15 2004 Martin Stransky <stransky at redhat.com> 2.4.1-1
- diff patch (fix obsolete version of diff parameter) #137342
- posix/warnings patch #110825

* Mon Dec 13 2004 Martin Stransky <stransky at redhat.com> 2.4.1-1
- update to INN 2.4.1
- Thanks to Jochen Schmitt <Jochen at herr-schmitt.de>

kernel-2.6.9-1.1037_FC4
-----------------------
* Thu Dec 16 2004 Dave Jones <davej at redhat.com>
- Better version of the PCI Posting fixes for AGPGART.
- Add missing cache flush to the AGP code.
- Drop netdump and common crashdump code.

* Mon Dec 13 2004 Dave Jones <davej at redhat.com>
- Drop diskdump. Aiming for a better kexec based solution for FC4.

kudzu-1.1.103-1
---------------
* Thu Dec 16 2004 Bill Nottingham <notting at redhat.com> - 1.1.103-1
- tweak network device detection algorithm (#141338)

* Tue Nov 30 2004 Bill Nottingham <notting at redhat.com> - 1.1.101-1
- clear out driver on new usb interfaces (#141358)

* Wed Nov 24 2004 Bill Nottingham <notting at redhat.com> - 1.1.100-1
- clear out device on new usb interfaces (#130805)

libgsf-1.11.1-1
---------------
* Thu Dec 16 2004 Caolan McNamara <caolanm at redhat.com> 1.11.1-1
- upgrade to 1.11.1

libungif-4.1.3-2
----------------
* Thu Dec 16 2004 Matthias Clasen  <mclasen at redhat.com> 4.1.3-2
- Remove Obsoletes: giflib  (#140952)

libwmf-0.2.8.3-7
----------------
* Thu Dec 16 2004 Caolan McNamara <caolanm at redhat.com> 0.2.8.3-7
- RH#143096# No need for extra X libs to be linked against

mozilla-37:1.7.3-20
-------------------
* Wed Dec 15 2004 Christopher Aillon <caillon at redhat.com> 37:1.7.3-20
- Enable smooth scrolling and system colors by default.
- Add RPM version to useragent
- Some specfile cleanup

postgresql-7.4.6-3
------------------
* Thu Dec 16 2004 Tom Lane <tgl at redhat.com> 7.4.6-3
- Update to PyGreSQL 3.6 (to fix bug #142711)
- Adjust a few file permissions (bug #142431)
- Assign %{_libdir}/pgsql to base package instead of -server (bug #74003)

rpmdb-fedora-1:4-0.20041217
---------------------------

selinux-policy-strict-1.19.14-2
-------------------------------
* Thu Dec 16 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-2
- Changes to increase the number of daemons in targeted policy

* Thu Dec 16 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-1
- Update latest from NSA

selinux-policy-targeted-1.19.14-1
---------------------------------
* Thu Dec 16 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-1
- Update latest from NSA

thunderbird-0:1.0-2
-------------------
* Thu Dec 16 2004 Christopher Aillon <caillon at redhat.com> 1.0-2
- Add RPM version to useragent

* Thu Dec 16 2004 Christopher Blizzard <blizzard at redhat.com>
- Port over pango patches from firefox

udev-048-2
----------
* Thu Dec 16 2004 Harald Hoyer <harald at redhat.com> - 048-2
- fixed a case where reading /proc/ide/hd?/media returns EIO
  (bug rh#142713)
- changed all device node permissions of group "disk" to 0640 
  (bug rh#110197)
- remove $udev_db with -fr in case of a directory (bug rh#142962)

xcdroast-0.98a15-8
------------------
* Thu Dec 16 2004 Harald Hoyer <harald at redhat.com> - 0.98a15-8
- fixed frozen progress bars with patch from Didier Heyden (bug #134334)

* Mon Sep 20 2004 Harald Hoyer <harald at redhat.com> - 0.98a15-7
- only add /dev/cdrom*
- enable prodvd mode for our cdrecord



From ssc at coolspot.de  Fri Dec 17 13:44:02 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Fri, 17 Dec 2004 14:44:02 +0100
Subject: FreeTDS
Message-ID: <41C2E2A2.1020501@coolspot.de>

Is there a reason for not having freetds in fedora ?
I would maintain the packet, if that's the problem.
Cheers,
Stefan



From cturner at redhat.com  Fri Dec 17 13:57:39 2004
From: cturner at redhat.com (Chip Turner)
Date: Fri, 17 Dec 2004 08:57:39 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
Message-ID: <vzkwtvhrprg.fsf@gotham64.devel.redhat.com>

Cristian Gafton <gafton at redhat.com> writes:

> ... An yet having worked on a good number of Linux releases since way
> back, those packages and spec files always end up being the biggest
> pain in the back. Probably not for as long as the author maintains
> interest in them and continues to maintain them, but when it comes the
> time to hand them over to somebody else, the struggle begins. They
> usually end up being chockfull of hacks for various corner scenarios
> that a new maintainer has never seen/imagined, they perform extra
> steps just to get the things "in sync" across all supported releases,
> etc. All that is knowledge intimate to the author of the super
> specfile, and it is completely foreign to a new maintainer.

Seems like we're arguing about how many angels can dance on the head
of a pin.  Sweeping generalizations, attempts to get people to commit
to vague concepts before there are specifics, etc.

How about we argue about particular specfiles and macros.  Instead of
letting either past troubles or past successes decide, let's see a
proposal (maybe, I dunno, a specfile and macros) and talk about the
specifics of what does or doesn't make it maintainable.  From there we
can either find ways to address those specific concerns, or decide
there is no way to do so.  But we shouldn't give up or try to make
technical decisions based on instinct and our own personal experiences
alone without at least seeing a couple of specifics from the proposal
itself.

Dag, do you have any spec files right now you consider archetypical of
the kind of packages you would be interested in dealing with in Extras?

Chip

-- 
Chip Turner                   cturner at redhat.com
                              Red Hat, Inc.



From carwyn at carwyn.com  Fri Dec 17 14:45:18 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Fri, 17 Dec 2004 14:45:18 +0000
Subject: FreeTDS
In-Reply-To: <41C2E2A2.1020501@coolspot.de>
References: <41C2E2A2.1020501@coolspot.de>
Message-ID: <4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>


On 17 Dec 2004, at 13:44, Stefan Sonnenberg-Carstens wrote:

> Is there a reason for not having freetds in fedora ?
> I would maintain the packet, if that's the problem.

This is a good candidate for adding into Fedora Extras.

Carwyn



From symbiont at berlios.de  Fri Dec 17 14:59:26 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 17 Dec 2004 22:59:26 +0800
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.60.0412171336270.26232@chip.laiskiainen.org>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412171206290.921@horsea.3ti.be>
	<Pine.LNX.4.60.0412171336270.26232@chip.laiskiainen.org>
Message-ID: <200412172259.26397.symbiont@berlios.de>

On Friday 17 December 2004 19:40, Panu Matilainen wrote:
> Shock horror, many many RH's own packages have various switches,
> toggles and macros to deal with building on several distro versions.

sendmail is a fun one.

-- 
-jeff



From symbiont at berlios.de  Fri Dec 17 15:06:31 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 17 Dec 2004 23:06:31 +0800
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <41C29749.1010307@balclutha.org>
References: <20041217062511.A37BC74038@hormel.redhat.com>
	<41C29749.1010307@balclutha.org>
Message-ID: <200412172306.31515.symbiont@berlios.de>

On Friday 17 December 2004 16:22, Alan Milligan wrote:
> I've spent the last two months agitating for the resolution of bug
> 120635, Python macros - when will it finally occur to someone as to
> the merits of this case ????

This is happening upstream in RPM itself.  There's other baggage to help 
with Python and RPM.  It'll trickle into FC4, I presume.  Eg, Requires: 
python(abi) = 2.4 could be possible.

For an immediate solution, provide a forward pkg that provides 
a /etc/rpm/macros.python.  Poke rpm-devel for further details.

take care,
-- 
-jeff



From hp at redhat.com  Fri Dec 17 16:28:22 2004
From: hp at redhat.com (Havoc Pennington)
Date: Fri, 17 Dec 2004 11:28:22 -0500
Subject: branches (Re: Fedora Extras, Fedora Core CVS Open!)
In-Reply-To: <Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
Message-ID: <1103300902.3857.16.camel@localhost.localdomain>

Hi,

There is one very important reason for branches, and that is freezes. In
the GNOME project we had exactly this same debate back in the day; lots
of people did not want to branch, they wanted to keep the same version
and rebuild it for multiple GNOME releases.

The problem is that then people cheat on the freeze rules. The stable
branch of GNOME was bugfixes only. So if you didn't branch, there was no
way to do any development - you had to follow the most restrictive
freeze for any release you might build into. Of course the people most
annoyed by having to branch were also the people making the most changes
and doing the most development. ;-)

Fedora is a bit different, because we do allow package updates with new
versions and new features, something GNOME does not allow. So it is more
acceptable not to branch. Even for Fedora though there are a lot of
changes that would be inappropriate in an already-released version of
the OS.

But consider that we're using the same build and CVS setup for RHEL,
where branching is pretty much absolutely mandatory and we don't want to
risk any changes to the stable branch unless they are *explicitly*
backported.

The original explanation of the GNOME rules is here:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html

Perhaps it's interesting how things work today in GNOME: we allow
maintainers to branch when they want, which is essentially "the first
time they do a non-bugfix (want to break the freeze)" - but the branch
name is standardized, and they have to mail the translators and docs
teams that the branch has happened, and they can't put in freeze-
violating changes until they branch. 

So I'm not advocating here that we need Fedora to work one way or
another, I'm just pointing out that there's a problem with having all
your development work automatically/implicitly affect already-released
versions of the OS.

Remember that the primary task of a distribution is integration, and
that means the packages have to be tested as a set; you invalidate that
integration work if you aren't thinking about what changes are
reasonable in each version specifically.

Again, Fedora does have a goal of keeping stuff as updated as possible,
but I still think we want to think about whether a change is right for
already-released versions rather than automatically having much of
rawhide propagating back.

It's also possible that Core and Extras are different in how they handle
this stuff.

Dunno, .02

Havoc




From notting at redhat.com  Fri Dec 17 16:57:49 2004
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 17 Dec 2004 11:57:49 -0500
Subject: Updates on the Fedora CVS server
In-Reply-To: <41C2AA1D.1050806@sohanet.de>
References: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>
	<41C2AA1D.1050806@sohanet.de>
Message-ID: <20041217165749.GC17411@nostromo.devel.redhat.com>

Bernd Bartmann (Bernd.Bartmann at sohanet.de) said: 
> Hmm, I could subscribe to fedora-extras-commits, but fedora-cvs-commits
> seems to have a config problem:

Please try again.

Bill



From 421246 at posta.unizar.es  Fri Dec 17 17:30:33 2004
From: 421246 at posta.unizar.es (soraberri)
Date: Fri, 17 Dec 2004 18:30:33 +0100
Subject: undefined reference..
Message-ID: <cpv552$lpf$1@sea.gmane.org>

hi,
compiling some application I get the error: "undefined reference to 
'baswap' " and I know well that baswap is a function defined in one .h 
wich is properly included, and it's in /usr/include/bluetooth
  what does it usually mean?

thankyou



From Bernd.Bartmann at sohanet.de  Fri Dec 17 16:59:45 2004
From: Bernd.Bartmann at sohanet.de (Bernd Bartmann)
Date: Fri, 17 Dec 2004 17:59:45 +0100
Subject: Updates on the Fedora CVS server
In-Reply-To: <20041217165749.GC17411@nostromo.devel.redhat.com>
References: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>	<41C2AA1D.1050806@sohanet.de>
	<20041217165749.GC17411@nostromo.devel.redhat.com>
Message-ID: <41C31081.2040309@sohanet.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Nottingham wrote:
| Bernd Bartmann (Bernd.Bartmann at sohanet.de) said:
|
|>Hmm, I could subscribe to fedora-extras-commits, but fedora-cvs-commits
|>seems to have a config problem:
|
|
| Please try again.

Thanks, it's working now.

Best regards.

- --
Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann at sohanet.de>
I.S. Security and Network Engineer
SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
Fon: +49 30 214783-44 / Fax: +49 30 214783-46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBwxCAkQuIaHu84cIRAjv/AJ4+cfMoL4HwUDWZ3EE8YTtVgCvklgCgjYok
k45CxpMK75qRo32CbTxs/l8=
=Ao+a
-----END PGP SIGNATURE-----



From skvidal at fedoraproject.org  Thu Dec 16 19:00:26 2004
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 16 Dec 2004 14:00:26 -0500
Subject: Fedora Project launches Pre-Extras
Message-ID: <1103223626.1763.18.camel@cutter>

The Fedora Project is officially launching Fedora Pre-Extras, to work
alongside Fedora Core 3 for i386 and x86_64 based platforms.

What is Pre-Extras?
It is our way of showing you that we've been working hard, as many
packages have been built, and are ready for distribution. 

We are working very hard to make the build system work well, and the
infrastructure for this is almost ready, it just has a few kinks that we
are ironing out. As a measure of good faith, CVS for both Core and
Extras has already been opened.

While waiting for Extras to officially launch, use Pre-Extras today!

Where did all these packages come from?
These were packages from the now-merged Fedora.us repository as well as
freshrpms.net repository. So they maintain the same high quality
standards that was imposed previously.

So how do I get it?
Pre-Extras is currently hosted on the FedoraProject.org website, and is
available at:

	http://fedoraproject.org/pre-extras/3/

It is available as a YUM repository, and an entry like the following
would suffice (in /etc/yum.conf):

[pre-extras]
name=Pre Extras
baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
gpgcheck=1

There is a temporary Pre Extras GPG key, which all packages are signed
with. The fingerprint:

pub  1024D/1AC70CE6 2004-12-14 Fedora Pre Extras Release <pre-extras at fedoraproject.org>
     Key fingerprint = 5389 DD00 C5BC 5168 12B4  3272 82ED 9504 1AC7 0CE6
sub  1024g/4E1A9D43 2004-12-14

To import the key:
	
 rpm --import http://fedoraproject.org/pre-extras/RPM-GPG-KEY-Fedora-Pre-Extras

What about bugs?
If you find bugs in the packages, report them at the Fedora Extras
Bugzilla:

	http://bugzilla.redhat.com/beta/

A cautionary note...
To paraphrase a Fedora Project contributor, Jef Spaleta, these packages
could eat babies; that is to say, they are built, signed, and ready for
use, but they have not gone through the rigorous QA testing that would
be expected normally from Extras. So if they break, submit a bug report,
but there are no implied warranties or guarantees that they will work.
Use these packages at your own risk!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041216/b29dfe34/attachment-0002.sig>
-------------- next part --------------
-- 
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-------------- next part --------------
--
fedora-announce-list mailing list
fedora-announce-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-announce-list

From rahulsundaram at yahoo.co.in  Fri Dec 17 18:05:34 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 10:05:34 -0800 (PST)
Subject: undefined reference..
In-Reply-To: <cpv552$lpf$1@sea.gmane.org>
Message-ID: <20041217180534.91695.qmail@web8507.mail.in.yahoo.com>


--- soraberri <421246 at posta.unizar.es> wrote:

> hi,
> compiling some application I get the error:
> "undefined reference to 
> 'baswap' " and I know well that baswap is a function
> defined in one .h 
> wich is properly included, and it's in
> /usr/include/bluetooth
>   what does it usually mean?

ask in the users list. this is considered off topic in
this development list

Note: you need to be more specific about the program
are you compiling

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250



From gafton at redhat.com  Fri Dec 17 05:21:06 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 00:21:06 -0500 (EST)
Subject: Updates on the Fedora CVS server
Message-ID: <Pine.LNX.4.61.0412161706040.2983@alien.devel.redhat.com>


We have opened to the public the anonymous access CVS server for Fedora 
Core and Fedora Extras. The server lives on http://cvs.fedora.redhat.com 
and it has been in use for quite some time now.

The CVS server currently hosts two major projects, with more headed its 
way:

1. Fedora Core read-only anonymous mirror for our internal Fedora 
development tree. Now you can follow through CVS every commit done by the 
Red Hat engineers to the Fedora Core development tree. You can quickly 
reference when, where and why certain changes have been inserted into your 
favorite packages.
 	CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist
 	export CVSROOT

2. Fedora Extras repository. Thanks to a group of very dedicated 
volunteers the repository has been updated to be compatible with the 
Fedora Core 3; we're working on getting an automated build system in place 
that will provide binary rpms for all out of this repository.
 	CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/extras
 	export CVSROOT

Detailed checkout instructions are available on the CVS server's home 
page, at http://cvs.fedora.redhat.com/


For those that do not want to read instructions and want to get to the 
"bleeding edge" as fast as possible, we have daily checkout snapshots 
available at http://cvs.fedora.redhat.com/webfiles/

After unpacking your download, you can issue a "cvs update" to bring the 
tree in sync with the latest changes since the archive was created. If 
this is the first time accessing the Fedora CVS server, you will need to 
do a "cvs login", hit Enter when asked for a password, and then attempt 
the "cvs update".


ViewCVS is also available for both of these repositories if you prefer to 
browse through the packages:
- Fedora Core: http://cvs.fedora.redhat.com/viewcvs/?root=core
- Fedora Extras: http://cvs.fedora.redhat.com/viewcvs/?root=extras


There are also CVS-related mailing lists that you can subscribe to. these 
mailing lists publish the CVS commits as they happen. If you are curious, 
you can sign up for the mailing lists at the following links:
- Fedora Core:
 	http://www.redhat.com/mailman/listinfo/fedora-cvs-commits
- Fedora Extras:
 	http://www.redhat.com/mailman/listinfo/fedora-extras-commits


Have fun,

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution

--
fedora-announce-list mailing list
fedora-announce-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-announce-list



From 421246 at posta.unizar.es  Fri Dec 17 18:08:40 2004
From: 421246 at posta.unizar.es (soraberri)
Date: Fri, 17 Dec 2004 19:08:40 +0100
Subject: includes and binary code
Message-ID: <cpv7ch$td7$1@sea.gmane.org>

I think my problem is a concept failure:
When I include in my programs a #include <afile.h> I am telling the 
compiler to look for afile.h and paste the code in my program. So far so 
good. But the header file usually only holds definitions and not the 
implementation of the functions, so what I don't understand is how can 
the system (compiler) know where and how to find the library or the 
piece of binary code that actually implements the functions defined in 
the afile.h

hope this is a very simple question for you

regards



From michael.favia at insitesinc.com  Fri Dec 17 18:11:04 2004
From: michael.favia at insitesinc.com (Michael Favia)
Date: Fri, 17 Dec 2004 12:11:04 -0600
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <1103279969.3791.26.camel@perun.redhat.usu>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	<1103279969.3791.26.camel@perun.redhat.usu>
Message-ID: <41C32138.3080602@insitesinc.com>


> I think that the problem is clear. Red Hat/Fedora Core have different
> goals than independent repositories. The goal of Fedora Core is to have
> a stable set of packages for a release which then don't evolve much - we
> only fix bugs with security impact or other serious bugs. 
<snip>
> That's much different from independent repositories such as Dag's
> because they have the goal to deliver packages of new versions of
> various software to as many distributions as possible. For this it's
> much better to have one spec file with macros.
> 
> So the question is, will Fedora Extras be more like independent
> repository or more like the Fedora Core. Or it could depend on package.

This is the first response to address the real issue in my opinion. If 
fedora extras is meant to be on par with fedora and maintain a forward 
looking policy (eg new releases for current FC and security fixes only 
for past FC) then the choice seems fairly easy.

The real question is: "Is the independent packaging community willing to 
follow this mantra of 'moving forward' and thus abandoning backwards 
compatibility without maintaining separate spec files"?

If not is the cost of regressions/complexity in the spec files (that 
they want to use) greater than the benefit of having those individuals 
on board?

Perhaps the real issue we need to be asking is while it is very nice (i 
repeat: very nice and greatly appreciated) to be able to install new 
versions of various software on my FC1 boxes, how inline with the goal 
of the fedora project is that? I would argue that it doesnt really have 
a place, at least not in fedora extras. But, we need the independent 
package managers onboard and to do so we either need to convince them of 
the benefits of a forward looking approach to this distro or we need to 
allow at least some the complexities they bring with the skills they 
honed in more stable and longer life cycle distros.

I personally believe that the fedora extras should compliment Fedora 
Core by adopting the same style of release pattern on a wider array of 
packages that, for various reasons arent included in Core. The other 
goals such as backwards compatibility seem to have a place in a Fedora 
Legacy project.

<Important Part>
Maybe maintaining 2 spec file sets is the best solution:

1 for Fedora core that is simple an focuses only on the current release
1 for Fedora Legacy that includes macros and attempts to bring extended 
support to the fedora core distribution

That way the barrier to entry for innovation remains low and individuals 
dedicated to maintaining historical perspective can do so efficiently. I 
confess ignorance on the details of such an implementation but it seems 
a likely solution for everyone involved from my point of view.
</Important Part>

happy holidays,
mf

-- 
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated       http://michael.insitesinc.com



From 421246 at posta.unizar.es  Fri Dec 17 18:14:29 2004
From: 421246 at posta.unizar.es (soraberri)
Date: Fri, 17 Dec 2004 19:14:29 +0100
Subject: undefined reference..
In-Reply-To: <20041217180534.91695.qmail@web8507.mail.in.yahoo.com>
References: <cpv552$lpf$1@sea.gmane.org>
	<20041217180534.91695.qmail@web8507.mail.in.yahoo.com>
Message-ID: <cpv7nd$u7u$1@sea.gmane.org>

Rahul Sundaram wrote:
> --- soraberri <421246 at posta.unizar.es> wrote:
> 
> 
>>hi,
>>compiling some application I get the error:
>>"undefined reference to 
>>'baswap' " and I know well that baswap is a function
>>defined in one .h 
>>wich is properly included, and it's in
>>/usr/include/bluetooth
>>  what does it usually mean?
> 
> 
> ask in the users list. this is considered off topic in
> this development list
> 
> Note: you need to be more specific about the program
> are you compiling
> 
> =====
> Regards
> Rahul Sundaram
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250
> 
sorry and thanks Rahul.
So you can ignore the next post also.



From elanthis at awesomeplay.com  Fri Dec 17 18:15:24 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Fri, 17 Dec 2004 13:15:24 -0500
Subject: includes and binary code
In-Reply-To: <cpv7ch$td7$1@sea.gmane.org>
References: <cpv7ch$td7$1@sea.gmane.org>
Message-ID: <1103307324.11251.8.camel@support02.civic.twp.ypsilanti.mi.us>

On Fri, 2004-12-17 at 19:08 +0100, soraberri wrote:
> I think my problem is a concept failure:
> When I include in my programs a #include <afile.h> I am telling the 
> compiler to look for afile.h and paste the code in my program. So far so 
> good. But the header file usually only holds definitions and not the 
> implementation of the functions, so what I don't understand is how can 
> the system (compiler) know where and how to find the library or the 
> piece of binary code that actually implements the functions defined in 
> the afile.h
> 
> hope this is a very simple question for you

You tell the compiler to include the library using -l.  For example,
   gcc -o test test.c -lsomelibrary
Please read the GCC documentation instead of asking the list. (Which
isn't even the right list to ask user questions - this list is for
developing the Fedora distribution.)

> 
> regards
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.



From jspaleta at gmail.com  Fri Dec 17 18:30:40 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 13:30:40 -0500
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <41C32138.3080602@insitesinc.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>
	<1103279969.3791.26.camel@perun.redhat.usu>
	<41C32138.3080602@insitesinc.com>
Message-ID: <604aa791041217103015a0e05@mail.gmail.com>

On Fri, 17 Dec 2004 12:11:04 -0600, Michael Favia
<michael.favia at insitesinc.com> wrote:
> I personally believe that the fedora extras should compliment Fedora
> Core by adopting the same style of release pattern on a wider array of
> packages that, for various reasons arent included in Core. The other
> goals such as backwards compatibility seem to have a place in a Fedora
> Legacy project.


There are definitely pros and cons to the approach, but long term I
like the idea of "Fedora Collections" Tiemann has expressed publicly
in one of these list a good while back.  If we want to think of Core
has just one possible collection tightly controlled by Red Hat, and
want to encourage community to create new collections based on a
superset of the packages in Core and Extras, i think Extras will have
to establish a development model very closely aligned to Core, so that
Collection builders can pull from both Core and Extras without wierd
development model sync issues.  I think Extras needs to be focused on
a 'development' tree aproach as much as possible so that integration
issues get hammered out as early as possible.

-jef



From rahulsundaram at yahoo.co.in  Fri Dec 17 18:31:05 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 10:31:05 -0800 (PST)
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
Message-ID: <20041217183105.18471.qmail@web8504.mail.in.yahoo.com>

Hi

>  + Changes to macros are never backported, this is a
> major concern if you 
>    have to support older distributions, again I have
> a simple change for 
>    this to RPM but cannot give JBJ consensus


It would be better to explicitly state those ideas to
this list so that knowledgable people can discuss them
and try to reach consensus if this hasnt been done
already and I am not sure whether this consensus is
expected to happen between distros using rpm or
something else?

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From ssc at coolspot.de  Fri Dec 17 18:45:26 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Fri, 17 Dec 2004 19:45:26 +0100
Subject: FreeTDS
In-Reply-To: <4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
References: <41C2E2A2.1020501@coolspot.de>
	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
Message-ID: <41C32946.9090605@coolspot.de>

Carwyn Edwards wrote:

>
> On 17 Dec 2004, at 13:44, Stefan Sonnenberg-Carstens wrote:
>
>> Is there a reason for not having freetds in fedora ?
>> I would maintain the packet, if that's the problem.
>
>
> This is a good candidate for adding into Fedora Extras.
>
> Carwyn
>
Ok, what do I need to do ?



From michael.favia at insitesinc.com  Fri Dec 17 18:50:50 2004
From: michael.favia at insitesinc.com (Michael Favia)
Date: Fri, 17 Dec 2004 12:50:50 -0600
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa791041217103015a0e05@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>	<Pine.LNX.4.61.0412170028200.2983@alien.devel.redhat.com>	<1103279969.3791.26.camel@perun.redhat.usu>	<41C32138.3080602@insitesinc.com>
	<604aa791041217103015a0e05@mail.gmail.com>
Message-ID: <41C32A8A.3010403@insitesinc.com>

Jeff Spaleta wrote:
> On Fri, 17 Dec 2004 12:11:04 -0600, Michael Favia
> <michael.favia at insitesinc.com> wrote:
> 
>>I personally believe that the fedora extras should compliment Fedora
>>Core by adopting the same style of release pattern on a wider array of
>>packages that, for various reasons arent included in Core. The other
>>goals such as backwards compatibility seem to have a place in a Fedora
>>Legacy project.
> 
> I think Extras needs to be focused on
> a 'development' tree aproach as much as possible so that integration
> issues get hammered out as early as possible.
> 

Which is what i thought i was advocating above but maybe im not as clear 
as i thought i was. If I were to visualize fedora core, fedora extras, 
and fedora legacy i would have a small layered cake (fedora core) 
surrounded by a larger one (fedora extras) with each with solid layers 
of past cakes below it (fedora legacy).

Cross-Section of my circular cakes from side profile:

    +--------+-----------------+--------+
    |        |                 |        |
    | Fedora |   Fedora Core   | Extras |
    +--------+-----------------+--------+
    |                                   |
    |           Fedora Legacy           |
    |                                   |
   -+-----------------------------------+-

mmm.. cake...

-mf

-- 
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated       http://michael.insitesinc.com



From ndbecker2 at verizon.net  Fri Dec 17 19:09:53 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 17 Dec 2004 14:09:53 -0500
Subject: yum - tidy untidy
Message-ID: <cpvau1$3ul$1@sea.gmane.org>

yum bug?

sudo yum install tidy
Setting up Install Process
Setting up Repo:  dag
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  kde-redhat-stable-all
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  kde-redhat-stable
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  jpackage16-fc3
repomd.xml                100% |=========================|  903 B    00:00
Setting up Repo:  jpackage16-generic
repomd.xml                100% |=========================|  903 B    00:00
Setting up Repo:  base
repomd.xml                100% |=========================| 1.1 kB    00:00
Setting up Repo:  updates-released
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  haskell
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  freshrpms
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  pre-extras
repomd.xml                100% |=========================|  951 B    00:00
Reading repository metadata in from local files
dag       : ################################################## 1389/1389
kde-redhat: ################################################## 324/324
kde-redhat: ################################################## 229/229
jpackage16: ################################################## 19/19
jpackage16: ################################################## 1277/1277
base      : ################################################## 2622/2622
primary.xml.gz            100% |=========================| 150 kB    00:01
MD Read   : ################################################## 348/348
updates-re: ################################################## 348/348
haskell   : ################################################## 35/35
freshrpms : ################################################## 452/452
pre-extras: ################################################## 617/617
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package tidy.i386 0:0.99.0-2.20040916 set to be installed
--> Running transaction check
--> Processing Dependency: libtidy-0.99.so.0 for package: tidy
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package tidy.i386 0:0.99.0-0.fdr.4.20041005.3 set to be installed
--> Running transaction check

Dependencies Resolved
Transaction Listing:
  Install: tidy.i386 0:0.99.0-2.20040916

Performing the following to resolve dependencies:
  Install: tidy.i386 0:0.99.0-0.fdr.4.20041005.3
Is this ok [y/N]: y
Downloading Packages:
tidy-0.99.0-2.20040916.i3 100% |=========================|  89 kB    00:00
Running Transaction Test
Finished Transaction Test
Transaction Check Error:   file /usr/bin/tab2space conflicts between
attempted installs of tidy-0.99.0-0.fdr.4.20041005.3 and
tidy-0.99.0-2.20040916
  file /usr/bin/tidy conflicts between attempted installs of
tidy-0.99.0-0.fdr.4.20041005.3 and tidy-0.99.0-2.20040916




From skvidal at phy.duke.edu  Fri Dec 17 19:12:46 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 17 Dec 2004 14:12:46 -0500
Subject: yum - tidy untidy
In-Reply-To: <cpvau1$3ul$1@sea.gmane.org>
References: <cpvau1$3ul$1@sea.gmane.org>
Message-ID: <1103310766.9364.47.camel@opus.phy.duke.edu>

On Fri, 2004-12-17 at 14:09 -0500, Neal D. Becker wrote:
> yum bug?
> 
> sudo yum install tidy
> Setting up Install Process
> Setting up Repo:  dag
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  kde-redhat-stable-all
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  kde-redhat-stable
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  jpackage16-fc3
> repomd.xml                100% |=========================|  903 B    00:00
> Setting up Repo:  jpackage16-generic
> repomd.xml                100% |=========================|  903 B    00:00
> Setting up Repo:  base
> repomd.xml                100% |=========================| 1.1 kB    00:00
> Setting up Repo:  updates-released
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  haskell
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  freshrpms
> repomd.xml                100% |=========================|  951 B    00:00
> Setting up Repo:  pre-extras
> repomd.xml                100% |=========================|  951 B    00:00
> Reading repository metadata in from local files
> dag       : ################################################## 1389/1389
> kde-redhat: ################################################## 324/324
> kde-redhat: ################################################## 229/229
> jpackage16: ################################################## 19/19
> jpackage16: ################################################## 1277/1277
> base      : ################################################## 2622/2622
> primary.xml.gz            100% |=========================| 150 kB    00:01
> MD Read   : ################################################## 348/348
> updates-re: ################################################## 348/348
> haskell   : ################################################## 35/35
> freshrpms : ################################################## 452/452
> pre-extras: ################################################## 617/617
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Package tidy.i386 0:0.99.0-2.20040916 set to be installed
> --> Running transaction check
> --> Processing Dependency: libtidy-0.99.so.0 for package: tidy
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package tidy.i386 0:0.99.0-0.fdr.4.20041005.3 set to be installed
> --> Running transaction check
> 


> Dependencies Resolved
> Transaction Listing:
>   Install: tidy.i386 0:0.99.0-2.20040916
> 
> Performing the following to resolve dependencies:
>   Install: tidy.i386 0:0.99.0-0.fdr.4.20041005.3

ugh.

okay - this is bizarre. Try this:

yum -d5 install tidy - I'm curious what the other possible resolvers
are.

-sv




From gentoo.warrior at gmail.com  Fri Dec 17 19:17:24 2004
From: gentoo.warrior at gmail.com (Eivind)
Date: Fri, 17 Dec 2004 11:17:24 -0800
Subject: OpenOffice Memory Bloat?
Message-ID: <dbc15d4904121711173e908c16@mail.gmail.com>

I am just curious why OpenOffice on FC3 consumes roughly 150MB of
memory contra a 100MB of memory using Gentoo.

I did a little experiment myself, where I checked the System Monitor
and listsed the memory maps for that process, (Identically, you can do
it by 'cat /proc/<pid_of_OO>/maps' and sort the output by size).

I found that the library libsvx645li.so which is a 12MB library is
loaded 6 times into memory on FC3 in contrast to Gentoo wich only
loads this library once. On gentoo I am using the vanilla OO from
www.openoffice.org, and I've tested this with both the standard FC3
rpm and the vanilla OO with no significant difference (~2-4MB).

Both distributions is using gnome 2.6 and the Metacity window manager.
I am just curious on what may cause this huge memory bloat (why is
this library loaded 6 times and not 1).

Any comments? 

- Eivind



From ndbecker2 at verizon.net  Fri Dec 17 19:23:21 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 17 Dec 2004 14:23:21 -0500
Subject: yum - tidy untidy
References: <cpvau1$3ul$1@sea.gmane.org>
	<1103310766.9364.47.camel@opus.phy.duke.edu>
Message-ID: <cpvbn9$9qh$1@sea.gmane.org>

Is this enough?

> okay - this is bizarre. Try this:
> 
> yum -d5 install tidy - I'm curious what the other possible resolvers
> are.
> 
> -sv
> 
> 
sudo yum -d5 install tidy
Yum Version: 2.1.11
COMMAND: yum -d5 install tidy
Installroot: /
Ext Commands:
   tidy
Setting up Install Process
Setting up Repo:  dag
Baseurl(s) for repo: ['http://apt.sw.be/fedora/3/en/i386/dag']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  kde-redhat-stable-all
Baseurl(s) for repo: ['http://apt.kde-redhat.org/apt/kde-redhat/all/stable',
'ftp://apt.kde-redhat.org/apt/kde-redhat/all/stable']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  kde-redhat-stable
Baseurl(s) for repo:
['http://apt.kde-redhat.org/apt/kde-redhat/fedora/3/i386/stable',
'ftp://apt.kde-redhat.org/apt/kde-redhat/fedora/3/i386/stable']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  jpackage16-fc3
Baseurl(s) for repo:
['ftp://jpackage.hmdc.harvard.edu/JPackage/1.6/fedora-3/free/']
repomd.xml                100% |=========================|  903 B    00:00
Setting up Repo:  jpackage16-generic
Baseurl(s) for repo:
['ftp://jpackage.hmdc.harvard.edu/JPackage/1.6/generic/free/']
repomd.xml                100% |=========================|  903 B    00:00
Setting up Repo:  base
Baseurl(s) for repo:
['http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/',
'http://mirrors.kernel.org/fedora/core/3/i386/os/',
'http://fedora.cat.pdx.edu/linux/core/3/i386/os/',
'http://fedora.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/3/i386/os',
'http://fedora-mirror.dkuug.dk/linux/core/3/i386/os/',
'http://fr2.rpmfind.net/linux/fedora/core/3/i386/os',
'http://fr.rpmfind.net/linux/fedora/core/3/i386/os',
'http://ftp.ale.org/pub/fedora/linux/core/3/i386/os',
'http://ftp.chg.ru/pub/Linux/fedora/linux/core/3/i386/os/',
'http://ftp.esat.net/pub/linux/fedora/3/i386/os/',
'http://ftp.heanet.ie/pub/fedora/linux/core/3/i386/os/',
'http://ftp.hostrino.com/pub/fedora/linux/core/3/i386/os/',
'http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/3/i386/os',
'http://ftp.kddilabs.jp/Linux/packages/fedora/core/3/i386/os',
'http://ftp.lug.ro/fedora/linux/core/3/i386/os/',
'http://ftp.ndlug.nd.edu/pub/fedora/linux/core/3/i386/os/',
'http://ftp.rhnet.is/pub/fedora/3/i386/os/',
'http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/3/i386/os/',
'http://ftp.uni-bayreuth.de/linux/fedora/linux/core/3/i386/os',
'http://ftp.uni-koeln.de/fedora/3/i386/os/',
'http://ftp.ussg.iu.edu/linux/fedora/linux/core/3/i386/os/',
'http://gd.tuwien.ac.at/opsys/linux/fedora/core/3/i386/os/',
'http://klid.dk/homeftp/fedora/linux/core/3/i386/os',
'http://limestone.uoregon.edu/ftp/fedora/3/i386/os/',
'http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/3/i386/os/',
'http://mirror.etf.bg.ac.yu/fedora/linux/core/3/i386/os',
'http://mirror.hiwaay.net/redhat/fedora/linux/core/3/i386/os/',
'http://mirror.netglobalis.net/pub/fedora/core/3/i386/os/',
'http://mirror.stanford.edu/fedora/linux/core/3/i386/os/',
'http://mirror.switch.ch/ftp/mirror/fedora/linux/core/3/i386/os',
'http://mirror.web-ster.com/fedora/3/i386/os/',
'http://redhat.secsup.org/fedora/core/3/i386/os',
'http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/core/3/i386/os/',
'http://sunsite.informatik.rwth-aachen.de/ftp/pub/linux/fedora-core/3/i386/os/',
'http://sunsite.mff.cuni.cz/pub/fedora/3/i386/os/',
'http://wftp.tu-chemnitz.de/pub/linux/fedora-core/3/i386/os/',
'http://www.las.ic.unicamp.br/pub/fedora/linux/core/3/i386/os/',
'http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os']
repomd.xml                100% |=========================| 1.1 kB    00:00
Setting up Repo:  updates-released
Baseurl(s) for repo:
['http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/',
'http://mirrors.kernel.org/fedora/core/updates/3/i386/',
'http://fedora.cat.pdx.edu/linux/core/updates/3/i386/',
'http://fedora.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/updates/3/i386/',
'http://fedora-mirror.dkuug.dk/linux/core/updates/3/i386/',
'http://fr2.rpmfind.net/linux/fedora/core/updates/3/i386',
'http://fr.rpmfind.net/linux/fedora/core/updates/3/i386',
'http://ftp.ale.org/pub/fedora/linux/core/updates/3/i386/',
'http://ftp.chg.ru/pub/Linux/fedora/linux/core/updates/3/i386/',
'http://ftp.esat.net/pub/linux/fedora/updates/3/i386/',
'http://ftp.heanet.ie/pub/fedora/linux/core/updates/3/i386/',
'http://ftp.hostrino.com/pub/fedora/linux/core/updates/3/i386/',
'http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/updates/3/i386/',
'http://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/3/i386/',
'http://ftp.lug.ro/fedora/linux/core/updates/3/i386/',
'http://ftp.ndlug.nd.edu/pub/fedora/linux/core/updates/3/i386/',
'http://ftp.rhnet.is/pub/fedora/updates/3/i386/',
'http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/updates/3/i386/',
'http://ftp.uni-bayreuth.de/linux/fedora/linux/core/updates/3/i386',
'http://ftp.uni-koeln.de/fedora/updates/3/i386/',
'http://ftp.ussg.iu.edu/linux/fedora/linux/core/updates/3/i386/',
'http://gd.tuwien.ac.at/opsys/linux/fedora/core/updates/3/i386/',
'http://klid.dk/homeftp/fedora/linux/core/updates/3/i386',
'http://limestone.uoregon.edu/ftp/fedora/updates/3/i386/',
'http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/updates/3/i386/',
'http://mirror.etf.bg.ac.yu/fedora/linux/core/updates/3/i386',
'http://mirror.hiwaay.net/redhat/fedora/linux/core/updates/3/i386/',
'http://mirror.netglobalis.net/pub/fedora/updates/3/i386',
'http://mirror.stanford.edu/fedora/linux/core/updates/3/i386/',
'http://mirror.switch.ch/ftp/mirror/fedora/linux/core/updates/3/i386',
'http://mirror.web-ster.com/fedora/updates/3/i386/',
'http://redhat.secsup.org/fedora/core/updates/3/i386/',
'http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/core/updates/3/i386/',
'http://sunsite.informatik.rwth-aachen.de/ftp/pub/linux/fedora-core/updates/3/i386/',
'http://sunsite.mff.cuni.cz/pub/fedora/updates/3/i386/',
'http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/',
'http://www.las.ic.unicamp.br/pub/fedora/linux/core/updates/3/i386',
'http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  haskell
Baseurl(s) for repo:
['http://www.haskell.org/fedora/haskell/3/i386/RPMS.stable']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  freshrpms
Baseurl(s) for repo:
['http://ayo.ie.freshrpms.net/fedora/linux/3/i386/freshrpms/',
'http://ayo.uk3.freshrpms.net/fedora/linux/3/i386/freshrpms/',
'http://ayo.us5.freshrpms.net/fedora/linux/3/i386/freshrpms/',
'http://ayo.pt.freshrpms.net/fedora/linux/3/i386/freshrpms/',
'http://ayo.si.freshrpms.net/fedora/linux/3/i386/freshrpms/']
repomd.xml                100% |=========================|  951 B    00:00
Setting up Repo:  pre-extras
Baseurl(s) for repo: ['http://fedoraproject.org/pre-extras/3/i386/']
repomd.xml                100% |=========================|  951 B    00:00
Reading repository metadata in from local files
Setting up Package Sacks
dag       : ################################################## 1389/1389
kde-redhat: ################################################## 324/324
kde-redhat: ################################################## 229/229
jpackage16: ################################################## 19/19
jpackage16: ################################################## 1277/1277
base      : ################################################## 2622/2622
primary.xml.gz            100% |=========================| 152 kB    00:01
MD Read   : ################################################## 355/355
updates-re: ################################################## 355/355
haskell   : ################################################## 35/35
freshrpms : ################################################## 452/452
pre-extras: ################################################## 617/617
Reading Local RPMDB
reduced installs :
   tidy.i386 0:0.99.0-2.20040916
Resolving Dependencies
1103311287.1
--> Populating transaction set with selected packages. Please wait.
Adding Package tidy - 0.99.0-2.20040916.i386 in mode i
---> Package tidy.i386 0:0.99.0-2.20040916 set to be installed
--> Running transaction check
# of Deps = 1
tidy requires: libtidy-0.99.so.0
--> Processing Dependency: libtidy-0.99.so.0 for package: tidy
Requiring package is from transaction set
Resolving for requiring package: tidy-0.99.0-2.20040916 in state i
Resolving for requirement: libtidy-0.99.so.0
Searching pkgSack for dep: libtidy-0.99.so.0
Potential match for libtidy-0.99.so.0 from tidy -
0.99.0-0.fdr.4.20041005.3.i386
Matched tidy - 0.99.0-0.fdr.4.20041005.3.i386 to require for
libtidy-0.99.so.0
Potential match for libtidy-0.99.so.0 from libtidy - 0.99.0-2.20040916.i386
Matched libtidy - 0.99.0-2.20040916.i386 to require for libtidy-0.99.so.0
TSINFO: Marking tidy - 0.99.0-0.fdr.4.20041005.3.i386 as install for tidy
miss = 0
conf = 0
CheckDeps = 1
--> Restarting Dependency Resolution with new changes.
---> Loop Number: 2
Restarting Loop
--> Populating transaction set with selected packages. Please wait.
Adding Package tidy - 0.99.0-0.fdr.4.20041005.3.i386 in mode i
---> Package tidy.i386 0:0.99.0-0.fdr.4.20041005.3 set to be installed
--> Running transaction check

Dependencies Resolved
1103311287.22
Transaction Listing:
  Install: tidy.i386 0:0.99.0-2.20040916

Performing the following to resolve dependencies:
  Install: tidy.i386 0:0.99.0-0.fdr.4.20041005.3
Is this ok [y/N]:        



From skvidal at phy.duke.edu  Fri Dec 17 19:25:10 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 17 Dec 2004 14:25:10 -0500
Subject: yum - tidy untidy
In-Reply-To: <cpvbn9$9qh$1@sea.gmane.org>
References: <cpvau1$3ul$1@sea.gmane.org>
	<1103310766.9364.47.camel@opus.phy.duke.edu>
	<cpvbn9$9qh$1@sea.gmane.org>
Message-ID: <1103311510.9364.51.camel@opus.phy.duke.edu>

On Fri, 2004-12-17 at 14:23 -0500, Neal D. Becker wrote:
> Is this enough?
> 
> > okay - this is bizarre. Try this:
> > 
> > yum -d5 install tidy - I'm curious what the other possible resolvers
> > are.
> > 
> > -sv
> > 
> > 
> sudo yum -d5 install tidy
> Yum Version: 2.1.11
> COMMAND: yum -d5 install tidy
> Installroot: /
> Ext Commands:
>    tidy

Could you install yum 2.1.12 from testing-updates and tell me if it
resolves this problem or at least changes it some? :)
-sv




From rahulsundaram at yahoo.co.in  Fri Dec 17 19:25:17 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 11:25:17 -0800 (PST)
Subject: OpenOffice Memory Bloat?
In-Reply-To: <dbc15d4904121711173e908c16@mail.gmail.com>
Message-ID: <20041217192517.98137.qmail@web8506.mail.in.yahoo.com>


--- Eivind <gentoo.warrior at gmail.com> wrote:

> I am just curious why OpenOffice on FC3 consumes
> roughly 150MB of
> memory contra a 100MB of memory using Gentoo.

put this into bugzilla if its not a known thing already

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 



From ssc at coolspot.de  Fri Dec 17 19:33:00 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Fri, 17 Dec 2004 20:33:00 +0100
Subject: FreeTDS
In-Reply-To: <41C32946.9090605@coolspot.de>
References: <41C2E2A2.1020501@coolspot.de>	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
	<41C32946.9090605@coolspot.de>
Message-ID: <41C3346C.7000509@coolspot.de>

Stefan Sonnenberg-Carstens wrote:

> Carwyn Edwards wrote:
>
>>
>> On 17 Dec 2004, at 13:44, Stefan Sonnenberg-Carstens wrote:
>>
>>> Is there a reason for not having freetds in fedora ?
>>> I would maintain the packet, if that's the problem.
>>
>>
>>
>> This is a good candidate for adding into Fedora Extras.
>>
>> Carwyn
>>
> Ok, what do I need to do ?
>
I got rpms compiled under FC3.
They are available under

http://www.coolspot.de/fedora-devel/

Test them, please.
They worl ok, but right now I have to verify if they
fit into the fedora policy.

Cheers,
Stefan Sonnenberg



From dries at ulyssis.org  Fri Dec 17 19:47:35 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Fri, 17 Dec 2004 20:47:35 +0100
Subject: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <41C32138.3080602@insitesinc.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<1103279969.3791.26.camel@perun.redhat.usu>
	<41C32138.3080602@insitesinc.com>
Message-ID: <200412172047.35576.dries@ulyssis.org>

On Friday 17 December 2004 19:11, Michael Favia wrote:

> > That's much different from independent repositories such as Dag's
> > because they have the goal to deliver packages of new versions of
> > various software to as many distributions as possible. For this it's
> > much better to have one spec file with macros.
> >
> > So the question is, will Fedora Extras be more like independent
> > repository or more like the Fedora Core. Or it could depend on package.
>
> This is the first response to address the real issue in my opinion. If
> fedora extras is meant to be on par with fedora and maintain a forward
> looking policy (eg new releases for current FC and security fixes only
> for past FC) then the choice seems fairly easy.
>
> The real question is: "Is the independent packaging community willing to
> follow this mantra of 'moving forward' and thus abandoning backwards
> compatibility without maintaining separate spec files"?
>
> If not is the cost of regressions/complexity in the spec files (that
> they want to use) greater than the benefit of having those individuals
> on board?
>
> Perhaps the real issue we need to be asking is while it is very nice (i
> repeat: very nice and greatly appreciated) to be able to install new
> versions of various software on my FC1 boxes, how inline with the goal
> of the fedora project is that? I would argue that it doesnt really have
> a place, at least not in fedora extras. But, we need the independent
> package managers onboard and to do so we either need to convince them of
> the benefits of a forward looking approach to this distro or we need to
> allow at least some the complexities they bring with the skills they
> honed in more stable and longer life cycle distros.

Please note that 'the independent  repositories' are not only busy with 
backwards compatibility for older Fedora Core or Red Hat Linux releases, but 
also with compatibility for other/newer distributions like for example Aurora 
Linux (a Fedora Core for Sparc) and Fedora for Alpha and Yellow Dog Linux and 
RHEL (or clones) and simply getting stuff working on the newest Fedora Core 
itself (for example compile fixes for the newer gcc or amd64). 

And yes indeed.. normally all from the same spec file! I bet you're all 
thinking now that those spec files really must be evil and full of weird 
macros. :-)
Well actually, they're not. I really would like to invite you to have a look 
yourself!

You make it sound as if compatibility is something holy for Dag and other  
independent repositories. That's a bit exagerated i think.  If the spec file 
builds and works fine on older or other distributions, then why won't you use 
that possibility? Instead of only the users of recent Fedora versions, you 
can make a lot of other users happy too with a minimum of effort :-)

For example when i make a spec file, then i test it and build it for Fedora 
Core 3 first. Most of the time, the same spec file builds and works also on 
'not too old' versions like Fedora Core 2 and other quite recent distros like 
Aurora 1.92. If the program looks usefull to me  and only a minimal effort is 
needed to get it to compile & work too on for example Fedora Core 1.. then 
why not? But if it requires more work (like when it needs a recent Gnome or 
KDE) then i won't even think of trying to achieve backwards compatibility.  
Backwards compatibility is nice, but only if it doesn't require a lot of 
work. 

It's not "keeping every program/spec file backwards compatibile with 
everything since RH 7.3" which i think is important, but "having the 
possibility to keep a program/spec file working on other and older distros if 
it's not too much work".

To achieve that goal, we use one spec file for a program, which can contain  
some easy macros, where most of those macros are only used for  
buildrequirements. We can't maintain a spec file for each distro/arch 
combination.. that's too much work.

Please don't get me wrong: the project Fedora Extras is really great for the 
Fedora community, but in my humble opinion the same project can also be great 
for a lot more people with only a bit of work :-)

kind regards,
Dries Verachtert

PS: You can find those spec files at http://svn.rpmforge.net/svn/trunk/rpms/ 
and  http://dag.wieers.com/packages/ and 
http://dries.ulyssis.org/ayo/packages/ and others.



From ndbecker2 at verizon.net  Fri Dec 17 19:54:43 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 17 Dec 2004 14:54:43 -0500
Subject: yum - tidy untidy
References: <cpvau1$3ul$1@sea.gmane.org>
	<1103310766.9364.47.camel@opus.phy.duke.edu>
	<cpvbn9$9qh$1@sea.gmane.org>
	<1103311510.9364.51.camel@opus.phy.duke.edu>
Message-ID: <cpvdi3$f3o$1@sea.gmane.org>

seth vidal wrote:

> On Fri, 2004-12-17 at 14:23 -0500, Neal D. Becker wrote:
>> Is this enough?
>> 
>> > okay - this is bizarre. Try this:
>> > 
>> > yum -d5 install tidy - I'm curious what the other possible resolvers
>> > are.
>> > 
>> > -sv
>> > 
>> > 
>> sudo yum -d5 install tidy
>> Yum Version: 2.1.11
>> COMMAND: yum -d5 install tidy
>> Installroot: /
>> Ext Commands:
>>    tidy
> 
> Could you install yum 2.1.12 from testing-updates and tell me if it
> resolves this problem or at least changes it some? :)
> -sv
> 
> 

yum --version
2.1.12

I think it's the same result.
[...]
Reading repository metadata in from local files
Setting up Package Sacks
dag       : ################################################## 1389/1389
kde-redhat: ################################################## 324/324
kde-redhat: ################################################## 229/229
jpackage16: ################################################## 19/19
jpackage16: ################################################## 1277/1277
base      : ################################################## 2622/2622
updates-re: ################################################## 355/355
haskell   : ################################################## 35/35
freshrpms : ################################################## 452/452
pre-extras: ################################################## 617/617
Reading Local RPMDB
No other tidy installed, adding to list for install
No other tidy installed, adding to list for install
reduced installs :
   tidy.i386 0:0.99.0-2.20040916
Resolving Dependencies
1103313163.16
--> Populating transaction set with selected packages. Please wait.
Adding Package tidy - 0.99.0-2.20040916.i386 in mode i
---> Package tidy.i386 0:0.99.0-2.20040916 set to be installed
--> Running transaction check
# of Deps = 1
tidy requires: libtidy-0.99.so.0
--> Processing Dependency: libtidy-0.99.so.0 for package: tidy
Requiring package is from transaction set
Resolving for requiring package: tidy-0.99.0-2.20040916 in state i
Resolving for requirement: libtidy-0.99.so.0
Searching pkgSack for dep: libtidy-0.99.so.0
Potential match for libtidy-0.99.so.0 from tidy -
0.99.0-0.fdr.4.20041005.3.i386
Matched tidy - 0.99.0-0.fdr.4.20041005.3.i386 to require for
libtidy-0.99.so.0
Potential match for libtidy-0.99.so.0 from libtidy - 0.99.0-2.20040916.i386
Matched libtidy - 0.99.0-2.20040916.i386 to require for libtidy-0.99.so.0
TSINFO: Marking tidy - 0.99.0-0.fdr.4.20041005.3.i386 as install for tidy
miss = 0
conf = 0
CheckDeps = 1
--> Restarting Dependency Resolution with new changes.
---> Loop Number: 2
Restarting Loop
--> Populating transaction set with selected packages. Please wait.
Adding Package tidy - 0.99.0-0.fdr.4.20041005.3.i386 in mode i
---> Package tidy.i386 0:0.99.0-0.fdr.4.20041005.3 set to be installed
--> Running transaction check

Dependencies Resolved
1103313163.28
Transaction Listing:
  Install: tidy.i386 0:0.99.0-2.20040916

Performing the following to resolve dependencies:
  Install: tidy.i386 0:0.99.0-0.fdr.4.20041005.3
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Adding Package tidy - 0.99.0-2.20040916.i386 in mode i
Adding Package tidy - 0.99.0-0.fdr.4.20041005.3.i386 in mode i
Finished Transaction Test
Transaction Check Error:   file /usr/bin/tab2space conflicts between
attempted installs of tidy-0.99.0-0.fdr.4.20041005.3 and
tidy-0.99.0-2.20040916
  file /usr/bin/tidy conflicts between attempted installs of
tidy-0.99.0-0.fdr.4.20041005.3 and tidy-0.99.0-2.20040916




From kyrre at solution-forge.net  Fri Dec 17 20:13:54 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Fri, 17 Dec 2004 21:13:54 +0100
Subject: Choice of default fonts in webrowsers
In-Reply-To: <1103235683.12071.5.camel@rousalka.dyndns.org>
References: <20041216221157.72779.qmail@web8509.mail.in.yahoo.com>
	<1103235683.12071.5.camel@rousalka.dyndns.org>
Message-ID: <1103314434.2737.13.camel@kyrre>

tor, 16.12.2004 kl. 23.21 skrev Nicolas Mailhot:
> Le jeudi 16 d?cembre 2004 ? 14:11 -0800, Rahul Sundaram a ?crit :
> > Hi
> > 
> > 
> > > 
> > > Why is it so? Why is those fonts, which it seem like
> > > "everyone" thinks
> > > are really ugly are used, when better fonts are
> > > shipped?
> > 
> > 
> > I have heard before that this is because the default
> > fonts should be internationalised or something like
> > that which bitstream fonts arent
> 
> It might be worth taking a new look now that the deja variant of vera is
> announcing new glyphs every other months. Of course we're far from full
> unicode coverage, but fontconfig will fall back on Luxi if needed, so...

Would that mean that if we used the nice fonts as default, everyone
wanting to read a document with common glyphs would have no problem
reading it (both glyphwise and readabilitywise) - and those who has a
doc with less common glyphs, would get a mix? Or will the get only "old"
glyps in those docs? So for those who uses common glyphs, it will be a
good thing, and it won't hurt those who use less common glyps?

What are we waiting for?

Kyrre



From walters at redhat.com  Fri Dec 17 20:21:10 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 15:21:10 -0500
Subject: svn or arch
In-Reply-To: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
Message-ID: <1103314870.12552.107.camel@nexus.verbum.private>

On Thu, 2004-12-16 at 10:13 -0800, Rahul Sundaram wrote:
> Hi
> 
> Is there any discussions about using Subversion or GNU
> arch/Bazaar (http://bazaar.canonical.com/) instead of
> cvs for the repositories.

My opinion is that in order to really enjoy the benefits of a modern RCS
(in particular history-sensitive merging), we would need to change a
number of things in the way building an RPM package works.

First, I think it's wacky to maintain patch files in revision control.
If you want to look back at history, you're looking at a diff of a diff,
which is just incomprehensible.  The right way to do this in my opinion
is to have each patch be a direct branch of the upstream source.  If you
have patch interdependencies, then you create a new branch which merges
from the interdependent branches, just like how you have to adjust the
patch files now.

Second, get rid of the RPM changelog embedded in the spec file;
conceptually the goo to build a package is independent of the history of
that goo.  Just extract the history from the RCS, or have a separate
file, or something.

Third, get rid of the idea of manually bumping revision numbers and
hardcoding these in the spec file.  These should be automatically
generated from the upstream source version and a package build database
when I want to build a package.

There's lots more we could do too, but that's a start.




From shiva at sewingwitch.com  Fri Dec 17 20:55:05 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Fri, 17 Dec 2004 12:55:05 -0800
Subject: svn or arch
In-Reply-To: <1103314870.12552.107.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
Message-ID: <A3DD015023608F3EEB659EA9@[10.169.6.246]>

--On Friday, December 17, 2004 3:21 PM -0500 Colin Walters 
<walters at redhat.com> wrote:

> Second, get rid of the RPM changelog embedded in the spec file;
> conceptually the goo to build a package is independent of the history of
> that goo.  Just extract the history from the RCS, or have a separate
> file, or something.

The changelog should reflect the history of the *packaging*, not the 
package.

> Third, get rid of the idea of manually bumping revision numbers and
> hardcoding these in the spec file.  These should be automatically
> generated from the upstream source version and a package build database
> when I want to build a package.

A lot of packages include a spec.in file which is then passed through sed 
to install the version number in the spec file before a tarball is 
generated. Eliminating this extra step would make it easier for upstreams 
to provide RPM support by eliminating this extra step.



From cra at WPI.EDU  Fri Dec 17 21:11:38 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Fri, 17 Dec 2004 16:11:38 -0500
Subject: svn or arch
In-Reply-To: <1103314870.12552.107.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
Message-ID: <20041217211138.GV5001@angus.ind.WPI.EDU>

On Fri, Dec 17, 2004 at 03:21:10PM -0500, Colin Walters wrote:
> First, I think it's wacky to maintain patch files in revision control.
> If you want to look back at history, you're looking at a diff of a diff,
> which is just incomprehensible.  The right way to do this in my opinion
> is to have each patch be a direct branch of the upstream source.  If you
> have patch interdependencies, then you create a new branch which merges
> from the interdependent branches, just like how you have to adjust the
> patch files now.

It would be neat if I could do:

Patch: cvs://cvs.fedora.fedhat.com/....



From walters at redhat.com  Fri Dec 17 21:12:15 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 16:12:15 -0500
Subject: svn or arch
In-Reply-To: <A3DD015023608F3EEB659EA9@[10.169.6.246]>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
Message-ID: <1103317935.12552.117.camel@nexus.verbum.private>

On Fri, 2004-12-17 at 12:55 -0800, Kenneth Porter wrote:
> --On Friday, December 17, 2004 3:21 PM -0500 Colin Walters 
> <walters at redhat.com> wrote:
> 
> > Second, get rid of the RPM changelog embedded in the spec file;
> > conceptually the goo to build a package is independent of the history of
> > that goo.  Just extract the history from the RCS, or have a separate
> > file, or something.
> 
> The changelog should reflect the history of the *packaging*, not the 
> package.

By "independent", I mean that you do not need the packaging history to
just build the package, and you don't need the build goo to read the
changelog.  The reason why globbing them together is bad is the same
reason that the magic CVS tags like $Id$ and $Log$ are bad - it screws
merging.

Independent things should be in separate files.  In the particular case
of the packaging history, since we now depend on an RCS, we can just
generate it from the RCS history when creating the SRPM (which is now
basically just a convenient single-file cache of the packaging).

> A lot of packages include a spec.in file which is then passed through sed 
> to install the version number in the spec file before a tarball is 
> generated. Eliminating this extra step would make it easier for upstreams 
> to provide RPM support by eliminating this extra step.

Yes; but you still have the rpm revision number.  I am arguing for its
removal entirely.  That's one less spurious thing you see in a diff
between branches, and one less thing to merge conflict on.




From rahulsundaram at yahoo.co.in  Fri Dec 17 21:30:44 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 13:30:44 -0800 (PST)
Subject: svn or arch
In-Reply-To: <1103317935.12552.117.camel@nexus.verbum.private>
Message-ID: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>

Hi
> Yes; but you still have the rpm revision number.  I
> am arguing for its
> removal entirely.  That's one less spurious thing
> you see in a diff
> between branches, and one less thing to merge
> conflict on.


can such things be done without breaking compatibility ?

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



From ville.skytta at iki.fi  Fri Dec 17 21:37:08 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Fri, 17 Dec 2004 23:37:08 +0200
Subject: svn or arch
In-Reply-To: <20041217211138.GV5001@angus.ind.WPI.EDU>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041217211138.GV5001@angus.ind.WPI.EDU>
Message-ID: <1103319428.7746.70.camel@bobcat.mine.nu>

On Fri, 2004-12-17 at 16:11 -0500, Charles R. Anderson wrote:

> It would be neat if I could do:
> 
> Patch: cvs://cvs.fedora.fedhat.com/....

If you don't mind the filenames, you can almost do:

Patch: http://cvs.fedora.redhat.com/viewcvs/devel/alsa-firmware/Makefile?root=extras&r1=1.1&r2=1.2&makepatch=1

Only almost, because apparently rpm either cuts the basename at
unexpected places (eg. "&" or ";") or fails to escape those chars
properly when feeding it to patch.  In the above example, it fails with
".../Makefile?root=extras: No such file or directory".

But this isn't probably what you were after, anyway ;)



From walters at redhat.com  Fri Dec 17 21:38:35 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 16:38:35 -0500
Subject: svn or arch
In-Reply-To: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
Message-ID: <1103319515.12552.125.camel@nexus.verbum.private>

On Fri, 2004-12-17 at 13:30 -0800, Rahul Sundaram wrote:
> Hi
> > Yes; but you still have the rpm revision number.  I
> > am arguing for its
> > removal entirely.  That's one less spurious thing
> > you see in a diff
> > between branches, and one less thing to merge
> > conflict on.
> 
> 
> can such things be done without breaking compatibility ?

In short, yes.  

I see no serious problems with taking a snapshot of the source tree and
generating a compatible SRPM.  It's trivial to regenerate the Release:
and Version: headers from the package build database.  The changelog can
be generated from the RCS history.

Keeping compatibility with PatchN: is a bit harder since with a modern
RCS, you can e.g. add a binary file in a branch.  But if you limit your
branches to what can be expressed by diff, then you just do a checkout
of the patch-branch, do a diff, and stick in a PatchN line.

One thing that should be clear is that by using a revision control
system for RPM packaging, we've already conceptually broken
compatibility because the SRPM is no longer the preferred form of
modification, to use the GPL terminology.




From ssc at coolspot.de  Fri Dec 17 21:49:03 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Fri, 17 Dec 2004 22:49:03 +0100
Subject: FreeTDS
In-Reply-To: <41C3346C.7000509@coolspot.de>
References: <41C2E2A2.1020501@coolspot.de>	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>	<41C32946.9090605@coolspot.de>
	<41C3346C.7000509@coolspot.de>
Message-ID: <41C3544F.9020201@coolspot.de>

Stefan Sonnenberg-Carstens wrote:

> Stefan Sonnenberg-Carstens wrote:
>
>> Carwyn Edwards wrote:
>>
>>>
>>> On 17 Dec 2004, at 13:44, Stefan Sonnenberg-Carstens wrote:
>>>
>>>> Is there a reason for not having freetds in fedora ?
>>>> I would maintain the packet, if that's the problem.
>>>
>>>
>>>
>>>
>>> This is a good candidate for adding into Fedora Extras.
>>>
>>> Carwyn
>>>
>> Ok, what do I need to do ?
>>
> I got rpms compiled under FC3.
> They are available under
>
> http://www.coolspot.de/fedora-devel/
>
> Test them, please.
> They worl ok, but right now I have to verify if they
> fit into the fedora policy.
>
> Cheers,
> Stefan Sonnenberg
>
Oh, and having this in fc should imply to have
php-mssql ;-)
My world would be so perfect ...

But what is the official way to get a rpm into the "base" system ?



From rahulsundaram at yahoo.co.in  Fri Dec 17 21:54:20 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 13:54:20 -0800 (PST)
Subject: FreeTDS
In-Reply-To: <41C3544F.9020201@coolspot.de>
Message-ID: <20041217215420.24238.qmail@web8507.mail.in.yahoo.com>

Hi

> Oh, and having this in fc should imply to have
> php-mssql ;-)
> My world would be so perfect ...
> 
> But what is the official way to get a rpm into the
> "base" system ?
> 

probably getting it into fedora extras is a first
step. you will have to present a convincing argument
as to why its required to be in core

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From rahulsundaram at yahoo.co.in  Fri Dec 17 21:58:37 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 13:58:37 -0800 (PST)
Subject: svn or arch
In-Reply-To: <1103319515.12552.125.camel@nexus.verbum.private>
Message-ID: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>

Hi


> One thing that should be clear is that by using a
> revision control
> system for RPM packaging, we've already conceptually
> broken
> compatibility because the SRPM is no longer the
> preferred form of
> modification, to use the GPL terminology.


I was more concerned about breaking binary
compatibility. srpms would still be relevant to people
who dont have a build setup similar to redhat right?



=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From walters at redhat.com  Fri Dec 17 22:03:14 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 17:03:14 -0500
Subject: svn or arch
In-Reply-To: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
Message-ID: <1103320995.12552.131.camel@nexus.verbum.private>

On Fri, 2004-12-17 at 13:58 -0800, Rahul Sundaram wrote:
> Hi
> 
> 
> > One thing that should be clear is that by using a
> > revision control
> > system for RPM packaging, we've already conceptually
> > broken
> > compatibility because the SRPM is no longer the
> > preferred form of
> > modification, to use the GPL terminology.
> 
> 
> I was more concerned about breaking binary
> compatibility. srpms would still be relevant to people
> who dont have a build setup similar to redhat right?

No; you should be able to build packages from the Fedora public CVS
without access to the Fedora build system.  I say "should" in that I
don't know if it works now, but I think it's a bug if it doesn't.





From ssc at coolspot.de  Fri Dec 17 22:15:47 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Fri, 17 Dec 2004 23:15:47 +0100
Subject: FreeTDS
In-Reply-To: <20041217215420.24238.qmail@web8507.mail.in.yahoo.com>
References: <20041217215420.24238.qmail@web8507.mail.in.yahoo.com>
Message-ID: <41C35A93.1060506@coolspot.de>

Rahul Sundaram wrote:

>Hi
>
>  
>
>>Oh, and having this in fc should imply to have
>>php-mssql ;-)
>>My world would be so perfect ...
>>
>>But what is the official way to get a rpm into the
>>"base" system ?
>>
>>    
>>
>
>probably getting it into fedora extras is a first
>step. you will have to present a convincing argument
>as to why its required to be in core
>
>=====
>Regards
>Rahul Sundaram
>
>
>		
>__________________________________ 
>Do you Yahoo!? 
>Dress up your holiday email, Hollywood style. Learn more. 
>http://celebrity.mail.yahoo.com
>
>  
>
Ok, is this the sort of thing like
old RedHat contrib ?



From jspaleta at gmail.com  Fri Dec 17 22:17:23 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 17:17:23 -0500
Subject: svn or arch
In-Reply-To: <1103320995.12552.131.camel@nexus.verbum.private>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
Message-ID: <604aa7910412171417512a48ea@mail.gmail.com>

On Fri, 17 Dec 2004 17:03:14 -0500, Colin Walters <walters at redhat.com> wrote:
> No; you should be able to build packages from the Fedora public CVS
> without access to the Fedora build system.  I say "should" in that I
> don't know if it works now, but I think it's a bug if it doesn't.

the pre-extras packages would be an example of this working.. since
the fedora build system isn't fully together yet, the pre-extras
packages were built on machines seth had access to. I think he built
them on an fc3 full install system.

-jef



From skvidal at phy.duke.edu  Fri Dec 17 22:23:31 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 17 Dec 2004 17:23:31 -0500
Subject: svn or arch
In-Reply-To: <604aa7910412171417512a48ea@mail.gmail.com>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
	<604aa7910412171417512a48ea@mail.gmail.com>
Message-ID: <1103322212.9364.68.camel@opus.phy.duke.edu>

On Fri, 2004-12-17 at 17:17 -0500, Jeff Spaleta wrote:
> On Fri, 17 Dec 2004 17:03:14 -0500, Colin Walters <walters at redhat.com> wrote:
> > No; you should be able to build packages from the Fedora public CVS
> > without access to the Fedora build system.  I say "should" in that I
> > don't know if it works now, but I think it's a bug if it doesn't.
> 
> the pre-extras packages would be an example of this working.. since
> the fedora build system isn't fully together yet, the pre-extras
> packages were built on machines seth had access to. I think he built
> them on an fc3 full install system.
> 

an x86_64 and an x86 'everything' install, yes.

-sv




From dries at ulyssis.org  Fri Dec 17 22:36:21 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Fri, 17 Dec 2004 23:36:21 +0100
Subject: svn or arch
In-Reply-To: <604aa7910412171417512a48ea@mail.gmail.com>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
	<604aa7910412171417512a48ea@mail.gmail.com>
Message-ID: <200412172336.21200.dries@ulyssis.org>

On Friday 17 December 2004 23:17, Jeff Spaleta wrote:
> On Fri, 17 Dec 2004 17:03:14 -0500, Colin Walters <walters at redhat.com> 
wrote:
> > No; you should be able to build packages from the Fedora public CVS
> > without access to the Fedora build system.  I say "should" in that I
> > don't know if it works now, but I think it's a bug if it doesn't.
>
> the pre-extras packages would be an example of this working.. since
> the fedora build system isn't fully together yet, the pre-extras
> packages were built on machines seth had access to. I think he built
> them on an fc3 full install system.

Is it maybe possible to give already a little bit of information about this 
fedora build system? For example what i'm interested at: what is the minimal 
set of packages which are installed within each buildroot? Is it possible to 
give a list of packages for each distro/arch? People who are willing to 
contribute, can already start with modifying their spec files according to 
this lists so they can be added faster when the cvs is open and the build 
system is ready.

An example: is gcc-c++ installed by default or should it be included in the 
BuildRequires of each c++ program?

kind regards,
Dries Verachtert



From gafton at redhat.com  Fri Dec 17 22:46:06 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 17:46:06 -0500 (EST)
Subject: svn or arch
In-Reply-To: <1103320995.12552.131.camel@nexus.verbum.private>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
Message-ID: <Pine.LNX.4.61.0412171745180.24065@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Colin Walters wrote:

>> I was more concerned about breaking binary
>> compatibility. srpms would still be relevant to people
>> who dont have a build setup similar to redhat right?
>
> No; you should be able to build packages from the Fedora public CVS
> without access to the Fedora build system.  I say "should" in that I
> don't know if it works now, but I think it's a bug if it doesn't.

I am certainly mindful of this popular request and I believe it is 
something we should attempt to have.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From jspaleta at gmail.com  Fri Dec 17 22:50:54 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Dec 2004 17:50:54 -0500
Subject: svn or arch
In-Reply-To: <200412172336.21200.dries@ulyssis.org>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
	<604aa7910412171417512a48ea@mail.gmail.com>
	<200412172336.21200.dries@ulyssis.org>
Message-ID: <604aa791041217145018a7d15f@mail.gmail.com>

On Fri, 17 Dec 2004 23:36:21 +0100, Dries Verachtert <dries at ulyssis.org> wrote:
> Is it maybe possible to give already a little bit of information about this
> fedora build system? 

I think we are probably going to have to wait for Gafton to present
the initial extras build script tools for review, that he promised in
one of these threads sometime yesterday or the day before, to be able
to get an accurate starting picture and work from there.

-jef



From kyrre at solution-forge.net  Fri Dec 17 22:47:20 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Fri, 17 Dec 2004 23:47:20 +0100
Subject: OpenOffice Memory Bloat?
In-Reply-To: <dbc15d4904121711173e908c16@mail.gmail.com>
References: <dbc15d4904121711173e908c16@mail.gmail.com>
Message-ID: <1103322563.2737.152.camel@kyrre>

fre, 17.12.2004 kl. 20.17 skrev Eivind:
> I am just curious why OpenOffice on FC3 consumes roughly 150MB of
> memory contra a 100MB of memory using Gentoo.
> 
> I did a little experiment myself, where I checked the System Monitor
> and listsed the memory maps for that process, (Identically, you can do
> it by 'cat /proc/<pid_of_OO>/maps' and sort the output by size).
> 
> I found that the library libsvx645li.so which is a 12MB library is
> loaded 6 times into memory on FC3 in contrast to Gentoo wich only
> loads this library once. On gentoo I am using the vanilla OO from
> www.openoffice.org, and I've tested this with both the standard FC3
> rpm and the vanilla OO with no significant difference (~2-4MB).
> 
> Both distributions is using gnome 2.6 and the Metacity window manager.
> I am just curious on what may cause this huge memory bloat (why is
> this library loaded 6 times and not 1).
> 
> Any comments? 
> 

I did a norwegian "nynorsk" (there are two, very similar official
languages in norway) test on my laptop today, in which i happened to use
the spellchecker quite extencively...

But when i was about to print the result, i plugged in the network cable
and hit print - the printer's (network printers shared through a CUPS
server on the LAN) wasn't there... So i restarted OO.

It took about 1-3 minutes *shutting down* OO (it had swapped out
something like 300 MB), and then at least a minute starting it up again
(as "everything" was out in the swap...). And i was in a hurry...

So i have some questions:
- Why did OO stop discovering printers when they are added (it did
before - just close the printer dialogue and reopen it)
- Why does OO load many hundred MB of dictionaries? I don't care if a
misspelled word happen to be correct in Czech. (Norwegian misspelled
words has some tend to be correct in that language.) It also slows down
the spellchecker a *lot*.
- Why aren't OO quickstart included in fedora?

At least #2 should be quite fixable right now (just send an update)...

Kyrre
Waiting impatiently for OO 2.0



From gafton at redhat.com  Fri Dec 17 22:52:37 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 17:52:37 -0500 (EST)
Subject: svn or arch
In-Reply-To: <200412172336.21200.dries@ulyssis.org>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<1103320995.12552.131.camel@nexus.verbum.private>
	<604aa7910412171417512a48ea@mail.gmail.com>
	<200412172336.21200.dries@ulyssis.org>
Message-ID: <Pine.LNX.4.61.0412171746560.24065@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Dries Verachtert wrote:

> Is it maybe possible to give already a little bit of information about this
> fedora build system? For example what i'm interested at: what is the minimal
> set of packages which are installed within each buildroot? Is it possible to

Look at the comps.xml file. You can depend on having in the buildroot the 
packages from the @base and @development-tools groups. Everything else 
will have to be BuildRequires:'d in the src.rpm.

The build root setup script installs the @base and @develoment-tools 
packages and then looks at the src.rpm's Buildrequires and attempts to 
solve those. Once that is done, the package build script chroots into the 
newly created buildroot and issues an rpmbuild --rebuild for the src.rpm 
as a non-root user.

> give a list of packages for each distro/arch? People who are willing to
> contribute, can already start with modifying their spec files according to
> this lists so they can be added faster when the cvs is open and the build
> system is ready.

I'll see what I can do to publish the builroot setup script so that you 
can check whether your BuildRequires are complete.

> An example: is gcc-c++ installed by default or should it be included in the
> BuildRequires of each c++ program?

No, the development tools like compilers, make, autconf are assumed to be 
available. I realize that the @development-tools group might be broad for 
some tastes; later on we'll look at eventually reducing the scope further 
of what is assumed to be in the buildroot; for now that is a relativey 
sane and safe compromise, I think.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From gafton at redhat.com  Fri Dec 17 22:54:09 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 17:54:09 -0500 (EST)
Subject: svn or arch
In-Reply-To: <1103319428.7746.70.camel@bobcat.mine.nu>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041217211138.GV5001@angus.ind.WPI.EDU>
	<1103319428.7746.70.camel@bobcat.mine.nu>
Message-ID: <Pine.LNX.4.61.0412171753250.24065@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Ville [ISO-8859-1] Skytt? wrote:

> On Fri, 2004-12-17 at 16:11 -0500, Charles R. Anderson wrote:
>
>> It would be neat if I could do:
>>
>> Patch: cvs://cvs.fedora.fedhat.com/....
>
> If you don't mind the filenames, you can almost do:
>
> Patch: http://cvs.fedora.redhat.com/viewcvs/devel/alsa-firmware/Makefile?root=extras&r1=1.1&r2=1.2&makepatch=1

Or, you can put the patches in the lookaside cache and refer them from the 
lookaside cache - that generates saner URLs that rpm could grok.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution

From dries at ulyssis.org  Fri Dec 17 22:55:16 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Fri, 17 Dec 2004 23:55:16 +0100
Subject: svn or arch
In-Reply-To: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
Message-ID: <200412172355.17027.dries@ulyssis.org>

On Friday 17 December 2004 22:30, Rahul Sundaram wrote:
> Hi
>
> > Yes; but you still have the rpm revision number.  I
> > am arguing for its
> > removal entirely.  That's one less spurious thing
> > you see in a diff
> > between branches, and one less thing to merge
> > conflict on.
>
> can such things be done without breaking compatibility ?

Do you mean the Release tag or the Version-Release of a spec file with 'the 
rpm revision number'?

If i'm correct, you suggest to remove the release or the version-release  
completely from the spec file.. this would make it impossible to build the 
spec file with a 'rpmbuild -ba bla.spec'. What about adding default tags like  
'Release: 1' which gets replaced by the build system of Fedora Extras?

Such tags can be changed by the Fedora Extras buildsystem before it starts a 
rebuild of a spec file, no?  I'm also doing something like that with my 
self-made mini buildsystem: the last commit revision of that spec file is 
added automatically to the first changelog entry.
This makes it possible to check automatically which spec files are already 
built for a certain distro/arch and which are not because i can compare the 
svncmtid of the binary rpms with the current version of a spec file in the  
subversion repository. I really like this kind of automated stuff which makes 
life a lot easier for me :-)  This is also possible with cvs instead of 
subversion and the release tag (or version and release tag) instead of the 
changelog i guess.

kind regards,
Dries Verachtert



From dries at ulyssis.org  Fri Dec 17 23:07:56 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Sat, 18 Dec 2004 00:07:56 +0100
Subject: svn or arch
In-Reply-To: <Pine.LNX.4.61.0412171746560.24065@alien.devel.redhat.com>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<200412172336.21200.dries@ulyssis.org>
	<Pine.LNX.4.61.0412171746560.24065@alien.devel.redhat.com>
Message-ID: <200412180007.56739.dries@ulyssis.org>

On Friday 17 December 2004 23:52, Cristian Gafton wrote:
> On Fri, 17 Dec 2004, Dries Verachtert wrote:

> > An example: is gcc-c++ installed by default or should it be included in
> > the BuildRequires of each c++ program?
>
> No, the development tools like compilers, make, autconf are assumed to be
> available. I realize that the @development-tools group might be broad for
> some tastes; later on we'll look at eventually reducing the scope further
> of what is assumed to be in the buildroot; for now that is a relativey
> sane and safe compromise, I think.

Thank you very much for the information! Although i must confess i'm used to 
mach which doesn't install that much packages automatically within a 
buildroot, i think it's great there is (or will be) some standard endorsed by 
Red Hat which will be used by Fedora Core and Fedora Extras and maybe also by 
others like maybe Fedora Legacy.. this will make it easier to transfer a spec 
file from Fedora Core to Fedora Extras i guess. 

kind regards,
Dries Verachtert



From fedora at wir-sind-cool.org  Fri Dec 17 23:17:38 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 18 Dec 2004 00:17:38 +0100
Subject: FreeTDS
In-Reply-To: <41C3346C.7000509@coolspot.de>
References: <41C2E2A2.1020501@coolspot.de>
	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
	<41C32946.9090605@coolspot.de> <41C3346C.7000509@coolspot.de>
Message-ID: <20041218001738.519de929.fedora@wir-sind-cool.org>

On Fri, 17 Dec 2004 20:33:00 +0100, Stefan Sonnenberg-Carstens wrote:

> I got rpms compiled under FC3.
> They are available under
> 
> http://www.coolspot.de/fedora-devel/
> 
> Test them, please.

The src.rpm fails to build on FC3. Try to clean up your installation
to find missing build dependencies:

  http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires


Other packaging mistakes after a brief look. In random order:

 * Main package must not contain files %_libdir/*.so
   All these belong into the -devel package. Same applies to the
   -unixodbc sub package. It must not include %_libdir/*.so either.
   These files are needed at build-time only.


 * rpmlint reports a few relevant things:

E: freetds summary-too-long FreeTDS is a free re-implementation of the TDS (Tabular DataStream) protocol that is used by Sybase and Microsoft for their database products.

 => better:  A free re-implementation of the TDS protocol

 Everything longer than ~70 characters ought to be put into the
 package description.


W: freetds no-url-tag

 => You've put that into "Vendor:" field instead. Change that into
    "URL: http://www.freetds.org" -- the vendor is the package vendor
    and usually will be substituted by a build system automatically.


E: freetds no-signature

 => minor issue for a test package - you didn't sign it with
    your GPG key


W: freetds strange-permission freetds.spec 0664

 => also unimportant, but a user who would extract the file into
    /tmp would end up with a group-writable file


W: freetds obsolete-tag Copyright

 => should be "License: LGPL" not "Copyright: LGPL"


> %define	name	freetds
> %define	version	0.62.4
>  
> Name: %{name} 
> Version: %{version} 

That construct is redundant. The %name and %version macros are defined
by "Name:" and "Version:" already.


> %package devel 
> Requires: freetds = %{version}

Better would be:

  Requires: freetds = %{version}-%release

Why? Imagine you apply a patch which patches the header files or other
files in the -devel package or which fixes a bug in the main package.
You want main package release and -devel package release to stay in
sync. "yum update freetds-devel" should pull in the updated "freetds"
main package, too.


> %post 
> /sbin/ldconfig 

Better:

  %post -p /sbin/ldconfig
  %postun -p /sbin/ldconfig

Why? It adds an automatic dependency on /sbin/ldconfig and updates the
run-time linker cache also after package un-installation, when the
freetds libraries are gone. Your %post script would be executed in
/bin/sh.


> %configure --with-tdsver=4.2 --prefix=/usr --with-unixodbc=/usr/ --sysconfdir=%{_sysconfdir}

The %configure macro sets --prefix=%_prefix and --syconfdir=%_sysconfdir
already. You can trim the line a bit. :)


> %doc AUTHORS BUGS COPYING ChangeLog INSTALL NEWS README TODO 

COPYING is GPL, which is not what's specified in "License:" field.
File COPYING.LIB would be the LGPL and should be included.
The INSTALL file contains generic instructions, which are irrelevant
to the package user.


> %{_libdir}/libct.so*

Files with such non-unique names will likely cause conflicts in
%_libdir in the future, when more and more packages share that
directory and more projects use similar short names. This topic will
come back in the near future as it will be necessary more often to
install such libraries into %_libdir/%name/ and add that path to the
run-time linker's search path list.

Same with regard to some of the header names in %_includedir:

> -rw-r--r-- root  root      3036 /usr/include/bkpublic.h
> -rw-r--r-- root  root     22514 /usr/include/cspublic.h
> -rw-r--r-- root  root      1251 /usr/include/cstypes.h
> -rw-r--r-- root  root      4492 /usr/include/ctpublic.h
> -rw-r--r-- root  root      2207 /usr/include/dblib.h
> -rw-r--r-- root  root      1096 /usr/include/sqldb.h
> -rw-r--r-- root  root      1119 /usr/include/sqlfront.h


> %package unixodbc
> Requires: freetds = %{version}, unixODBC >= 2.2.9

Fedora Core 3 includes unixODBC 2.2.9, the dependency on libodbcinst.so.1
is automatic, so the explicit dependency on a package called
unixODBC doesn't add any value. Be careful with "explicit Requires".
If Fedora Core 4 moved libodbcinst.so.1 into a package with a different
name, this dependency would break.

With regard to the freetds dependency, same as above.



From rahulsundaram at yahoo.co.in  Fri Dec 17 23:29:17 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 15:29:17 -0800 (PST)
Subject: OpenOffice Memory Bloat?
In-Reply-To: <1103322563.2737.152.camel@kyrre>
Message-ID: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>

Hi

> - Why does OO load many hundred MB of dictionaries?
> I don't care if a
> misspelled word happen to be correct in Czech.
> (Norwegian misspelled
> words has some tend to be correct in that language.)
> It also slows down
> the spellchecker a *lot*.
> - Why aren't OO quickstart included in fedora?'

the dictionary bug is a known one. look in bugzilla
for details. the i18n package is also being split up
to reduce the size

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



From enrico.scholz at informatik.tu-chemnitz.de  Fri Dec 17 23:29:21 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 18 Dec 2004 00:29:21 +0100
Subject: svn or arch
In-Reply-To: <1103319515.12552.125.camel@nexus.verbum.private> (Colin
	Walters's message of "Fri, 17 Dec 2004 16:38:35 -0500")
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<1103319515.12552.125.camel@nexus.verbum.private>
Message-ID: <87wtvg1p2m.fsf@kosh.ultra.csn.tu-chemnitz.de>

walters at redhat.com (Colin Walters) writes:

> One thing that should be clear is that by using a revision control
> system for RPM packaging, we've already conceptually broken
> compatibility because the SRPM is no longer the preferred form of
> modification, to use the GPL terminology.

CVS can not replace SRPM:

- SRPM can be signed, CVS not
- SRPM are (usually) working, while the CVS checkout might be a completely
  broken development snapshot
- SRPM give you reproducibility, CVS not
- SRPM can be better accessed (e.g. in a browsable http/ftp listing);
  for CVS you need tags which are more difficultly to handle
- SRPM are buildable with system-tools (rpmbuild); for CVS you need lots
  of prerequisites.
(- a known CVS drawback: cvs checkin/checkout is not atomic)



Enrico



From rahulsundaram at yahoo.co.in  Fri Dec 17 23:31:40 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 15:31:40 -0800 (PST)
Subject: svn or arch
In-Reply-To: <Pine.LNX.4.61.0412171745180.24065@alien.devel.redhat.com>
Message-ID: <20041217233140.29820.qmail@web8506.mail.in.yahoo.com>

Hi

> >
> > No; you should be able to build packages from the
> Fedora public CVS
> > without access to the Fedora build system.  I say
> "should" in that I
> > don't know if it works now, but I think it's a bug
> if it doesn't.
> 

would srpms still be provided on the test/final
releases for convenience inorder to be able to do
customisations without pulling stuff from the fedora
cvs. the external contributors would probably like to
generate them automatically for other releases 

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From rahulsundaram at yahoo.co.in  Fri Dec 17 23:34:18 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 15:34:18 -0800 (PST)
Subject: FreeTDS
In-Reply-To: <41C35A93.1060506@coolspot.de>
Message-ID: <20041217233418.30051.qmail@web8506.mail.in.yahoo.com>

Hi

> Ok, is this the sort of thing like
> old RedHat contrib ?

yes but this is bound to be a better implementation or
atleast thats what I expect

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From gafton at redhat.com  Fri Dec 17 23:35:54 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Fri, 17 Dec 2004 18:35:54 -0500 (EST)
Subject: svn or arch
In-Reply-To: <20041217233140.29820.qmail@web8506.mail.in.yahoo.com>
References: <20041217233140.29820.qmail@web8506.mail.in.yahoo.com>
Message-ID: <Pine.LNX.4.61.0412171833570.24065@alien.devel.redhat.com>

On Fri, 17 Dec 2004, Rahul Sundaram wrote:

> would srpms still be provided on the test/final
> releases for convenience inorder to be able to do
> customisations without pulling stuff from the fedora
> cvs. the external contributors would probably like to
> generate them automatically for other releases

Yes, the availability of the CVS tree should not interefer with the way we 
have been releasing the test releases, or the rawhide trees for that 
matter.

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From enrico.scholz at informatik.tu-chemnitz.de  Fri Dec 17 23:40:24 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 18 Dec 2004 00:40:24 +0100
Subject: svn or arch
In-Reply-To: <1103317935.12552.117.camel@nexus.verbum.private> (Colin
	Walters's message of "Fri, 17 Dec 2004 16:12:15 -0500")
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
Message-ID: <87sm641ok7.fsf@kosh.ultra.csn.tu-chemnitz.de>

walters at redhat.com (Colin Walters) writes:

> Yes; but you still have the rpm revision number.  I am arguing for its
> removal entirely.

How will you workaround non-numeric versions which would break rpmvercmp()
without manual revisions?



Enrico



From fedora at wir-sind-cool.org  Fri Dec 17 23:41:30 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 18 Dec 2004 00:41:30 +0100
Subject: buildrequires (was: svn or arch)
In-Reply-To: <200412180007.56739.dries@ulyssis.org>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<200412172336.21200.dries@ulyssis.org>
	<Pine.LNX.4.61.0412171746560.24065@alien.devel.redhat.com>
	<200412180007.56739.dries@ulyssis.org>
Message-ID: <20041218004130.3d074014.fedora@wir-sind-cool.org>

On Sat, 18 Dec 2004 00:07:56 +0100, Dries Verachtert wrote:

> On Friday 17 December 2004 23:52, Cristian Gafton wrote:
> > On Fri, 17 Dec 2004, Dries Verachtert wrote:
> 
> > > An example: is gcc-c++ installed by default or should it be included in
> > > the BuildRequires of each c++ program?
> >
> > No, the development tools like compilers, make, autconf are assumed to be
> > available. I realize that the @development-tools group might be broad for
> > some tastes; later on we'll look at eventually reducing the scope further
> > of what is assumed to be in the buildroot; for now that is a relativey
> > sane and safe compromise, I think.
> 
> Thank you very much for the information! Although i must confess i'm used to 
> mach which doesn't install that much packages automatically within a 
> buildroot, i think it's great there is (or will be) some standard endorsed by 
> Red Hat which will be used by Fedora Core and Fedora Extras and maybe also by 
> others like maybe Fedora Legacy.. this will make it easier to transfer a spec 
> file from Fedora Core to Fedora Extras i guess. 

In the meantime, give the fedora-rmdevelrpms tool a try:

  http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires

It's included in the fedora-develrpms package. It finds and uninstalls
a lot of development packages automatically, but at the same depends
on a minimal set of other development packages which stay installed.

It's a good start, although depending on what you have installed, you
may see that it fails to uninstall gettext and m4 and any of their
dependencies.



From rahulsundaram at yahoo.co.in  Fri Dec 17 23:42:24 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 15:42:24 -0800 (PST)
Subject: fedoraproject.org
Message-ID: <20041217234224.73309.qmail@web8501.mail.in.yahoo.com>

Hi

Is fedoraproject.org going to be the new home page for
fedora instead of fedora.redhat.com. whats the current
plan regarding managing that website. I would like to
lin to "community" websites like fedoratracker.org
fedoranews.org fedorafaq.org fedoraforum.org and so on

I would enjoy something like redhat magazine
specifically targetted just for fedora or is that too
much of a niche?

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 



From walters at redhat.com  Fri Dec 17 23:44:53 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 18:44:53 -0500
Subject: svn or arch
In-Reply-To: <87wtvg1p2m.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<1103319515.12552.125.camel@nexus.verbum.private>
	<87wtvg1p2m.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103327093.12552.142.camel@nexus.verbum.private>

On Sat, 2004-12-18 at 00:29 +0100, Enrico Scholz wrote:
> walters at redhat.com (Colin Walters) writes:
> 
> > One thing that should be clear is that by using a revision control
> > system for RPM packaging, we've already conceptually broken
> > compatibility because the SRPM is no longer the preferred form of
> > modification, to use the GPL terminology.
> 
> CVS can not replace SRPM:

Note that I was talking about prerequisites for changing to a better
revision control system, not how our current system is flawed.  But I'll
answer anyways:

> - SRPM can be signed, CVS not

Right; this is solved directly in pretty much all the distributed RCSes.

> - SRPM are (usually) working, while the CVS checkout might be a completely
>   broken development snapshot

You wouldn't check out CVS HEAD; you'd check out a branch tag
corresponding to a particluar NVR.

> - SRPM give you reproducibility, CVS not

Not true if you can map NVR->CVS tag.

> - SRPM can be better accessed (e.g. in a browsable http/ftp listing);

ViewCVS solves this, I think.  And e.g. Arch includes tools to browse
the repository in the client.

>   for CVS you need tags which are more difficultly to handle

Sure.

> - SRPM are buildable with system-tools (rpmbuild); for CVS you need lots
>   of prerequisites.

Not necessarily.  We could just stick the necessary scripts in the
common/ dir or whatever.  Or just include the necessary tools in an
updated rpmbuild.

> (- a known CVS drawback: cvs checkin/checkout is not atomic)

checkin is unrelated to this discussion, and checkout is solved because
you check out a tag.




From walters at redhat.com  Fri Dec 17 23:51:22 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 18:51:22 -0500
Subject: svn or arch
In-Reply-To: <87sm641ok7.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
	<87sm641ok7.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103327483.12552.151.camel@nexus.verbum.private>

On Sat, 2004-12-18 at 00:40 +0100, Enrico Scholz wrote:
> walters at redhat.com (Colin Walters) writes:
> 
> > Yes; but you still have the rpm revision number.  I am arguing for its
> > removal entirely.
> 
> How will you workaround non-numeric versions which would break rpmvercmp()
> without manual revisions?

Perhaps the spec file could provide a little python function to fix
upstream versions.  Or you have an override file.  Or (preferably) you
get upstream to name their versions sanely.






From walters at redhat.com  Fri Dec 17 23:53:14 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 18:53:14 -0500
Subject: svn or arch
In-Reply-To: <200412172355.17027.dries@ulyssis.org>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
Message-ID: <1103327594.12552.155.camel@nexus.verbum.private>

On Fri, 2004-12-17 at 23:55 +0100, Dries Verachtert wrote:

> Do you mean the Release tag or the Version-Release of a spec file with 'the 
> rpm revision number'?

I mean the Release and Version tags.

> If i'm correct, you suggest to remove the release or the version-release  
> completely from the spec file.. this would make it impossible to build the 
> spec file with a 'rpmbuild -ba bla.spec'. 

Indeed.  You would need to specify something like this:

rpmbuild -ba --version '1.2-4' bla.spec

Longer term, I think what we really want is a better way to branch
packages and maintain them, and to sync with the upstream packager.  So
if you wanted to customize say the Fedora httpd RPM, you'd create your
own build database, etc.  This would require a distributed RCS too.

> What about adding default tags like  
> 'Release: 1' which gets replaced by the build system of Fedora Extras?

That could work I guess, but then people might be tempted to bump the
Release tag.  Better to just have people specify it at build time I
think and remove that temptation.

> Such tags can be changed by the Fedora Extras buildsystem before it starts a 
> rebuild of a spec file, no?  I'm also doing something like that with my 
> self-made mini buildsystem: the last commit revision of that spec file is 
> added automatically to the first changelog entry.

Yeah, that screws merging.  Better to just dump the changelog from the
spec.

> This makes it possible to check automatically which spec files are already 
> built for a certain distro/arch and which are not because i can compare the 
> svncmtid of the binary rpms with the current version of a spec file in the  
> subversion repository. 

I think you're abusing the revision control system as a generic
database; better to use a real SQL database for this.  Then you can add
additional metadata such as which package versions pass test suites, are
released for which distributions, etc.






From abo at kth.se  Sat Dec 18 00:09:57 2004
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 18 Dec 2004 01:09:57 +0100
Subject: FreeTDS
In-Reply-To: <20041218001738.519de929.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de>
	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
	<41C32946.9090605@coolspot.de> <41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
Message-ID: <1103328597.29652.12.camel@tudor.e.kth.se>

l?r 2004-12-18 klockan 00:17 +0100 skrev Michael Schwendt:

> > %{_libdir}/libct.so*
> 
> Files with such non-unique names will likely cause conflicts in
> %_libdir in the future, when more and more packages share that
> directory and more projects use similar short names. This topic will
> come back in the near future as it will be necessary more often to
> install such libraries into %_libdir/%name/ and add that path to the
> run-time linker's search path list.

But if a lib needs to be in a directory in the run-time search path then
it will eventually be part of a conflict anyway, won't it?

Just make sure the users of the library (programs and other libs) has
the complete pathname (%_libdir/%name/libct.so.?) hardcoded in the
binaries.

/abo




From rjune at bravegnuworld.com  Sat Dec 18 00:29:55 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Fri, 17 Dec 2004 19:29:55 -0500
Subject: FreeTDS
In-Reply-To: <20041218001738.519de929.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de> <41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
Message-ID: <200412171929.58361.rjune@bravegnuworld.com>

> Other packaging mistakes after a brief look. In random order:
>
>  * Main package must not contain files %_libdir/*.so
>    All these belong into the -devel package. Same applies to the
>    -unixodbc sub package. It must not include %_libdir/*.so either.
>    These files are needed at build-time only.
Uhm, please, correct me if I'm wrong, but I thought *.so files were shared 
objects required by the binary, as such, shouldn't they be in the main or a 
libs package, rather than a devel package? I thought .a files went in the 
devel package.
-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041217/824c922d/attachment.sig>

From balay at fastmail.fm  Sat Dec 18 00:30:02 2004
From: balay at fastmail.fm (Satish Balay)
Date: Fri, 17 Dec 2004 18:30:02 -0600 (CST)
Subject: svn or arch
In-Reply-To: <1103327594.12552.155.camel@nexus.verbum.private>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
Message-ID: <Pine.LNX.4.61.0412171818290.14188@asterix>

On Fri, 17 Dec 2004, Colin Walters wrote:

> On Fri, 2004-12-17 at 23:55 +0100, Dries Verachtert wrote:
> 
> > Do you mean the Release tag or the Version-Release of a spec file with 'the 
> > rpm revision number'?
> 
> I mean the Release and Version tags.
> 
> > If i'm correct, you suggest to remove the release or the version-release  
> > completely from the spec file.. this would make it impossible to build the 
> > spec file with a 'rpmbuild -ba bla.spec'. 
> 
> Indeed.  You would need to specify something like this:
> 
> rpmbuild -ba --version '1.2-4' bla.spec

I would sugest 'rpmbuild --rebuild bla.src.rpm' should work for
users. i.e 'bla.spec' that gets into 'bla.src.rpm' should be a
generated file based on all the data that can be automatically pulled
from external sources.
- version number
- changelog
- macro expansions etc..

I guess the tool that does this could be 'rpmbuild' or something else
(whatever is a convenient model for the packagers).

Satish



From walters at redhat.com  Sat Dec 18 00:33:43 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 19:33:43 -0500
Subject: svn or arch
In-Reply-To: <Pine.LNX.4.61.0412171818290.14188@asterix>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
	<Pine.LNX.4.61.0412171818290.14188@asterix>
Message-ID: <1103330023.1186.3.camel@nexus.verbum.private>

On Fri, 2004-12-17 at 18:30 -0600, Satish Balay wrote:

> I would sugest 'rpmbuild --rebuild bla.src.rpm' should work for
> users. i.e 'bla.spec' that gets into 'bla.src.rpm' should be a
> generated file based on all the data that can be automatically pulled
> from external sources.

Absolutely agreed.  The SRPM becomes a legacy format that should work
with legacy tools.




From fedora at wir-sind-cool.org  Sat Dec 18 00:50:49 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 18 Dec 2004 01:50:49 +0100
Subject: FreeTDS
In-Reply-To: <1103328597.29652.12.camel@tudor.e.kth.se>
References: <41C2E2A2.1020501@coolspot.de>
	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
	<41C32946.9090605@coolspot.de> <41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
	<1103328597.29652.12.camel@tudor.e.kth.se>
Message-ID: <20041218015049.1d0d5005.fedora@wir-sind-cool.org>

On Sat, 18 Dec 2004 01:09:57 +0100, Alexander Bostr?m wrote:

> l?r 2004-12-18 klockan 00:17 +0100 skrev Michael Schwendt:
> 
> > > %{_libdir}/libct.so*
> > 
> > Files with such non-unique names will likely cause conflicts in
> > %_libdir in the future, when more and more packages share that
> > directory and more projects use similar short names. This topic will
> > come back in the near future as it will be necessary more often to
> > install such libraries into %_libdir/%name/ and add that path to the
> > run-time linker's search path list.
> 
> But if a lib needs to be in a directory in the run-time search path then
> it will eventually be part of a conflict anyway, won't it?
> 
> Just make sure the users of the library (programs and other libs) has
> the complete pathname (%_libdir/%name/libct.so.?) hardcoded in the
> binaries.

Yes, RPATHs are one way to make the run-time linker load from
other directories.




From fedora at wir-sind-cool.org  Sat Dec 18 00:51:38 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 18 Dec 2004 01:51:38 +0100
Subject: FreeTDS
In-Reply-To: <200412171929.58361.rjune@bravegnuworld.com>
References: <41C2E2A2.1020501@coolspot.de> <41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
	<200412171929.58361.rjune@bravegnuworld.com>
Message-ID: <20041218015138.3e4d0e6a.fedora@wir-sind-cool.org>

On Fri, 17 Dec 2004 19:29:55 -0500, Richard June wrote:

> > Other packaging mistakes after a brief look. In random order:
> >
> >  * Main package must not contain files %_libdir/*.so
> >    All these belong into the -devel package. Same applies to the
> >    -unixodbc sub package. It must not include %_libdir/*.so either.
> >    These files are needed at build-time only.
>
> Uhm, please, correct me if I'm wrong, but I thought *.so files were shared 
> objects required by the binary, as such, shouldn't they be in the main or a 
> libs package, rather than a devel package? I thought .a files went in the 
> devel package.

*.so files usually are softlinks, which point to the actual library, so
the compile-time linker finds a library with -lfoo (where "foo" is the
library SONAME). *.so links are needed at compile-time only and point
to the specific version which you want to compile/link with.

Most likely you mean the versioned shared objects of the form *.so.*,
e.g. libfoo.so.2 or libfoo.so.2.1.4. Those are an application's
actual run-time dependencies.

There are probably only two exceptions when an application wants *.so
named files at run-time. (A) The library version is included in the
library SONAME, e.g. libfoo-1.0.so, and hence the application depends
on the specific libfoo-1.0.so. (B) The application dlopen's a shared
object named *.so at run-time. That's an application bug. It should
dlopen a specific API version *.so.* instead.



From enrico.scholz at informatik.tu-chemnitz.de  Sat Dec 18 01:11:05 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 18 Dec 2004 02:11:05 +0100
Subject: svn or arch
In-Reply-To: <1103327093.12552.142.camel@nexus.verbum.private> (Colin
	Walters's message of "Fri, 17 Dec 2004 18:44:53 -0500")
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<1103319515.12552.125.camel@nexus.verbum.private>
	<87wtvg1p2m.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1103327093.12552.142.camel@nexus.verbum.private>
Message-ID: <87oegs1kd2.fsf@kosh.ultra.csn.tu-chemnitz.de>

walters at redhat.com (Colin Walters) writes:

>> CVS can not replace SRPM:
>
> Note that I was talking about prerequisites for changing to a better
> revision control system, not how our current system is flawed.  But I'll
> answer anyways:
>
>> - SRPM can be signed, CVS not
>
> Right; this is solved directly in pretty much all the distributed
> RCSes.

How? Signing the data-transfer can not be compared with SRPM signing. The
on-disk data could be changed but the data-stream would be still valid.


>> - SRPM give you reproducibility, CVS not
>
> Not true if you can map NVR->CVS tag.

You do not know if somebody renamed the tag between two checkouts.


>> - SRPM are buildable with system-tools (rpmbuild); for CVS you need lots
>>   of prerequisites.
>
> Not necessarily.  We could just stick the necessary scripts in the
> common/ dir or whatever.  Or just include the necessary tools in an
> updated rpmbuild.

You will still need online-access. SRPMS can be used offline.



Enrico



From enrico.scholz at informatik.tu-chemnitz.de  Sat Dec 18 01:14:33 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 18 Dec 2004 02:14:33 +0100
Subject: svn or arch
In-Reply-To: <1103327483.12552.151.camel@nexus.verbum.private> (Colin
	Walters's message of "Fri, 17 Dec 2004 18:51:22 -0500")
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
	<87sm641ok7.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1103327483.12552.151.camel@nexus.verbum.private>
Message-ID: <87k6rg1k7a.fsf@kosh.ultra.csn.tu-chemnitz.de>

walters at redhat.com (Colin Walters) writes:

>> > Yes; but you still have the rpm revision number.  I am arguing for its
>> > removal entirely.
>> 
>> How will you workaround non-numeric versions which would break rpmvercmp()
>> without manual revisions?
>
> Perhaps the spec file could provide a little python function to fix
> upstream versions.

How do you fix '2.6.9-rc1'?


> Or you have an override file.

What is that?


> Or (preferably) you get upstream to name their versions sanely.

Hahaha... that's a good one... I will ask Linus to use sane version
numbers. ;)




Enrico



From walters at redhat.com  Sat Dec 18 02:03:22 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 21:03:22 -0500
Subject: svn or arch
In-Reply-To: <87oegs1kd2.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<1103319515.12552.125.camel@nexus.verbum.private>
	<87wtvg1p2m.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1103327093.12552.142.camel@nexus.verbum.private>
	<87oegs1kd2.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103335402.1186.9.camel@nexus.verbum.private>

On Sat, 2004-12-18 at 02:11 +0100, Enrico Scholz wrote:

> How? Signing the data-transfer can not be compared with SRPM signing.

In Arch for example, each individual changeset is signed with a GPG
signature.  What is the threat that SRPM signing solves that Arch
changeset signing doesn't?

> >> - SRPM give you reproducibility, CVS not
> >
> > Not true if you can map NVR->CVS tag.
> 
> You do not know if somebody renamed the tag between two checkouts.

This is a CVS flaw, to be sure.  But moving a tag should never happen;
we'd build a bit of intelligence into our tools to double-check this.

> >> - SRPM are buildable with system-tools (rpmbuild); for CVS you need lots
> >>   of prerequisites.
> >
> > Not necessarily.  We could just stick the necessary scripts in the
> > common/ dir or whatever.  Or just include the necessary tools in an
> > updated rpmbuild.
> 
> You will still need online-access. 

No, you don't.  You do a CVS checkout, and then build on your local
machine.  How is that different from SRPM?




From avibrazil at gmail.com  Sat Dec 18 02:04:36 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Fri, 17 Dec 2004 23:04:36 -0300
Subject: Choice of default fonts in webrowsers
In-Reply-To: <1103314434.2737.13.camel@kyrre>
References: <20041216221157.72779.qmail@web8509.mail.in.yahoo.com>
	<1103235683.12071.5.camel@rousalka.dyndns.org>
	<1103314434.2737.13.camel@kyrre>
Message-ID: <ed0efd31041217180479060470@mail.gmail.com>

This stuff is going to be published on TLDP soon as the new unified Font-HOWTO:

http://avi.alkalay.net/linux/docs/font-howto

I'm just waiting for some revisions.

Regards,
Avi


On Fri, 17 Dec 2004 21:13:54 +0100, Kyrre Ness Sjobak
<kyrre at solution-forge.net> wrote:
> tor, 16.12.2004 kl. 23.21 skrev Nicolas Mailhot:
> > Le jeudi 16 d?cembre 2004 ? 14:11 -0800, Rahul Sundaram a ?crit :
> > > Hi
> > >
> > >
> > > >
> > > > Why is it so? Why is those fonts, which it seem like
> > > > "everyone" thinks
> > > > are really ugly are used, when better fonts are
> > > > shipped?
> > >
> > >
> > > I have heard before that this is because the default
> > > fonts should be internationalised or something like
> > > that which bitstream fonts arent
> >
> > It might be worth taking a new look now that the deja variant of vera is
> > announcing new glyphs every other months. Of course we're far from full
> > unicode coverage, but fontconfig will fall back on Luxi if needed, so...
> 
> Would that mean that if we used the nice fonts as default, everyone
> wanting to read a document with common glyphs would have no problem
> reading it (both glyphwise and readabilitywise) - and those who has a
> doc with less common glyphs, would get a mix? Or will the get only "old"
> glyps in those docs? So for those who uses common glyphs, it will be a
> good thing, and it won't hurt those who use less common glyps?
> 
> What are we waiting for?
> 
> Kyrre
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From walters at redhat.com  Sat Dec 18 02:09:32 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 17 Dec 2004 21:09:32 -0500
Subject: svn or arch
In-Reply-To: <87k6rg1k7a.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
	<87sm641ok7.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1103327483.12552.151.camel@nexus.verbum.private>
	<87k6rg1k7a.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103335772.1186.16.camel@nexus.verbum.private>

On Sat, 2004-12-18 at 02:14 +0100, Enrico Scholz wrote:
> walters at redhat.com (Colin Walters) writes:
> 
> >> > Yes; but you still have the rpm revision number.  I am arguing for its
> >> > removal entirely.
> >> 
> >> How will you workaround non-numeric versions which would break rpmvercmp()
> >> without manual revisions?
> >
> > Perhaps the spec file could provide a little python function to fix
> > upstream versions.
> 
> How do you fix '2.6.9-rc1'?

However the kernel packagers fix it now.  I don't know how they do it,
but it could include:

1) Don't package -rc, backport changesets instead
2) Convert it to e.g. 2.6.8.999rc1
3) Fix RPM to have an prerelease character which sorts
   lower than even nothing; Debian uses '~' for this purpose, so you
   could use 2.6.9~rc1 which is earlier than 2.6.9

> > Or you have an override file.
> 
> What is that?

An explicit mapping from upstream versions to RPM versions, like:

2.6.9-rc1 2.6.8.99rc1

Or maybe it could use regular expressions.

> > Or (preferably) you get upstream to name their versions sanely.
> 
> Hahaha... that's a good one... I will ask Linus to use sane version
> numbers. ;)

Why don't you?  He seems to choose versions rather randomly; IIRC there
were a number of people upset when he suddenly decided to release a
version with 4 components.  I don't think it's unrealistic at all to ask
him to use version numbers which are compatible with RPM and dpkg.




From rahulsundaram at yahoo.co.in  Sat Dec 18 02:17:30 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 18:17:30 -0800 (PST)
Subject: Choice of default fonts in webrowsers
In-Reply-To: <ed0efd31041217180479060470@mail.gmail.com>
Message-ID: <20041218021730.31097.qmail@web8510.mail.in.yahoo.com>


--- Avi Alkalay <avibrazil at gmail.com> wrote:

> This stuff is going to be published on TLDP soon as
> the new unified Font-HOWTO:
> 
> http://avi.alkalay.net/linux/docs/font-howto
> 
> I'm just waiting for some revisions.
> 

since you havent yet proposed it to the tldp list it
is wrong for you to claim that its going to be
*published*



=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



From avibrazil at gmail.com  Sat Dec 18 02:43:12 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Fri, 17 Dec 2004 23:43:12 -0300
Subject: Choice of default fonts in webrowsers
In-Reply-To: <20041218021730.31097.qmail@web8510.mail.in.yahoo.com>
References: <ed0efd31041217180479060470@mail.gmail.com>
	<20041218021730.31097.qmail@web8510.mail.in.yahoo.com>
Message-ID: <ed0efd3104121718432f58c51d@mail.gmail.com>

It is a teamwork between the authors of the two former font-related
howtos and me. We all agreed that they are outdated now, and that this
one will substitude both.
I have 2 more HOWTOs with other subjects published in TLDP and a good
relationship with the "institution". I don't see a reason to not
publish it.

Do you see any reason ?

Thank you,
Avi

On Fri, 17 Dec 2004 18:17:30 -0800 (PST), Rahul Sundaram
<rahulsundaram at yahoo.co.in> wrote:
> 
> --- Avi Alkalay <avibrazil at gmail.com> wrote:
> 
> > This stuff is going to be published on TLDP soon as
> > the new unified Font-HOWTO:
> >
> > http://avi.alkalay.net/linux/docs/font-howto
> >
> > I'm just waiting for some revisions.
> >
> 
> since you havent yet proposed it to the tldp list it
> is wrong for you to claim that its going to be
> *published*
> 
> =====
> Regards
> Rahul Sundaram
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
>



From rahulsundaram at yahoo.co.in  Sat Dec 18 03:14:43 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Fri, 17 Dec 2004 19:14:43 -0800 (PST)
Subject: Choice of default fonts in webrowsers
In-Reply-To: <ed0efd3104121718432f58c51d@mail.gmail.com>
Message-ID: <20041218031443.93702.qmail@web8501.mail.in.yahoo.com>


Hi

> I have 2 more HOWTOs with other subjects published
> in TLDP and a good
> relationship with the "institution". I don't see a
> reason to not
> publish it.

As as TLDP volunteer I am aware that you have a couple
of docs there. you should be aware that not all docs
proposed are accepted. We have a review process setup
that every document should go through before its
decided to include it in the collection.

A cursory look at the document suggests that it looks
acceptable but you can never claim that it will get
published authoritatively.

Recently the review process itself was stagnated when
Tabatha, the current review coordinator became busy
with other works and ESR (who claims have contributed
the largest amount of docs ) was unable to get through
this, thou it wasnt his fault so its not necessarily
something to do with poor howtos or such

I suggest that you propose the document and collect
peer feedback from the discussion list as early as
possible anyway


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From nando at ccrma.Stanford.EDU  Sat Dec 18 03:14:48 2004
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: 17 Dec 2004 19:14:48 -0800
Subject: fedora-d-rh] Re: Fedora Extras, Fedora Core CVS Open!
In-Reply-To: <604aa79104121623586965471f@mail.gmail.com>
References: <20041217015158.31215.qmail@web8506.mail.in.yahoo.com>
	<Pine.LNX.4.61.0412170332290.921@horsea.3ti.be>
	<604aa79104121619495f4b1063@mail.gmail.com>
	<Pine.LNX.4.61.0412170503080.921@horsea.3ti.be>
	<604aa79104121621023f851b2c@mail.gmail.com>
	<Pine.LNX.4.61.0412170135060.16741@swampfox.owlriver.com>
	<604aa7910412162305decff0@mail.gmail.com>
	<Pine.LNX.4.61.0412170220080.27891@swampfox.owlriver.com>
	<604aa79104121623586965471f@mail.gmail.com>
Message-ID: <1103339688.31391.1195.camel@cmn37.stanford.edu>

On Thu, 2004-12-16 at 23:58, Jeff Spaleta wrote:
> On Fri, 17 Dec 2004 02:26:20 -0500 (EST), R P Herrold
> <herrold at owlriver.com> wrote:
> > Bottom line: no buildsystem -- not yet a fair question to
> > expect a yes or no on.
> 
> ...  I want every packager
> who has been vocal about the flaws in the fedora.us process to stand
> up and pledge they will atleast attempt to work inside the new process
> contributing atleast ONE package as soon as its possible, instead of
> waiting for the system to be perfect.

I'd be interested in starting to contribute and see how the process
works...
  (stuff from http://ccrma.stanford.edu/planetccrma/software/)
-- Fernando




From joelonlinux at optonline.net  Sat Dec 18 06:05:40 2004
From: joelonlinux at optonline.net (Joel Rittvo)
Date: Sat, 18 Dec 2004 01:05:40 -0500
Subject: rawhide report: 20041217 changes
In-Reply-To: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
Message-ID: <41C3C8B4.7040905@optonline.net>

Build System wrote:
>  
> Updated Packages:
> 
> cups-1:1.1.22-5
> ---------------
> * Thu Dec 16 2004 Tim Waugh <twaugh at redhat.com> 1.1.22-5
> - Fixed STR #1023 (part of bug #143086).
> - Fixed STR #1024 (rest of bug #143086).

I subscribe to both the fedora-devel-list and the fedora-test-list, and 
as far as I can tell, these Build System Reports only go out to the 
developer list.  Shouldn't it be going to the test list as well?  How 
else is a tester going to know about the release of a new package?  Most 
of us probably only update what we already have, and are clueless that 
something new was introduced into Rawhide.  When NetworkManager came 
out, I would not have known about that from just the test list for 
weeks.  Not a very good way to get things tested promptly . . . . .

Joel Rittvo



From ville.skytta at iki.fi  Sat Dec 18 08:24:14 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sat, 18 Dec 2004 10:24:14 +0200
Subject: buildrequires (was: svn or arch)
In-Reply-To: <20041218004130.3d074014.fedora@wir-sind-cool.org>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<200412172336.21200.dries@ulyssis.org>
	<Pine.LNX.4.61.0412171746560.24065@alien.devel.redhat.com>
	<200412180007.56739.dries@ulyssis.org>
	<20041218004130.3d074014.fedora@wir-sind-cool.org>
Message-ID: <1103358254.9615.1.camel@bobcat.mine.nu>

On Sat, 2004-12-18 at 00:41 +0100, Michael Schwendt wrote:

> In the meantime, give the fedora-rmdevelrpms tool a try:
> 
>   http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires
> 
> It's included in the fedora-develrpms package. It finds and uninstalls
> a lot of development packages automatically, but at the same depends
> on a minimal set of other development packages which stay installed.
> 
> It's a good start, although depending on what you have installed, you
> may see that it fails to uninstall gettext and m4 and any of their
> dependencies.

...and if that happens, customize /etc/fedora/rmdevelrpms.conf to match
your setup.



From buildsys at redhat.com  Sat Dec 18 12:27:19 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 18 Dec 2004 07:27:19 -0500
Subject: rawhide report: 20041218 changes
Message-ID: <200412181227.iBICRJw29172@porkchop.devel.redhat.com>

 

 
Updated Packages:

authconfig-4.6.8-1
------------------
* Fri Dec 17 2004 Tomas Mraz <tmraz at redhat.com>
- add option for making local authorization sufficient for local users
  this is attempt to 'solve/workaround' the problem with blocking local logins by
  pulling out network cable (#115181)

* Wed Dec 15 2004 Tomas Mraz <tmraz at redhat.com>
- remove dependency on nscd
- don't show warning messages when switching options off

cups-1:1.1.22-6
---------------
* Fri Dec 17 2004 Tim Waugh <twaugh at redhat.com> 1.1.22-6
- Use upstream patches for bug #143086.

glibc-2.3.3-97
--------------
* Fri Dec 17 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-97
- update from CVS
  - fix ppc64 getcontext and swapcontext (BZ#610)
  - sparc/sparc64 fixes

* Wed Dec 15 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-96
- update from CVS
  - fix i686 __USE_STRING_INLINES strncat
  - make sure ppc/ppc64 maintain correct stack alignment
    across clone

* Wed Dec 15 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-95
- export nis_domain_of_r from libnsl.so again which was
  unintentionally lost

gnumeric-1:1.4.1-3
------------------
* Fri Dec 17 2004 Caolan McNamara <caolanm at redhat.com> 1.4.1-3
- dubious "lib" usage from 64bit POV

* Fri Dec 17 2004 Caolan McNamara <caolanm at redhat.com> 1.4.1-2
- RH#143161# crash on reading corrupt excel file

grep-2.5.1-43
-------------
* Thu Dec 16 2004 Tim Waugh <twaugh at redhat.com> 2.5.1-43
- Bypass kwset matching when ignoring case and processing multibyte input
  (bug #143079).

kernel-2.6.9-1.1047_FC4
-----------------------
* Fri Dec 17 2004 Dave Jones <davej at redhat.com>
- Fix bio error propagation.
- Clear ebp on sysenter return.
- Extra debugging info on OOM kill.
- exit() race fix.
- Fix refcounting order in sd/sr, fixing cable pulls on USB storage.
- IGMP source filter fixes.
- Fix ext2/3 leak on umount.
- fix missing wakeup in ipc/sem
- Fix another tux corner case bug.
- NULL out ptrs in airo driver after kfree'ing them.

kudzu-1.1.104-1
---------------
* Fri Dec 17 2004 Bill Nottingham <notting at redhat.com> - 1.1.104-1
- don't configure/unconfigure printers
- don't probe serial bus by default in /usr/sbin/kudzu
- remove the UI - run without user interaction

namazu-2.0.14-1
---------------
* Fri Dec 17 2004 Akira TAGOH <tagoh at redhat.com> - 2.0.14-1
- Security fix release.
  http://namazu.org/security.html

nmap-2:3.78-1
-------------
* Fri Dec 17 2004 Harald Hoyer <harald at redhat.com> - 2:3.78-1
- version 3.78

procinfo-18-14
--------------
* Fri Dec 17 2004 Karel Zak <kzak at redhat.com> 18-14
- fixed limit of devices (#89176)

rpmdb-fedora-1:4-0.20041218
---------------------------

samba-0:3.0.10-2
----------------
* Fri Dec 17 2004 Jay Fenlason <fenlason at redhat.com> 3.0.10-2
- New upstream release that closes CAN-2004-1154  bz#142544
- Include the -64bit patch from Nalin.  This closes bz#142873
- Update the -logfiles patch to work with 3.0.10
- Create /var/run/winbindd and make it part of the -common rpm to close
  bz#142242

selinux-policy-strict-1.19.14-3
-------------------------------
* Fri Dec 17 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-3
- Fixes for ldconfig in targeted policy

selinux-policy-targeted-1.19.14-3
---------------------------------
* Fri Dec 17 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-3
- Fixes for ldconfig in targeted policy
- Add lots of new targeted policy

* Thu Dec 16 2004 Dan Walsh <dwalsh at redhat.com> 1.19-14-2
- Changes to increase the number of daemons in targeted policy

sendmail-8.13.2-1
-----------------
* Fri Dec 17 2004 Thomas Woerner <twoerner at redhat.com> 8.13.2-1
- new version 8.13.2
- thanks to Robert Scheck for adapting the patches

xorg-x11-6.8.1-25
-----------------
* Sat Dec 18 2004 Mike A. Harris <mharris at redhat.com> 6.8.1-25
- Tag CVS head of latest changes, to update to 6.8.2rc1 (6.8.1.901) for the
  next commit

* Mon Dec 13 2004 Kristian H??gsberg <krh at redhat.com>
- Rename xorg-x11.conf to xorg-x11-x86_64.conf so it works on
  multilib systems.



From rjune at bravegnuworld.com  Sat Dec 18 13:34:48 2004
From: rjune at bravegnuworld.com (Richard June)
Date: Sat, 18 Dec 2004 08:34:48 -0500
Subject: FreeTDS
In-Reply-To: <20041218015138.3e4d0e6a.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de>
	<200412171929.58361.rjune@bravegnuworld.com>
	<20041218015138.3e4d0e6a.fedora@wir-sind-cool.org>
Message-ID: <200412180835.00253.rjune@bravegnuworld.com>

> *.so files usually are softlinks, which point to the actual library, so
> the compile-time linker finds a library with -lfoo (where "foo" is the
> library SONAME). *.so links are needed at compile-time only and point
> to the specific version which you want to compile/link with.
ok, I'm with you so far, but I thought ldconfig would create the symlinks
-- 
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041218/e1ba0093/attachment.sig>

From fedora at wir-sind-cool.org  Sat Dec 18 14:07:54 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 18 Dec 2004 15:07:54 +0100
Subject: FreeTDS
In-Reply-To: <200412180835.00253.rjune@bravegnuworld.com>
References: <41C2E2A2.1020501@coolspot.de>
	<200412171929.58361.rjune@bravegnuworld.com>
	<20041218015138.3e4d0e6a.fedora@wir-sind-cool.org>
	<200412180835.00253.rjune@bravegnuworld.com>
Message-ID: <20041218150754.74f9c5bf.fedora@wir-sind-cool.org>

On Sat, 18 Dec 2004 08:34:48 -0500, Richard June wrote:

> > *.so files usually are softlinks, which point to the actual library, so
> > the compile-time linker finds a library with -lfoo (where "foo" is the
> > library SONAME). *.so links are needed at compile-time only and point
> > to the specific version which you want to compile/link with.
>
> ok, I'm with you so far, but I thought ldconfig would create the symlinks

Not the *.so links.



From dries at ulyssis.org  Sat Dec 18 16:09:42 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Sat, 18 Dec 2004 17:09:42 +0100
Subject: buildrequires (was: svn or arch)
In-Reply-To: <20041218004130.3d074014.fedora@wir-sind-cool.org>
References: <20041217215837.61548.qmail@web8501.mail.in.yahoo.com>
	<200412180007.56739.dries@ulyssis.org>
	<20041218004130.3d074014.fedora@wir-sind-cool.org>
Message-ID: <200412181709.42393.dries@ulyssis.org>

On Saturday 18 December 2004 00:41, Michael Schwendt wrote:
>
> In the meantime, give the fedora-rmdevelrpms tool a try:
>
>   http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires

I'm using a slightly modified mach which seems to be described on that page as 
a better way for checking for buildrequirements.

> It's included in the fedora-develrpms package. It finds and uninstalls
> a lot of development packages automatically, but at the same depends
> on a minimal set of other development packages which stay installed.
>
> It's a good start, although depending on what you have installed, you
> may see that it fails to uninstall gettext and m4 and any of their
> dependencies.

I tryed it but it indeed can't uninstall some stuff. I also can't use this 
regularly on my laptop because i use my laptop for my work.. i need a lot of 
those packages installed all the time.

The list given by Cristian Gafton contains quite a lot more.. ( 'base' and 
'development-tools' from the comps.xml file). For example it contains already 
m4, bison, automake, flex and 40 -devel packages.   

The full list of packages of a base fc3 machroot + yum + comps + the groups 
base and development tools follows.

kind regards,
Dries Verachtert

tzdata termcap e2fsprogs gawk fedora-release psmisc libacl libstdc++ 
util-linux hwdata less readline procps mingetty pam openssl beecrypt rpm yum 
libselinux expat fontconfig diffutils hesiod zlib-devel lockdev audiofile 
rhpl kudzu bluez-libs cups-libs shared-mime-info logrotate syslinux time 
openssl-devel boost guile esound redhat-menus pyOpenSSL libstdc++-devel mailx 
wireless-tools libattr-devel mkbootdisk dump boost-devel netdump 
bluez-hcidump diskdumputils authconfig netconfig nss_db expat-devel 
python-devel lftp mgetty nano bluez-bluefw texinfo talk telnetcdecl pam_krb5 
eject rsh pkgconfig rcs cryptsetup doxygen finger man-pages tmpwatch 
xorg-x11-libs libbonobo libgnome libbonoboui perl-XML-NamespaceSupport 
ypbindlibgnomeui ppp cups gcc valgrind perl-libwww-perl aspell-en 
perl-XML-Encoding setools NetworkManager memprof 
system-config-securitylevel-tui selinux-policy-targeted acpid ipsec-tools 
ncurses-devel cvs logwatch passwd cyrus-sasl-devel up2date redhat-lsb 
system-config-network-tui setup basesystem glibc-common glibc libtermcap 
ncurses info pcre sed iputils iproute libattr cracklib cracklib-dicts db4 
poptcpio MAKEDEV usbutils udev gzip device-mapper lvm2 mkinitrd libsepol 
ethtool net-tools coreutils krb5-libs openssh openssh-server bzip2-libs 
rpm-libs elfutils gmp python comps bash libxml2 atk dbus freetype libart_lgpl 
dbus-glib make libpng libgpg-error newt libgcrypt libtiff nscd bzip2 patch 
pyxf86config libogg hal libusb zip libogg-devel slang-devel xmlsec1 utempter 
libxml2-python vim-minimal at mtools gpm gettext hotplug krb5-devel groff 
procmail cpp umb-scheme libidn alsa-lib howl desktop-file-utils htmlview 
ORBit2 rhnlib rmt libtool-libs libwvstreams bind-libs checkpolicy 
fedora-logos dosfstools pciutils-devel libacl-devel grub krbafs-devel pinfo 
swig anacron sudo xmlsec1-openssl libvorbis-devel bluez-utils libcap-devel 
irda-utils readline-devel minicom libxml2-devel setuptool hesiod-devel 
stunnel dbus-devel slocate rpm-devel gdb psacct unzip pdksh cscope ed wget 
gmp-develsysreport jwhois nc tcsh hdparm lha audit dos2unix pax diffstat 
pam_passwdqc rdist db4-utils mtr unix2dos statserial specspo lsof ltrace 
dmraid pam_smb pam_ccreds mt-st rootfiles symlinks lrzsz ftp setserial attr 
flex perl kernel pango GConf2gnome-vfs2 libgnomecanvas autoconf automake17 
libgcj portmap perl-XML-SAX xorg-x11-Mesa-libGL libgcj-devel gnome-keyring qt 
libpcap dhclient xinetd glibc-kernheaders glibc-devel policycoreutils 
perl-XML-LibXML-Common perl-Convert-ASN1 perl-HTML-Parser perl-XML-Parser 
perl-Filter perl-XML-Grove perl-XML-Twig perl-LDAP perl-XML-LibXML gcc-g77 
gcc-java wvdial oprofile libtool iptstate automake16 vconfig quota tcpdump 
kernel-utils dhcpv6_client isdn4k-utils patchutils numactl fbset 
redhat-rpm-config perl-Crypt-SSLeay cyrus-sasl libuser usermode gnupg 
nss_ldap python-ldap kbd autofs cyrus-sasl-plain openldap-devel libuser-devel 
filesystem libgcc mktemp zlib grep chkconfig findutils words glib2 kernel tar 
SysVinit sysklogd module-init-tools tcp_wrappers elfutils-libelf gdbm 
rpm-python strace shadow-utilslibjpeg m4 binutils slang libxslt 
libtermcap-devel glib libcap file libvorbis libmng openssh-clients bc 
crontabs e2fsprogs-devel man gamin curl howl-libs libIDL gnome-mime-data 
krbafs libf2c rsync kudzu-devel bind-utils curl-devel gpm-devel newt-devel 
libusb-devel bzip2-devel lockdev-devel ntsysv bison libselinux-devel 
krb5-workstation gdbm-devel parted ash indent dialog db4-devel setarch 
traceroute pam-devel pstack ctags schedutils byacc splint acl rdate mailcap 
crash initscriptsgtk2 libglade2 automake15 iptables perl-URI automake 
pciutils vixie-cron glibc-headers aspell perl-HTML-Tagset perl-libxml-perl 
perl-XML-Dumper valgrind-callgrind gcc-c++ rp-pppoe yp-tools prelink 
pcmcia-cs apmd automake14 rpm-build jpackage-utils openldap sendmail 
system-config-mouse mdadm nfs-utils cyrus-sasl-md5



From skvidal at phy.duke.edu  Sat Dec 18 16:13:39 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 18 Dec 2004 11:13:39 -0500
Subject: fedoraproject.org
In-Reply-To: <20041217234224.73309.qmail@web8501.mail.in.yahoo.com>
References: <20041217234224.73309.qmail@web8501.mail.in.yahoo.com>
Message-ID: <1103386419.16769.28.camel@cutter>

On Fri, 2004-12-17 at 15:42 -0800, Rahul Sundaram wrote:
> Hi
> 
> Is fedoraproject.org going to be the new home page for
> fedora instead of fedora.redhat.com. whats the current
> plan regarding managing that website. I would like to
> lin to "community" websites like fedoratracker.org
> fedoranews.org fedorafaq.org fedoraforum.org and so on
> 
> I would enjoy something like redhat magazine
> specifically targetted just for fedora or is that too
> much of a niche?

fedoraproject.org - as a name is registered by stu tomlinson.

the server is at duke. We've been using it for catchall quick one-off
directories, temp locations, clandestine transfers of pre-beta stuff,
etc etc. It's easier to put it there and give people some obscure link
than it is to wait for permission to put things up on a *.redhat.com
site. red hat has all sorts of legal/marketing concerns with  what goes
up on download.fedora.redhat.com and fedora.redhat.com. Those problems
just aren't present on the machine at duke. It's on a very reasonable
connection to the outside world. The machine, while not super-duper
fast, is pretty okay.In short, it's a good spot to put stuff at a
moments notice and we don't have to sift through the red hat legal
constraints to get a change posted.

So I setup the wiki in use at: http://fedoraproject.org/wiki. And I set
up the planet implementations at: http://fedoraproject.org/people and
http://fedoraproject.org/infofeed/. It's been used for a temp repository
for the x86_64 extras repo that Justin Forbes built. It also has the ppc
fc3 tree that Colin Charles and Paul Nasrat (among others) worked on.
It's just a place to put things quickly. At some point in the future, I
am told, there will be a box at red hat that does some of these things.
And then we'll transfer those services over, possibly the domain. But
that's not up to me. I just take care of sysadmin stuff on the machine
and try to keep it reasonably secure.

fedoraproject.org aka fedora.linux.duke.edu is just a way to let non-red
hat folks(and of course some red hat folks, too) have a place to put
things, easily, that help out misc administrivia. It's a good testing
location for certain web applications and other items.

If you're looking for fedora journalism - you might talk to Thomas Chung
over at fedoranews.org. They've done a reasonably good job at those
items. I think what you might be looking for is something like fedora
weekly news. Colin Charles was doing those excellently for a while but
he's just gotten too busy with other fedora and non-fedora work, I
think. If you're interested in starting them back up, then email him and
talk to him about what it would entail.

Thanks!
-sv




From dries at ulyssis.org  Sat Dec 18 16:12:56 2004
From: dries at ulyssis.org (Dries Verachtert)
Date: Sat, 18 Dec 2004 17:12:56 +0100
Subject: svn or arch
In-Reply-To: <1103327594.12552.155.camel@nexus.verbum.private>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
Message-ID: <200412181712.56837.dries@ulyssis.org>

On Saturday 18 December 2004 00:53, Colin Walters wrote:
> On Fri, 2004-12-17 at 23:55 +0100, Dries Verachtert wrote:

> > This makes it possible to check automatically which spec files are
> > already built for a certain distro/arch and which are not because i can
> > compare the svncmtid of the binary rpms with the current version of a
> > spec file in the subversion repository.
>
> I think you're abusing the revision control system as a generic
> database; better to use a real SQL database for this.  Then you can add
> additional metadata such as which package versions pass test suites, are
> released for which distributions, etc.

I'm using a PostgreSQL database to store all this information and also a lot 
of meta information about each rpm. 

My scripts only add the svn commit revision before a spec file is used for a 
rebuild. That modified spec file which contains the svn commit revision is 
not checked in again. It's only used for the rebuild. 

kind regards,
Dries Verachtert



From shiva at sewingwitch.com  Sat Dec 18 17:02:03 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sat, 18 Dec 2004 09:02:03 -0800
Subject: PHP vulnerability
Message-ID: <C4E21AC4872713FC7D671DEE@[10.0.0.4]>

Saw this on SlashDot:

<http://developers.slashdot.org/article.pl?sid=04/12/17/1641212>

Several bugzillas in play:

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132>
(See my comment #9 there for others)

No signs yet of a fix:

<http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/>
<http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/>
<http://download.fedora.redhat.com/pub/fedora/linux/core/development/>



From lars at homer.se  Sat Dec 18 21:51:01 2004
From: lars at homer.se (Lars E. Pettersson)
Date: Sat, 18 Dec 2004 22:51:01 +0100
Subject: firefox and icons...
Message-ID: <41C4A645.6050001@homer.se>

Just tried the rawhide firefox on my FC3 (Gnome, Bluecurve) installation 
and noticed that the icons had changed to something that resembles the 
ones used by nautilus, epiphany, etc.

Is it possible to revert this to the original firefox icons (the ones 
used by the FC3 firefox, both are 1.0-versions)? If it is possible, how 
would one do that? (Without doing the obvious, recompiling, of course.)

Why are these icons used and not the original ones?

Would it be possible to, in the themes selection, add a theme named 
"firefox original", so that two choices exist, the (what I think they 
are called) Gnome specific icons, and the original firefox icons?

I really like the original firefox icons better, than the ones used by 
nautilus, epiphany, etc.

Lars
-- 
Lars E. Pettersson <lars at homer.se>
http://www.sm6rpz.se/



From hp at redhat.com  Sat Dec 18 22:42:03 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 18 Dec 2004 17:42:03 -0500
Subject: firefox and icons...
In-Reply-To: <41C4A645.6050001@homer.se>
References: <41C4A645.6050001@homer.se>
Message-ID: <1103409723.5679.53.camel@localhost.localdomain>

Hi,

On Sat, 2004-12-18 at 22:51 +0100, Lars E. Pettersson wrote:
> Just tried the rawhide firefox on my FC3 (Gnome, Bluecurve) installation 
> and noticed that the icons had changed to something that resembles the 
> ones used by nautilus, epiphany, etc.
> 
> Is it possible to revert this to the original firefox icons (the ones 
> used by the FC3 firefox, both are 1.0-versions)? If it is possible, how 
> would one do that? (Without doing the obvious, recompiling, of course.)

I would have thought you could change the Firefox-specific application
theme in Tools->Themes in Firefox, but it looks like there's no option
there for now.

> Why are these icons used and not the original ones?

We use a consistent icon theme across the whole desktop and apps.
Application-specific theme systems are generally considered Evil.

The right fix if you like those Firefox icons would be for someone to
make a theme in that style for the whole desktop.

> Would it be possible to, in the themes selection, add a theme named 
> "firefox original", so that two choices exist, the (what I think they 
> are called) Gnome specific icons, and the original firefox icons?

Not in the global Prefs->Theme theme dialog since the firefox theme is
only a firefox theme, not a desktop theme.

Havoc




From stevelist at silverorange.com  Sat Dec 18 23:13:53 2004
From: stevelist at silverorange.com (Steven Garrity)
Date: Sat, 18 Dec 2004 19:13:53 -0400
Subject: firefox and icons...
In-Reply-To: <1103409723.5679.53.camel@localhost.localdomain>
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
Message-ID: <41C4B9B1.6010402@silverorange.com>

Havoc Pennington wrote:
> I would have thought you could change the Firefox-specific application
> theme in Tools->Themes in Firefox, but it looks like there's no option
> there for now.

No, the application icon is beyond the scope (and capability?) of the 
application's own theme.

Steven Garrity



From hp at redhat.com  Sat Dec 18 23:52:53 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 18 Dec 2004 18:52:53 -0500
Subject: firefox and icons...
In-Reply-To: <41C4B9B1.6010402@silverorange.com>
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
	<41C4B9B1.6010402@silverorange.com>
Message-ID: <1103413973.5679.73.camel@localhost.localdomain>

On Sat, 2004-12-18 at 19:13 -0400, Steven Garrity wrote:
> Havoc Pennington wrote:
> > I would have thought you could change the Firefox-specific application
> > theme in Tools->Themes in Firefox, but it looks like there's no option
> > there for now.
> 
> No, the application icon is beyond the scope (and capability?) of the 
> application's own theme.

I thought he was talking about the toolbar icons, not the icon in the
menus/launchers.

Havoc




From stevelist at silverorange.com  Sat Dec 18 23:52:37 2004
From: stevelist at silverorange.com (Steven Garrity)
Date: Sat, 18 Dec 2004 19:52:37 -0400
Subject: firefox and icons...
In-Reply-To: <1103413973.5679.73.camel@localhost.localdomain>
References: <41C4A645.6050001@homer.se>	<1103409723.5679.53.camel@localhost.localdomain>	<41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
Message-ID: <41C4C2C5.6020508@silverorange.com>

Havoc Pennington wrote:
> I thought he was talking about the toolbar icons, not the icon in the
> menus/launchers.

I see - my mistake.

If rawhide does indeed pick up the Gnome theme icons (which is great), 
then perhaps we could also ship a "Firefox Default" theme with the 
default (windows) theme icons.

Steven Garrity



From carlos.efr at mail.telepac.pt  Sun Dec 19 01:08:09 2004
From: carlos.efr at mail.telepac.pt (Carlos Rodrigues)
Date: Sun, 19 Dec 2004 01:08:09 +0000
Subject: firefox and icons...
In-Reply-To: <41C4A645.6050001@homer.se>
References: <41C4A645.6050001@homer.se>
Message-ID: <41C4D479.1030906@mail.telepac.pt>

Lars E. Pettersson wrote:
> Just tried the rawhide firefox on my FC3 (Gnome, Bluecurve) installation 
> and noticed that the icons had changed to something that resembles the 
> ones used by nautilus, epiphany, etc.
> 
> Is it possible to revert this to the original firefox icons (the ones 
> used by the FC3 firefox, both are 1.0-versions)? If it is possible, how 
> would one do that? (Without doing the obvious, recompiling, of course.)
> 
> Why are these icons used and not the original ones?
> 
> Would it be possible to, in the themes selection, add a theme named 
> "firefox original", so that two choices exist, the (what I think they 
> are called) Gnome specific icons, and the original firefox icons?
> 
> I really like the original firefox icons better, than the ones used by 
> nautilus, epiphany, etc.
> 
> Lars

I've noticed this too, and hated it. Not the change itself, since it is 
good to have consistent icons, but not being able to select old ones. I 
like the Firefox default ones and would like to have them back, thank 
you. This should be selectable in someway. I don't mind if its just an 
option in "prefs.js" or something, just don't force me to look at those 
ugly icons, I really like Firefox's default theme, _with_ its default icons.

Just a user,
	Carlos Rodrigues

-- 
url: http://tudo-sobre-nada.blogspot.com



From hp at redhat.com  Sun Dec 19 01:10:04 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 18 Dec 2004 20:10:04 -0500
Subject: firefox and icons...
In-Reply-To: <41C4C2C5.6020508@silverorange.com>
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
	<41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
	<41C4C2C5.6020508@silverorange.com>
Message-ID: <1103418604.5679.75.camel@localhost.localdomain>

On Sat, 2004-12-18 at 19:52 -0400, Steven Garrity wrote:
> Havoc Pennington wrote:
> > I thought he was talking about the toolbar icons, not the icon in the
> > menus/launchers.
> 
> I see - my mistake.
> 
> If rawhide does indeed pick up the Gnome theme icons (which is great), 
> then perhaps we could also ship a "Firefox Default" theme with the 
> default (windows) theme icons.
> 

I think that would be nice, yep. We can't convince you to draw a whole
desktop theme in that style can we? ;-)

Havoc




From stevelist at silverorange.com  Sun Dec 19 01:12:35 2004
From: stevelist at silverorange.com (Steven Garrity)
Date: Sat, 18 Dec 2004 21:12:35 -0400
Subject: firefox and icons...
In-Reply-To: <1103418604.5679.75.camel@localhost.localdomain>
References: <41C4A645.6050001@homer.se>	<1103409723.5679.53.camel@localhost.localdomain>	<41C4B9B1.6010402@silverorange.com>	<1103413973.5679.73.camel@localhost.localdomain>	<41C4C2C5.6020508@silverorange.com>
	<1103418604.5679.75.camel@localhost.localdomain>
Message-ID: <41C4D583.5010503@silverorange.com>

Havoc Pennington wrote:
> On Sat, 2004-12-18 at 19:52 -0400, Steven Garrity wrote:
>>If rawhide does indeed pick up the Gnome theme icons (which is great), 
>>then perhaps we could also ship a "Firefox Default" theme with the 
>>default (windows) theme icons.
>
> I think that would be nice, yep. We can't convince you to draw a whole
> desktop theme in that style can we? ;-)

I'd *love* to see that - or rather, a style that was built from the 
ground up, rather than being built to mesh nicely with the Windows 
environment.

However, I'm only the guy would talks a lot and takes credit for 
everything. The actual artists behind the theme/toolbar artwork in 
Firefox are Kevin Gerich (http://www.kmgerich.com/) and Stephen Horlander.

I do think it is time to have another go at a great modern Gnome theme. 
Both Bluecurve and the default Gnome theme are showing their age.

Steven Garrity



From rahulsundaram at yahoo.co.in  Sun Dec 19 00:16:06 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Sat, 18 Dec 2004 16:16:06 -0800 (PST)
Subject: firefox and icons...
In-Reply-To: <41C4C2C5.6020508@silverorange.com>
Message-ID: <20041219001606.15433.qmail@web8501.mail.in.yahoo.com>

Hi


> If rawhide does indeed pick up the Gnome theme icons
> (which is great), 
> then perhaps we could also ship a "Firefox Default"
> theme with the 
> default (windows) theme icons.
> 
> Steven Garrity

does that mean this gnome integration is a fedora
specific patch not  upstreamed?. 

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From stevelist at silverorange.com  Sun Dec 19 01:20:09 2004
From: stevelist at silverorange.com (Steven Garrity)
Date: Sat, 18 Dec 2004 21:20:09 -0400
Subject: firefox and icons...
In-Reply-To: <20041219001606.15433.qmail@web8501.mail.in.yahoo.com>
References: <20041219001606.15433.qmail@web8501.mail.in.yahoo.com>
Message-ID: <41C4D749.4060009@silverorange.com>

Rahul Sundaram wrote:
> does that mean this gnome integration is a fedora
> specific patch not  upstreamed?. 

Rahul,
Use of gnome-theme toolbar icons is probably a Fedora-specific patch 
*for now*, but will likely be included in a future release upstream 
release too.

My (limited) understanding is that it is still in pretty heavy development.

Steven Garrity



From mr700 at globalnet.bg  Sun Dec 19 02:32:38 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Sun, 19 Dec 2004 04:32:38 +0200
Subject: firefox and icons...
In-Reply-To: <1103413973.5679.73.camel@localhost.localdomain>
References: <41C4A645.6050001@homer.se> <41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
Message-ID: <200412190432.38451@-mr700>

On 2004-12-19 (Sunday) 01:52, Havoc Pennington wrote:
> On Sat, 2004-12-18 at 19:13 -0400, Steven Garrity wrote:
> > Havoc Pennington wrote:
> > > I would have thought you could change the Firefox-specific application
> > > theme in Tools->Themes in Firefox, but it looks like there's no option
> > > there for now.
> > 
> > No, the application icon is beyond the scope (and capability?) of the 
> > application's own theme.
> 
> I thought he was talking about the toolbar icons, not the icon in the
> menus/launchers.
> 

    What does this mean? All firefox's icons (menu/launcher and theme)
are changed to something else?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From hp at redhat.com  Sun Dec 19 04:59:12 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 18 Dec 2004 23:59:12 -0500
Subject: firefox and icons...
In-Reply-To: <200412190432.38451@-mr700>
References: <41C4A645.6050001@homer.se> <41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
	<200412190432.38451@-mr700>
Message-ID: <1103432353.5679.102.camel@localhost.localdomain>

On Sun, 2004-12-19 at 04:32 +0200, Doncho N. Gunchev wrote:
>     What does this mean? All firefox's icons (menu/launcher and theme)
> are changed to something else?

They follow the desktop icon theme, like every other app.

Havoc




From arcofdescent at gmail.com  Sun Dec 19 09:58:44 2004
From: arcofdescent at gmail.com (Rohan Romanus Almeida)
Date: Sun, 19 Dec 2004 15:28:44 +0530
Subject: update of package in extras
Message-ID: <777aada20412190158713c6494@mail.gmail.com>

HI,

I have a package in Fedora Extras. I mean, I'm not the 
maintainer, but I'm the original author. I'm planning to 
release a new version soon. How does it work in Fedora?
Does the maintainer magically know? or do I have to 
personally contact her? or post an announce on this list?

Pleas advice.

--
Rohan



From fedora at wir-sind-cool.org  Sun Dec 19 12:20:31 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sun, 19 Dec 2004 13:20:31 +0100
Subject: update of package in extras
In-Reply-To: <777aada20412190158713c6494@mail.gmail.com>
References: <777aada20412190158713c6494@mail.gmail.com>
Message-ID: <20041219132031.20500ade.fedora@wir-sind-cool.org>

On Sun, 19 Dec 2004 15:28:44 +0530, Rohan Romanus Almeida wrote:

> HI,
> 
> I have a package in Fedora Extras.

Fedora Extras does not exist yet. That means, it is not ready yet in the
form it is planned.  [The package is included in fedora.us and hence was
rebuilt and published in the pre-Extras repository. As a packager for
fedora.us, you would adhere to the documented package submission
policies.]

> I mean, I'm not the 
> maintainer, but I'm the original author.

Of the package or the software in the package? Who created the package or
adapted it? He put his e-mail address into the package changelog, didn't
he?

> I'm planning to 
> release a new version soon. How does it work in Fedora?
> Does the maintainer magically know? or do I have to 
> personally contact her? or post an announce on this list?

Based on this I assume you refer to being the author of the
software. Well, if you don't keep close contact to a packager, most likely
he monitors your release habits, your announcements or mailing-lists (if
any), or visits your website from time to time. Maybe he upgrades his
private working copy as soon as he knows about a new release, but takes
enough time to evaluate it before he pushes out an upgraded package.
Maybe he needs to test dependencies with it, too. Depending on what
software it is, the procedure varies. If you, as a program author, want to
contact a packager, you are free to do so. Either using e-mail or
bugzilla. I would not assume that all packagers are subscribed to
fedora-devel-list.

> Pleas advice.
> 
> --
> Rohan
> 



From mike at navi.cx  Sun Dec 19 12:17:18 2004
From: mike at navi.cx (Mike Hearn)
Date: Sun, 19 Dec 2004 12:17:18 +0000
Subject: firefox and icons...
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
	<41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
	<41C4C2C5.6020508@silverorange.com>
	<1103418604.5679.75.camel@localhost.localdomain>
	<41C4D583.5010503@silverorange.com>
Message-ID: <pan.2004.12.19.12.17.18.799150@navi.cx>

On Sat, 18 Dec 2004 21:12:35 -0400, Steven Garrity wrote:
> I do think it is time to have another go at a great modern Gnome theme. 
> Both Bluecurve and the default Gnome theme are showing their age.

Maybe, but I still quite like the stock GNOME artwork. Garret LeSage has
done an Industrial firefox theme which makes it integrate a lot nicer with
Industrial based desktops (so not stock Fedora unfortunately).

I'm not sure what you mean by Bluecurve showing its age though - it only
came out with RH8, which I still remember clearly. That was only perhaps
2-3 years ago.

To be honest, while I love the Bluecurve filetype/app icons and "image
represents task" idea, I was never that wild about the Bluecurve GTK+
stock artwork which to my eye does not look sharp or clear. The Industrial
theme with the stock GNOME artwork is what I keep going back to, the
matching Firefox theme is just a nice bonus.



From buildsys at redhat.com  Sun Dec 19 12:46:30 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 19 Dec 2004 07:46:30 -0500
Subject: rawhide report: 20041219 changes
Message-ID: <200412191246.iBJCkUM02960@porkchop.devel.redhat.com>

 

 
Updated Packages:

glibc-2.3.3-99
--------------
* Sun Dec 19 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-99
- rebuilt

* Sat Dec 18 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-98
- add .%{_target_cpu} to glibc_post_upgrade, only run telinit u
  if /sbin/init is the same ELF class and machine as
  glibc_post_upgrade.%{_target_cpu} and similarly with
  condrestarting sshd (#143046)

perl-PDL-2.4.1-9
----------------
* Sat Dec 18 2004 Miloslav Trmac <mitr at redhat.com> - 2.4.1-9
- Rebuild with fixed gsl-devel (#142695)

rpmdb-fedora-1:4-0.20041219
---------------------------

xorg-x11-6.8.1.901-1
--------------------
* Sat Dec 18 2004 Mike A. Harris <mharris at redhat.com> 6.8.1.901-1
- Update main tarball to X.Org X11 6.8.1.901 (6.8.2 release candidate 1)
  via CVS export of CVS tag XORG-6_8_1_901
- Removed the following patches, as they are integrated into CVS now:
    xorg-x11-6.8.1-ati-radeon-segv-130888.patch
    xorg-x11-6.8.1-ati-radeon-panel-timing-param-init-130888.patch
    xorg-x11-6.8.0-ia64-460gx-pci-typo.patch
    xorg-x11-6.8.1-ati-radeon-mobility-display-detection-fix2.patch
    xorg-x11-6.8.1-ati-radeon-dynamic-clocks-fix.patch
    xorg-x11-6.8.1-libX11-stack-overflow.patch
    xorg-x11-6.8.1-vidmode-change-verbosity.patch
    xorg-x11-6.8.1-disable-dri-option.patch
    xorg-x11-6.8.1-xmodmap-overflows.patch
    xorg-x11-6.8.1-xpm-security-fixes-CAN-2004-0914.patch
    xorg-x11-6.8.1-xpm-security-fixes-CAN-2004-0914-sec8-ammendment.patch
    xorg-x11-6.8.1-r128-logout-deadlock.patch
    xorg-x11-6.8.1-add-missing-lucidatypewriter-font.patch
- Disabled xorg-x11-6.8.1-i810-update.patch, but left it present, as only some
  hunks fail to apply.  This leads me to believe perhaps 6.8.2 has only part of
  the i810 CVS head code.  We need to explore this a bit before dropping the
  patch altogether.



From che666 at uni.de  Sun Dec 19 13:21:48 2004
From: che666 at uni.de (Rudolf Kastl)
Date: Sun, 19 Dec 2004 14:21:48 +0100
Subject: contributions to fedora extras/wine maintainer
Message-ID: <1103462508.18008.3.camel@localhost.localdomain>

Hello to you.

Just want to announce that i sent an email to Michael Tieman about cvs
access to fedora extras. If wanted id contribute things from the
newrpms.sunsite.dk repository as well as fixes in general (i have yet to
look into the policy if there is one already).

Also as far as i heard theres still a wine package maintainer needed. Id
volunteer.

regards,
rudolf kastl





From byte at aeon.com.my  Sun Dec 19 15:16:27 2004
From: byte at aeon.com.my (Colin Charles)
Date: Sun, 19 Dec 2004 23:16:27 +0800
Subject: contributions to fedora extras/wine maintainer
In-Reply-To: <1103462508.18008.3.camel@localhost.localdomain>
References: <1103462508.18008.3.camel@localhost.localdomain>
Message-ID: <1103469388.5149.31.camel@localhost.localdomain>

On Sun, 2004-12-19 at 14:21 +0100, Rudolf Kastl wrote:
> Just want to announce that i sent an email to Michael Tieman about cvs
> access to fedora extras. If wanted id contribute things from the
> newrpms.sunsite.dk repository as well as fixes in general (i have yet
> to
> look into the policy if there is one already).

Michael isn't on task to get these things sorted out (i.e. cvs accounts)

When we have policy to make it all work nicely, we'll definitely have an
announcement here, so hang in there. It basically inovlves filling an
interesting form, and reading some legalese

So, patience in the meantime, till we officially open Fedora Extras
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From che666 at uni.de  Sun Dec 19 17:54:31 2004
From: che666 at uni.de (Rudolf Kastl)
Date: Sun, 19 Dec 2004 18:54:31 +0100
Subject: contributions to fedora extras/wine maintainer
In-Reply-To: <1103469388.5149.31.camel@localhost.localdomain>
References: <1103462508.18008.3.camel@localhost.localdomain>
	<1103469388.5149.31.camel@localhost.localdomain>
Message-ID: <1103478871.5873.0.camel@localhost.localdomain>

alright. no need for haste. 

regards,
rudolf kastl

Am Sonntag, den 19.12.2004, 23:16 +0800 schrieb Colin Charles:
> On Sun, 2004-12-19 at 14:21 +0100, Rudolf Kastl wrote:
> > Just want to announce that i sent an email to Michael Tieman about cvs
> > access to fedora extras. If wanted id contribute things from the
> > newrpms.sunsite.dk repository as well as fixes in general (i have yet
> > to
> > look into the policy if there is one already).
> 
> Michael isn't on task to get these things sorted out (i.e. cvs accounts)
> 
> When we have policy to make it all work nicely, we'll definitely have an
> announcement here, so hang in there. It basically inovlves filling an
> interesting form, and reading some legalese
> 
> So, patience in the meantime, till we officially open Fedora Extras
> -- 
> Colin Charles, byte at aeon.com.my
> http://www.bytebot.net/
> "First they ignore you, then they laugh at you, then they fight you, 
> then you win." -- Mohandas Gandhi
> 



From rahulsundaram at yahoo.co.in  Sun Dec 19 17:37:02 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Sun, 19 Dec 2004 09:37:02 -0800 (PST)
Subject: firefox and icons...
In-Reply-To: <pan.2004.12.19.12.17.18.799150@navi.cx>
Message-ID: <20041219173702.56599.qmail@web8506.mail.in.yahoo.com>

Hi

> I'm not sure what you mean by Bluecurve showing its
> age though - it only
> came out with RH8, which I still remember clearly.
> That was only perhaps
> 2-3 years ago.

it has also been revised heavily after that

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From kyrre at solution-forge.net  Sun Dec 19 20:41:12 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Sun, 19 Dec 2004 21:41:12 +0100
Subject: OpenOffice Memory Bloat?
In-Reply-To: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>
References: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>
Message-ID: <1103488872.2729.38.camel@kyrre>

l?r, 18.12.2004 kl. 00.29 skrev Rahul Sundaram:
> Hi
> 
> > - Why does OO load many hundred MB of dictionaries?
> > I don't care if a
> > misspelled word happen to be correct in Czech.
> > (Norwegian misspelled
> > words has some tend to be correct in that language.)
> > It also slows down
> > the spellchecker a *lot*.
> > - Why aren't OO quickstart included in fedora?'
> 
> the dictionary bug is a known one. look in bugzilla
> for details. the i18n package is also being split up
> to reduce the size
> 

I think i have seen that bug report, but i can't find it rigth now.
Could anybody please give me a number?

However, this bug is *OLD*, and hugely annoying. What about fixing it
(i.e. disabling the "check if this is correct in every other existing
language" functionality)?

I guess i should just uninstall those dicts, untill things are fixed...

Kyrre



From byte at aeon.com.my  Sun Dec 19 22:26:20 2004
From: byte at aeon.com.my (Colin Charles)
Date: Mon, 20 Dec 2004 06:26:20 +0800
Subject: OpenOffice Memory Bloat?
In-Reply-To: <1103488872.2729.38.camel@kyrre>
References: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>
	<1103488872.2729.38.camel@kyrre>
Message-ID: <1103495180.5149.46.camel@localhost.localdomain>

On Sun, 2004-12-19 at 21:41 +0100, Kyrre Ness Sjobak wrote:
> > the dictionary bug is a known one. look in bugzilla
> > for details. the i18n package is also being split up
> > to reduce the size
> > 
> 
> I think i have seen that bug report, but i can't find it rigth now.
> Could anybody please give me a number?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124374
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136133

Its fixed in rawhide, and testers are welcome to post their responses to
bugzilla, or fedora-test-list
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From dwmw2 at infradead.org  Mon Dec 20 00:47:32 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 20 Dec 2004 00:47:32 +0000
Subject: rawhide report: 20041217 changes
In-Reply-To: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
Message-ID: <1103503652.5917.1.camel@localhost.localdomain>

On Fri, 2004-12-17 at 08:09 -0500, Build System wrote:
> exim-4.43-3
> -----------
> * Thu Dec 16 2004 David Woodhouse <dwmw2 at redhat.com> 4.43-3
> - Demonstrate SASL auth configuration in default config file
> - Enable TLS and provide certificate if necessary
> - Don't reject all GB2312 charset mail by default

This enables TLS on incoming and outgoing mail by default -- some
feedback from testing would be appreciated.

-- 
dwmw2



From mknepher at bluethingy.com  Mon Dec 20 02:25:29 2004
From: mknepher at bluethingy.com (Michael Knepher)
Date: Sun, 19 Dec 2004 18:25:29 -0800
Subject: firefox and icons...
In-Reply-To: <200412190432.38451@-mr700>
References: <41C4A645.6050001@homer.se>
	<41C4B9B1.6010402@silverorange.com>	<1103413973.5679.73.camel@localhost.localdomain>
	<200412190432.38451@-mr700>
Message-ID: <41C63819.3030608@bluethingy.com>

Doncho N. Gunchev wrote:

>    What does this mean? All firefox's icons (menu/launcher and theme)
>are changed to something else?
>
>  
>
For an example, see:
http://www.bluethingy.com/linux/bluecurve_firefox.png



From dcbw at redhat.com  Mon Dec 20 02:34:07 2004
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 19 Dec 2004 21:34:07 -0500 (EST)
Subject: OpenOffice Memory Bloat?
In-Reply-To: <1103322563.2737.152.camel@kyrre>
References: <dbc15d4904121711173e908c16@mail.gmail.com>
	<1103322563.2737.152.camel@kyrre>
Message-ID: <Pine.LNX.4.58.0412192133120.20343@devserv.devel.redhat.com>

On Fri, 17 Dec 2004, Kyrre Ness Sjobak wrote:
> - Why does OO load many hundred MB of dictionaries? I don't care if a
> misspelled word happen to be correct in Czech. (Norwegian misspelled
> words has some tend to be correct in that language.) It also slows down
> the spellchecker a *lot*.

Because people asked for them.  A lot.  This was before the memory 
problems were known, at some point earlier this year.

> - Why aren't OO quickstart included in fedora?

Good point, we should include it.

Dan



From dcbw at redhat.com  Mon Dec 20 02:46:02 2004
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 19 Dec 2004 21:46:02 -0500 (EST)
Subject: OpenOffice Memory Bloat?
In-Reply-To: <1103488872.2729.38.camel@kyrre>
References: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>
	<1103488872.2729.38.camel@kyrre>
Message-ID: <Pine.LNX.4.58.0412192139290.20343@devserv.devel.redhat.com>

On Sun, 19 Dec 2004, Kyrre Ness Sjobak wrote:
> However, this bug is *OLD*, and hugely annoying. What about fixing it
> (i.e. disabling the "check if this is correct in every other existing
> language" functionality)?

Unfortunately, that doesn't do it.  OOo will still load every dictionary 
in the dictionary.lst file anyway, it just won't _check_ with them when 
that's unchecked.  It will still suggest them though.  I took a couple 
hours to go through the code (lingucomponent and linguistic modules in OOo 
CVS) and its quite broken in some respects, especially dictionary loading.  
There is no option to tell the spelling suggester to only check in the 
current language.

Besides, you don't want to only check in the current language, you may 
wish to check in English and French for example.  However, unchecking 
stuff in the Writing Aids->Edit boxes doesn't work (at least when I tried 
it).

This appears to be a bug, since this works correctly in upstream 1.1.3.

After the holidays we'll be working on merging our local patches back up 
to ooo-build and then jumping to 1.1.3 and pushing that down as an update.  
Language packs will be split out too, but that might come after the 1.1.3 
update.

Dan



From pbruna at linuxcenterla.com  Mon Dec 20 03:13:38 2004
From: pbruna at linuxcenterla.com (Patricio Bruna V)
Date: Mon, 20 Dec 2004 00:13:38 -0300
Subject: RPM tools
Message-ID: <1103512418.3226.1.camel@p.linuxcenter.cl>

hi, im looking tools for work with rpms.

what kind of tools?

1. Let me easier build packages.
2. Admin rpm distros (Fedora)
-- 
Patricio Bruna                                  http://www.linuxcenterla.com
Ingeniero de Proyectos                  Mariano S?nchez Fontecilla 310, piso 2
Red Hat Certified Engineer              Las Condes, Santiago - CHILE
Linux Center Latinoamerica              Fono: +56 2 2745000, Fax : +56 22747075
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041220/e4311fe3/attachment.sig>

From mpeters at mac.com  Mon Dec 20 04:32:33 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Mon, 20 Dec 2004 04:32:33 +0000
Subject: RPM tools
In-Reply-To: <1103512418.3226.1.camel@p.linuxcenter.cl> (from
	pbruna@linuxcenterla.com on Sun Dec 19 19:13:38 2004)
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
Message-ID: <1103517153l.4541l.0l@devel.mpeters.us>

On 12/19/2004 07:13:38 PM, Patricio Bruna V wrote:
> hi, im looking tools for work with rpms.
> 
> what kind of tools?
> 
> 1. Let me easier build packages.

emacs - the Fedora emacs comes with a plugin to ease writing spec  
files.
IE - emacs something.spec
You'll have a template to work from.

rpmlint - from Fedora Extras (pre) - you can run it on your src.rpm to  
make sure it's clean.

GnuPG - for signing packages

> 2. Admin rpm distros (Fedora)

createrepo - used to create the metadata header files needed for  
(current) yum

yum, apt, smart - all good pieces of software for managing a systems  
packages. I don't think smart does gpg checking so maybe that's out.

----
Is that what you were looking for?




From dpaun at rogers.com  Mon Dec 20 04:49:06 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Sun, 19 Dec 2004 23:49:06 -0500
Subject: svn or arch
In-Reply-To: <1103314870.12552.107.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
Message-ID: <20041220044906.GA22942@rogers.com>

On Fri, Dec 17, 2004 at 03:21:10PM -0500, Colin Walters wrote:
> First, I think it's wacky to maintain patch files in revision control.
> If you want to look back at history, you're looking at a diff of a diff,
> which is just incomprehensible.  The right way to do this in my opinion
> is to have each patch be a direct branch of the upstream source.  If you
> have patch interdependencies, then you create a new branch which merges
> from the interdependent branches, just like how you have to adjust the
> patch files now.

That's an idea that I've been playing with myself. However, I want to
be able to generate SRPMS from it too, preferably generating the PatchN
series of patches. Problem is that with PatchN you have an ordering for
the patches, whereas with the direct branching from the upstream source
you don't. And I don't quite see how a new branch for interdependent branches
would work in practice.

However, I think we can avoid all sorts of problems, if instead of branching
from the source, we branch from the brances -- this would give us the
ordering. So, say that now you have a package 'foo' that has 3 patches in
its .src.rpm:
 Patch00: disable-bar.patch
 Patch01: bluecurve.patch
 Patch02: memleak-fix.patch

We can then branch as follows:
  foo                          -- branch for tracking upstream source
   |
   \-disable-bar               -- branch for the 'disable-bar' feature
      |
      \-bluecurve              -- branch for the 'bluecurve' feature
         |
         \-memleak-fix         -- branch for the 'mem-leak' feature

This should be enough to be able to automatically generate the correct
patches, and build the SRPM, no?

It does make it a bit difficult to change the order of the patches, but
it can be done, and to be honest, I don't see this sort of reordering as
a common occurence.

-- 
Dimi.



From meetkaustubhghosh at vsnl.net  Mon Dec 20 05:07:13 2004
From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh)
Date: Mon, 20 Dec 2004 10:37:13 +0530
Subject: Questions regarding Linux Equivalents
In-Reply-To: <20041219170005.7B70273C0C@hormel.redhat.com>
References: <20041219170005.7B70273C0C@hormel.redhat.com>
Message-ID: <41C65E01.2030106@vsnl.net>

Can someone please point out:
1.Linux Equivalent of prmap_t in solaris 2.5
2.Linux Equivalent of Doskey in Dos/windows

The questions r in context of C programming.
Thanks in advance for any help that I can get.

Kaustubh Ghosh.



From symbiont at berlios.de  Mon Dec 20 05:50:38 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Mon, 20 Dec 2004 13:50:38 +0800
Subject: RPM tools
In-Reply-To: <1103512418.3226.1.camel@p.linuxcenter.cl>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
Message-ID: <200412201350.39305.symbiont@berlios.de>

On Monday 20 December 2004 11:13, Patricio Bruna V wrote:
> what kind of tools?

This piece might be helpful:

http://lists.freshrpms.net/pipermail/freshrpms-list/2004-August/010772.html

There are dozens of tools out there, but this will help you get an intro 
to what offerings are available. (Which is why I question whether 
Fedora Extras really needs to reinvent another build system.  NIH, I 
guess.)

-- 
-jeff



From skvidal at phy.duke.edu  Mon Dec 20 05:57:58 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 20 Dec 2004 00:57:58 -0500
Subject: RPM tools
In-Reply-To: <200412201350.39305.symbiont@berlios.de>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
	<200412201350.39305.symbiont@berlios.de>
Message-ID: <1103522278.8869.18.camel@cutter>

On Mon, 2004-12-20 at 13:50 +0800, Jeff Pitman wrote:
> On Monday 20 December 2004 11:13, Patricio Bruna V wrote:
> > what kind of tools?
> 
> This piece might be helpful:
> 
> http://lists.freshrpms.net/pipermail/freshrpms-list/2004-August/010772.html
> 
> There are dozens of tools out there, but this will help you get an intro 
> to what offerings are available. (Which is why I question whether 
> Fedora Extras really needs to reinvent another build system.  NIH, I 
> guess.)
> 

a lot of it has to do with the cvs system in place and internal
processes.

it's not NIH - it's just "won't work here".

-sv




From symbiont at berlios.de  Mon Dec 20 06:40:06 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Mon, 20 Dec 2004 14:40:06 +0800
Subject: RPM tools
In-Reply-To: <1103522278.8869.18.camel@cutter>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
	<200412201350.39305.symbiont@berlios.de>
	<1103522278.8869.18.camel@cutter>
Message-ID: <200412201440.07007.symbiont@berlios.de>

On Monday 20 December 2004 13:57, seth vidal wrote:
> a lot of it has to do with the cvs system in place and internal
> processes.

Ok, that's fine. I would just like to reiterate a few things that I 
think I wouldn't be alone in voicing:

1. These processes are opened up by Redhat.
2. That a formal project be started to refine the build system. (Put it 
in the "Projects" menu on the fedora.redhat.com website)

This will enable all to see that, Yes, we need to mold existing 
methodologies to what Fedora needs and wow, we can use foo, bar, and 
baz from these other projects to help facilitate the betterment of this 
system. Otherwise, we'll be stuck with the "internal process" euphemism 
for along time while wondering how we can better contribute besides 
tweaking Buildrequires or perl one-liners in already-existing spec 
files.

take care,
-- 
-jeff



From nbargnesi at gmail.com  Mon Dec 20 07:12:49 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Mon, 20 Dec 2004 02:12:49 -0500
Subject: Questions regarding Linux Equivalents
In-Reply-To: <41C65E01.2030106@vsnl.net>
References: <20041219170005.7B70273C0C@hormel.redhat.com>
	<41C65E01.2030106@vsnl.net>
Message-ID: <3077b8a00412192312a4f7c73@mail.gmail.com>

Doskey?  Didn't that remember commands previously used?
That can be accomplished using the up arrow.
If you want something a little more advanced, try
set -o vi
to do line editing a la vi.  You could also use emacs, but that's heresy.  ;)
-Nick

On Mon, 20 Dec 2004 10:37:13 +0530, Kaustubh Ghosh
<meetkaustubhghosh at vsnl.net> wrote:
> Can someone please point out:
> 1.Linux Equivalent of prmap_t in solaris 2.5
> 2.Linux Equivalent of Doskey in Dos/windows
> 
> The questions r in context of C programming.
> Thanks in advance for any help that I can get.
> 
> Kaustubh Ghosh.
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From pbrobinson at gmail.com  Mon Dec 20 07:39:44 2004
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 20 Dec 2004 15:39:44 +0800
Subject: gnome-vfs2 and howl
Message-ID: <5256d0b04121923391f348720@mail.gmail.com>

Hi All,

I just tried upgrading my version of howl to the latest 0.9.8 by
downloading the source and the current SRPM, replacing the appropriate
lines and recompiling. All went well but the gnome-vfs2 had a
dependancy on libhowl-0.9.6.so.1

So downloaded the SRPM for that to see if it was in there or a compile
time dep. Its seems its the later as the spec file specificly mentions
the >= howl and the associated packages. If I do a 'rpm -q --requires
gnome-vfs2' the specific library is mentioned.

[root at morpheus i386]# rpm -Uvh howl-0.9.8-1.FC3.i386.rpm
howl-devel-0.9.8-1.FC3.i386.rpm howl-libs-0.9.8-1.FC3.i386.rpm
error: Failed dependencies:
        libhowl-0.9.6.so.1 is needed by (installed) gnome-vfs2-2.8.2-8.i386

So my question is should I be able to upgrade howl to a later version
of is gnome-vfs2 dependant on that particular version. If I should be
able to should I bugzilla it? I did a quick search and found a similar
problems with gamin at bug #140679 but nothing specific to howl.

I want a version later than 0.9.6 to fix a problem that shows up in
gnomemeeting 1.2.0. For the moment I have just upgraded with a
--nodeps, not sure what havoc it'll cause with gnome-vf2 but for the
moment aren't actually running X on this box.

Cheers
Pete



From skvidal at phy.duke.edu  Mon Dec 20 07:49:50 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 20 Dec 2004 02:49:50 -0500
Subject: RPM tools
In-Reply-To: <200412201440.07007.symbiont@berlios.de>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
	<200412201350.39305.symbiont@berlios.de>
	<1103522278.8869.18.camel@cutter>
	<200412201440.07007.symbiont@berlios.de>
Message-ID: <1103528990.8869.48.camel@cutter>

On Mon, 2004-12-20 at 14:40 +0800, Jeff Pitman wrote:
> On Monday 20 December 2004 13:57, seth vidal wrote:
> > a lot of it has to do with the cvs system in place and internal
> > processes.
> 
> Ok, that's fine. I would just like to reiterate a few things that I 
> think I wouldn't be alone in voicing:

Guess what? you're not alone. Guess what else? I've been doing that for
a long ass time. Things needed to get prepped inside b/c the cvs
infrastructure that Gafton set up has completely changed how internal
structures work. They wanted ONE cvs structure for everything. They had
THREE prior to this so you can see the advantages to getting them all
together. So that everyone is on the same page.

Do you know how long it takes to get everyone inside a medium-sized
company on the same page w/o bringing all productivity to a halt?

I bet it takes something like 6-8 months.

Notice the timeline since cvs was first put in place for fedora? looks
something like 6 to 8 months ago. :)


> 1. These processes are opened up by Redhat.

The memos and emails and bullshit internally really doesn't matter. That
was to get their own people on the same page. It just took some time and
well, that sucks but that's how it was.

> 2. That a formal project be started to refine the build system. (Put it 
> in the "Projects" menu on the fedora.redhat.com website)

That will happen. And, as I know we said earlier, the latest estimate
was sometime shortly after xmas. It depends on availability of time. 
Now, I, personally, think we should be in the 'release early, release
horribly broken'  mode but I know it's not always that easy.
 That's why Me, Colin, Michael and a bunch of others decided to do the
pre-extras release. To build the stuff we had. To show people that:
 1. work was going on
 2. there's stuff in place and wheels are turning
 3. how cool some of it is.

> This will enable all to see that, Yes, we need to mold existing 
> methodologies to what Fedora needs and wow, we can use foo, bar, and 
> baz from these other projects to help facilitate the betterment of this 
> system. Otherwise, we'll be stuck with the "internal process" euphemism 
> for along time while wondering how we can better contribute besides 
> tweaking Buildrequires or perl one-liners in already-existing spec 
> files.

So here's a fun fact: Other projects were looked at and other projects
are being used. But opening up the floor for wide-open debate on the
subject isn't going to get the work done. It's just going to make for a
lot of debate w/little actual forward motion.

What I know of how some of the build system is being worked on for
extras is this:
 - when you check in a package to cvs you can tag it with a special
'buildme' tag. (not the real tag name, obviously)
 - the buildsystem scans for those tags, creates a buildroot using
something like: 
  yum -y --installroot=/someplace groupinstall base development

  it might not be using yum - it might be using rpm directly. I don't 
  know for certain - but as the author of yum I tend to think in yum 
  commands :)

 - the package is built, the logs are dumped to useful places
 

the problems:
  - in order to make building safe you either need to vet all the
potential scriptlets and build commands (hah) or run it in some sort of
virtualized or protected environment. I know gafton said he got
sidetracked trying to get Xen to work in this capacity. But he needed to
go ahead and work on tying all the bits together.
  - you've got to get all the build deps in place and make everything
flow smoothly from checked in package to complete rpm.


That's what going on. That's where we are. It's not a NIH issue. It's a
huge amount of glue coding that's occurring. I agree with you that I'd
like it to be a little more exposed and it's going in that direction.
But seeing as I'm not internal to red hat and I've got a bunch of this
information I hope you can accept my statement that things are opening
up. More and more.

Like I said last week or so, I'll let you know more as I know it.

And I will. Watch the fedora people page
(http://fedoraproject.org/people) I'll try to post entries into my blog
when I get useful info. Okay?

Oh and if you're curious why this doesn't get posted to the fedora-
devel-list by the project leaders themselves my answers are these two:

 1. some of them are not all that talkative and don't always have the
time considering that they're also project managers and developers
inside red hat.

 2. did you see the thread-that-would-never-die from this weekend? :-)

Right now my messages are probably the best you're gonna get.

I'll be glad to field other questions and answer whatever I know.

cool?

-sv




From alexl at redhat.com  Mon Dec 20 08:06:14 2004
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 20 Dec 2004 09:06:14 +0100
Subject: gnome-vfs2 and howl
In-Reply-To: <5256d0b04121923391f348720@mail.gmail.com>
References: <5256d0b04121923391f348720@mail.gmail.com>
Message-ID: <1103529974.8669.262.camel@greebo>

On Mon, 2004-12-20 at 15:39 +0800, Peter Robinson wrote:
> Hi All,
> 
> I just tried upgrading my version of howl to the latest 0.9.8 by
> downloading the source and the current SRPM, replacing the appropriate
> lines and recompiling. All went well but the gnome-vfs2 had a
> dependancy on libhowl-0.9.6.so.1
> 
> So downloaded the SRPM for that to see if it was in there or a compile
> time dep. Its seems its the later as the spec file specificly mentions
> the >= howl and the associated packages. If I do a 'rpm -q --requires
> gnome-vfs2' the specific library is mentioned.
> 
> [root at morpheus i386]# rpm -Uvh howl-0.9.8-1.FC3.i386.rpm
> howl-devel-0.9.8-1.FC3.i386.rpm howl-libs-0.9.8-1.FC3.i386.rpm
> error: Failed dependencies:
>         libhowl-0.9.6.so.1 is needed by (installed) gnome-vfs2-2.8.2-8.i386
> 
> So my question is should I be able to upgrade howl to a later version
> of is gnome-vfs2 dependant on that particular version. If I should be
> able to should I bugzilla it? I did a quick search and found a similar
> problems with gamin at bug #140679 but nothing specific to howl.
> 
> I want a version later than 0.9.6 to fix a problem that shows up in
> gnomemeeting 1.2.0. For the moment I have just upgraded with a
> --nodeps, not sure what havoc it'll cause with gnome-vf2 but for the
> moment aren't actually running X on this box.

Howl 0.9.6 doesn't handle upgrades like that because the library
filename is "libhowl-0.9.6.so.1". An upgrade would break all apps
linking to the old version.

I think this has been fixed in later versions of how, but atm you can't
upgrade without also rebuilding all apps/libs that link to it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an otherworldly native American cowboy searching for his wife's true 
killer. She's a mistrustful antique-collecting mermaid who believes she is the 
reincarnation of an ancient Egyptian queen. They fight crime! 



From console at spray.se  Mon Dec 20 08:32:37 2004
From: console at spray.se (Daniel)
Date: Mon, 20 Dec 2004 08:32:37 GMT 
Subject: gnome-vfs2 and howl
Message-ID: <1103531557022135@lycos-europe.com>

 
	

hi

try rpm -ivh, it use to work when you want to versions of same package installed. Sometimes there will be a confilct somewere but I usually ignore that and do --force to.

/D

> Fr?n: Peter Robinson <pbrobinson at gmail.com>
> Till: fedora-devel-list at redhat.com
> Rubrik: gnome-vfs2 and howl
> Datum: Mon, 20 Dec 2004 15:39:44 +0800

> Hi All,
> 
> I just tried upgrading my version of howl to the latest 0.9.8 by
> downloading the source and the current SRPM, replacing the appropriate
> lines and recompiling. All went well but the gnome-vfs2 had a
> dependancy on libhowl-0.9.6.so.1
> 
> So downloaded the SRPM for that to see if it was in there or a compile
> time dep. Its seems its the later as the spec file specificly mentions
> the >= howl and the associated packages. If I do a 'rpm -q --requires
> gnome-vfs2' the specific library is mentioned.
> 
> [root at morpheus i386]# rpm -Uvh howl-0.9.8-1.FC3.i386.rpm
> howl-devel-0.9.8-1.FC3.i386.rpm howl-libs-0.9.8-1.FC3.i386.rpm
> error: Failed dependencies:
>         libhowl-0.9.6.so.1 is needed by (installed) gnome-vfs2-2.8.2-8.i386
> 
> So my question is should I be able to upgrade howl to a later version
> of is gnome-vfs2 dependant on that particular version. If I should be
> able to should I bugzilla it? I did a quick search and found a similar
> problems with gamin at bug #140679 but nothing specific to howl.
> 
> I want a version later than 0.9.6 to fix a problem that shows up in
> gnomemeeting 1.2.0. For the moment I have just upgraded with a
> --nodeps, not sure what havoc it'll cause with gnome-vf2 but for the
> moment aren't actually running X on this box.
> 
> Cheers
> Pete
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> <A HREF="http://www.redhat.com/mailman/listinfo/fedora-devel-list" TARGET="_blank">http://www.redhat.com/mailman/listinfo/fedora-devel-list</A>

10 Gigabyte Mailbox - mail.spray.se


From pbrobinson at gmail.com  Mon Dec 20 08:37:40 2004
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 20 Dec 2004 16:37:40 +0800
Subject: gnome-vfs2 and howl
In-Reply-To: <1103529974.8669.262.camel@greebo>
References: <5256d0b04121923391f348720@mail.gmail.com>
	<1103529974.8669.262.camel@greebo>
Message-ID: <5256d0b041220003775820561@mail.gmail.com>

On Mon, 20 Dec 2004 09:06:14 +0100, Alexander Larsson <alexl at redhat.com> wrote:
> On Mon, 2004-12-20 at 15:39 +0800, Peter Robinson wrote:
> > Hi All,
> >
> > I just tried upgrading my version of howl to the latest 0.9.8 by
> > downloading the source and the current SRPM, replacing the appropriate
> > lines and recompiling. All went well but the gnome-vfs2 had a
> > dependancy on libhowl-0.9.6.so.1
> >
> > So downloaded the SRPM for that to see if it was in there or a compile
> > time dep. Its seems its the later as the spec file specificly mentions
> > the >= howl and the associated packages. If I do a 'rpm -q --requires
> > gnome-vfs2' the specific library is mentioned.
> >
> > [root at morpheus i386]# rpm -Uvh howl-0.9.8-1.FC3.i386.rpm
> > howl-devel-0.9.8-1.FC3.i386.rpm howl-libs-0.9.8-1.FC3.i386.rpm
> > error: Failed dependencies:
> >         libhowl-0.9.6.so.1 is needed by (installed) gnome-vfs2-2.8.2-8.i386
> >
> > So my question is should I be able to upgrade howl to a later version
> > of is gnome-vfs2 dependant on that particular version. If I should be
> > able to should I bugzilla it? I did a quick search and found a similar
> > problems with gamin at bug #140679 but nothing specific to howl.
> >
> > I want a version later than 0.9.6 to fix a problem that shows up in
> > gnomemeeting 1.2.0. For the moment I have just upgraded with a
> > --nodeps, not sure what havoc it'll cause with gnome-vf2 but for the
> > moment aren't actually running X on this box.
> 
> Howl 0.9.6 doesn't handle upgrades like that because the library
> filename is "libhowl-0.9.6.so.1". An upgrade would break all apps
> linking to the old version.
> 
> I think this has been fixed in later versions of how, but atm you can't
> upgrade without also rebuilding all apps/libs that link to it.

Thanks for that Alexander,

Didn't think it would be that easy :-(

It appears, as far as the rpm dependancies goes, the only one that is
affected is the gnome-vfs2 package. At least as far as my FC3 box is
concerned.

Are there any plans to upgrade howl in either FC3 as a update or in
devel? It has some interesting bugs that affect at least the new
version of gnomemeeting. looks like the library versioning stuff was
fixed in 0.9.8

Cheers
Pete



From symbiont at berlios.de  Mon Dec 20 09:06:21 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Mon, 20 Dec 2004 17:06:21 +0800
Subject: Fedora Extras (was Re: RPM tools)
In-Reply-To: <1103528990.8869.48.camel@cutter>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
	<200412201440.07007.symbiont@berlios.de>
	<1103528990.8869.48.camel@cutter>
Message-ID: <200412201706.21536.symbiont@berlios.de>

On Monday 20 December 2004 15:49, seth vidal wrote:
> cool?

It's cool. Congrats to you and others going through all the politics to 
get this stuff through the pipe.  Obviously, it's a long time coming.  
Coming from a corp of around 3000 people and personally pushing several 
process changing initiatives, I know the timeframes and what it takes 
for things of this magnitude to happen.

I know you're not Redhat.  But, you're still very much in the know.

I don't want to debate, but rather work on helping on the technical 
details. That's why I recommended a specific project centered around 
the build system.

I think the endless thread opened up as the result of Extras lacking in 
clearly defined objectives.  Is it only FCX and FCX-1?  Or does the 
infra provide support to others?  Is it an endless pit of packages or 
is it moderated by Redhat? Etc. I'm certain these will be eventually 
resolved, but in the interim I wouldn't entirely discount these 
discussions as "needing to die" because they are healthy to talk about.  
Since they're coming from packagers that are being asked to join in to 
participate.

Lastly, remember that we're volunteers.  Well, those of us 
non- at redhat.com'ers anyway.  We want to help.  That's why we're still 
here (the weenies left last year).  If we sometimes come out with 
Clueless Idiot emails, I hope that that in itself will be a clue as to 
the lack of information out there.

Thanks for your answers, your blog, your yum, your info, your input.  It 
definitely allows us to gain insight into the process and allows me to 
say, yeah I'd like to dive in and help.

take care,
-- 
-jeff



From alexl at redhat.com  Mon Dec 20 09:21:56 2004
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 20 Dec 2004 10:21:56 +0100
Subject: gnome-vfs2 and howl
In-Reply-To: <5256d0b041220003775820561@mail.gmail.com>
References: <5256d0b04121923391f348720@mail.gmail.com>
	<1103529974.8669.262.camel@greebo>
	<5256d0b041220003775820561@mail.gmail.com>
Message-ID: <1103534516.8669.291.camel@greebo>

On Mon, 2004-12-20 at 16:37 +0800, Peter Robinson wrote:
> On Mon, 20 Dec 2004 09:06:14 +0100, Alexander Larsson <alexl at redhat.com> wrote:
> > On Mon, 2004-12-20 at 15:39 +0800, Peter Robinson wrote:
> > > Hi All,
> > >
> > > I just tried upgrading my version of howl to the latest 0.9.8 by
> > > downloading the source and the current SRPM, replacing the appropriate
> > > lines and recompiling. All went well but the gnome-vfs2 had a
> > > dependancy on libhowl-0.9.6.so.1
> > >
> > > So downloaded the SRPM for that to see if it was in there or a compile
> > > time dep. Its seems its the later as the spec file specificly mentions
> > > the >= howl and the associated packages. If I do a 'rpm -q --requires
> > > gnome-vfs2' the specific library is mentioned.
> > >
> > > [root at morpheus i386]# rpm -Uvh howl-0.9.8-1.FC3.i386.rpm
> > > howl-devel-0.9.8-1.FC3.i386.rpm howl-libs-0.9.8-1.FC3.i386.rpm
> > > error: Failed dependencies:
> > >         libhowl-0.9.6.so.1 is needed by (installed) gnome-vfs2-2.8.2-8.i386
> > >
> > > So my question is should I be able to upgrade howl to a later version
> > > of is gnome-vfs2 dependant on that particular version. If I should be
> > > able to should I bugzilla it? I did a quick search and found a similar
> > > problems with gamin at bug #140679 but nothing specific to howl.
> > >
> > > I want a version later than 0.9.6 to fix a problem that shows up in
> > > gnomemeeting 1.2.0. For the moment I have just upgraded with a
> > > --nodeps, not sure what havoc it'll cause with gnome-vf2 but for the
> > > moment aren't actually running X on this box.
> > 
> > Howl 0.9.6 doesn't handle upgrades like that because the library
> > filename is "libhowl-0.9.6.so.1". An upgrade would break all apps
> > linking to the old version.
> > 
> > I think this has been fixed in later versions of how, but atm you can't
> > upgrade without also rebuilding all apps/libs that link to it.
> 
> Thanks for that Alexander,
> 
> Didn't think it would be that easy :-(
> 
> It appears, as far as the rpm dependancies goes, the only one that is
> affected is the gnome-vfs2 package. At least as far as my FC3 box is
> concerned.
> 
> Are there any plans to upgrade howl in either FC3 as a update or in
> devel? It has some interesting bugs that affect at least the new
> version of gnomemeeting. looks like the library versioning stuff was
> fixed in 0.9.8

I don't have any specific plans for that. Its gonna appear in rawhide
shortly though, I think.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a superhumanly strong neurotic ex-con whom everyone believes is mad. 
She's a hard-bitten motormouth former first lady from aristocratic European 
stock. They fight crime! 



From ssc at coolspot.de  Mon Dec 20 10:06:59 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 11:06:59 +0100
Subject: FreeTDS
In-Reply-To: <20041218001738.519de929.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de>	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>	<41C32946.9090605@coolspot.de>
	<41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
Message-ID: <41C6A443.9080304@coolspot.de>

Michael Schwendt wrote:

>On Fri, 17 Dec 2004 20:33:00 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>I got rpms compiled under FC3.
>>They are available under
>>
>>http://www.coolspot.de/fedora-devel/
>>
>>Test them, please.
>>    
>>
>
>The src.rpm fails to build on FC3. Try to clean up your installation
>to find missing build dependencies:
>
>  http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires
>
>
>Other packaging mistakes after a brief look. In random order:
>
> * Main package must not contain files %_libdir/*.so
>   All these belong into the -devel package. Same applies to the
>   -unixodbc sub package. It must not include %_libdir/*.so either.
>   These files are needed at build-time only.
>
>
> * rpmlint reports a few relevant things:
>
>E: freetds summary-too-long FreeTDS is a free re-implementation of the TDS (Tabular DataStream) protocol that is used by Sybase and Microsoft for their database products.
>
> => better:  A free re-implementation of the TDS protocol
>
> Everything longer than ~70 characters ought to be put into the
> package description.
>
>
>W: freetds no-url-tag
>
> => You've put that into "Vendor:" field instead. Change that into
>    "URL: http://www.freetds.org" -- the vendor is the package vendor
>    and usually will be substituted by a build system automatically.
>
>
>E: freetds no-signature
>
> => minor issue for a test package - you didn't sign it with
>    your GPG key
>
>
>W: freetds strange-permission freetds.spec 0664
>
> => also unimportant, but a user who would extract the file into
>    /tmp would end up with a group-writable file
>
>
>W: freetds obsolete-tag Copyright
>
> => should be "License: LGPL" not "Copyright: LGPL"
>
>
>  
>
>>%define	name	freetds
>>%define	version	0.62.4
>> 
>>Name: %{name} 
>>Version: %{version} 
>>    
>>
>
>That construct is redundant. The %name and %version macros are defined
>by "Name:" and "Version:" already.
>
>
>  
>
>>%package devel 
>>Requires: freetds = %{version}
>>    
>>
>
>Better would be:
>
>  Requires: freetds = %{version}-%release
>
>Why? Imagine you apply a patch which patches the header files or other
>files in the -devel package or which fixes a bug in the main package.
>You want main package release and -devel package release to stay in
>sync. "yum update freetds-devel" should pull in the updated "freetds"
>main package, too.
>
>
>  
>
>>%post 
>>/sbin/ldconfig 
>>    
>>
>
>Better:
>
>  %post -p /sbin/ldconfig
>  %postun -p /sbin/ldconfig
>
>Why? It adds an automatic dependency on /sbin/ldconfig and updates the
>run-time linker cache also after package un-installation, when the
>freetds libraries are gone. Your %post script would be executed in
>/bin/sh.
>
>
>  
>
>>%configure --with-tdsver=4.2 --prefix=/usr --with-unixodbc=/usr/ --sysconfdir=%{_sysconfdir}
>>    
>>
>
>The %configure macro sets --prefix=%_prefix and --syconfdir=%_sysconfdir
>already. You can trim the line a bit. :)
>
>
>  
>
>>%doc AUTHORS BUGS COPYING ChangeLog INSTALL NEWS README TODO 
>>    
>>
>
>COPYING is GPL, which is not what's specified in "License:" field.
>File COPYING.LIB would be the LGPL and should be included.
>The INSTALL file contains generic instructions, which are irrelevant
>to the package user.
>
>
>  
>
>>%{_libdir}/libct.so*
>>    
>>
>
>Files with such non-unique names will likely cause conflicts in
>%_libdir in the future, when more and more packages share that
>directory and more projects use similar short names. This topic will
>come back in the near future as it will be necessary more often to
>install such libraries into %_libdir/%name/ and add that path to the
>run-time linker's search path list.
>
>Same with regard to some of the header names in %_includedir:
>
>  
>
>>-rw-r--r-- root  root      3036 /usr/include/bkpublic.h
>>-rw-r--r-- root  root     22514 /usr/include/cspublic.h
>>-rw-r--r-- root  root      1251 /usr/include/cstypes.h
>>-rw-r--r-- root  root      4492 /usr/include/ctpublic.h
>>-rw-r--r-- root  root      2207 /usr/include/dblib.h
>>-rw-r--r-- root  root      1096 /usr/include/sqldb.h
>>-rw-r--r-- root  root      1119 /usr/include/sqlfront.h
>>    
>>
>
>
>  
>
>>%package unixodbc
>>Requires: freetds = %{version}, unixODBC >= 2.2.9
>>    
>>
>
>Fedora Core 3 includes unixODBC 2.2.9, the dependency on libodbcinst.so.1
>is automatic, so the explicit dependency on a package called
>unixODBC doesn't add any value. Be careful with "explicit Requires".
>If Fedora Core 4 moved libodbcinst.so.1 into a package with a different
>name, this dependency would break.
>
>With regard to the freetds dependency, same as above.
>
>  
>
Thanks for your reply.
I'll upload changed files as soon as I got them ready.

Cheers,
Stefan



From alan at redhat.com  Mon Dec 20 10:36:35 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 20 Dec 2004 05:36:35 -0500
Subject: Questions regarding Linux Equivalents
In-Reply-To: <41C65E01.2030106@vsnl.net>
References: <20041219170005.7B70273C0C@hormel.redhat.com>
	<41C65E01.2030106@vsnl.net>
Message-ID: <20041220103635.GB26843@devserv.devel.redhat.com>

On Mon, Dec 20, 2004 at 10:37:13AM +0530, Kaustubh Ghosh wrote:
> Can someone please point out:
> 1.Linux Equivalent of prmap_t in solaris 2.5

Don't know Solaris from the engineering end

> 2.Linux Equivalent of Doskey in Dos/windows

>From the programming side - readline provides a library for doing nice
cursor editing and auto-completion. It's what the command line uses for example



From ssc at coolspot.de  Mon Dec 20 11:51:22 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 12:51:22 +0100
Subject: FreeTDS
In-Reply-To: <20041218001738.519de929.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de>	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>	<41C32946.9090605@coolspot.de>
	<41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
Message-ID: <41C6BCBA.9020205@coolspot.de>

You said that FC3 "comes" with unixODBC.
In fact, I did a clean install, and it does not.
I was in the need to install it manually.


Michael Schwendt schrieb:

>On Fri, 17 Dec 2004 20:33:00 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>I got rpms compiled under FC3.
>>They are available under
>>
>>http://www.coolspot.de/fedora-devel/
>>
>>Test them, please.
>>    
>>
>
>The src.rpm fails to build on FC3. Try to clean up your installation
>to find missing build dependencies:
>
>  http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires
>
>
>Other packaging mistakes after a brief look. In random order:
>
> * Main package must not contain files %_libdir/*.so
>   All these belong into the -devel package. Same applies to the
>   -unixodbc sub package. It must not include %_libdir/*.so either.
>   These files are needed at build-time only.
>
>
> * rpmlint reports a few relevant things:
>
>E: freetds summary-too-long FreeTDS is a free re-implementation of the TDS (Tabular DataStream) protocol that is used by Sybase and Microsoft for their database products.
>
> => better:  A free re-implementation of the TDS protocol
>
> Everything longer than ~70 characters ought to be put into the
> package description.
>
>
>W: freetds no-url-tag
>
> => You've put that into "Vendor:" field instead. Change that into
>    "URL: http://www.freetds.org" -- the vendor is the package vendor
>    and usually will be substituted by a build system automatically.
>
>
>E: freetds no-signature
>
> => minor issue for a test package - you didn't sign it with
>    your GPG key
>
>
>W: freetds strange-permission freetds.spec 0664
>
> => also unimportant, but a user who would extract the file into
>    /tmp would end up with a group-writable file
>
>
>W: freetds obsolete-tag Copyright
>
> => should be "License: LGPL" not "Copyright: LGPL"
>
>
>  
>
>>%define	name	freetds
>>%define	version	0.62.4
>> 
>>Name: %{name} 
>>Version: %{version} 
>>    
>>
>
>That construct is redundant. The %name and %version macros are defined
>by "Name:" and "Version:" already.
>
>
>  
>
>>%package devel 
>>Requires: freetds = %{version}
>>    
>>
>
>Better would be:
>
>  Requires: freetds = %{version}-%release
>
>Why? Imagine you apply a patch which patches the header files or other
>files in the -devel package or which fixes a bug in the main package.
>You want main package release and -devel package release to stay in
>sync. "yum update freetds-devel" should pull in the updated "freetds"
>main package, too.
>
>
>  
>
>>%post 
>>/sbin/ldconfig 
>>    
>>
>
>Better:
>
>  %post -p /sbin/ldconfig
>  %postun -p /sbin/ldconfig
>
>Why? It adds an automatic dependency on /sbin/ldconfig and updates the
>run-time linker cache also after package un-installation, when the
>freetds libraries are gone. Your %post script would be executed in
>/bin/sh.
>
>
>  
>
>>%configure --with-tdsver=4.2 --prefix=/usr --with-unixodbc=/usr/ --sysconfdir=%{_sysconfdir}
>>    
>>
>
>The %configure macro sets --prefix=%_prefix and --syconfdir=%_sysconfdir
>already. You can trim the line a bit. :)
>
>
>  
>
>>%doc AUTHORS BUGS COPYING ChangeLog INSTALL NEWS README TODO 
>>    
>>
>
>COPYING is GPL, which is not what's specified in "License:" field.
>File COPYING.LIB would be the LGPL and should be included.
>The INSTALL file contains generic instructions, which are irrelevant
>to the package user.
>
>
>  
>
>>%{_libdir}/libct.so*
>>    
>>
>
>Files with such non-unique names will likely cause conflicts in
>%_libdir in the future, when more and more packages share that
>directory and more projects use similar short names. This topic will
>come back in the near future as it will be necessary more often to
>install such libraries into %_libdir/%name/ and add that path to the
>run-time linker's search path list.
>
>Same with regard to some of the header names in %_includedir:
>
>  
>
>>-rw-r--r-- root  root      3036 /usr/include/bkpublic.h
>>-rw-r--r-- root  root     22514 /usr/include/cspublic.h
>>-rw-r--r-- root  root      1251 /usr/include/cstypes.h
>>-rw-r--r-- root  root      4492 /usr/include/ctpublic.h
>>-rw-r--r-- root  root      2207 /usr/include/dblib.h
>>-rw-r--r-- root  root      1096 /usr/include/sqldb.h
>>-rw-r--r-- root  root      1119 /usr/include/sqlfront.h
>>    
>>
>
>
>  
>
>>%package unixodbc
>>Requires: freetds = %{version}, unixODBC >= 2.2.9
>>    
>>
>
>Fedora Core 3 includes unixODBC 2.2.9, the dependency on libodbcinst.so.1
>is automatic, so the explicit dependency on a package called
>unixODBC doesn't add any value. Be careful with "explicit Requires".
>If Fedora Core 4 moved libodbcinst.so.1 into a package with a different
>name, this dependency would break.
>
>With regard to the freetds dependency, same as above.
>
>  
>



From fedora at wir-sind-cool.org  Mon Dec 20 12:17:05 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 13:17:05 +0100
Subject: FreeTDS
In-Reply-To: <41C6BCBA.9020205@coolspot.de>
References: <41C2E2A2.1020501@coolspot.de>
	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>
	<41C32946.9090605@coolspot.de> <41C3346C.7000509@coolspot.de>
	<20041218001738.519de929.fedora@wir-sind-cool.org>
	<41C6BCBA.9020205@coolspot.de>
Message-ID: <20041220131705.6cc10476.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 12:51:22 +0100, Stefan Sonnenberg-Carstens wrote:

> You said that FC3 "comes" with unixODBC.
> In fact, I did a clean install, and it does not.
> I was in the need to install it manually.

You misread my comment. Let's see:

> >>%package unixodbc
> >>Requires: freetds = %{version}, unixODBC >= 2.2.9
> >>    
> >>
> >
> >Fedora Core 3 includes unixODBC 2.2.9, the dependency on libodbcinst.so.1
> >is automatic, so the explicit dependency on a package called
> >unixODBC doesn't add any value. Be careful with "explicit Requires".
> >If Fedora Core 4 moved libodbcinst.so.1 into a package with a different
> >name, this dependency would break.

Rephrased: In Fedora Core 3, unixODBC 2.2.9 is included, even it it
may not be installed by default. That means, the version of unixODBC
available in FC3 is sufficient for your requirements. When your
package is built, it will include an automatic dependency on
libodbcinst.so.1, which will cause package tools to select the package
that provides libodbcinst.so.1. No need to specify an explicit
dependency on a fixed package name and a minimal version which is
included in FC3 anyway. [Remainder of my comment unchanged]

HTH



From buildsys at redhat.com  Mon Dec 20 12:28:58 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 20 Dec 2004 07:28:58 -0500
Subject: rawhide report: 20041220 changes
Message-ID: <200412201228.iBKCSwn01823@porkchop.devel.redhat.com>

 

 
Updated Packages:

bootparamd-0.17-19
------------------
* Mon Dec 20 2004 Martin Stransky <stransky at redhat.com>
- fast DNS look-up extension

dev86-0.16.16-2
---------------
* Sun Dec 19 2004 Miloslav Trmac <mitr at redhat.com> - 0.16.16-2
- Fix invalid memory allocation in bcc.c:build_prefix () (#143325)

devhelp-0.9.3-2
---------------
* Sun Dec 19 2004 Christopher Aillon <caillon at redhat.com> 0.9.3-2
- Require mozilla 1.7.5

* Sun Dec 19 2004 Christopher Aillon <caillon at redhat.com> 0.9.3-1
- Update to 0.9.3

evolution-2.0.3-2
-----------------
* Sun Dec 19 2004 Christopher Aillon <caillon at redhat.com> 2.0.3-2
- Rebuild against mozilla 1.7.5

gimp-2:2.2.0-1
--------------
* Mon Dec 20 2004 Nils Philippsen <nphilipp at redhat.com>
- version 2.2.0
- include pygimp-logo.png missing from tarball

gnumeric-1:1.4.1-4
------------------
* Sun Dec 19 2004 Caolan McNamara <caolanm at redhat.com> 1.4.1-4
- libgsf must be >= 1.10.0

grub-0.95-5
-----------
* Fri Dec 17 2004 Peter Jones <pjones at redhat.com> 0.95-5
- added support for RAID1 devices to grub-install, partly based on a
  patch from David Knierim. (#114690)

krb5-1.3.5-7
------------
* Mon Dec 20 2004 Martin Stransky <stransky at redhat.com> 1.3.5-7
- fix deadlock during file transfer via rsync/krsh
- thanks goes to James Antil for hint

* Fri Nov 26 2004 Nalin Dahyabhai <nalin at redhat.com> 1.3.5-6
- rebuild

* Mon Nov 22 2004 Nalin Dahyabhai <nalin at redhat.com> 1.3.5-3
- fix predictable-tempfile-name bug in krb5-send-pr (CAN-2004-0971, #140036)

mozilla-37:1.7.5-1
------------------
* Fri Dec 17 2004 Christopher Aillon <caillon at redhat.com> 37:1.7.5-1
- Update to 1.7.5

openh323-1.15.2-1
-----------------
* Sun Dec 19 2004 Daniel Reed <djr at redhat.com> 1.15.2-1
- version bump for GnomeMeeting 1.2

pwlib-1.8.3-1
-------------
* Sun Dec 19 2004 Daniel Reed <djr at redhat.com> 1.8.3-1
- version bump for GnomeMeeting 1.2

rpmdb-fedora-1:4-0.20041220
---------------------------

sylpheed-1.0.0-0.1.rc
---------------------
* Mon Dec 20 2004 Akira TAGOH <tagoh at redhat.com> - 1.0.0-0.1.rc
- New upstream release.



From ssc at coolspot.de  Mon Dec 20 12:48:42 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 13:48:42 +0100
Subject: FreeTDS
In-Reply-To: <20041220131705.6cc10476.fedora@wir-sind-cool.org>
References: <41C2E2A2.1020501@coolspot.de>	<4552C560-503A-11D9-A358-000D9350AFAA@carwyn.com>	<41C32946.9090605@coolspot.de>
	<41C3346C.7000509@coolspot.de>	<20041218001738.519de929.fedora@wir-sind-cool.org>	<41C6BCBA.9020205@coolspot.de>
	<20041220131705.6cc10476.fedora@wir-sind-cool.org>
Message-ID: <41C6CA2A.9090002@coolspot.de>

Thanks, I got it ;-)


Michael Schwendt schrieb:

>On Mon, 20 Dec 2004 12:51:22 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>You said that FC3 "comes" with unixODBC.
>>In fact, I did a clean install, and it does not.
>>I was in the need to install it manually.
>>    
>>
>
>You misread my comment. Let's see:
>
>  
>
>>>>%package unixodbc
>>>>Requires: freetds = %{version}, unixODBC >= 2.2.9
>>>>   
>>>>
>>>>        
>>>>
>>>Fedora Core 3 includes unixODBC 2.2.9, the dependency on libodbcinst.so.1
>>>is automatic, so the explicit dependency on a package called
>>>unixODBC doesn't add any value. Be careful with "explicit Requires".
>>>If Fedora Core 4 moved libodbcinst.so.1 into a package with a different
>>>name, this dependency would break.
>>>      
>>>
>
>Rephrased: In Fedora Core 3, unixODBC 2.2.9 is included, even it it
>may not be installed by default. That means, the version of unixODBC
>available in FC3 is sufficient for your requirements. When your
>package is built, it will include an automatic dependency on
>libodbcinst.so.1, which will cause package tools to select the package
>that provides libodbcinst.so.1. No need to specify an explicit
>dependency on a fixed package name and a minimal version which is
>included in FC3 anyway. [Remainder of my comment unchanged]
>
>HTH
>
>  
>



From christopher.blizzard at gmail.com  Fri Dec 17 20:12:51 2004
From: christopher.blizzard at gmail.com (Chris Blizzard)
Date: Fri, 17 Dec 2004 15:12:51 -0500
Subject: Choice of default fonts in webrowsers
In-Reply-To: <1103230340.4702.5.camel@kyrre>
References: <1103230340.4702.5.camel@kyrre>
Message-ID: <eab5d65c04121712125125920@mail.gmail.com>

The fonts are driven by fontconfig.  So it's up to the system config
to do the mapping.

--Chris


On Thu, 16 Dec 2004 21:52:46 +0100, Kyrre Ness Sjobak
<kyrre at solution-forge.net> wrote:
> Hello
> 
> After reading to much forums, i can se "everyone" is complaing about
> "the default font in (put your favorite web browser here) is so ugly, it
> is hardly readable!"
> 
> Then the reply is "use Bitstream vera (sans) instead" and then "oh! that
> was better! it was really readable! nice!"
> 
> Why is it so? Why is those fonts, which it seem like "everyone" thinks
> are really ugly are used, when better fonts are shipped?
> 
> I would guess there are more people than me who has opinions on this.
> 
> Disclaimer: i am forwarding a "general feeling" from parts of the
> comunity, as not everyone are on this list. But after changing my
> default fonts in firefox, i must say i agree. This was *much* better!
> 
> Kyrre Ness Sj?b?k
> 
> --
> Fedora-desktop-list mailing list
> Fedora-desktop-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-desktop-list
>



From Peter.Dedecker at vtk2.UGent.be  Sun Dec 19 02:10:03 2004
From: Peter.Dedecker at vtk2.UGent.be (Peter Dedecker)
Date: Sun, 19 Dec 2004 02:10:03 +0000
Subject: Fedora Stateless: stateless-snapshooter modified
Message-ID: <41C4E2FB.6020903@VTK.UGent.be>

Hi,

I've made some changes to stateless-snapshooter.py to make it work 
without X and pyGTK.  I don't know much about Python, so please, can 
someone take a look at it and give some feedback?  The changes are 
listed at http://blog.eikke.com/index.php/fedorastateless and I can give 
a diff-output if you want.

Thanks!

-- 
Peter Dedecker
The Fedora Stateless @ UGent project



From overholt at redhat.com  Mon Dec 20 15:10:28 2004
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 20 Dec 2004 10:10:28 -0500
Subject: RPM tools
In-Reply-To: <1103512418.3226.1.camel@p.linuxcenter.cl>
References: <1103512418.3226.1.camel@p.linuxcenter.cl>
Message-ID: <20041220151028.GA14837@redhat.com>

* Patricio Bruna V <pbruna at linuxcenterla.com> [2004-12-19 22:06]:
> hi, im looking tools for work with rpms.
> 
> what kind of tools?
> 
> 1. Let me easier build packages.

If you're into Eclipse, you could check out the RPM plugin:

http://tinyurl.com/6n5n5

http://sources.redhat.com/ml/eclipse/2004-q4/msg00000.html

Andrew



From mpeters at mac.com  Mon Dec 20 15:20:27 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Mon, 20 Dec 2004 15:20:27 +0000
Subject: firefox and icons...
In-Reply-To: <41C4D583.5010503@silverorange.com> (from
	stevelist@silverorange.com on Sat Dec 18 17:12:35 2004)
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
	<41C4B9B1.6010402@silverorange.com>
	<1103413973.5679.73.camel@localhost.localdomain>
	<41C4C2C5.6020508@silverorange.com>
	<1103418604.5679.75.camel@localhost.localdomain>
	<41C4D583.5010503@silverorange.com>
Message-ID: <1103556027l.20171l.5l@devel.mpeters.us>

On 12/18/2004 05:12:35 PM, Steven Garrity wrote:

> 
> I do think it is time to have another go at a great modern Gnome  
> theme. Both Bluecurve and the default Gnome theme are showing their  
> age.

This (FC3) is the first time I really like Bluecurve, and I really  
liked it - enough that it's what I use, except I use Smokey-Blue icons.

If Bluecurve is showing its age, either it's a fine wine (as I think it  
has gotten better) or I'm showing my age ... a distinct possibility ;)




From ssc at coolspot.de  Mon Dec 20 15:50:48 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 16:50:48 +0100
Subject: FreeTDS
Message-ID: <41C6F4D8.7030102@coolspot.de>

Packages are updatet and available under
http://www.coolspot.de/fedora-devel/.
Please test them, if you can.

*They have not reached production quality* ( yet ;-) )

Thanks to whom made suggestions ( mostly Michael Schwendt ).
I tried to fix what I could, but a few questions are left :
Shared libs are now into /usr/lib/freetds/, which is fine.
Is ldconfig aware ?  Or do I need to tell rpm to make an entry in 
ld.so.conf ?
Is there a "magical" way to let rpm do it ?
Michael Schwendt mentioned to check for extra (terrestrial) dependencies,
and I found fedora-rpmdevtools.
Where are these beasts ?

Cheers,
Stefan Sonnenberg-Carstens



From fedora at wir-sind-cool.org  Mon Dec 20 16:12:32 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 17:12:32 +0100
Subject: FreeTDS
In-Reply-To: <41C6F4D8.7030102@coolspot.de>
References: <41C6F4D8.7030102@coolspot.de>
Message-ID: <20041220171232.2c40d213.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:

> Packages are updatet and available under
> http://www.coolspot.de/fedora-devel/.
> Please test them, if you can.
> 
> *They have not reached production quality* ( yet ;-) )
> 
> Thanks to whom made suggestions ( mostly Michael Schwendt ).
> I tried to fix what I could, but a few questions are left :

You've missed several of the comments, though.

> Shared libs are now into /usr/lib/freetds/, which is fine.
> Is ldconfig aware ?  Or do I need to tell rpm to make an entry in 
> ld.so.conf ?
> Is there a "magical" way to let rpm do it ?

Not necessary. Didn't you wonder that the executables included in
the freetds package find the libraries in /usr/lib/freetds just fine?
See e.g. output of "ldd /usr/bin/freebcp". RPATH magic.

> Michael Schwendt mentioned to check for extra (terrestrial) dependencies,
> and I found fedora-rpmdevtools.
> Where are these beasts ?

http://fedoraproject.org/wiki/fedora_2drpmdevtools
 



From fedora at wir-sind-cool.org  Mon Dec 20 16:14:36 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 17:14:36 +0100
Subject: FreeTDS
In-Reply-To: <41C6F4D8.7030102@coolspot.de>
References: <41C6F4D8.7030102@coolspot.de>
Message-ID: <20041220171436.5f691d0c.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:

> Packages are updatet and available under
> http://www.coolspot.de/fedora-devel/.
> Please test them, if you can.
> 
> *They have not reached production quality* ( yet ;-) )
> 
> Thanks to whom made suggestions ( mostly Michael Schwendt ).
> I tried to fix what I could, but a few questions are left :
> Shared libs are now into /usr/lib/freetds/, which is fine.
> Is ldconfig aware ?

ldconfig does not search in /usr/lib/freetds, so running it makes
no sense.



From walters at redhat.com  Mon Dec 20 16:15:36 2004
From: walters at redhat.com (Colin Walters)
Date: Mon, 20 Dec 2004 11:15:36 -0500
Subject: svn or arch
In-Reply-To: <20041220044906.GA22942@rogers.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
Message-ID: <1103559336.3135.8.camel@nexus.verbum.private>

On Sun, 2004-12-19 at 23:49 -0500, Dimitrie O. Paun wrote:

> That's an idea that I've been playing with myself. 

You also have a build system?

> However, I want to
> be able to generate SRPMS from it too, preferably generating the PatchN
> series of patches. Problem is that with PatchN you have an ordering for
> the patches, whereas with the direct branching from the upstream source
> you don't. And I don't quite see how a new branch for interdependent branches
> would work in practice.

You'd do something like this in the spec file:

Branch: 64bitfixes
RefBranch: iconcache
RefBranch: pixbufext
Branch: iconpixbuf (iconcache, pixbufext)

So 64bitfixes here is a normal branch that is merged, and doesn't
conflict with anything else.  iconcache and pixbufext are branches that
conflict.  So you create a new branch iconpixbuf that merges from both
of those.  The merging would be manual, instead of automatic as for
normal Branch:.  RefBranch just notes in the spec file that this is an
active branch, but it isn't used directly by the build system at all.

> However, I think we can avoid all sorts of problems, if instead of branching
> from the source, we branch from the brances -- this would give us the
> ordering. 

Yes, that's definitely a possibility too.  I'm not sure honestly which
would work better in practice until someone actually writes the system
and we start using it for nontrivial packages.




From ssc at coolspot.de  Mon Dec 20 16:22:38 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 17:22:38 +0100
Subject: FreeTDS
In-Reply-To: <20041220171436.5f691d0c.fedora@wir-sind-cool.org>
References: <41C6F4D8.7030102@coolspot.de>
	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>
Message-ID: <41C6FC4E.6030205@coolspot.de>

Michael Schwendt wrote:

>On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>Packages are updatet and available under
>>http://www.coolspot.de/fedora-devel/.
>>Please test them, if you can.
>>
>>*They have not reached production quality* ( yet ;-) )
>>
>>Thanks to whom made suggestions ( mostly Michael Schwendt ).
>>I tried to fix what I could, but a few questions are left :
>>Shared libs are now into /usr/lib/freetds/, which is fine.
>>Is ldconfig aware ?
>>    
>>
>
>ldconfig does not search in /usr/lib/freetds, so running it makes
>no sense.
>
>  
>
I know that, at least for older versions.
Therefore my question about adding an entry to ld.so.conf



From bpm at ec-group.com  Mon Dec 20 16:19:50 2004
From: bpm at ec-group.com (Brian Millett)
Date: Mon, 20 Dec 2004 10:19:50 -0600 (CST)
Subject: selinux targeted error message
Message-ID: <19842.12.41.112.51.1103559590.squirrel@webmail.ec-group.com>

Hi, I am running rawhide on a laptop with selinux targeted
(selinux-policy-targeted-1.19.14-3) and I get the following in the
/var/log/messages

Dec 20 07:25:32 localhost kernel: audit(1103549132.867:0): avc:  denied  {
create } for  pid=2983 exe=/sbin/udev name=class at vc@vcsa7
scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:tty_device_t tclass=file
Dec 20 07:25:32 localhost kernel: audit(1103549132.881:0): avc:  denied  {
create } for  pid=2978 exe=/sbin/udev name=class at vc@vcs7
scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:tty_device_t tclass=file

How do I determine what to fix?

I have:
ls -Z /sbin/udev
-rwxr-xr-x  root     root     system_u:object_r:udev_exec_t    /sbin/udev
ls -Z /dev/vcsa7
crw-------  vcsa     tty      system_u:object_r:tty_device_t   /dev/vcsa7

Does this mean that some user command tried to modify /dev/vcsa7 ?

Thanks.

-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn





From rc040203 at freenet.de  Mon Dec 20 16:40:21 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 20 Dec 2004 17:40:21 +0100
Subject: FreeTDS
In-Reply-To: <41C6FC4E.6030205@coolspot.de>
References: <41C6F4D8.7030102@coolspot.de>
	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>
	<41C6FC4E.6030205@coolspot.de>
Message-ID: <1103560821.4792.53.camel@mccallum.corsepiu.local>

On Mon, 2004-12-20 at 17:22 +0100, Stefan Sonnenberg-Carstens wrote:
> Michael Schwendt wrote:
> 
> >On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:

> >ldconfig does not search in /usr/lib/freetds, so running it makes
> >no sense.

Installing to /usr/lib/freetds also rarely makes any sense.

> I know that, at least for older versions.
> Therefore my question about adding an entry to ld.so.conf
Install to /usr/lib, instead.

Ralf




From fedora at wir-sind-cool.org  Mon Dec 20 16:44:13 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 17:44:13 +0100
Subject: FreeTDS
In-Reply-To: <41C6FC4E.6030205@coolspot.de>
References: <41C6F4D8.7030102@coolspot.de>
	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>
	<41C6FC4E.6030205@coolspot.de>
Message-ID: <20041220174413.203c6712.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 17:22:38 +0100, Stefan Sonnenberg-Carstens wrote:

> Michael Schwendt wrote:
> 
> >On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:
> >
> >  
> >
> >>Packages are updatet and available under
> >>http://www.coolspot.de/fedora-devel/.
> >>Please test them, if you can.
> >>
> >>*They have not reached production quality* ( yet ;-) )
> >>
> >>Thanks to whom made suggestions ( mostly Michael Schwendt ).
> >>I tried to fix what I could, but a few questions are left :
> >>Shared libs are now into /usr/lib/freetds/, which is fine.
> >>Is ldconfig aware ?
> >>    
> >>
> >
> >ldconfig does not search in /usr/lib/freetds, so running it makes
> >no sense.
> >
> >  
> >
> I know that, at least for older versions.
> Therefore my question about adding an entry to ld.so.conf

If you did that (e.g. via /etc/ld.so.conf.d), all libraries within the
added directory would enter the global namespace again. Not
desirable. The only remaining benefit would be, that static libs and
libtool archives would be in the private namespace.



From ssc at coolspot.de  Mon Dec 20 16:43:48 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 17:43:48 +0100
Subject: FreeTDS
In-Reply-To: <1103560821.4792.53.camel@mccallum.corsepiu.local>
References: <41C6F4D8.7030102@coolspot.de>	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>	<41C6FC4E.6030205@coolspot.de>
	<1103560821.4792.53.camel@mccallum.corsepiu.local>
Message-ID: <41C70144.9070002@coolspot.de>

Ralf Corsepius wrote:

>On Mon, 2004-12-20 at 17:22 +0100, Stefan Sonnenberg-Carstens wrote:
>  
>
>>Michael Schwendt wrote:
>>
>>    
>>
>>>On Mon, 20 Dec 2004 16:50:48 +0100, Stefan Sonnenberg-Carstens wrote:
>>>      
>>>
>
>  
>
>>>ldconfig does not search in /usr/lib/freetds, so running it makes
>>>no sense.
>>>      
>>>
>
>Installing to /usr/lib/freetds also rarely makes any sense.
>
>  
>
>>I know that, at least for older versions.
>>Therefore my question about adding an entry to ld.so.conf
>>    
>>
>Install to /usr/lib, instead.
>
>Ralf
>
>
>  
>
Ok, should I prevent shared lib polution, or not ?
Is there a policy that comments on that issue ?
Why does it *not* make sense ?
It's perfectly leagal and makes sense in every way to me.
Cheers,
Stefan



From shahms at shahms.com  Mon Dec 20 16:49:17 2004
From: shahms at shahms.com (Shahms King)
Date: Mon, 20 Dec 2004 08:49:17 -0800
Subject: Choice of default fonts in webrowsers
In-Reply-To: <eab5d65c04121712125125920@mail.gmail.com>
References: <1103230340.4702.5.camel@kyrre>
	<eab5d65c04121712125125920@mail.gmail.com>
Message-ID: <1103561357.17224.3.camel@shahms.mesd.k12.or.us>

On Fri, 2004-12-17 at 15:12 -0500, Chris Blizzard wrote:
> The fonts are driven by fontconfig.  So it's up to the system config
> to do the mapping.
> 
> --Chris

Yes, and right now, by default, fontconfig prefers the Nimbus/Luxi fonts
over the Bitstream fonts. I have manually modified /etc/fonts/local.conf
to fix this problem, but it would be nice to have /etc/fonts/fonts.conf
have that as the default. At the moment, the Bitstream fonts are listed
as the second or third preferred font for serif, sans-serf and
monospace. 

> On Thu, 16 Dec 2004 21:52:46 +0100, Kyrre Ness Sjobak
> <kyrre at solution-forge.net> wrote:
> > Hello
> > 
> > After reading to much forums, i can se "everyone" is complaing about
> > "the default font in (put your favorite web browser here) is so ugly, it
> > is hardly readable!"
> > 
> > Then the reply is "use Bitstream vera (sans) instead" and then "oh! that
> > was better! it was really readable! nice!"
> > 
> > Why is it so? Why is those fonts, which it seem like "everyone" thinks
> > are really ugly are used, when better fonts are shipped?
> > 
> > I would guess there are more people than me who has opinions on this.
> > 
> > Disclaimer: i am forwarding a "general feeling" from parts of the
> > comunity, as not everyone are on this list. But after changing my
> > default fonts in firefox, i must say i agree. This was *much* better!
> > 
> > Kyrre Ness Sj?b?k
> > 
> > --
> > Fedora-desktop-list mailing list
> > Fedora-desktop-list at redhat.com
> > http://www.redhat.com/mailman/listinfo/fedora-desktop-list
> >
> 
-- 
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041220/b03ae0c9/attachment.sig>

From walters at redhat.com  Mon Dec 20 16:53:47 2004
From: walters at redhat.com (Colin Walters)
Date: Mon, 20 Dec 2004 11:53:47 -0500
Subject: svn or arch
In-Reply-To: <200412181712.56837.dries@ulyssis.org>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
	<200412181712.56837.dries@ulyssis.org>
Message-ID: <1103561627.3135.32.camel@nexus.verbum.private>

On Sat, 2004-12-18 at 17:12 +0100, Dries Verachtert wrote:

> I'm using a PostgreSQL database to store all this information and also a lot 
> of meta information about each rpm. 

Ah ok, cool.  Is this build system available anywhere?  I'd be
interested to see how you're using postgres.

> My scripts only add the svn commit revision before a spec file is used for a 
> rebuild. That modified spec file which contains the svn commit revision is 
> not checked in again. It's only used for the rebuild. 

Hmm.  So the Subversion repository revision is shared among all
packages?  That probably works, but it seems nicer to preserve the
natural ordering of package versions, with e.g. foo-1.2-3 -> foo-1.2-4
instead of foo-1.2-458 -> foo-1.2-7624.




From jamesaharrisonuk at yahoo.co.uk  Mon Dec 20 16:57:04 2004
From: jamesaharrisonuk at yahoo.co.uk (James Harrison)
Date: Mon, 20 Dec 2004 08:57:04 -0800 (PST)
Subject: [ RHEL4 == Fedora core 3 ]
Message-ID: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>

All,

Are the two products the same?

What are the two differences?

James

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From fedora at wir-sind-cool.org  Mon Dec 20 17:00:13 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 18:00:13 +0100
Subject: FreeTDS
In-Reply-To: <41C70144.9070002@coolspot.de>
References: <41C6F4D8.7030102@coolspot.de>
	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>
	<41C6FC4E.6030205@coolspot.de>
	<1103560821.4792.53.camel@mccallum.corsepiu.local>
	<41C70144.9070002@coolspot.de>
Message-ID: <20041220180013.7c8340d6.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 17:43:48 +0100, Stefan Sonnenberg-Carstens wrote:

> Ok, should I prevent shared lib polution, or not ?

You should be aware of it. That's all. You can always apply a
first-come-first-served rule and resolve conflicts when they occur. 
Please read my original reply again, in particular because you missed
several comments on mistakes in your package.

Btw, searching Google for libct.so.x, x=[0,1,2] point to freetds,
x=[3,4,8,9,10] point to Sybase, x=[5,6] point to a CTAPI driver. So,
the name libct is shared already.



From jos at xos.nl  Mon Dec 20 17:00:53 2004
From: jos at xos.nl (Jos Vos)
Date: Mon, 20 Dec 2004 18:00:53 +0100
Subject: [ RHEL4 == Fedora core 3 ]
In-Reply-To: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>;
	from jamesaharrisonuk@yahoo.co.uk on Mon, Dec 20, 2004 at
	08:57:04AM -0800
References: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>
Message-ID: <20041220180053.A22682@xos037.xos.nl>

On Mon, Dec 20, 2004 at 08:57:04AM -0800, James Harrison wrote:

> Are the two products the same?

No.

> What are the two differences?

After RHEL4 is released, which will probably take another few months,
people will be happy to tell you that ;-).

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From fedora at wir-sind-cool.org  Mon Dec 20 17:01:31 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 20 Dec 2004 18:01:31 +0100
Subject: [ RHEL4 == Fedora core 3 ]
In-Reply-To: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>
References: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>
Message-ID: <20041220180131.2483a77e.fedora@wir-sind-cool.org>

On Mon, 20 Dec 2004 08:57:04 -0800 (PST), James Harrison wrote:

> All,
> 
> Are the two products the same?
> 
> What are the two differences?

http://fedora.redhat.com/about/rhel.html



From mike at mommabears.com  Mon Dec 20 17:24:29 2004
From: mike at mommabears.com (MJang)
Date: Mon, 20 Dec 2004 09:24:29 -0800
Subject: [ RHEL4 == Fedora core 3 ]
In-Reply-To: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>
References: <20041220165704.67732.qmail@web25309.mail.ukl.yahoo.com>
Message-ID: <1103563470.6299.5.camel@suse1.site>

Dear James, 

On Mon, 2004-12-20 at 08:57 -0800, James Harrison wrote:
> Are the two products the same?

While the two products are - not - the same, Red Hat has announced that
it will base RHEL 4 on Fedora Core 3. 

In a similar vein, RHEL 3 is based on Red Hat Linux 9. I remember doing
a diff on the package names, and about 25% were identical (and I think
another 25% were similar enough to make little difference). RHEL 3 final
ended up with about 400 fewer packages. The beta for RHEL 4 certainly
looks similar to FC 3. Whether RHEL 4 final follows the same pattern is
TBD.

Thanks,
Mike



From dpaun at rogers.com  Mon Dec 20 17:28:07 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 20 Dec 2004 12:28:07 -0500
Subject: Fedora Stateless: stateless-snapshooter modified
In-Reply-To: <41C4E2FB.6020903@VTK.UGent.be>
References: <41C4E2FB.6020903@VTK.UGent.be>
Message-ID: <20041220172807.GA24832@rogers.com>

On Sun, Dec 19, 2004 at 02:10:03AM +0000, Peter Dedecker wrote:
> someone take a look at it and give some feedback?  The changes are 
> listed at http://blog.eikke.com/index.php/fedorastateless and I can give 
> a diff-output if you want.

Yes, a diff -u would be much appreciated.

-- 
Dimi.



From jamesaharrisonuk at yahoo.co.uk  Mon Dec 20 17:50:32 2004
From: jamesaharrisonuk at yahoo.co.uk (James Harrison)
Date: Mon, 20 Dec 2004 09:50:32 -0800 (PST)
Subject: [ RHEL4 == Fedora core 3 ]
In-Reply-To: <20041220180131.2483a77e.fedora@wir-sind-cool.org>
Message-ID: <20041220175032.76012.qmail@web25309.mail.ukl.yahoo.com>

I know about the official reresponse..

Is the software the same.. Has someone done an RPM version comparison?

James

--- Michael ScSchwendtfedora at wiwirisindool.ororgwrote:

> On Mon, 20 Dec 2004 08:57:04 -0800 (PST), James Harrison wrote:
> 
> > All,
> > 
> > Are the two products the same?
> > 
> > What are the two differences?
> 
> hthttp/fedora.reredhatom/about/rhrhelthtml> 
> -- 
> fedora-dedevelist mailing list
> fedora-dedevelist at reredhatom
> hthttp/wwwwweredhatom/mailman/lilistinfoedora-dedevelist
> 



		
__________________________________ 
Do you Yahoo!? 
Send a seasonal email greeting and help others. Do good. 
http://celebrity.mail.yahoo.com



From jos at xos.nl  Mon Dec 20 17:58:07 2004
From: jos at xos.nl (Jos Vos)
Date: Mon, 20 Dec 2004 18:58:07 +0100
Subject: [ RHEL4 == Fedora core 3 ]
In-Reply-To: <20041220175032.76012.qmail@web25309.mail.ukl.yahoo.com>;
	from jamesaharrisonuk@yahoo.co.uk on Mon, Dec 20, 2004 at
	09:50:32AM -0800
References: <20041220180131.2483a77e.fedora@wir-sind-cool.org>
	<20041220175032.76012.qmail@web25309.mail.ukl.yahoo.com>
Message-ID: <20041220185807.A22943@xos037.xos.nl>

On Mon, Dec 20, 2004 at 09:50:32AM -0800, James Harrison wrote:

> I know about the official reresponse..
> 
> Is the software the same.. Has someone done an RPM version comparison?
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If would have a time machine, I would have already done it
(i.s.o. in a few months, *after* RHEL4 is out)... ;-)

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From kyrre at solution-forge.net  Mon Dec 20 19:03:38 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Mon, 20 Dec 2004 20:03:38 +0100
Subject: OpenOffice Memory Bloat?
In-Reply-To: <Pine.LNX.4.58.0412192139290.20343@devserv.devel.redhat.com>
References: <20041217232917.67356.qmail@web8509.mail.in.yahoo.com>
	<1103488872.2729.38.camel@kyrre>
	<Pine.LNX.4.58.0412192139290.20343@devserv.devel.redhat.com>
Message-ID: <1103569418.2728.3.camel@kyrre>

man, 20.12.2004 kl. 03.46 skrev Dan Williams:
> On Sun, 19 Dec 2004, Kyrre Ness Sjobak wrote:
> > However, this bug is *OLD*, and hugely annoying. What about fixing it
> > (i.e. disabling the "check if this is correct in every other existing
> > language" functionality)?
> 
> Unfortunately, that doesn't do it.  OOo will still load every dictionary 
> in the dictionary.lst file anyway, it just won't _check_ with them when 
> that's unchecked.  It will still suggest them though.  I took a couple 
> hours to go through the code (lingucomponent and linguistic modules in OOo 
> CVS) and its quite broken in some respects, especially dictionary loading.  
> There is no option to tell the spelling suggester to only check in the 
> current language.
> 

I meant to kill'em from the .lst file and then rm -rf them. MUHAHA.

> Besides, you don't want to only check in the current language, you may 
> wish to check in English and French for example.  However, unchecking 
> stuff in the Writing Aids->Edit boxes doesn't work (at least when I tried 
> it).
> 
> This appears to be a bug, since this works correctly in upstream 1.1.3.
> 

A packaging/"local to RH" one also...

> After the holidays we'll be working on merging our local patches back up 
> to ooo-build and then jumping to 1.1.3 and pushing that down as an update.  
> Language packs will be split out too, but that might come after the 1.1.3 
> update.
> 

When will the 1.1.3 update be? Looking foreward. OO is getting steadly
better, and as far as i have heard, 2.0 will be even better. :D

Kyrre



From ssc at coolspot.de  Mon Dec 20 19:44:11 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 20:44:11 +0100
Subject: FreeTDS
In-Reply-To: <20041220180013.7c8340d6.fedora@wir-sind-cool.org>
References: <41C6F4D8.7030102@coolspot.de>	<20041220171436.5f691d0c.fedora@wir-sind-cool.org>	<41C6FC4E.6030205@coolspot.de>	<1103560821.4792.53.camel@mccallum.corsepiu.local>	<41C70144.9070002@coolspot.de>
	<20041220180013.7c8340d6.fedora@wir-sind-cool.org>
Message-ID: <41C72B8B.10803@coolspot.de>

Michael Schwendt wrote:

>On Mon, 20 Dec 2004 17:43:48 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>Ok, should I prevent shared lib polution, or not ?
>>    
>>
>
>You should be aware of it. That's all. You can always apply a
>first-come-first-served rule and resolve conflicts when they occur. 
>Please read my original reply again, in particular because you missed
>several comments on mistakes in your package.
>
>Btw, searching Google for libct.so.x, x=[0,1,2] point to freetds,
>x=[3,4,8,9,10] point to Sybase, x=[5,6] point to a CTAPI driver. So,
>the name libct is shared already.
>
>  
>
I'll try to elimate the errors.
Time is on my side ...



From dpaun at rogers.com  Mon Dec 20 19:52:45 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 20 Dec 2004 14:52:45 -0500
Subject: svn or arch
In-Reply-To: <1103559336.3135.8.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
Message-ID: <20041220195245.GB24832@rogers.com>

On Mon, Dec 20, 2004 at 11:15:36AM -0500, Colin Walters wrote:
> On Sun, 2004-12-19 at 23:49 -0500, Dimitrie O. Paun wrote:
> 
> > That's an idea that I've been playing with myself. 
> 
> You also have a build system?

Nothing that works, no. But I'm planning on setting one up, based
on arch. Thinking about it, I've reached the same conclusions you
had, which is what got me into this thread in the first place :)

> > However, I think we can avoid all sorts of problems, if instead of branching
> > from the source, we branch from the brances -- this would give us the
> > ordering. 
> 
> Yes, that's definitely a possibility too.  I'm not sure honestly which
> would work better in practice until someone actually writes the system
> and we start using it for nontrivial packages.

Goes without saying. But before we can write one, I have to have at
least a clue how it's going to work out.

But speaking of the branches, this is what will make or break such system.
Explicitly defining them in the .spec file is one way. More work, but:
  1. you get more control
  2. it's easy to add/delete/reorder things.

However, it's still not clear how it's going to work. Without merging
patches, how do you know they don't conflict? Even if they don't, they
may introduce fuzz for the others.

It seems to me the only way you are guranteed things will work is only
if you have the RCS system handle the order in which you do the patches
as well.

-- 
Dimi.



From walters at redhat.com  Mon Dec 20 20:08:57 2004
From: walters at redhat.com (Colin Walters)
Date: Mon, 20 Dec 2004 15:08:57 -0500
Subject: svn or arch
In-Reply-To: <20041220195245.GB24832@rogers.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
Message-ID: <1103573337.3135.47.camel@nexus.verbum.private>

On Mon, 2004-12-20 at 14:52 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 20, 2004 at 11:15:36AM -0500, Colin Walters wrote:
> > On Sun, 2004-12-19 at 23:49 -0500, Dimitrie O. Paun wrote:
> > 
> > > That's an idea that I've been playing with myself. 
> > 
> > You also have a build system?
> 
> Nothing that works, no. But I'm planning on setting one up, based
> on arch. Thinking about it, I've reached the same conclusions you
> had, which is what got me into this thread in the first place :)

Cool.  It definitely seems to me there's a lot of interest in a new
build system; there's mach, beehive, rookery, the fedora.us one, and
probably tons of others.  Maybe we should make a new list for this; or
maybe use the RPM list?

> Goes without saying. But before we can write one, I have to have at
> least a clue how it's going to work out.

Right; well I think in this case both would generally work.  In your
scenario, the other branches essentially just become an implementation
detail of the first branch.

> But speaking of the branches, this is what will make or break such system.
> Explicitly defining them in the .spec file is one way. More work, but:
>   1. you get more control
>   2. it's easy to add/delete/reorder things.

Well you need to define them somehow.  My idea was that the build system
would automatically do a 3-way merge *at build time*, based on the
Branch: headers.  If that failed, it failed the build and kicked it back
to you, just like it does now for applying a patch.

> However, it's still not clear how it's going to work. Without merging
> patches, how do you know they don't conflict? 

You'd just build on your local machine for testing, or use a 'scratch'
area in the build system.

> Even if they don't, they
> may introduce fuzz for the others.

I think you'd want an option to disable fuzzy patch application for
whatever RCS is in use; or maybe you get a build warning if there's a
too-fuzzy patch; e.g. over 5 lines displacement?  This is just detail
though.

> It seems to me the only way you are guranteed things will work is only
> if you have the RCS system handle the order in which you do the patches
> as well.

It's not clear to me that ordering is really all that useful if we make
it easy to create new branches that merge from two conflicting branches.
When would you want to reorder patches other than to work around
conflicts?




From dpaun at rogers.com  Mon Dec 20 20:29:32 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 20 Dec 2004 15:29:32 -0500
Subject: svn or arch
In-Reply-To: <1103573337.3135.47.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
Message-ID: <20041220202932.GC24832@rogers.com>

On Mon, Dec 20, 2004 at 03:08:57PM -0500, Colin Walters wrote:
> Cool.  It definitely seems to me there's a lot of interest in a new
> build system; there's mach, beehive, rookery, the fedora.us one, and
> probably tons of others.  Maybe we should make a new list for this; or
> maybe use the RPM list?

Maybe a Wiki? I wasn't even aware there are that many around <g>

> Well you need to define them somehow.  My idea was that the build system
> would automatically do a 3-way merge *at build time*, based on the
> Branch: headers.  If that failed, it failed the build and kicked it back
> to you, just like it does now for applying a patch.

Yes, but that would be awkard to work with. On a large project, I think
it would be slow, and it would be hard to maintain sane error reports.

> > However, it's still not clear how it's going to work. Without merging
> > patches, how do you know they don't conflict? 
> 
> You'd just build on your local machine for testing, or use a 'scratch'
> area in the build system.

Yeah, I can see that it can work, question is if this is the workflow
that you want. If I update the upstream package, I want to handle merge
conflicts at that time, not at build time. But maybe this is just me,
used to a certain way of doing things.

> > Even if they don't, they
> > may introduce fuzz for the others.
> 
> I think you'd want an option to disable fuzzy patch application for
> whatever RCS is in use; or maybe you get a build warning if there's a
> too-fuzzy patch; e.g. over 5 lines displacement?  This is just detail
> though.

Eh, devil is in the details though. The trick is to 'just use' the
RCS as much as possible IMO. And I clearly have arch in mind for
this task :)

> It's not clear to me that ordering is really all that useful if we make
> it easy to create new branches that merge from two conflicting branches.
> When would you want to reorder patches other than to work around
> conflicts?

If reordering is not a concern, it seems to me that branch-from-branch
method I'm proposing would be preferable, no?

-- 
Dimi.



From walters at redhat.com  Mon Dec 20 20:51:21 2004
From: walters at redhat.com (Colin Walters)
Date: Mon, 20 Dec 2004 15:51:21 -0500
Subject: svn or arch
In-Reply-To: <20041220202932.GC24832@rogers.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
	<20041220202932.GC24832@rogers.com>
Message-ID: <1103575881.3135.69.camel@nexus.verbum.private>

On Mon, 2004-12-20 at 15:29 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 20, 2004 at 03:08:57PM -0500, Colin Walters wrote:
> > Cool.  It definitely seems to me there's a lot of interest in a new
> > build system; there's mach, beehive, rookery, the fedora.us one, and
> > probably tons of others.  Maybe we should make a new list for this; or
> > maybe use the RPM list?
> 
> Maybe a Wiki? I wasn't even aware there are that many around <g>

There are a lot.  They all have different goals; of course we're really
talking about redesigning SRPM, not just a different way to turn 
SRPM->RPM.  But I'm sure all of these projects will have input.

> Yes, but that would be awkard to work with. On a large project, I think
> it would be slow, and it would be hard to maintain sane error reports.

Note that this approach is exactly analogous to how SRPM works now with
patches; the patch is applied at build time.

I don't think speed is an issue.  In the initial use I'm imagining,
you'd be just importing largish snapshots of new upstream versions into
the upstream branch, and your patch-branches would probably only have a
few changesets at most. 

As for error reports; I don't see how this would be a regression from
the current SRPM mechanism, anyways.  I think what you really want is an
easy mechanism for doing test builds.  Your patch may seem to apply
cleanly but produce a build error later.

> Yeah, I can see that it can work, question is if this is the workflow
> that you want. If I update the upstream package, I want to handle merge
> conflicts at that time, not at build time.

Well, I was thinking that you'd have an "upstream" branch that would be
as pristine as possible, just like how we try very hard right now to
have pristine tarballs.  So you generally wouldn't have conflicts
merging a new version into your upstream branch.  The conflicts would
really be in your patch-branch.

One cool thing of course here is that with a distributed RCS like Arch,
you don't even have to maintain the upstream branch yourself; your
package patch-branches just branch from upstream's archive directly.

> Eh, devil is in the details though. The trick is to 'just use' the
> RCS as much as possible IMO. 

Yeah.

> And I clearly have arch in mind for
> this task :)

I'm an Arch fan too; however, I think if we designed this correctly you
could plug in pretty much any RCS that has history-sensitive merging.
At least ideally.

> If reordering is not a concern, it seems to me that branch-from-branch
> method I'm proposing would be preferable, no?

Hmm.  Maybe.  I don't have a very strong opinion on it.  My main concern
is I want to make it easy to find out what the package delta is versus
upstream and manipulate that.  If I have to trace through branches of
branches, that becomes a bit harder.




From ndbecker2 at verizon.net  Mon Dec 20 21:00:51 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Mon, 20 Dec 2004 16:00:51 -0500
Subject: /usr/lib/jvm/java-1.4.2/include/jni.h x86_64
Message-ID: <cq7ei4$ki8$1@sea.gmane.org>

Something here is broken (FC3-x86_64):

ls -l /usr/lib/jvm/java-1.4.2/include/jni.h
lrwxrwxrwx  1 root root 56 Nov 17
20:44 /usr/lib/jvm/java-1.4.2/include/jni.h
-> /usr/lib64/gcc-lib/i386-redhat-linux/3.4.2/include/jni.h

ls -l /usr/lib64/gcc-lib
total 0

rpm --verify java-1.4.2-gcj-compat
[silence]
rpm --verify java-1.4.2-gcj-compat-devel
[same]



From ssc at coolspot.de  Mon Dec 20 21:10:16 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Mon, 20 Dec 2004 22:10:16 +0100
Subject: Building packages
Message-ID: <41C73FB8.2000700@coolspot.de>

It seems that at least on my mashine all packages are built with
mtune=pentium4
Would these work on stock pentium II/III ?
Is there a switch in rpm to get rid of it ?
Cheers,
Stefan Sonnenberg



From mattdm at mattdm.org  Mon Dec 20 21:14:20 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 20 Dec 2004 16:14:20 -0500
Subject: Building packages
In-Reply-To: <41C73FB8.2000700@coolspot.de>
References: <41C73FB8.2000700@coolspot.de>
Message-ID: <20041220211420.GA11601@jadzia.bu.edu>

On Mon, Dec 20, 2004 at 10:10:16PM +0100, Stefan Sonnenberg-Carstens wrote:
> It seems that at least on my mashine all packages are built with
> mtune=pentium4
> Would these work on stock pentium II/III ?

Yes, they do. I have a bunches of older machines running with no problem.

> Is there a switch in rpm to get rid of it ?

I doubt it's worth it.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From fedora-devel at camperquake.de  Mon Dec 20 21:14:20 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Mon, 20 Dec 2004 22:14:20 +0100
Subject: Building packages
In-Reply-To: <41C73FB8.2000700@coolspot.de>
References: <41C73FB8.2000700@coolspot.de>
Message-ID: <20041220221420.4f7dd219@nausicaa.camperquake.de>

Hi.

Stefan Sonnenberg-Carstens <ssc at coolspot.de> wrote:

> Would these work on stock pentium II/III ?

Yes.

> Is there a switch in rpm to get rid of it ?

This is not needed, it's just a tuning parameter.

-- 
I pretend to work. They pretend to pay me.



From rahulsundaram at yahoo.co.in  Mon Dec 20 21:46:53 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Mon, 20 Dec 2004 13:46:53 -0800 (PST)
Subject: svn or arch
In-Reply-To: <1103575881.3135.69.camel@nexus.verbum.private>
Message-ID: <20041220214653.96627.qmail@web8506.mail.in.yahoo.com>

Hi


> > And I clearly have arch in mind for
> > this task :)
> 
> I'm an Arch fan too; however, I think if we designed
> this correctly you
> could plug in pretty much any RCS that has
> history-sensitive merging.
> At least ideally.


To truly take advantage of a distributed system like
arch you need use make use of features like branching
in a heavy way which if frowned upon by cvs.

I suspect we would end up with something like conary
if we design a build system on top of arch. 


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 



From dpaun at rogers.com  Mon Dec 20 23:24:57 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 20 Dec 2004 18:24:57 -0500
Subject: svn or arch
In-Reply-To: <1103575881.3135.69.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
	<20041220202932.GC24832@rogers.com>
	<1103575881.3135.69.camel@nexus.verbum.private>
Message-ID: <20041220232457.GD24832@rogers.com>

On Mon, Dec 20, 2004 at 03:51:21PM -0500, Colin Walters wrote:
> > Yes, but that would be awkard to work with. On a large project, I think
> > it would be slow, and it would be hard to maintain sane error reports.
> 
> Note that this approach is exactly analogous to how SRPM works now with
> patches; the patch is applied at build time.

Yes, but this does not mean that SRPM is a convenient way to develop
patches. It's a good way to package and distribute them, not to develop.
I think that such a system should allow for easy _development_ of said
patches too, not just packaging. Once developed, the packaging should
happen automatically.

> Well, I was thinking that you'd have an "upstream" branch that would be
> as pristine as possible, just like how we try very hard right now to
> have pristine tarballs.

Correct.

> So you generally wouldn't have conflicts
> merging a new version into your upstream branch.  The conflicts would
> really be in your patch-branch.

Right. And here you'd to a regular merge and commit, which is something
that's more or less familiar to people.

> One cool thing of course here is that with a distributed RCS like Arch,
> you don't even have to maintain the upstream branch yourself; your
> package patch-branches just branch from upstream's archive directly.

Heh, assuming such projects are indeed maintained in arch, of course :)

> > If reordering is not a concern, it seems to me that branch-from-branch
> > method I'm proposing would be preferable, no?
> 
> Hmm.  Maybe.  I don't have a very strong opinion on it.  My main concern
> is I want to make it easy to find out what the package delta is versus
> upstream and manipulate that.  If I have to trace through branches of
> branches, that becomes a bit harder.

But that can be scriped, no? And a script should be able to figure this
stuff out from continuations, right?

-- 
Dimi.



From jwboyer at jdub.homelinux.org  Tue Dec 21 02:02:43 2004
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Mon, 20 Dec 2004 20:02:43 -0600
Subject: CVS kernel compile
Message-ID: <1103594563.6919.2.camel@jdub.homelinux.org>

Ok, so I'm probably an idiot, but can anyone explain to me how to build
the kernel out of CVS?

I've read the cvs.fedora.redhat.com website and done a CVS checkout.
But when I do a 'make sources' it comes up with the following error
after downloading the kernel tarball and merging a bunch of configs:

make: *** No rule to make target `download', needed by `sources'.  Stop.

I can't find the download target anywhere.  Am I the only one to see
this?

thx,
josh




From thesource at ldb-jab.org  Tue Dec 21 02:52:35 2004
From: thesource at ldb-jab.org (Lawrence Bowie)
Date: Mon, 20 Dec 2004 21:52:35 -0500
Subject: hotplug firmware location
In-Reply-To: <1103594563.6919.2.camel@jdub.homelinux.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
Message-ID: <41C78FF3.6070503@ldb-jab.org>

I thought the firmware hotplug location was

    /usr/lib/hotplug/firmware/

according to /etc/hotplug/firmware.agent

I have also used /lib/firmware and /etc/firmware but the firmware is still
not loading.... (so it says)

I get a return -2 when booting up everytime.

What could be the problem?


Thanks,

LDB

>  
>



From dpaun at rogers.com  Tue Dec 21 04:47:30 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Mon, 20 Dec 2004 23:47:30 -0500
Subject: svn or arch
In-Reply-To: <20041220214653.96627.qmail@web8506.mail.in.yahoo.com>
References: <1103575881.3135.69.camel@nexus.verbum.private>
	<20041220214653.96627.qmail@web8506.mail.in.yahoo.com>
Message-ID: <20041221044730.GB7176@rogers.com>

On Mon, Dec 20, 2004 at 01:46:53PM -0800, Rahul Sundaram wrote:
> I suspect we would end up with something like conary
> if we design a build system on top of arch.

Interesting. Any plans for RedHat/Fedora to switch to Conary?
One difference between this proposal and conary is that we would
try to remain compatible with a .rpm based system. In other
words, the output of our system would be regular .src.rpm's
that could be built/installed/etc. by existing tools.

But the question is if it's worth pursuing this. If Fedora intends
to use conary in the (near) future, puting up with the CVS-based
system may be the smartest thing to do.

-- 
Dimi.



From dpaun at rogers.com  Tue Dec 21 05:47:00 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Tue, 21 Dec 2004 00:47:00 -0500
Subject: svn or arch
In-Reply-To: <1103317935.12552.117.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
Message-ID: <20041221054700.GC7176@rogers.com>

On Fri, Dec 17, 2004 at 04:12:15PM -0500, Colin Walters wrote:
> > A lot of packages include a spec.in file which is then passed through sed 
> > to install the version number in the spec file before a tarball is 
> > generated. Eliminating this extra step would make it easier for upstreams 
> > to provide RPM support by eliminating this extra step.
> 
> Yes; but you still have the rpm revision number.  I am arguing for its
> removal entirely.  That's one less spurious thing you see in a diff
> between branches, and one less thing to merge conflict on.

Sorry for the late reply, but I must have missed one thing: where do
we store these? Now, I'm not arguing for having them in .spec (in fact,
I agree with you that they don't belong there), but where do we put
them?

-- 
Dimi.



From adrian at lisas.de  Tue Dec 21 06:52:48 2004
From: adrian at lisas.de (Adrian Reber)
Date: Tue, 21 Dec 2004 07:52:48 +0100
Subject: Building packages
In-Reply-To: <41C73FB8.2000700@coolspot.de>
References: <41C73FB8.2000700@coolspot.de>
Message-ID: <20041221065248.GA5540@lisas.de>

On Mon, Dec 20, 2004 at 10:10:16PM +0100, Stefan Sonnenberg-Carstens wrote:
> mtune=pentium4
> Would these work on stock pentium II/III ?
> Is there a switch in rpm to get rid of it ?

If you uninstall redhat-rpm-config the flags are changed back to
-O2 -g -march=i386 -mcpu=i686

		Adrian



From backes at rhrk.uni-kl.de  Tue Dec 21 07:03:45 2004
From: backes at rhrk.uni-kl.de (Joachim Backes)
Date: Tue, 21 Dec 2004 08:03:45 +0100
Subject: firefox in FC3; Ctrl A and Ctrl E without effect
Message-ID: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>

Hi,

question concerning firefox: How to skip to beginning/end in a firefox
input line?

Mozilla allows the usage of "CtrlA" and "CrtlE" for skipping to the
beginning/end of an input line. How to do this in forefox?
-- 
Regards

Joachim Backes

Joachim Backes <backes at rhrk.uni-kl.de>
University of Kaiserslautern,Computer Center,
High Performance Computing,
D-67653 Kaiserslautern, PO Box 3049, Germany
--------------------------------------------------
Phone: +49-631-205-2438, FAX: +49-631-205-3056
http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html



From carwyn at carwyn.com  Tue Dec 21 07:07:38 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Tue, 21 Dec 2004 07:07:38 +0000
Subject: firefox in FC3; Ctrl A and Ctrl E without effect
In-Reply-To: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>
References: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>
Message-ID: <41C7CBBA.4030604@carwyn.com>

Joachim Backes wrote:
> Mozilla allows the usage of "CtrlA" and "CrtlE" for skipping to the
> beginning/end of an input line. How to do this in forefox?

"Home" and "End" work. Ctrl+A tends to be mapped to "Select All" in 
Gnome - following "popular convention".

Carwyn



From ssc at coolspot.de  Tue Dec 21 08:43:39 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 09:43:39 +0100
Subject: FreeTDS
Message-ID: <41C7E23B.6060804@coolspot.de>

I hope I got most errors out, at least I thing so.
New packages are available under

http://www.coolspot.de/fedora-devel/

There are now signed with a gpg key, which can
now find in this dir along with md5 sums and the
output of rpmlint for all the rpms.
Rpmlint just now reports only warnings ;-)


Test them please.

Cheers,
Stefan Sonnenberg

P.S.:
What about changing the php rpms someday to have a
php-mssql which *works* ?



From ssc at coolspot.de  Tue Dec 21 08:47:18 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 09:47:18 +0100
Subject: FreeTDS
In-Reply-To: <41C7E23B.6060804@coolspot.de>
References: <41C7E23B.6060804@coolspot.de>
Message-ID: <41C7E316.9080804@coolspot.de>

Stefan Sonnenberg-Carstens wrote:

> I hope I got most errors out, at least I thing so.
> New packages are available under
>
> http://www.coolspot.de/fedora-devel/
>
> There are now signed with a gpg key, which can
> now find in this dir along with md5 sums and the
> output of rpmlint for all the rpms.
> Rpmlint just now reports only warnings ;-)
>
>
> Test them please.
>
> Cheers,
> Stefan Sonnenberg
>
> P.S.:
> What about changing the php rpms someday to have a
> php-mssql which *works* ?
>
How do I set the no-replace flag on files in a spec file ?
This seems to be a nice feature to prevent "side-effects" during
package updates.




From ssc at coolspot.de  Tue Dec 21 08:48:16 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 09:48:16 +0100
Subject: Building packages
In-Reply-To: <20041221065248.GA5540@lisas.de>
References: <41C73FB8.2000700@coolspot.de> <20041221065248.GA5540@lisas.de>
Message-ID: <41C7E350.9040500@coolspot.de>

Adrian Reber wrote:

>On Mon, Dec 20, 2004 at 10:10:16PM +0100, Stefan Sonnenberg-Carstens wrote:
>  
>
>>mtune=pentium4
>>Would these work on stock pentium II/III ?
>>Is there a switch in rpm to get rid of it ?
>>    
>>
>
>If you uninstall redhat-rpm-config the flags are changed back to
>-O2 -g -march=i386 -mcpu=i686
>
>		Adrian
>
>  
>
Which is standard then ?
I'd like to provide "correct" packages as possible.



From jani.kesanen at gmail.com  Tue Dec 21 08:56:13 2004
From: jani.kesanen at gmail.com (=?ISO-8859-1?Q?Jani_Kes=E4nen?=)
Date: Tue, 21 Dec 2004 10:56:13 +0200
Subject: PHP Vulnerability
Message-ID: <8efc1ce40412210056d55cd1a@mail.gmail.com>

As Kenneth Porter pointed out last week there isn't any update to
these php security issues.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132

Debian and Gentoo both reacted immediately. This is madness I tell
you. The only change seems to be that we'll have to shutdown every
webserver and switch distributions. This really isn't nice xmas
present from Fedora development.



From ssc at coolspot.de  Tue Dec 21 09:11:52 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 10:11:52 +0100
Subject: PHP Vulnerability
In-Reply-To: <8efc1ce40412210056d55cd1a@mail.gmail.com>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
Message-ID: <41C7E8D8.1060206@coolspot.de>

Jani Kes?nen wrote:

>As Kenneth Porter pointed out last week there isn't any update to
>these php security issues.
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141132
>
>Debian and Gentoo both reacted immediately. This is madness I tell
>you. The only change seems to be that we'll have to shutdown every
>webserver and switch distributions. This really isn't nice xmas
>present from Fedora development.
>
>  
>
Don't you think some people have reasons to wait with
pulling patches and fixes out ?
Gentoo guys do everything "immediately". But they don't care
about backward or binary compatibility. They just recompile
everything.
Debian did a good job, indeed, more over as the back-ported to
older versions.
But I'm working with RH/Fedora products for more than 6 years
now, and I always loved their stability and quality management.
Nobody stops you from updating packages your self from source.
And, of course, your are talking about RHEL, which has much
higher goals than Fedora, in terms of standing time.






From jani.kesanen at gmail.com  Tue Dec 21 09:43:37 2004
From: jani.kesanen at gmail.com (=?ISO-8859-1?Q?Jani_Kes=E4nen?=)
Date: Tue, 21 Dec 2004 11:43:37 +0200
Subject: PHP Vulnerability
In-Reply-To: <41C7E8D8.1060206@coolspot.de>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
	<41C7E8D8.1060206@coolspot.de>
Message-ID: <8efc1ce4041221014336bd6de4@mail.gmail.com>

On Tue, 21 Dec 2004 10:11:52 +0100, Stefan Sonnenberg-Carstens
<ssc at coolspot.de> wrote:

> Don't you think some people have reasons to wait with
> pulling patches and fixes out ?

Propably. But it's been already quite a while and there hasn't been
much discussion (as Kenneth's mail was not replied). There are plenty
of nasty exploits taking advantage of these security holes in php, so
it isn't that easy just sit back and wait.

http://news.netcraft.com/archives/2004/12/18/php_exploit_enables_theft_of_phpbb_passwords.html



From lists at donut.dk  Tue Dec 21 09:58:27 2004
From: lists at donut.dk (Cream[DONut])
Date: Tue, 21 Dec 2004 10:58:27 +0100
Subject: PHP Vulnerability
In-Reply-To: <41C7E8D8.1060206@coolspot.de>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
	<41C7E8D8.1060206@coolspot.de>
Message-ID: <41C7F3C3.5010809@donut.dk>

Stefan Sonnenberg-Carstens wrote:

> Don't you think some people have reasons to wait with
> pulling patches and fixes out ?

Ofcourse, but its having a rather big impact when people are forced to 
shutdown webservers.

I'd for one would very much like to have an estimate, on when we can see 
an update (atleast something to tell the people complaining about their 
websites being offline)

> Nobody stops you from updating packages your self from source.

I think most of us have been considering that since shutting down our 
servers, but would prefer a RPM.

> And, of course, your are talking about RHEL, which has much
> higher goals than Fedora, in terms of standing time.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141135
then



From ssc at coolspot.de  Tue Dec 21 10:05:34 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 11:05:34 +0100
Subject: PHP Vulnerability
In-Reply-To: <41C7F3C3.5010809@donut.dk>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>	<41C7E8D8.1060206@coolspot.de>
	<41C7F3C3.5010809@donut.dk>
Message-ID: <41C7F56E.5060905@coolspot.de>

Cream[DONut] wrote:

> Stefan Sonnenberg-Carstens wrote:
>
>> Don't you think some people have reasons to wait with
>> pulling patches and fixes out ?
>
>
> Ofcourse, but its having a rather big impact when people are forced to 
> shutdown webservers.
>
> I'd for one would very much like to have an estimate, on when we can 
> see an update (atleast something to tell the people complaining about 
> their websites being offline)
>
>> Nobody stops you from updating packages your self from source.
>
>
> I think most of us have been considering that since shutting down our 
> servers, but would prefer a RPM.
>
>> And, of course, your are talking about RHEL, which has much
>> higher goals than Fedora, in terms of standing time.
>
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141135
> then
>
So then blaim the maintainer.



From mr700 at globalnet.bg  Tue Dec 21 10:36:56 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Tue, 21 Dec 2004 12:36:56 +0200
Subject: PHP Vulnerability
In-Reply-To: <41C7F3C3.5010809@donut.dk>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
	<41C7E8D8.1060206@coolspot.de> <41C7F3C3.5010809@donut.dk>
Message-ID: <200412211236.56663@-mr700>

On 2004 12 21 (Tuesday) 11:58, Cream[DONut] wrote:
> Stefan Sonnenberg-Carstens wrote:
...
> 
> > Nobody stops you from updating packages your self from source.
> 
> I think most of us have been considering that since shutting down our 
> servers, but would prefer a RPM.
> 

    Why not just add the patch to the old src.rpm's spec file and
rebuild? That was the first thing I learned to do when I started
learning rpm. Add some 'custom tag', I add .mr700 to the release,
to make sure you'll remember you touched something in it later.

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From byte at aeon.com.my  Tue Dec 21 10:48:33 2004
From: byte at aeon.com.my (Colin Charles)
Date: Tue, 21 Dec 2004 18:48:33 +0800
Subject: CVS kernel compile
In-Reply-To: <1103594563.6919.2.camel@jdub.homelinux.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
Message-ID: <1103626114.4263.35.camel@localhost.localdomain>

On Mon, 2004-12-20 at 20:02 -0600, Josh Boyer wrote:
> Ok, so I'm probably an idiot, but can anyone explain to me how to build
> the kernel out of CVS?

Well, you'd do:
	make <arch>

In your case, make ppc will be fine :)

> I've read the cvs.fedora.redhat.com website and done a CVS checkout.
> But when I do a 'make sources' it comes up with the following error
> after downloading the kernel tarball and merging a bunch of configs:

That only downloads the sources, probably not what you want

It should begin the 34.5MB download, nonetheless, and seems to work for
me (I just ran it)
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From byte at aeon.com.my  Tue Dec 21 11:53:09 2004
From: byte at aeon.com.my (Colin Charles)
Date: Tue, 21 Dec 2004 19:53:09 +0800
Subject: CVS kernel compile
In-Reply-To: <1103594563.6919.2.camel@jdub.homelinux.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
Message-ID: <1103629990.4263.56.camel@localhost.localdomain>

On Mon, 2004-12-20 at 20:02 -0600, Josh Boyer wrote:
> make: *** No rule to make target `download', needed by `sources'.
> Stop.
> 
> I can't find the download target anywhere.  Am I the only one to see
> this?

Okay, I see this when I checked 'devel' out, it fails after doing the
merge's
-- 
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you, 
then you win." -- Mohandas Gandhi



From pekkas at netcore.fi  Tue Dec 21 11:55:18 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 21 Dec 2004 13:55:18 +0200 (EET)
Subject: PHP Vulnerability
In-Reply-To: <41C7E8D8.1060206@coolspot.de>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
	<41C7E8D8.1060206@coolspot.de>
Message-ID: <Pine.LNX.4.61.0412211351080.21292@netcore.fi>

On Tue, 21 Dec 2004, Stefan Sonnenberg-Carstens wrote:
> Debian did a good job, indeed, more over as the back-ported to
> older versions.

Incorrect.  Debian still has not released a patch to Stable (4.1.2 
based release, such as RHL73 is using).  There are patches for other 
distros out there for 4.2.x based releases (e.g., RHL9, RHEL3).

Of course, creating updated PHP packages for FC2 or FC3 is pretty 
trivial, but it's very low on the priorities of php maintainer, I'd 
suspect.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From ssc at coolspot.de  Tue Dec 21 11:59:46 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 12:59:46 +0100
Subject: PHP Vulnerability
In-Reply-To: <Pine.LNX.4.61.0412211351080.21292@netcore.fi>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>	<41C7E8D8.1060206@coolspot.de>
	<Pine.LNX.4.61.0412211351080.21292@netcore.fi>
Message-ID: <41C81032.6010007@coolspot.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pekka Savola wrote:

| On Tue, 21 Dec 2004, Stefan Sonnenberg-Carstens wrote:
|
|> Debian did a good job, indeed, more over as the back-ported to
|> older versions.
|
|
| Incorrect.  Debian still has not released a patch to Stable (4.1.2
| based release, such as RHL73 is using).  There are patches for
| other distros out there for 4.2.x based releases (e.g., RHL9,
| RHEL3).
|
| Of course, creating updated PHP packages for FC2 or FC3 is pretty
| trivial, but it's very low on the priorities of php maintainer, I'd
|  suspect.
|
Your right, indeed.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFByBAyzuwr3UA+1D8RAi5ZAKCSB2FKWgQ3uh6xfQ4wdQSwYvHqfACgqKq5
B9JhWY0PlkbbRP4LblpsNhg=
=bEWe
-----END PGP SIGNATURE-----



From jwboyer at jdub.homelinux.org  Tue Dec 21 12:14:46 2004
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 21 Dec 2004 06:14:46 -0600
Subject: CVS kernel compile
In-Reply-To: <1103629990.4263.56.camel@localhost.localdomain>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
	<1103629990.4263.56.camel@localhost.localdomain>
Message-ID: <1103631286.6919.5.camel@jdub.homelinux.org>

On Tue, 2004-12-21 at 19:53 +0800, Colin Charles wrote:
> On Mon, 2004-12-20 at 20:02 -0600, Josh Boyer wrote:
> > make: *** No rule to make target `download', needed by `sources'.
> > Stop.
> > 
> > I can't find the download target anywhere.  Am I the only one to see
> > this?
> 
> Okay, I see this when I checked 'devel' out, it fails after doing the
> merge's

Yep, same here.  I should have said I was using devel before, sorry.

Bugzilla time?

josh



From fedora-devel at camperquake.de  Tue Dec 21 12:18:39 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Tue, 21 Dec 2004 13:18:39 +0100
Subject: Building packages
In-Reply-To: <41C7E350.9040500@coolspot.de>
References: <41C73FB8.2000700@coolspot.de> <20041221065248.GA5540@lisas.de>
	<41C7E350.9040500@coolspot.de>
Message-ID: <20041221131839.2e266b6f@nausicaa.camperquake.de>

Hi.

Stefan Sonnenberg-Carstens <ssc at coolspot.de> wrote:

> Which is standard then ?
> I'd like to provide "correct" packages as possible.

Standard is what the distribution uses. -mtune=pentium4 is what (almost)
all packages in FC are built with.

-- 
"Your reality, sir, is lies and balderdash and I am delighted to say
that I have no grasp of it whatsoever."  -- Baron Munchausen



From buildsys at redhat.com  Tue Dec 21 12:41:39 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 21 Dec 2004 07:41:39 -0500
Subject: rawhide report: 20041221 changes
Message-ID: <200412211241.iBLCfdl07847@porkchop.devel.redhat.com>



From nphilipp at redhat.com  Tue Dec 21 12:48:50 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Tue, 21 Dec 2004 13:48:50 +0100
Subject: FreeTDS
In-Reply-To: <41C7E316.9080804@coolspot.de>
References: <41C7E23B.6060804@coolspot.de>  <41C7E316.9080804@coolspot.de>
Message-ID: <1103633330.5696.0.camel@wombat.tiptoe.de>

On Tue, 2004-12-21 at 09:47 +0100, Stefan Sonnenberg-Carstens wrote:

> How do I set the no-replace flag on files in a spec file ?
> This seems to be a nice feature to prevent "side-effects" during
> package updates.

You can only set noreplace on config files, e.g.

%config(noreplace) /etc/foo.conf

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From ssc at coolspot.de  Tue Dec 21 12:53:24 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 13:53:24 +0100
Subject: FreeTDS
In-Reply-To: <1103633330.5696.0.camel@wombat.tiptoe.de>
References: <41C7E23B.6060804@coolspot.de> <41C7E316.9080804@coolspot.de>
	<1103633330.5696.0.camel@wombat.tiptoe.de>
Message-ID: <41C81CC4.1070607@coolspot.de>

Nils Philippsen schrieb:

>On Tue, 2004-12-21 at 09:47 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>How do I set the no-replace flag on files in a spec file ?
>>This seems to be a nice feature to prevent "side-effects" during
>>package updates.
>>    
>>
>
>You can only set noreplace on config files, e.g.
>
>%config(noreplace) /etc/foo.conf
>
>Nils
>  
>
Thanks !



From fedora at wir-sind-cool.org  Tue Dec 21 13:05:58 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 21 Dec 2004 14:05:58 +0100
Subject: FreeTDS
In-Reply-To: <41C7E23B.6060804@coolspot.de>
References: <41C7E23B.6060804@coolspot.de>
Message-ID: <20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>

On Tue, 21 Dec 2004 09:43:39 +0100, Stefan Sonnenberg-Carstens wrote:

> I hope I got most errors out, at least I thing so.
> New packages are available under
> 
> http://www.coolspot.de/fedora-devel/

No time to check it further than with a single look. The *.so
softlinks still belong into the -devel package, not the main package.
And with libraries outside run-time linker's search path, ldconfig
scriptlets don't add any value.



From dcbw at redhat.com  Tue Dec 21 13:13:31 2004
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 21 Dec 2004 08:13:31 -0500
Subject: hotplug firmware location
In-Reply-To: <41C78FF3.6070503@ldb-jab.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
	<41C78FF3.6070503@ldb-jab.org>
Message-ID: <1103634811.23613.1.camel@dcbw.boston.redhat.com>

On Mon, 2004-12-20 at 21:52 -0500, Lawrence Bowie wrote:
> I thought the firmware hotplug location was
> 
>     /usr/lib/hotplug/firmware/

This is no longer the firmware location because /usr is not guaranteed
to be mounted early in bootup, and therefore you're not guaranteed to
have firmware for your network card, for example, before you've mounted
your networked /usr share.  Which is a problem.  Make sure everything is
in /lib/firmware, which is the correct location.

Dan



From richardl at redhat.com  Tue Dec 21 13:56:17 2004
From: richardl at redhat.com (Richard Li)
Date: Tue, 21 Dec 2004 08:56:17 -0500
Subject: svn or arch
In-Reply-To: <20041221044730.GB7176@rogers.com>
References: <1103575881.3135.69.camel@nexus.verbum.private>	<20041220214653.96627.qmail@web8506.mail.in.yahoo.com>
	<20041221044730.GB7176@rogers.com>
Message-ID: <41C82B81.3070306@redhat.com>


>But the question is if it's worth pursuing this. If Fedora intends
>to use conary in the (near) future, puting up with the CVS-based
>system may be the smartest thing to do.
>  
>
I doubt it would be realistic to make a switch in the near future since 
it's so fundamental to the distribution.

I would expect that if it was really going to happen, someone would 
start by experimenting with a switch  on a branch somewhere and invite 
people to play with it, shake out the bugs, and see how people like it.

Richard



From christopher.hotchkiss at gmail.com  Tue Dec 21 14:14:44 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 21 Dec 2004 09:14:44 -0500
Subject: hdlist order tag problem
In-Reply-To: <7f48492a041218182116d975ab@mail.gmail.com>
References: <7f48492a041218182116d975ab@mail.gmail.com>
Message-ID: <7f48492a0412210614318f507c@mail.gmail.com>

I am trying to add a custom rpm (my netexec script posted earlier to
fedora-devel), to a nfs kickstart install. I copied the rpm to the
RPMS/ directory and added the following to
/install/fedora/Fedora/base/comps.xml

<group>
    <id>netexec-sc</id>

    <name>Netexec Client/Server</name>

    <description>Network command queueing program</description>

    <uservisible>false</uservisible>

    <packagelist>
      <packagereq type="default"
requires="perl-Frontier-RPC">netexec</packagereq>
    </packagelist>
  </group>

Then I ran: /usr/lib/anaconda-runtime/genhdlist --productpath Fedora
/data/install/fedora

When I started the kickstart install it produced the following error and died:
WARNING: not all packages in hdlist had order tag.

Any clue as to why this died? The most recent information on custom
nfs installs that I
can find is from RedHat 8.0.
The rpm in question is attached.

-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netexec-1.0-1.i386.rpm
Type: application/x-rpm
Size: 5827 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041221/2686f53d/attachment.rpm>

From rdieter at math.unl.edu  Tue Dec 21 14:18:07 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 21 Dec 2004 08:18:07 -0600
Subject: hdlist order tag problem
In-Reply-To: <7f48492a0412210614318f507c@mail.gmail.com>
References: <7f48492a041218182116d975ab@mail.gmail.com>
	<7f48492a0412210614318f507c@mail.gmail.com>
Message-ID: <41C8309F.4060607@math.unl.edu>

Christopher Hotchkiss wrote:

> Then I ran: /usr/lib/anaconda-runtime/genhdlist --productpath Fedora
> /data/install/fedora
> 
> When I started the kickstart install it produced the following error and died:
> WARNING: not all packages in hdlist had order tag.
> 
> Any clue as to why this died? 

In my experience, the WARNING is harmless.  It's dieing for some other 
reason.

-- Rex



From mlauterbach at mail.wtamu.edu  Tue Dec 21 14:22:14 2004
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Tue, 21 Dec 2004 08:22:14 -0600
Subject: hdlist order tag problem
In-Reply-To: <41C8309F.4060607@math.unl.edu>
Message-ID: <20041221142214.B9EEC3E63E2@mail.wtamu.edu>

On Tuesday, December 21, 2004 8:18 AM, Rex Dieter wrote:
> Christopher Hotchkiss wrote:
> 
> > Then I ran: /usr/lib/anaconda-runtime/genhdlist --productpath Fedora
> > /data/install/fedora
> > 
> > When I started the kickstart install it produced the 
> following error and died:
> > WARNING: not all packages in hdlist had order tag.
> > 
> > Any clue as to why this died? 
> 
> In my experience, the WARNING is harmless.  It's dieing for 
> some other 
> reason.
> 
> -- Rex

I'm no expert on this, but can you do 'requires="perl-Frontier-RPC"' if
perl-Frontier-RPC is not somewhere earlier in the list?  Aren't you
requiring a package that doesn't exist?

Matthew E. Lauterbach



From thesource at ldb-jab.org  Tue Dec 21 14:27:11 2004
From: thesource at ldb-jab.org (Lawrence Bowie)
Date: Tue, 21 Dec 2004 09:27:11 -0500
Subject: hotplug firmware location
In-Reply-To: <1103634811.23613.1.camel@dcbw.boston.redhat.com>
References: <1103594563.6919.2.camel@jdub.homelinux.org>	<41C78FF3.6070503@ldb-jab.org>
	<1103634811.23613.1.camel@dcbw.boston.redhat.com>
Message-ID: <41C832BF.5070604@ldb-jab.org>

Ah... understood .... Where is /lib/firmware indicated in the
software?

Thanks,

LDB

Dan Williams wrote:

>On Mon, 2004-12-20 at 21:52 -0500, Lawrence Bowie wrote:
>  
>
>>I thought the firmware hotplug location was
>>
>>    /usr/lib/hotplug/firmware/
>>    
>>
>
>This is no longer the firmware location because /usr is not guaranteed
>to be mounted early in bootup, and therefore you're not guaranteed to
>have firmware for your network card, for example, before you've mounted
>your networked /usr share.  Which is a problem.  Make sure everything is
>in /lib/firmware, which is the correct location.
>
>Dan
>
>  
>



From fedora at wir-sind-cool.org  Tue Dec 21 14:32:51 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 21 Dec 2004 15:32:51 +0100
Subject: gconftool-2 failing in rpm scriptlets?
Message-ID: <20041221153251.2c7ecd5a.fedora@wir-sind-cool.org>

Under which circumstances might a GConf2 post-install scriptlet like
this fail to create application's default settings unreproducibly?

export GCONF_CONFIG_SOURCE="$(gconftool-2 --get-default-source)"
gconftool-2 --makefile-install-rule /etc/gconf/schemas/celestia.schemas &>/dev/null || :

If after package installation, the application's GConf2 defaults
cannot be found in /etc/gconf/gconf.xml.defaults/, is that an
indication that the post-install scriptlet was not executed at all
(and e.g. Yum could be involved) or that only GConf2 failed somehow?

Theories, anyone?

-- 
Background:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143318



From ssc at coolspot.de  Tue Dec 21 14:33:26 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 15:33:26 +0100
Subject: FreeTDS
In-Reply-To: <20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>
References: <41C7E23B.6060804@coolspot.de>
	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>
Message-ID: <41C83436.4030700@coolspot.de>

Ok.
I first thought it was about *all* .so files.
But why don't the symlinks don't belong into main ?
Don't they need to be there for versioning ?


Michael Schwendt schrieb:

>On Tue, 21 Dec 2004 09:43:39 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>I hope I got most errors out, at least I thing so.
>>New packages are available under
>>
>>http://www.coolspot.de/fedora-devel/
>>    
>>
>
>No time to check it further than with a single look. The *.so
>softlinks still belong into the -devel package, not the main package.
>And with libraries outside run-time linker's search path, ldconfig
>scriptlets don't add any value.
>
>  
>



From fedora at wir-sind-cool.org  Tue Dec 21 14:42:46 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 21 Dec 2004 15:42:46 +0100
Subject: FreeTDS
In-Reply-To: <41C83436.4030700@coolspot.de>
References: <41C7E23B.6060804@coolspot.de>
	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>
	<41C83436.4030700@coolspot.de>
Message-ID: <20041221154246.4a2c4809.fedora@wir-sind-cool.org>

On Tue, 21 Dec 2004 15:33:26 +0100, Stefan Sonnenberg-Carstens wrote:

> Ok.
> I first thought it was about *all* .so files.
> But why don't the symlinks don't belong into main ?
> Don't they need to be there for versioning ?

What kind of "versioning"?

https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00705.html



From os+fedora-devel at sumu.org  Tue Dec 21 14:45:23 2004
From: os+fedora-devel at sumu.org (Oskari Saarenmaa)
Date: Tue, 21 Dec 2004 16:45:23 +0200
Subject: PHP Vulnerability
Message-ID: <20041221144523.GA4112@shadow.sumu.org>

I rolled my own php-4.3.10 rpms (based on fc3 rpms) because there still
isn't an official update available.

Source and binary rpms for fc1 and fc3 are available from
http://rpms.www.sumu.org/php-4.3.10/

Differences between my php-4.3.10-0.os.1 rpms and the FC3 php-4.3.9-3:
- update to 4.3.10
- update php-4.3.6-umask.patch
- drop php-4.3.9-phpvar.patch and php-4.3.2-db4.patch
- buildrequire libidn-devel (required by curl apparently)
- disable test 30695

FC1 specific:
- gd module is in its own package (was in main php package in fc1)
- php-pear is required

Note that I haven't tested the provided rpms too much nor can I really
recommend that anyone would use them, but they appear to work on my own
fc1 and fc3 boxes that serve some fairly busy websites.

Cheers,
Oskari



From dcbw at redhat.com  Tue Dec 21 14:51:47 2004
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 21 Dec 2004 09:51:47 -0500
Subject: hotplug firmware location
In-Reply-To: <41C832BF.5070604@ldb-jab.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
	<41C78FF3.6070503@ldb-jab.org>
	<1103634811.23613.1.camel@dcbw.boston.redhat.com>
	<41C832BF.5070604@ldb-jab.org>
Message-ID: <1103640707.17599.3.camel@dcbw.boston.redhat.com>

On Tue, 2004-12-21 at 09:27 -0500, Lawrence Bowie wrote:
> Ah... understood .... Where is /lib/firmware indicated in the
> software?

I would guess the hotplug script itself...  But the change was sudden
and of course the RPM itself cannot move old firmware files over since
RPMs really really shouldn't touch files they don't own, though there
probably should have been some sort of warning.

dan



From ssc at coolspot.de  Tue Dec 21 14:53:51 2004
From: ssc at coolspot.de (Stefan Sonnenberg-Carstens)
Date: Tue, 21 Dec 2004 15:53:51 +0100
Subject: FreeTDS
In-Reply-To: <20041221154246.4a2c4809.fedora@wir-sind-cool.org>
References: <41C7E23B.6060804@coolspot.de>	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>	<41C83436.4030700@coolspot.de>
	<20041221154246.4a2c4809.fedora@wir-sind-cool.org>
Message-ID: <41C838FF.3010009@coolspot.de>

Ok, that would mean (for example)
main package ships *only* libct.so.2.0.0, nothing more
and the devel package would ship the symlink libct.so to libct.so.2.0.0
After one compiled e.g. php, php *knows* it needs libct.so.2.0.0 and
therefore doesn't need the symlink to libct.so anymore, and the devel
could be whiped away after all.

Am I right ?

Michael Schwendt schrieb:

>On Tue, 21 Dec 2004 15:33:26 +0100, Stefan Sonnenberg-Carstens wrote:
>
>  
>
>>Ok.
>>I first thought it was about *all* .so files.
>>But why don't the symlinks don't belong into main ?
>>Don't they need to be there for versioning ?
>>    
>>
>
>What kind of "versioning"?
>
>https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00705.html
>
>  
>



From fedora at wir-sind-cool.org  Tue Dec 21 15:12:52 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 21 Dec 2004 16:12:52 +0100
Subject: FreeTDS
In-Reply-To: <41C838FF.3010009@coolspot.de>
References: <41C7E23B.6060804@coolspot.de>
	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>
	<41C83436.4030700@coolspot.de>
	<20041221154246.4a2c4809.fedora@wir-sind-cool.org>
	<41C838FF.3010009@coolspot.de>
Message-ID: <20041221161252.59c24ba0.fedora@wir-sind-cool.org>

On Tue, 21 Dec 2004 15:53:51 +0100, Stefan Sonnenberg-Carstens wrote:

> Ok, that would mean (for example)

"that" here refers to nothing as long as you don't quote anything.
Please avoid top-posting.

> main package ships *only* libct.so.2.0.0, nothing more

Take a look at your package. There are also softlinks of the form
lib*.so.$MAJOR_VERSION in the main package, with $MAJOR_VERSION
usually being the current API version:

lrwxrwxrwx root  root        14 /usr/lib/freetds/libct.so.2

For libraries in run-time linker's search path, ldconfig would create
and update these links. But nevertheless, packages ought to include
them, so RPM database queries work.

> and the devel package would ship the symlink libct.so to libct.so.2.0.0

Yes.

> After one compiled e.g. php, php *knows* it needs libct.so.2.0.0 and
> therefore doesn't need the symlink to libct.so anymore, and the devel
> could be whiped away after all.
> 
> Am I right ?

Well, what results do you get after compiling software which depends
on your package? ;)



From rdieter at math.unl.edu  Tue Dec 21 15:17:02 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 21 Dec 2004 09:17:02 -0600
Subject: FreeTDS
In-Reply-To: <20041221161252.59c24ba0.fedora@wir-sind-cool.org>
References: <41C7E23B.6060804@coolspot.de>	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>	<41C83436.4030700@coolspot.de>	<20041221154246.4a2c4809.fedora@wir-sind-cool.org>	<41C838FF.3010009@coolspot.de>
	<20041221161252.59c24ba0.fedora@wir-sind-cool.org>
Message-ID: <41C83E6E.8000701@math.unl.edu>

Michael Schwendt wrote:
> On Tue, 21 Dec 2004 15:53:51 +0100, Stefan Sonnenberg-Carstens wrote:
> 
> 
>>Ok, that would mean (for example)
> 
> 
> "that" here refers to nothing as long as you don't quote anything.
> Please avoid top-posting.

Stefan,

I would also suggest that this fedora-devel list not be used for QA'ing 
packages.  Please submit it to
http://bugzilla.fedora.us/ (assuming this is still the right place)
following:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy

-- Rex



From fedora at wir-sind-cool.org  Tue Dec 21 15:51:53 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 21 Dec 2004 16:51:53 +0100
Subject: FreeTDS
In-Reply-To: <41C83E6E.8000701@math.unl.edu>
References: <41C7E23B.6060804@coolspot.de>
	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>
	<41C83436.4030700@coolspot.de>
	<20041221154246.4a2c4809.fedora@wir-sind-cool.org>
	<41C838FF.3010009@coolspot.de>
	<20041221161252.59c24ba0.fedora@wir-sind-cool.org>
	<41C83E6E.8000701@math.unl.edu>
Message-ID: <20041221165153.16970c08.fedora@wir-sind-cool.org>

On Tue, 21 Dec 2004 09:17:02 -0600, Rex Dieter wrote:

> Stefan,
> 
> I would also suggest that this fedora-devel list not be used for QA'ing 
> packages.

Some public discussion on creating packages doesn't hurt anyone, does
it?

> Please submit it to
> http://bugzilla.fedora.us/ (assuming this is still the right place)

Caution: that won't help as there are no fairies who would go through
the efforts of QA'ing and approving the package there.

> following:
> http://www.fedora.us/wiki/PackageSubmissionQAPolicy

fedora.us Wiki has been shut down. http://fedoraproject.org/wiki
is to be used instead.



From walters at redhat.com  Tue Dec 21 16:04:05 2004
From: walters at redhat.com (Colin Walters)
Date: Tue, 21 Dec 2004 11:04:05 -0500
Subject: svn or arch
In-Reply-To: <20041221054700.GC7176@rogers.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
	<20041221054700.GC7176@rogers.com>
Message-ID: <1103645045.3135.105.camel@nexus.verbum.private>

On Tue, 2004-12-21 at 00:47 -0500, Dimitrie O. Paun wrote:
> On Fri, Dec 17, 2004 at 04:12:15PM -0500, Colin Walters wrote:
> > > A lot of packages include a spec.in file which is then passed through sed 
> > > to install the version number in the spec file before a tarball is 
> > > generated. Eliminating this extra step would make it easier for upstreams 
> > > to provide RPM support by eliminating this extra step.
> > 
> > Yes; but you still have the rpm revision number.  I am arguing for its
> > removal entirely.  That's one less spurious thing you see in a diff
> > between branches, and one less thing to merge conflict on.
> 
> Sorry for the late reply, but I must have missed one thing: where do
> we store these? Now, I'm not arguing for having them in .spec (in fact,
> I agree with you that they don't belong there), but where do we put
> them?

A PostgreSQL database would be my suggestion.  That way you can also
easily store in all the other metadata that you might want associated
with a version, such as:

o which architectures it's built for
o what machine it was built on
o which test suites it passed
o which OS versions it was released in
o who maintains it

etc.




From walters at redhat.com  Tue Dec 21 16:32:50 2004
From: walters at redhat.com (Colin Walters)
Date: Tue, 21 Dec 2004 11:32:50 -0500
Subject: svn or arch
In-Reply-To: <20041220232457.GD24832@rogers.com>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
	<20041220202932.GC24832@rogers.com>
	<1103575881.3135.69.camel@nexus.verbum.private>
	<20041220232457.GD24832@rogers.com>
Message-ID: <1103646770.3135.126.camel@nexus.verbum.private>

On Mon, 2004-12-20 at 18:24 -0500, Dimitrie O. Paun wrote:
> On Mon, Dec 20, 2004 at 03:51:21PM -0500, Colin Walters wrote:
> > > Yes, but that would be awkard to work with. On a large project, I think
> > > it would be slow, and it would be hard to maintain sane error reports.
> > 
> > Note that this approach is exactly analogous to how SRPM works now with
> > patches; the patch is applied at build time.
> 
> Yes, but this does not mean that SRPM is a convenient way to develop
> patches. It's a good way to package and distribute them, not to develop.
> I think that such a system should allow for easy _development_ of said
> patches too, not just packaging. Once developed, the packaging should
> happen automatically.

Ok, I generally agree; however, let's dissect the process here.  I
assert that merging the patch-branches at build time is in most cases
better than merging at import time, and no worse in general.

Let's say you have a package, with two simple patches to it.  You want
to import a new minor upstream version.

You do e.g.:

make importpkg PKG=foo-1.2.tar.gz
$RCS commit -s 'new upstream version'

This goes off and unpacks foo-1.2.tar.gz, imports it into the upstream
branch (there should be no conflicts), adds it to the lookaside cache,
etc.  You explicitly do *not* modify the spec file here.  

Then later when you do a "make build", if your patches apply cleanly
(and you expect them to, this is just a new minor stable release), then
there's no further interaction.  You didn't need to babysit a merge
which went cleanly.

Now, let's say that you maintain a package with several major patches
(e.g. kernel).  In this case, you do:

make importpkg PKG=linux-2.6.22.tar.gz
$RCS commit -s 'new upstream version'

The same as above, so far.  But now you know that you have to merge in
your branch-patches.  So you do:

make merge

This goes off and for each Branch: in the spec file, tries a 3-way
merge, and if it conflicts (or perhaps is just too fuzzy), you get
dropped into a directory with the normal .rej files, etc.  You resolve
these conflicts:

$EDITOR mm/mmap.c.rej
...
$RCS commit -m 'fix exec-shield conflict'

Note this commit goes into the exec-shield patch-branch as a merge from
the new upstream version.

You repeatedly type 'make merge' until all conflicts are resolved.

Finally, you do:

make local-build

You install the resulting RPM, dogfood it on your laptop a bit, then do:

make build

That goes off and pushes it to the real build system just like the
previous simple case; it goes through test suites, etc.

So essentially what I'm saying is that in the simple case, you shouldn't
need to do an explicit 'merge patches' step.  In the complex case, you
generally *know* you need to merge anyways.

I'm sure there are packages which fall in between here - e.g. their
patches only conflict on new major upstream versions.  But even there,
is it so bad for you to try the test build and get a result back in 20
seconds that it failed?  Surely that's a small part of the time one
would spend actually resolving the conflict and testing the new upstream
major version.

> > Hmm.  Maybe.  I don't have a very strong opinion on it.  My main concern
> > is I want to make it easy to find out what the package delta is versus
> > upstream and manipulate that.  If I have to trace through branches of
> > branches, that becomes a bit harder.
> 
> But that can be scriped, no? And a script should be able to figure this
> stuff out from continuations, right?

It could be scripted, sure.  I just like making important things like
this very explicit.



From symbiont at berlios.de  Tue Dec 21 16:32:25 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 22 Dec 2004 00:32:25 +0800
Subject: %ghost .pyo
Message-ID: <200412220032.25687.symbiont@berlios.de>

Hi:

We've talked about this before.  It's implemented in fedora.us, 
livna.org, and pyvault.  But, I'm beginning to be weary about an issue 
brought up concerning read-only /usr and tripwire installs with a 
Python putting non-fingerprinted .pyo files under lib/python2.3/.  Has 
anyone ran into this issue and/or can comment on it?  Should we just 
package .pyo anyway?  (This also applies to upcoming Fedora Extras 
packages, too.)

thanks,
-- 
-jeff



From twaugh at redhat.com  Tue Dec 21 16:38:09 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Tue, 21 Dec 2004 16:38:09 +0000
Subject: %ghost .pyo
In-Reply-To: <200412220032.25687.symbiont@berlios.de>
References: <200412220032.25687.symbiont@berlios.de>
Message-ID: <20041221163809.GR5322@redhat.com>

On Wed, Dec 22, 2004 at 12:32:25AM +0800, Jeff Pitman wrote:

> Hi:
> 
> We've talked about this before.  It's implemented in fedora.us, 
> livna.org, and pyvault.  But, I'm beginning to be weary about an issue 
> brought up concerning read-only /usr and tripwire installs with a 
> Python putting non-fingerprinted .pyo files under lib/python2.3/.  Has 
> anyone ran into this issue and/or can comment on it?  Should we just 
> package .pyo anyway?  (This also applies to upcoming Fedora Extras 
> packages, too.)

We have been promised a redhat-rpm-config that turns on the Python
pre-compiling, which will fix all this. (But it hasn't shown up yet
that I've seen..)

Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041221/a066cdac/attachment.sig>

From walters at redhat.com  Tue Dec 21 16:44:42 2004
From: walters at redhat.com (Colin Walters)
Date: Tue, 21 Dec 2004 11:44:42 -0500
Subject: svn or arch
In-Reply-To: <1103646770.3135.126.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
	<20041220202932.GC24832@rogers.com>
	<1103575881.3135.69.camel@nexus.verbum.private>
	<20041220232457.GD24832@rogers.com>
	<1103646770.3135.126.camel@nexus.verbum.private>
Message-ID: <1103647482.3135.133.camel@nexus.verbum.private>

On Tue, 2004-12-21 at 11:32 -0500, Colin Walters wrote:

> Finally, you do:
> 
> make local-build
> 
> You install the resulting RPM, dogfood it on your laptop a bit, then do:
> 
> make build

Incidentally, one other nice thing here about killing off the Release
from the spec file: these targets would actually use different releases,
without modifying the spec.  For a local-build, it would look at the
current version of the package installed on your system, and suffix it
with .0.local.N (or increment N if you already have a local version
installed).  That way the package installs without any warnings from RPM
or --force flags, etc.  When you do a real 'make build', it would use
the central postgres database to get a new build version.  This would be
newer than the .0.local.N versions, so you transparently get the "real"
version from the central build server when it comes through.




From walters at redhat.com  Tue Dec 21 16:55:12 2004
From: walters at redhat.com (Colin Walters)
Date: Tue, 21 Dec 2004 11:55:12 -0500
Subject: svn or arch
In-Reply-To: <20041220214653.96627.qmail@web8506.mail.in.yahoo.com>
References: <20041220214653.96627.qmail@web8506.mail.in.yahoo.com>
Message-ID: <1103648112.3135.140.camel@nexus.verbum.private>

On Mon, 2004-12-20 at 13:46 -0800, Rahul Sundaram wrote:

> To truly take advantage of a distributed system like
> arch you need use make use of features like branching
> in a heavy way which if frowned upon by cvs.
> 
> I suspect we would end up with something like conary
> if we design a build system on top of arch. 

I should investigate Conary further.  My understanding though is that
it's a much larger change than what we're discussing (e.g. you can't use
existing .spec files), and while it has some similar goals in some
areas, it isn't exactly the same thing.

In particular, it  focused on maintaining a delta from OS-distributed
binary RPMs and high-level binary RPM management, whereas we're more
discussing simply improving the development process for SRPMs.

Still though, it seems pretty interesting.



From symbiont at berlios.de  Tue Dec 21 16:52:30 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 22 Dec 2004 00:52:30 +0800
Subject: %ghost .pyo
In-Reply-To: <20041221163809.GR5322@redhat.com>
References: <200412220032.25687.symbiont@berlios.de>
	<20041221163809.GR5322@redhat.com>
Message-ID: <200412220052.31050.symbiont@berlios.de>

On Wednesday 22 December 2004 00:38, Tim Waugh wrote:
> > anyone ran into this issue and/or can comment on it? ?Should we
> > just package .pyo anyway? ?(This also applies to upcoming Fedora
> > Extras packages, too.)
>
> We have been promised a redhat-rpm-config that turns on the Python
> pre-compiling, which will fix all this. (But it hasn't shown up yet
> that I've seen..)

They're making progress, from what I've seen..

Anyhowl, we can pre-compile ourselves in an individual spec, but that 
doesn't fix the issue with %ghost.  To my knowledge and what google has 
on record is that %ghost was used to "save space" since pyo didn't 
really "save time".  However, python executed with -O as root actually 
introduces .pyo files in /usr/lib/python2.3/site-packages anyway which 
could have implications for read-only /usr (which I think python just 
ignores anyway), but more importantly for setups with tripwire 
triggers. Not being personally familiar with this type of security 
issue, I'm wondering out loud if we should even care about %ghost. 

thanks,
-- 
-jeff



From rdieter at math.unl.edu  Tue Dec 21 17:14:46 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 21 Dec 2004 11:14:46 -0600
Subject: FreeTDS
In-Reply-To: <20041221165153.16970c08.fedora@wir-sind-cool.org>
References: <41C7E23B.6060804@coolspot.de>	<20041221140558.1ec7c8bc.fedora@wir-sind-cool.org>	<41C83436.4030700@coolspot.de>	<20041221154246.4a2c4809.fedora@wir-sind-cool.org>	<41C838FF.3010009@coolspot.de>	<20041221161252.59c24ba0.fedora@wir-sind-cool.org>	<41C83E6E.8000701@math.unl.edu>
	<20041221165153.16970c08.fedora@wir-sind-cool.org>
Message-ID: <41C85A06.9060005@math.unl.edu>

Michael Schwendt wrote:
> On Tue, 21 Dec 2004 09:17:02 -0600, Rex Dieter wrote:
> 
> 
>>Stefan,
>>
>>I would also suggest that this fedora-devel list not be used for QA'ing 
>>packages.
> 
> 
> Some public discussion on creating packages doesn't hurt anyone, does
> it?

I justed want to avoid fedora-devel becoming a "Fedora Extras QA" QA 
forum, fedora-extras-list would be more appropriate IMO.


-- Rex



From dhollis at davehollis.com  Tue Dec 21 17:13:19 2004
From: dhollis at davehollis.com (David Hollis)
Date: Tue, 21 Dec 2004 12:13:19 -0500
Subject: PHP Vulnerability
In-Reply-To: <20041221144523.GA4112@shadow.sumu.org>
References: <20041221144523.GA4112@shadow.sumu.org>
Message-ID: <1103649199.3458.23.camel@dhollis-lnx.centricconsulting.com>

On Tue, 2004-12-21 at 16:45 +0200, Oskari Saarenmaa wrote:
> I rolled my own php-4.3.10 rpms (based on fc3 rpms) because there still
> isn't an official update available.
> 
> Source and binary rpms for fc1 and fc3 are available from
> http://rpms.www.sumu.org/php-4.3.10/

Making use of the new CVS accessiblity, you can find updated php.spec
and patch files at:

http://cvs.fedora.redhat.com/viewcvs/rpms/php/FC-3/


With these, you can roll your own 4.3.10 RPMs if you can't wait for them
to be officially released.  Do note that these would be fully
unsupported, etc and you do so at your own risk and all of that other
disclaimer stuff.  You would certainly still be wise to update to the
officially blessed RH packages once they are released in any event.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041221/d8c160d5/attachment.sig>

From chuldev at gmail.com  Tue Dec 21 17:28:58 2004
From: chuldev at gmail.com (D. Malhotra)
Date: Tue, 21 Dec 2004 22:58:58 +0530
Subject: Diskless client to run Fedora 
Message-ID: <41c85d5c.075966c5.1924.09e0@smtp.gmail.com>

 

 

Dear Members,

 

I want to make a cluster of clients which should boot in Fedora core
2/x86-64.

 

Configuration of my clients would be AMD 64/ADA2800 processors with 2Gigs of
RAM each.

 

I would be having a central server with loads of data which I would like to
split and loaded on the clients' ramdisks. 

 

The server would fetch data from them when needed. I want this for faster
accessibility.

 

Where can I find good documents/HOWTOs to create such a configuration of
clients and server? And the tools necessary for the same.

 

Also, is it possible that I run Windows server 2003 for the server which can
store the kernel for booting the clients and I install bootp/tftp on the
same.

 

Thanks,

Arnie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041221/9701e36b/attachment.htm>

From mattdm at mattdm.org  Tue Dec 21 17:47:15 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Dec 2004 12:47:15 -0500
Subject: Diskless client to run Fedora
In-Reply-To: <41c85d5c.075966c5.1924.09e0@smtp.gmail.com>
References: <41c85d5c.075966c5.1924.09e0@smtp.gmail.com>
Message-ID: <20041221174715.GA17111@jadzia.bu.edu>

On Tue, Dec 21, 2004 at 10:58:58PM +0530, D. Malhotra wrote:
> I want to make a cluster of clients which should boot in Fedora core
> 2/x86-64.

This discussion should go on the regular fedora-list, not fedora-devel-list.


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From rahulsundaram at yahoo.co.in  Tue Dec 21 16:49:15 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Tue, 21 Dec 2004 08:49:15 -0800 (PST)
Subject: svn or arch
In-Reply-To: <20041221044730.GB7176@rogers.com>
Message-ID: <20041221164915.68036.qmail@web8507.mail.in.yahoo.com>

Hi

> 
> Interesting. Any plans for RedHat/Fedora to switch
> to Conary?
> One difference between this proposal and conary is
> that we would
> try to remain compatible with a .rpm based system.
> In other
> words, the output of our system would be regular
> .src.rpm's
> that could be built/installed/etc. by existing
> tools.

rpm might be considered a legacy format if conary is
choosen but I am not sure its past the experimental
stage yet. It has been developed by ex redhat guys and
I saw a few people blogging about it. The presentation
on kernel meet was interesting

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Send holiday email and support a worthy cause. Do good. 
http://celebrity.mail.yahoo.com



From shiva at sewingwitch.com  Tue Dec 21 18:11:10 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 21 Dec 2004 10:11:10 -0800
Subject: PHP Vulnerability
In-Reply-To: <1103649199.3458.23.camel@dhollis-lnx.centricconsulting.com>
References: <20041221144523.GA4112@shadow.sumu.org>
	<1103649199.3458.23.camel@dhollis-lnx.centricconsulting.com>
Message-ID: <86ADCDE81046A81D6D6C0C40@[10.0.0.4]>

--On Tuesday, December 21, 2004 12:13 PM -0500 David Hollis 
<dhollis at davehollis.com> wrote:

> Making use of the new CVS accessiblity, you can find updated php.spec
> and patch files at:
>
> http://cvs.fedora.redhat.com/viewcvs/rpms/php/FC-3/
>
>
> With these, you can roll your own 4.3.10 RPMs if you can't wait for them
> to be officially released.  Do note that these would be fully
> unsupported, etc and you do so at your own risk and all of that other
> disclaimer stuff.  You would certainly still be wise to update to the
> officially blessed RH packages once they are released in any event.

Meanwhile, I figured I'd take the leap and move to the 5.0 branch. Alas, 
I've been unable to get the new 5.0.3 tarball to build using the old 5.0.2 
specfile:

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143101>

I don't see a 5.0.3 spec file in CVS yet:

<http://cvs.fedora.redhat.com/viewcvs/rpms/php/devel/>




From cra at WPI.EDU  Tue Dec 21 18:42:41 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Tue, 21 Dec 2004 13:42:41 -0500
Subject: %ghost .pyo
In-Reply-To: <200412220052.31050.symbiont@berlios.de>
References: <200412220032.25687.symbiont@berlios.de>
	<20041221163809.GR5322@redhat.com>
	<200412220052.31050.symbiont@berlios.de>
Message-ID: <20041221184241.GF5001@angus.ind.WPI.EDU>

On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> issue, I'm wondering out loud if we should even care about %ghost. 

I've heard that %ghost was on its deathbed anyway.



From rdieter at math.unl.edu  Tue Dec 21 18:51:13 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 21 Dec 2004 12:51:13 -0600
Subject: %ghost .pyo
In-Reply-To: <20041221184241.GF5001@angus.ind.WPI.EDU>
References: <200412220032.25687.symbiont@berlios.de>	<20041221163809.GR5322@redhat.com>	<200412220052.31050.symbiont@berlios.de>
	<20041221184241.GF5001@angus.ind.WPI.EDU>
Message-ID: <41C870A1.3040807@math.unl.edu>

Charles R. Anderson wrote:
> On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> 
>>issue, I'm wondering out loud if we should even care about %ghost. 
> 
> 
> I've heard that %ghost was on its deathbed anyway.

I hope you heard wrong, because %ghost can be very useful.


-- Rex



From fitzsim at redhat.com  Tue Dec 21 19:42:10 2004
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Tue, 21 Dec 2004 14:42:10 -0500
Subject: /usr/lib/jvm/java-1.4.2/include/jni.h x86_64
In-Reply-To: <cq7ei4$ki8$1@sea.gmane.org>
References: <cq7ei4$ki8$1@sea.gmane.org>
Message-ID: <1103658130.6374.42.camel@tortoise.toronto.redhat.com>

On Mon, 2004-12-20 at 16:00 -0500, Neal D. Becker wrote:
> Something here is broken (FC3-x86_64):
> 
> ls -l /usr/lib/jvm/java-1.4.2/include/jni.h
> lrwxrwxrwx  1 root root 56 Nov 17
> 20:44 /usr/lib/jvm/java-1.4.2/include/jni.h
> -> /usr/lib64/gcc-lib/i386-redhat-linux/3.4.2/include/jni.h
> 
> ls -l /usr/lib64/gcc-lib
> total 0
> 
> rpm --verify java-1.4.2-gcj-compat
> [silence]
> rpm --verify java-1.4.2-gcj-compat-devel
> [same]
> 

The next release of java-1.4.2-gcj-compat will fix this; jni.h is
present in gcc's default include path so this symlink is not needed.

Tom




From rahulsundaram at yahoo.co.in  Tue Dec 21 17:03:33 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Tue, 21 Dec 2004 09:03:33 -0800 (PST)
Subject: svn or arch
In-Reply-To: <1103648112.3135.140.camel@nexus.verbum.private>
Message-ID: <20041221170333.19029.qmail@web8508.mail.in.yahoo.com>

Hi


.  My
> understanding though is that
> it's a much larger change than what we're discussing
> (e.g. you can't use
> existing .spec files), and while it has some similar
> goals in some
> areas, it isn't exactly the same thing.

No. its not. Its just something to keep in mind for a
later development perhaps. I just mentioned it because
it seems close to whats being discussed here. If you
want to looking for better ways to build rpms conary
is not probably what you want


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 



From sarahs at redhat.com  Tue Dec 21 20:27:50 2004
From: sarahs at redhat.com (Sarah Wang)
Date: Wed, 22 Dec 2004 06:27:50 +1000
Subject: [Fwd: kde-i18n-lithuanian]
Message-ID: <1103660870.2285.5.camel@cpe-203-45-173-76.qld.bigpond.net.au>


-------------- next part --------------
An embedded message was scrubbed...
From: Roberto <roberto at mikrovisata.net>
Subject: kde-i18n-lithuanian
Date: Mon, 20 Dec 2004 13:45:36 +0200
Size: 3548
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/efa07e55/attachment.eml>

From enrico.scholz at informatik.tu-chemnitz.de  Tue Dec 21 20:28:28 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 21 Dec 2004 21:28:28 +0100
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <1103503652.5917.1.camel@localhost.localdomain> (David
	Woodhouse's message of "Mon, 20 Dec 2004 00:47:32 +0000")
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
Message-ID: <87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>

dwmw2 at infradead.org (David Woodhouse) writes:

>> exim-4.43-3
>> -----------
>> * Thu Dec 16 2004 David Woodhouse <dwmw2 at redhat.com> 4.43-3
>> - Demonstrate SASL auth configuration in default config file
>> - Enable TLS and provide certificate if necessary
>> - Don't reject all GB2312 charset mail by default
>
> This enables TLS on incoming and outgoing mail by default -- some
> feedback from testing would be appreciated.

To repeat my arguments from bugs #141479, #143392 and #143393:

* the /usr filesystem (inclusive /usr/share/ssl) can be shared between
  several hosts; when there are multiple servers, every one would use
  the same certificate. This will not work because CN must match the DNS
  name

* the sharing happens in >90% of all cases over an unencrypted
  network-filesystem (NFS). So, an attacker could easily get the
  SSL key.

A better place for the certificates would be somewhere under /etc.




Enrico



From rdieter at math.unl.edu  Tue Dec 21 20:34:06 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 21 Dec 2004 14:34:06 -0600
Subject: kde-i18n-lithuanian
In-Reply-To: <1103660870.2285.5.camel@cpe-203-45-173-76.qld.bigpond.net.au>
References: <1103660870.2285.5.camel@cpe-203-45-173-76.qld.bigpond.net.au>
Message-ID: <41C888BE.8080009@math.unl.edu>

Sarah Wang wrote:

> In fc3 package kde-i18n-lithuanian was removed. Why? 
> In fc2 it was.
> Who can add kde-i18n-lithuanian to rawhide and future release?

I believe it was upstream kde that dropped it, I don't see a kde-i18n-lt at
http://download.kde.org/download.php?url=stable/3.3.2/src/kde-i18n/


-- Rex



From jwboyer at jdub.homelinux.org  Tue Dec 21 20:49:16 2004
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 21 Dec 2004 14:49:16 -0600
Subject: CVS bugzillas
Message-ID: <1103662157.8764.4.camel@jdub.homelinux.org>

If there are issues with either the CVS server itself or the contents in
a package directory (i.e. make doesn't complete, etc), should we file
bugs against the CVS infrastructure?

If so, there doesn't seem to be a good target.  I could open a bug to
get a target in bugzilla for this, but I'd like to know if this is
desired or not.  Or maybe there is (or should be) a fedora-cvs list?  I
don't mean fedora-cvs-commits either, that's a bit different.

thx,
josh



From toshio at tiki-lounge.com  Tue Dec 21 21:45:48 2004
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 21 Dec 2004 13:45:48 -0800
Subject: %ghost .pyo
In-Reply-To: <200412220052.31050.symbiont@berlios.de>;
	from symbiont@berlios.de on Wed, Dec 22, 2004 at 12:52:30AM +0800
References: <200412220032.25687.symbiont@berlios.de>
	<20041221163809.GR5322@redhat.com>
	<200412220052.31050.symbiont@berlios.de>
Message-ID: <20041221134548.B18135@tiki-lounge.com>

On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> Anyhowl, we can pre-compile ourselves in an individual spec, but that 
> doesn't fix the issue with %ghost.  To my knowledge and what google has 
> on record is that %ghost was used to "save space" since pyo didn't 
> really "save time".  However, python executed with -O as root actually 
> introduces .pyo files in /usr/lib/python2.3/site-packages anyway which 
> could have implications for read-only /usr (which I think python just 
> ignores anyway), but more importantly for setups with tripwire 
> triggers. Not being personally familiar with this type of security 
> issue, I'm wondering out loud if we should even care about %ghost. 
> 
On my laptop I definitely care about it.  6MB of disk doesn't stretch very
far.  On my desktop, the savings is appreciated.  But it may not justify
making tripwire harder to deal with (I don't run tripwire.)  OTOH, a
read-only /usr should prevent python from creating the pyo files so that's
less of an issue.  Additionally, aren't python optimized files a non-default
setting?  So someone had to set root on the tripwire enabled boxes to
create these files in the first place?

-Toshio



From walters at redhat.com  Tue Dec 21 22:01:20 2004
From: walters at redhat.com (Colin Walters)
Date: Tue, 21 Dec 2004 17:01:20 -0500
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103666480.3135.186.camel@nexus.verbum.private>

On Tue, 2004-12-21 at 21:28 +0100, Enrico Scholz wrote:

> A better place for the certificates would be somewhere under /etc.

Longer term, I think we really want a more formal certificate management
system, with a defined interface for installing a certificate on the
system (or for a specific user), removing certificates, granting access
to certain certificates to particular daemons, creating a new CA, etc.
And most importantly, get every application to use it.  Right now it's
just crazy with applications dropping certificates in any random place
with ad-hoc access controls, and applications not using the same
verification chains.

A first step at this could be a utility like install-certificate that
just dropped certs into a well-defined directory in /etc.





From christopher.hotchkiss at gmail.com  Tue Dec 21 22:26:29 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 21 Dec 2004 17:26:29 -0500
Subject: hdlist order tag problem
In-Reply-To: <20041221142214.B9EEC3E63E2@mail.wtamu.edu>
References: <41C8309F.4060607@math.unl.edu>
	<20041221142214.B9EEC3E63E2@mail.wtamu.edu>
Message-ID: <7f48492a04122114264fc8cfdc@mail.gmail.com>

Well I removed all my changes to the comps.xml file and did a
genhdlist. When I boot an intstall box though, I still get the same
error.

-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From christopher.hotchkiss at gmail.com  Tue Dec 21 22:26:29 2004
From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss)
Date: Tue, 21 Dec 2004 17:26:29 -0500
Subject: hdlist order tag problem
In-Reply-To: <20041221142214.B9EEC3E63E2@mail.wtamu.edu>
References: <41C8309F.4060607@math.unl.edu>
	<20041221142214.B9EEC3E63E2@mail.wtamu.edu>
Message-ID: <7f48492a04122114264fc8cfdc@mail.gmail.com>

Well I removed all my changes to the comps.xml file and did a
genhdlist. When I boot an intstall box though, I still get the same
error.

-- 
Christopher Hotchkiss
(813)960-9273
http://www.post227.org



From symbiont at berlios.de  Wed Dec 22 00:33:14 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 22 Dec 2004 08:33:14 +0800
Subject: %ghost .pyo
In-Reply-To: <20041221134548.B18135@tiki-lounge.com>
References: <200412220032.25687.symbiont@berlios.de>
	<200412220052.31050.symbiont@berlios.de>
	<20041221134548.B18135@tiki-lounge.com>
Message-ID: <200412220833.14523.symbiont@berlios.de>

On Wednesday 22 December 2004 05:45, Toshio Kuratomi wrote:
> Additionally, aren't python optimized files a non-default
> setting? ?

They don't need to exist for proper python operation.

> So someone had to set root on the tripwire enabled boxes to 
> create these files in the first place?

Probably. So, it has to be explicitly setup now. Any SELinux 
implications?

Do note that the base python package does distribute pyo, it's the 
modules and apps that %ghost them in the fedora.us template.  (Unless 
the python package has been changed in Rawhide...)

thanks,
-- 
-jeff



From shiva at sewingwitch.com  Wed Dec 22 01:32:44 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 21 Dec 2004 17:32:44 -0800
Subject: PHP Vulnerability
In-Reply-To: <8efc1ce40412210056d55cd1a@mail.gmail.com>
References: <8efc1ce40412210056d55cd1a@mail.gmail.com>
Message-ID: <F11008D69F75D24C8EBBB0BD@[10.169.6.246]>

The 4.3.10 update came out today.

If you run phpBB, your job's not quite over. You should make sure you've 
updated phpBB to 2.0.11, as it has a separate flaw that's being actively 
use to deface websites and delete files.

<http://it.slashdot.org/article.pl?sid=04/12/21/2135235>






From pbrobinson at gmail.com  Wed Dec 22 02:23:39 2004
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 22 Dec 2004 10:23:39 +0800
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <1103666480.3135.186.camel@nexus.verbum.private>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<1103666480.3135.186.camel@nexus.verbum.private>
Message-ID: <5256d0b0412211823261b146a@mail.gmail.com>

> > A better place for the certificates would be somewhere under /etc.
> 
> Longer term, I think we really want a more formal certificate management
> system, with a defined interface for installing a certificate on the
> system (or for a specific user), removing certificates, granting access
> to certain certificates to particular daemons, creating a new CA, etc.
> And most importantly, get every application to use it.  Right now it's
> just crazy with applications dropping certificates in any random place
> with ad-hoc access controls, and applications not using the same
> verification chains.
> 
> A first step at this could be a utility like install-certificate that
> just dropped certs into a well-defined directory in /etc.

Sounds like the certificate stuff redhat bought from Netscape would
fit the bill quite nicely when they finish all the various stuff
required to release it.

P



From Axel.Thimm at ATrpms.net  Wed Dec 22 03:24:13 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 22 Dec 2004 04:24:13 +0100
Subject: %ghost .pyo
In-Reply-To: <20041221184241.GF5001@angus.ind.WPI.EDU>
References: <200412220032.25687.symbiont@berlios.de>
	<20041221163809.GR5322@redhat.com>
	<200412220052.31050.symbiont@berlios.de>
	<20041221184241.GF5001@angus.ind.WPI.EDU>
Message-ID: <20041222032413.GX20813@neu.nirvana>

On Tue, Dec 21, 2004 at 01:42:41PM -0500, Charles R. Anderson wrote:
> On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> > issue, I'm wondering out loud if we should even care about %ghost. 
> 
> I've heard that %ghost was on its deathbed anyway.

Don't you need %ghost for logfiles?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/247a634a/attachment.sig>

From Axel.Thimm at ATrpms.net  Wed Dec 22 03:30:27 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 22 Dec 2004 04:30:27 +0100
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <20041222033027.GY20813@neu.nirvana>

On Tue, Dec 21, 2004 at 09:28:28PM +0100, Enrico Scholz wrote:
> dwmw2 at infradead.org (David Woodhouse) writes:
> >> exim-4.43-3
> >> * Thu Dec 16 2004 David Woodhouse <dwmw2 at redhat.com> 4.43-3
> >> - Demonstrate SASL auth configuration in default config file
> >> - Enable TLS and provide certificate if necessary
> >> - Don't reject all GB2312 charset mail by default
> >
> > This enables TLS on incoming and outgoing mail by default -- some
> > feedback from testing would be appreciated.
> 
> To repeat my arguments from bugs #141479, #143392 and #143393:
> 
> * the /usr filesystem (inclusive /usr/share/ssl) can be shared between
>   several hosts; when there are multiple servers, every one would use
>   the same certificate. This will not work because CN must match the DNS
>   name
> 
> * the sharing happens in >90% of all cases over an unencrypted
>   network-filesystem (NFS). So, an attacker could easily get the
>   SSL key.
> 
> A better place for the certificates would be somewhere under /etc.

Indeed, I always wondered why the certificates had been put under
/usr/share/ssl and by whom. The FHS had been quite strict on this from
the very beginning.

/etc seems a rather sane place. Perhaps /etc/ssl/?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/e2dc14ff/attachment.sig>

From symbiont at berlios.de  Wed Dec 22 03:31:28 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 22 Dec 2004 11:31:28 +0800
Subject: %ghost .pyo
In-Reply-To: <20041222032413.GX20813@neu.nirvana>
References: <200412220032.25687.symbiont@berlios.de>
	<20041221184241.GF5001@angus.ind.WPI.EDU>
	<20041222032413.GX20813@neu.nirvana>
Message-ID: <200412221131.29131.symbiont@berlios.de>

On Wednesday 22 December 2004 11:24, Axel Thimm wrote:
> On Tue, Dec 21, 2004 at 01:42:41PM -0500, Charles R. Anderson wrote:
> > On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> > > issue, I'm wondering out loud if we should even care about
> > > %ghost.
> >
> > I've heard that %ghost was on its deathbed anyway.
>
> Don't you need %ghost for logfiles?

Yep. %ghost is great for /var, but it seems /usr would have issues.  Is 
it even FHS-compliant to have a program write files in /usr during 
program execution?  If there is a compliancy issue and setup 
complications in Tripwire or SELinux, then it seems packaging pyo is 
the way to go.

thanks,
-- 
-jeff



From davej at redhat.com  Wed Dec 22 07:01:35 2004
From: davej at redhat.com (Dave Jones)
Date: Wed, 22 Dec 2004 02:01:35 -0500
Subject: CVS kernel compile
In-Reply-To: <1103594563.6919.2.camel@jdub.homelinux.org>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
Message-ID: <20041222070134.GB28113@redhat.com>

On Mon, Dec 20, 2004 at 08:02:43PM -0600, Josh Boyer wrote:
 > Ok, so I'm probably an idiot, but can anyone explain to me how to build
 > the kernel out of CVS?
 > 
 > I've read the cvs.fedora.redhat.com website and done a CVS checkout.
 > But when I do a 'make sources' it comes up with the following error
 > after downloading the kernel tarball and merging a bunch of configs:
 > 
 > make: *** No rule to make target `download', needed by `sources'.  Stop.
 > 
 > I can't find the download target anywhere.  Am I the only one to see

Its defined in common/Makefile.common.  Do you have the common dir checked out too?

		Dave



From dpaun at rogers.com  Wed Dec 22 07:02:53 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Wed, 22 Dec 2004 02:02:53 -0500
Subject: [Peter.Dedecker@vtk2.ugent.be: Re: Fedora Stateless:
	stateless-snapshooter modified]
Message-ID: <20041222070253.GD7176@rogers.com>

----- Forwarded message from Peter Dedecker - FSU <Peter.Dedecker at vtk2.ugent.be> -----

Date: Tue, 21 Dec 2004 08:48:56 +0000
From: Peter Dedecker - FSU <Peter.Dedecker at vtk2.ugent.be>
Organization: VTK
To: dpaun at rogers.com
Subject: Re: Fedora Stateless: stateless-snapshooter modified

Hi,

Dimitrie O. Paun wrote:
>Yes, a diff -u would be much appreciated.

I've lots of trouble with that mailing list.  The post you answered, was 
my first post ever on that list.  I'm subscribed to that list and I'm 
also subscribed with a lot of e-mail adresses to post-only at redhat.com so 
there would be no reason to hold back my messages.

So, in awaiting of my message by fedora-devel-list, I'll sent my answer 
directly to you.  Can you post it on fedora-devel-list?  Thanks a lot!



Dimitrie O. Paun wrote:

> Yes, a diff -u would be much appreciated.


Sorry, but with my mods, it still doesn't work.  I recieve this errors 
that don't have anything in relationshop with my mods because I didn't 
modify anything in the list-function.

# ./stateless-snapshooter_modified --list
Traceback (most recent call last):
File "/usr/share/stateless/stateless-snapshooter.py_modified", line 79, in ?
protosystems = snapshooter.list_protosystems ()
File "/usr/share/stateless/snapshooter.py", line 54, in list_protosystems
srv = get_readonly_service ()
File "/usr/share/stateless/snapshooter.py", line 50, in get_readonly_service
return LDAPUtils.StatelessService (LDAPUtils.ReadOnlyDirectory (cfg))
File "/usr/share/stateless/LDAPUtils.py", line 81, in init
Directory.init (self, cfg)
File "/usr/share/stateless/LDAPUtils.py", line 65, in init
self.uri = cfg.get_ldap_uri ()
File "/usr/share/stateless/config.py", line 43, in get_ldap_uri
server = self["LDAP_SERVER"].lstrip()
AttributeError: 'NoneType' object has no attribute 'lstrip'

If you want a diff -u output of my changes, just take a look at 
http://studwww.ugent.be/~peddecke/diff

Don't you also think this tool has to become pyGTK independant?

Thanks!


-- 
Peter Dedecker
The Fedora Stateless @ UGent project
http://blog.eikke.com/index.php/fedorastateless

----- End forwarded message -----



From dpaun at rogers.com  Wed Dec 22 07:22:17 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Wed, 22 Dec 2004 02:22:17 -0500
Subject: svn or arch
In-Reply-To: <1103646770.3135.126.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<20041220044906.GA22942@rogers.com>
	<1103559336.3135.8.camel@nexus.verbum.private>
	<20041220195245.GB24832@rogers.com>
	<1103573337.3135.47.camel@nexus.verbum.private>
	<20041220202932.GC24832@rogers.com>
	<1103575881.3135.69.camel@nexus.verbum.private>
	<20041220232457.GD24832@rogers.com>
	<1103646770.3135.126.camel@nexus.verbum.private>
Message-ID: <20041222072217.GE7176@rogers.com>

On Tue, Dec 21, 2004 at 11:32:50AM -0500, Colin Walters wrote:
> 
> Ok, I generally agree; however, let's dissect the process here.  I
> assert that merging the patch-branches at build time is in most cases
> better than merging at import time, and no worse in general.

I'm afraid that the more we discuss, the less I like this merging
at build time. Yes, I agree with you that common cases should be
simple, but I see very little reason why what I'm proposing should
be any more complicated. However, you have two big advantages the
way I'm proposing, namely:
  A. You get to *see* the source that's going to be built.
     This is very, very important, not the least being that it's
     the way people are used to. I want to be able to look at what 
     is going to be built, maybe make sure a patch has no semantic 
     conflicts, etc. Besides, what do you do when you
     have a problem? You need to look at the _exact_ stuff that's
     being built, which will not be readily available if you 
     patch at built time. Moreover, one typically tries to catch
     (and fix) problems as early as possible in the process, not
     push them to a big operation that will eventually generate
     a source that I've never seen.
  B. The whole point of this exercise is to try to preserve the
     individual patches in the SRPM as they are now. I think this
     provides value, and it's a worthwhile effort. However, having
     all this mix-in branches that merge two patches that interact
     will result in having only one patch for the two features.
     This is contrary to what we're trying to achive, and I see no
     reason for this limitation.

Now, let's look at the process that you propose, see if it would be
any different if we are to maintain the changes in interdependent
branches:

> Let's say you have a package, with two simple patches to it.  You want
> to import a new minor upstream version.
> 
> You do e.g.:
> 
> make importpkg PKG=foo-1.2.tar.gz
> $RCS commit -s 'new upstream version'

[...]
> make merge
> 
> This goes off and for each Branch: in the spec file, tries a 3-way
> merge, and if it conflicts (or perhaps is just too fuzzy), you get
> dropped into a directory with the normal .rej files, etc.  You resolve
> these conflicts:
> 
> $EDITOR mm/mmap.c.rej
> ...
> $RCS commit -m 'fix exec-shield conflict'
> 
> Note this commit goes into the exec-shield patch-branch as a merge from
> the new upstream version.
> 
> You repeatedly type 'make merge' until all conflicts are resolved.


Agreed. Now, there is nothing stopping this process from working
*exactly* the same if we are to use the branch-from-branch approach.
Of course, you don't need to read the 'Branch:' from .spec file or
anything like that: the RCS already knows that branch B is derived
from branch A. Less housekeeping.

-- 
Dimi.



From mk at crc.dk  Wed Dec 22 07:23:36 2004
From: mk at crc.dk (Mogens Kjaer)
Date: Wed, 22 Dec 2004 08:23:36 +0100
Subject: ia32e, er EM64T that is...
In-Reply-To: <20040906174717.GA11888@devserv.devel.redhat.com>
References: <200409061011.52742.jkeating@j2solutions.net>
	<20040906174717.GA11888@devserv.devel.redhat.com>
Message-ID: <41C920F8.7020601@crc.dk>

Alan Cox wrote:
> On Mon, Sep 06, 2004 at 10:11:51AM -0700, Jesse Keating wrote:
> 
>>I guess a better question: With kernel 2.6, is there any need to have a 
>>specific ia32e vs amd64 kernel?  Are all the differences worked out at 
>>runtime and thus a non-issue?  Thanks.
> 
> 
> em64t as Intel currently call it is pretty close to the x86-64 architecture
> so its not too bad a clone. It lacks prefetch/prefetchw which can also be 
> used by some fancy user space stuff like image processors. It also lacks
> a hardware IOMMU so you may have performance problems going above about 3.5Gb
> of RAM depending on your other hardware.
>

Sorry for following up on an old thread...

I have a Xeon/EM64T machine with 4G.

FC3-32bit installs without problems, 4G available.

FC3 x86-64 doesn't install, no disks are found.

If I boot FC3 x86-64 installation with mem=3072M,
there are no problems.

I have to add mem=3072M to grub after the installation
to get a running system.

The funny thing is, if I write mem=4096M, it still
boots, but only 3G memory is available.

I can see from /proc/iomem that there are devices
starting at the 3G address, so my guess is that
I've run into the problem described above.

Is there any way to get a x86-64 kernel to use all
4G?

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk at crc.dk Homepage: http://www.crc.dk



From dpaun at rogers.com  Wed Dec 22 07:32:00 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Wed, 22 Dec 2004 02:32:00 -0500
Subject: svn or arch
In-Reply-To: <1103645045.3135.105.camel@nexus.verbum.private>
References: <20041216181302.99295.qmail@web8503.mail.in.yahoo.com>
	<1103314870.12552.107.camel@nexus.verbum.private>
	<A3DD015023608F3EEB659EA9@[10.169.6.246]>
	<1103317935.12552.117.camel@nexus.verbum.private>
	<20041221054700.GC7176@rogers.com>
	<1103645045.3135.105.camel@nexus.verbum.private>
Message-ID: <20041222073200.GF7176@rogers.com>

On Tue, Dec 21, 2004 at 11:04:05AM -0500, Colin Walters wrote:
> A PostgreSQL database would be my suggestion.  That way you can also
> easily store in all the other metadata that you might want associated
> with a version, such as:
> 
> o which architectures it's built for
> o what machine it was built on
> o which test suites it passed
> o which OS versions it was released in
> o who maintains it

Thing is, I truely dislike databases for such simple tasks. This are
hard to setup/maintain beasts, that are not really needed for this
task. Why not simply store this info in some files in the repository?

Having a *simply* system to setup and work with is essential. Someone
could simply get started by just checking out stuff, and go. With a
database system required (but for most system not needed) it becomes
a pain, and as a result user base gets smaller.

That aside, I also don't like it at a conceptual level: we are splitting
data that belongs together. I can't think of many examples where that
was a good idea. You would have state now in two independent systems that
you'd need to keep in synch, you'd need some sort of versioning in the
DB, and before you know it you have to roll up your own little RCS in
the DB. Enter subversion, see how well the DB idea worked for them :)

So unless we'd have *big* problems without a RDBMS, I strongly suggest
we stick to a simple to understand text file setup, keep everything
together, and use the RCS to version stuff.

-- 
Dimi.



From arjanv at redhat.com  Wed Dec 22 09:50:31 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 22 Dec 2004 10:50:31 +0100
Subject: ia32e, er EM64T that is...
In-Reply-To: <41C920F8.7020601@crc.dk>
References: <200409061011.52742.jkeating@j2solutions.net>
	<20040906174717.GA11888@devserv.devel.redhat.com>
	<41C920F8.7020601@crc.dk>
Message-ID: <1103709031.4131.11.camel@laptopd505.fenrus.org>

On Wed, 2004-12-22 at 08:23 +0100, Mogens Kjaer wrote:

> I have a Xeon/EM64T machine with 4G.
> 
> FC3-32bit installs without problems, 4G available.
> 
> FC3 x86-64 doesn't install, no disks are found.
> 
> If I boot FC3 x86-64 installation with mem=3072M,
> there are no problems.
> 
> I have to add mem=3072M to grub after the installation
> to get a running system.
> 
> The funny thing is, if I write mem=4096M, it still
> boots, but only 3G memory is available.


this is a known issue and I think is fixed now; not sure if the kernel
with the fix has gone out of testing yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/027a65a2/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 10:02:46 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 11:02:46 +0100
Subject: firefox in FC3; Ctrl A and Ctrl E without effect
In-Reply-To: <41C7CBBA.4030604@carwyn.com> (Carwyn Edwards's message of
	"Tue, 21 Dec 2004 07:07:38 +0000")
References: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>
	<41C7CBBA.4030604@carwyn.com>
Message-ID: <87vfaubqgp.fsf@kosh.ultra.csn.tu-chemnitz.de>

carwyn at carwyn.com (Carwyn Edwards) writes:

>> Mozilla allows the usage of "CtrlA" and "CrtlE" for skipping to the
>> beginning/end of an input line. How to do this in forefox?
>
> "Home" and "End" work. Ctrl+A tends to be mapped to "Select All" in
> Gnome - following "popular convention".

How can I change this without executing gnome-settings-daemon?



Enrico



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 10:15:45 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 11:15:45 +0100
Subject: firefox and icons...
In-Reply-To: <1103409723.5679.53.camel@localhost.localdomain> (Havoc
	Pennington's message of "Sat, 18 Dec 2004 17:42:03 -0500")
References: <41C4A645.6050001@homer.se>
	<1103409723.5679.53.camel@localhost.localdomain>
Message-ID: <87u0qebpv2.fsf@kosh.ultra.csn.tu-chemnitz.de>

hp at redhat.com (Havoc Pennington) writes:

>> Why are these icons used and not the original ones?
>
> We use a consistent icon theme across the whole desktop and apps.
> Application-specific theme systems are generally considered Evil.

I do not think so. A consistent theme across applications which are used
only from time-to-time is ok. But when you use regularly an application
you will want to configure certain aspects without affecting other apps
with these settings.

E.g. in an often used application I need only the graphical icons, while
I appreciate a text description in seldom used apps. Or, my XEmacs looks
best with a dark gray as background whereas gnome uses white. The result
can be found at [1]. Or, it is ok when most applications use a common
proxy setting. But for web-viewing applications (browsers), individual
settings should be possible (e.g. for anonymizing proxies).


Overall, I think that a too tight desktop-coupling should be avoided.
You will have only disadvantages when the "right" desktop-environment is
not used.  E.g. when you do not use Gnome, you will be punished everytime
when gnome-settions-daemon is executed as it misconfigures your keyboard
settings ([2]). Or, opening the new, gnomeish 'save-as' dialog in firefox
needs now 5-10 seconds; the plain old appeared immediatly.



Enrico

Footnotes: 
[1]  http://www-user.tu-chemnitz.de/~ensc/colors-broken.png
     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103521
[2]  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117221



From arjanv at redhat.com  Wed Dec 22 10:51:52 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 22 Dec 2004 11:51:52 +0100
Subject: firefox in FC3; Ctrl A and Ctrl E without effect
In-Reply-To: <87vfaubqgp.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>
	<41C7CBBA.4030604@carwyn.com>
	<87vfaubqgp.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1103712712.4131.14.camel@laptopd505.fenrus.org>

On Wed, 2004-12-22 at 11:02 +0100, Enrico Scholz wrote:
> carwyn at carwyn.com (Carwyn Edwards) writes:
> 
> >> Mozilla allows the usage of "CtrlA" and "CrtlE" for skipping to the
> >> beginning/end of an input line. How to do this in forefox?
> >
> > "Home" and "End" work. Ctrl+A tends to be mapped to "Select All" in
> > Gnome - following "popular convention".
> 
> How can I change this without executing gnome-settings-daemon?

make sure you have something like this:
$ cat ~/.gtkrc-2.0
gtk-key-theme-name = "Emacs"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/51ec3dea/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 10:59:33 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 11:59:33 +0100
Subject: firefox and icons...
In-Reply-To: <41C4A645.6050001@homer.se> (Lars E. Pettersson's message of
	"Sat, 18 Dec 2004 22:51:01 +0100")
References: <41C4A645.6050001@homer.se>
Message-ID: <87llbqbnu2.fsf@kosh.ultra.csn.tu-chemnitz.de>

lars at homer.se ("Lars E. Pettersson") writes:

> Just tried the rawhide firefox on my FC3 (Gnome, Bluecurve)
> installation and noticed that the icons had changed to something that
> resembles the ones used by nautilus, epiphany, etc.
>
> Is it possible to revert this to the original firefox icons (the ones
> used by the FC3 firefox, both are 1.0-versions)?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138988
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138984

Or, a comparision of the new style (taken from [1]) with the old one is
available at

       http://www.tu-chemnitz.de/~ensc/firefox-icons-compare.png



Enrico

Footnotes: 
[1]  http://www.bluethingy.com/linux/bluecurve_firefox.png
     http://listman.redhat.com/archives/fedora-devel-list/2004-December/msg00747.html



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 11:12:01 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 12:12:01 +0100
Subject: firefox in FC3; Ctrl A and Ctrl E without effect
In-Reply-To: <1103712712.4131.14.camel@laptopd505.fenrus.org> (Arjan van de
	Ven's message of "Wed, 22 Dec 2004 11:51:52 +0100")
References: <1103612625.8717.4.camel@sunny.rhrk.uni-kl.de>
	<41C7CBBA.4030604@carwyn.com>
	<87vfaubqgp.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1103712712.4131.14.camel@laptopd505.fenrus.org>
Message-ID: <87hdmebn9a.fsf@kosh.ultra.csn.tu-chemnitz.de>

arjanv at redhat.com (Arjan van de Ven) writes:

>> > "Home" and "End" work. Ctrl+A tends to be mapped to "Select All" in
>> > Gnome - following "popular convention".
>> 
>> How can I change this without executing gnome-settings-daemon?
>
> make sure you have something like this:
> $ cat ~/.gtkrc-2.0
> gtk-key-theme-name = "Emacs"

Cool, it works. Many thanks.



Enrico



From Nicolas.Mailhot at laPoste.net  Wed Dec 22 11:12:44 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 22 Dec 2004 12:12:44 +0100
Subject: svn or arch
In-Reply-To: <1103330023.1186.3.camel@nexus.verbum.private>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
	<Pine.LNX.4.61.0412171818290.14188@asterix>
	<1103330023.1186.3.camel@nexus.verbum.private>
Message-ID: <1103713964.25633.4.camel@ulysse.olympe.o2t>

Le vendredi 17 d?cembre 2004 ? 19:33 -0500, Colin Walters a ?crit :
> On Fri, 2004-12-17 at 18:30 -0600, Satish Balay wrote:
> 
> > I would sugest 'rpmbuild --rebuild bla.src.rpm' should work for
> > users. i.e 'bla.spec' that gets into 'bla.src.rpm' should be a
> > generated file based on all the data that can be automatically pulled
> > from external sources.
> 
> Absolutely agreed.  The SRPM becomes a legacy format that should work
> with legacy tools.

Please don't.
I can happily work with a few cds on SRPMS.
I'll shot the first one that'll only suggest to replace it with a multi-
cd cvs dump

One of the foremost qualities of rpm is that a srpm is a simple archive
of package root + patches + specfile. CVS is ok for people heavily
involved in a project. For casual users, it can not replace a SRPM.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/b4a841cc/attachment.sig>

From dwmw2 at infradead.org  Wed Dec 22 12:11:59 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 22 Dec 2004 12:11:59 +0000
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <1103666480.3135.186.camel@nexus.verbum.private>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<1103666480.3135.186.camel@nexus.verbum.private>
Message-ID: <1103717519.6111.152.camel@localhost.localdomain>

On Tue, 2004-12-21 at 17:01 -0500, Colin Walters wrote:
> On Tue, 2004-12-21 at 21:28 +0100, Enrico Scholz wrote:
> 
> > A better place for the certificates would be somewhere under /etc.

Agreed.

> Longer term, I think we really want a more formal certificate management
> system, with a defined interface for installing a certificate on the
> system (or for a specific user), removing certificates, granting access
> to certain certificates to particular daemons, creating a new CA, etc.

Also agreed. As it was I just copied the %post script from dovecot, but
I note that mod_ssl does it differently.

> A first step at this could be a utility like install-certificate that
> just dropped certs into a well-defined directory in /etc.

Provide a patch which adds this to the openssl package, I suppose.
Once this exists we can fix the Exim/dovecot/etc RPMs to use it.

-- 
dwmw2



From lfarkas at bppiac.hu  Wed Dec 22 12:38:36 2004
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Wed, 22 Dec 2004 13:38:36 +0100
Subject: SSL cert/key location
In-Reply-To: <20041222033027.GY20813@neu.nirvana>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>	<1103503652.5917.1.camel@localhost.localdomain>	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
Message-ID: <41C96ACC.2020204@bppiac.hu>

Axel Thimm wrote:
> On Tue, Dec 21, 2004 at 09:28:28PM +0100, Enrico Scholz wrote:
> 
>>dwmw2 at infradead.org (David Woodhouse) writes:
>>
>>>>exim-4.43-3
>>>>* Thu Dec 16 2004 David Woodhouse <dwmw2 at redhat.com> 4.43-3
>>>>- Demonstrate SASL auth configuration in default config file
>>>>- Enable TLS and provide certificate if necessary
>>>>- Don't reject all GB2312 charset mail by default
>>>
>>>This enables TLS on incoming and outgoing mail by default -- some
>>>feedback from testing would be appreciated.
>>
>>To repeat my arguments from bugs #141479, #143392 and #143393:
>>
>>* the /usr filesystem (inclusive /usr/share/ssl) can be shared between
>>  several hosts; when there are multiple servers, every one would use
>>  the same certificate. This will not work because CN must match the DNS
>>  name
>>
>>* the sharing happens in >90% of all cases over an unencrypted
>>  network-filesystem (NFS). So, an attacker could easily get the
>>  SSL key.
>>
>>A better place for the certificates would be somewhere under /etc.
> 
> 
> Indeed, I always wondered why the certificates had been put under
> /usr/share/ssl and by whom. The FHS had been quite strict on this from
> the very beginning.
> 
> /etc seems a rather sane place. Perhaps /etc/ssl/?

agree!
the first think what i used to do is
mkdir /etc/ssl
mv /usr/share/ssl/* /etc/ssl/
rm -rf /usr/share/ssl
ln -s /etc/ssl /usr/share/
these are the only configuration files which are not under /etc. why???


-- 
   Levente                               "Si vis pacem para bellum!"



From buildsys at redhat.com  Wed Dec 22 12:50:13 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 22 Dec 2004 07:50:13 -0500
Subject: rawhide report: 20041222 changes
Message-ID: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com>

New package GFS
	GFS - The Global File System

New package GFS-kernel
	GFS-kernel - The Global File System kernel modules

New package ccs
	CCS - The Cluster Configuration System

New package cfengine
	GNU cfengine - a systems administration tool for networks

New package cman
	cman - The Cluster Manager

New package cman-kernel
	cman-kernel - The Cluster Manager kernel modules

New package dlm
	dlm - The Distributed Lock Manager

New package dlm-kernel
	dlm-kernel - The Distributed Lock Manager kernel modules.

New package fence
	fence - The cluster I/O fencing system

New package gnbd
	gnbd - GFS's Network Block Device

New package gnbd-kernel
	gnbd-kernel - The kernel module for GFS's Network Block Device

New package gulm
	gulm - One possible lock manager for GFS

New package iddev
	iddev is a library that identifies device contents.

New package lvm2-cluster
	Cluster extenstions for userland logical volume management tools

New package magma
	A cluster/lock manager API abstraction library

New package magma-plugins
	Cluster manager plugins for magma

New package rgmanager
	Open Source HA Resource Group Failover for Red Hat Enterprise Linux


 
Updated Packages:

MAKEDEV-3.16-3
--------------
* Tue Dec 21 2004 Nalin Dahyabhai <nalin at redhat.com> 3.16-3
- raise number of loop devices from 16 to 256 (Kenneth Lee)
- create 'vmware' alias for vnet,vmnet,vmmon devices
- change vmnet->vnet to vmnet0->vnet0, so that it isn't left dangling

dialog-1.0.20041219-1
---------------------
* Tue Dec 21 2004 Harald Hoyer <harald at redhat.com> 1.0-20041219-1
- new version 1.0-20041219

glib2-2.6.0-1
-------------
* Tue Dec 21 2004 Matthias Clasen <mclasen at redhat.com> - 2.6.0-1
- Upgrade to 2.6.0

glibc-2.3.4-3
-------------
* Tue Dec 21 2004 Jakub Jelinek <jakub at redhat.com> 2.3.4-3
- rebuilt

* Mon Dec 20 2004 Jakub Jelinek <jakub at redhat.com> 2.3.4-2
- work around rpm bug some more, this time by copying
  iconvconfig to iconvconfig.%{_target_cpu}.

* Mon Dec 20 2004 Jakub Jelinek <jakub at redhat.com> 2.3.4-1
- update from CVS
  - glibc 2.3.4 release
  - add -o and --nostdlib options to iconvconfig
- if /sbin/ldconfig doesn't exist when running
  glibc_post_upgrade.%{_target_cpu}, just don't attempt to run it.
  This can happen during first install of bi-arch glibc and the
  other arch glibc's %post wil run /sbin/ldconfig (#143326)
- use -o and --nostdlib options to create all needed
  gconv-modules.cache files on bi-arch setups

grep-2.5.1-44
-------------
* Tue Dec 21 2004 Tim Waugh <twaugh at redhat.com> 2.5.1-44
- Fixed -Fi for multibyte input (bug #143079).

gtk2-2.6.0-1
------------

gtk2-engines-2.2.0-7
--------------------
* Tue Dec 21 2004 Matthias Clasen <mclasen at redhat.com> 2.2.0-6
- remove pixbuf engine which is integrated in gtk+ 2.6

kernel-2.6.9-1.1048_FC4
-----------------------
* Tue Dec 21 2004 Dave Jones <davej at redhat.com>
- Fix two silly bugs in the AGP posting fixes.

kernel-utils-1:2.4-13.1.49
--------------------------
* Tue Dec 21 2004 Dave Jones <davej at redhat.com>
- Fix missing delimiter token in microcode_ctl initscript. (143372)

* Sun Nov 28 2004 Dave Jones <davej at redhat.com>
- More SMP cpuspeed work. (#134398)
- Don't enable smartd by default. (#114669)
- Update irqbalance to 1.12 (#130625)
- Don't use binaries from /usr too early. (#102049)
- Fix bogus "" in microcode_ctl initscript. (#112014)
- Don't start microcode_ctl on 586's (#112088)

* Sat Oct 30 2004 Dave Jones <davej at redhat.com>
- Install irqbalance manpage. (#90023)

lapack-3.0-28
-------------
* Tue Dec 21 2004 Ivana Varekova <varekova at redhat.com>
- fix bug #143420 problem with compiler optimalizations

lm_sensors-2.8.8-1
------------------
* Tue Dec 21 2004 Phil Knirsch <pknirsch at redhat.com> 2.8.7-3
- Added Buildprereq for bison (#138888)
- Update to lm_sensors-2.8.8

mc-1:4.6.1a-0.3
---------------
* Tue Dec 21 2004 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.3
- rewrote mbstrlen() in utf8 patch, this fixes:
  - dir name truncation in command prompt for ja_JP, ko_KR locales (#142706)
  - localized texts will fit dialog windows and pull-down menus - tweak create_menu()
  - dialog titles are centered correctly
- fix bad displaying of mc logo in help (#143415)
- merge msglen patch with utf8 patch

mktemp-2:1.5-22
---------------
* Tue Dec 21 2004 Than Ngo <than at redhat.com> 2:1.5-22
- fix permission issue

mysql-4.1.7-8
-------------
* Tue Dec 21 2004 Tom Lane <tgl at redhat.com> 4.1.7-8
- Run make test on all archs except s390x (which seems to have a bdb issue)

* Mon Dec 13 2004 Tom Lane <tgl at redhat.com> 4.1.7-7
- Suppress someone's silly idea that libtool overhead can be skipped

* Sun Dec 12 2004 Tom Lane <tgl at redhat.com> 4.1.7-6
- Fix init script to not need a valid username for startup check (bz#142328)
- Fix init script to honor settings appearing in /etc/my.cnf (bz#76051)
- Enable SSL (bz#142032)

pango-1.8.0-1
-------------
* Tue Dec 21 2004 Matthias Clasen <mclasen at redhat.com> - 1.8.0-1
- Version 1.8.0
- Drop unneeded patches and hacks

pcmcia-cs-3.2.7-4.1
-------------------
* Tue Dec 21 2004 Bill Nottingham <notting at redhat.com>
- fix broken close-on-exec patch (#135508)

rpmdb-fedora-1:4-0.20041222
---------------------------

selinux-policy-strict-1.19.15-1
-------------------------------
* Mon Dec 20 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-1
- Update to latest from NSA

selinux-policy-targeted-1.19.15-1
---------------------------------
* Tue Dec 21 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-1
- Update to latest from NSA

tmpwatch-2.9.2-1
----------------
* Wed Dec 22 2004 Miloslav Trmac <mitr at redhat.com> - 2.9.2-1
- Mention skipping of lost+found in the man page (#143526)

udev-048-4
----------
* Tue Dec 21 2004 Dan Walsh <dwalsh at redhat.com> - 048-4
- Call selinux_restore to fix labeling problem in selinux
- Fixes rh#142817

* Tue Dec 21 2004 Harald Hoyer <harald at redhat.com> - 048-3
- maybe fixed bug rh#143367



From mk at crc.dk  Wed Dec 22 12:56:22 2004
From: mk at crc.dk (Mogens Kjaer)
Date: Wed, 22 Dec 2004 13:56:22 +0100
Subject: ia32e, er EM64T that is...
In-Reply-To: <1103709031.4131.11.camel@laptopd505.fenrus.org>
References: <200409061011.52742.jkeating@j2solutions.net>	<20040906174717.GA11888@devserv.devel.redhat.com>	<41C920F8.7020601@crc.dk>
	<1103709031.4131.11.camel@laptopd505.fenrus.org>
Message-ID: <41C96EF6.50808@crc.dk>

Arjan van de Ven wrote:
> On Wed, 2004-12-22 at 08:23 +0100, Mogens Kjaer wrote:
...
>>The funny thing is, if I write mem=4096M, it still
>>boots, but only 3G memory is available.
> 
> 
> 
> this is a known issue and I think is fixed now; not sure if the kernel
> with the fix has gone out of testing yet.
> 

Thanks, with
kernel-smp-2.6.9-1.1047_FC4.x86_64.rpm
I get 4G of RAM.

However, now the (reinstalled) nvidia driver
won't work - but I guess this is not your
problem :-)

The nvidia module loads (with a warning about
increasing swiotlb), but it fails with
rm_init_adapter failed. I tried setting
swiotlb to 16384 or 32768, but it didn't help.

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk at crc.dk Homepage: http://www.crc.dk



From jwboyer at jdub.homelinux.org  Wed Dec 22 13:05:44 2004
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Wed, 22 Dec 2004 07:05:44 -0600
Subject: CVS kernel compile
In-Reply-To: <20041222070134.GB28113@redhat.com>
References: <1103594563.6919.2.camel@jdub.homelinux.org>
	<20041222070134.GB28113@redhat.com>
Message-ID: <1103720744.8764.10.camel@jdub.homelinux.org>

On Wed, 2004-12-22 at 02:01 -0500, Dave Jones wrote:
> On Mon, Dec 20, 2004 at 08:02:43PM -0600, Josh Boyer wrote:
>  > 
>  > make: *** No rule to make target `download', needed by `sources'.  Stop.
>  > 
>  > I can't find the download target anywhere.  Am I the only one to see
> 
> Its defined in common/Makefile.common.  Do you have the common dir checked out too?

Yes, I do.  And I think the fact that it's _not_ defined in
Makefile.common is the problem.  But since I have no idea what that
target is supposed to do, I can't fix it :).  At least in my cursory
glance I couldn't find a download target or figure out what it does.

Below is the output from running a 'make sources' done in the devel dir,
on a fresh checkout of the kernel from this morning.  Colin saw the same
problem I think, so it's not just me.

thx,
josh


[jwboyer at yoda devel]$ make sources
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 34.5M  100 34.5M    0     0   148k      0  0:03:59  0:03:59 --:--:--  129k
-rw-rw-r--  1 jwboyer jwboyer 36261440 Oct 18 17:54 linux-2.6.9.tar.bz2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  101k  100  101k    0     0  39333      0  0:00:02  0:00:02 --:--:-- 52412
-rw-rw-r--  1 jwboyer jwboyer 104066 Nov 22 17:18 patch-2.6.9-ac11.bz2
cp config-generic temp-generic
if echo  | grep -q -e "^dist-[^-]*E\($\|-\)"; then perl merge.pl config-rhel-generic config-generic > temp-generic ; fi
perl merge.pl config-x86-generic temp-generic  > temp-x86-generic
perl merge.pl config-i686 temp-x86-generic i386 > kernel-2.6.9-i686.config
perl merge.pl config-i686-smp temp-x86-generic i386 > kernel-2.6.9-i686-smp.config
perl merge.pl config-i686-bigmem temp-x86-generic i386 > kernel-2.6.9-i686-hugemem.config
perl merge.pl config-i586 temp-x86-generic i386 > kernel-2.6.9-i586.config
perl merge.pl config-i586-smp temp-x86-generic i386 > kernel-2.6.9-i586-smp.config
perl merge.pl config-x86_64-generic temp-generic  > temp-x86_64-generic
perl merge.pl config-x86_64 temp-x86_64-generic x86_64 > kernel-2.6.9-x86_64.config
perl merge.pl config-x86_64-smp temp-x86_64-generic x86_64 > kernel-2.6.9-x86_64-smp.config
perl merge.pl config-ppc64-generic temp-generic  > temp-ppc64-generic
perl merge.pl config-ppc64-iseries temp-ppc64-generic ppc64 > kernel-2.6.9-ppc64iseries.config
perl merge.pl config-s390-generic temp-generic > temp-s390-generic
perl merge.pl config-s390 temp-s390-generic s390 > kernel-2.6.9-s390.config
perl merge.pl config-s390x temp-s390-generic s390 > kernel-2.6.9-s390x.config
perl merge.pl config-ppc-generic temp-generic > temp-ppc-generic
perl merge.pl config-ppc-pmac temp-ppc-generic ppc > kernel-2.6.9-ppc.config
perl merge.pl config-ppc64 temp-ppc64-generic ppc64 > kernel-2.6.9-ppc64.config
perl merge.pl config-ia64-generic temp-generic > temp-ia64-generic
perl merge.pl config-ia64 temp-ia64-generic ia64 > kernel-2.6.9-ia64.config
perl merge.pl temp-x86-generic temp-generic > temp-x86-xen-generic
perl merge.pl config-xen-generic temp-x86-xen-generic > temp-xen-generic
perl merge.pl config-xen-xen0 temp-xen-generic xen > kernel-2.6.9-i686-xen0.config
perl merge.pl config-xen-xenU temp-xen-generic xen > kernel-2.6.9-i686-xenU.config
make: *** No rule to make target `download', needed by `sources'.  Stop.



From ndbecker2 at verizon.net  Wed Dec 22 13:20:55 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Wed, 22 Dec 2004 08:20:55 -0500
Subject: rawhide report: 20041222 changes
References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com>
Message-ID: <cqbsbn$g7c$1@sea.gmane.org>

Build System wrote:

> New package GFS
> GFS - The Global File System
> 

Yummy!  I wonder if this stuff would work on an otherwise up-to-date FC3?



From toshio at tiki-lounge.com  Wed Dec 22 13:29:17 2004
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 22 Dec 2004 05:29:17 -0800
Subject: %ghost .pyo
In-Reply-To: <200412220833.14523.symbiont@berlios.de>;
	from symbiont@berlios.de on Wed, Dec 22, 2004 at 08:33:14AM +0800
References: <200412220032.25687.symbiont@berlios.de>
	<200412220052.31050.symbiont@berlios.de>
	<20041221134548.B18135@tiki-lounge.com>
	<200412220833.14523.symbiont@berlios.de>
Message-ID: <20041222052917.A7913@tiki-lounge.com>

On Wed, Dec 22, 2004 at 08:33:14AM +0800, Jeff Pitman wrote:
> On Wednesday 22 December 2004 05:45, Toshio Kuratomi wrote:
> > Additionally, aren't python optimized files a non-default
> > setting? ?
> 
> They don't need to exist for proper python operation.
> 
> > So someone had to set root on the tripwire enabled boxes to 
> > create these files in the first place?
> 
> Probably. So, it has to be explicitly setup now. Any SELinux 
> implications?
> 
Seems like SELinux should be the same as a read-only root.  Python app
tries to write to /usr directory protected by SELinux.  It's denied.
Application continues on its way.

> Do note that the base python package does distribute pyo, it's the 
> modules and apps that %ghost them in the fedora.us template.  (Unless 
> the python package has been changed in Rawhide...)
> 
Yep.  And that's 17 MB I have to reclaim manually on my laptop.

-Toshio



From alan at redhat.com  Wed Dec 22 13:37:09 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 22 Dec 2004 08:37:09 -0500
Subject: ia32e, er EM64T that is...
In-Reply-To: <41C920F8.7020601@crc.dk>
References: <200409061011.52742.jkeating@j2solutions.net>
	<20040906174717.GA11888@devserv.devel.redhat.com>
	<41C920F8.7020601@crc.dk>
Message-ID: <20041222133709.GA26965@devserv.devel.redhat.com>

On Wed, Dec 22, 2004 at 08:23:36AM +0100, Mogens Kjaer wrote:
> FC3-32bit installs without problems, 4G available.
> FC3 x86-64 doesn't install, no disks are found.

SATA ? If so you are hitting a known limit/bug in the older SATA code that
Jeff has now fixed up.

> The funny thing is, if I write mem=4096M, it still
> boots, but only 3G memory is available.

Typically the extra memory is mapped higher than 4Gb and a 512Mb-1Gb hole
is left for the PCI devices.



From alan at redhat.com  Wed Dec 22 13:42:30 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 22 Dec 2004 08:42:30 -0500
Subject: ia32e, er EM64T that is...
In-Reply-To: <41C96EF6.50808@crc.dk>
References: <200409061011.52742.jkeating@j2solutions.net>
	<20040906174717.GA11888@devserv.devel.redhat.com>
	<41C920F8.7020601@crc.dk>
	<1103709031.4131.11.camel@laptopd505.fenrus.org>
	<41C96EF6.50808@crc.dk>
Message-ID: <20041222134230.GB26965@devserv.devel.redhat.com>

On Wed, Dec 22, 2004 at 01:56:22PM +0100, Mogens Kjaer wrote:
> The nvidia module loads (with a warning about
> increasing swiotlb), but it fails with
> rm_init_adapter failed. I tried setting
> swiotlb to 16384 or 32768, but it didn't help.

Correct. The Nvidia driver wants huge amounts of I/O memory space below 32bit.
Various other drivers have similar issues due to the lack of an IOMMU. There
has been some discussion and proposals on the kernel list about ways to handle
this better but that is certainly not likely to occur until after 2.6.10



From cmadams at hiwaay.net  Wed Dec 22 14:58:25 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 22 Dec 2004 08:58:25 -0600
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <20041222033027.GY20813@neu.nirvana>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
Message-ID: <20041222145825.GA1324747@hiwaay.net>

Once upon a time, Axel Thimm <Axel.Thimm at ATrpms.net> said:
> Indeed, I always wondered why the certificates had been put under
> /usr/share/ssl and by whom. The FHS had been quite strict on this from
> the very beginning.
> 
> /etc seems a rather sane place. Perhaps /etc/ssl/?

You'll need to modify OpenSSL to handle multiple "default" directories.
Currently I think you can only specify a single directory for certs (the
certs setting under the CA_default section in openssl.cnf).
Applications use OpenSSL calls to validate the cert chain, so it'll need
to look in the local directory (/etc/ssl/certs) first and then the other
directory (/usr/share/ssl/certs) when walking the cert chain.  The crl
directory should be similar (so you can add local revocations).

What may be a good idea is to have "well known" names for services, like
/etc/ssl/certs/imap, /etc/ssl/certs/smtp, etc.  Then you could configure
sendmail for example to use /etc/ssl/certs/smtp.  The admin can choose
which cert to use for SSL by symlinking /etc/ssl/certs/smtp to
/etc/ssl/certs/mycert.pem (without having to reconfigure sendmail).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From lfarkas at bppiac.hu  Wed Dec 22 15:11:23 2004
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Wed, 22 Dec 2004 16:11:23 +0100
Subject: SSL cert/key location
In-Reply-To: <20041222145825.GA1324747@hiwaay.net>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>	<1103503652.5917.1.camel@localhost.localdomain>	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>	<20041222033027.GY20813@neu.nirvana>
	<20041222145825.GA1324747@hiwaay.net>
Message-ID: <41C98E9B.6050504@bppiac.hu>

Chris Adams wrote:
> Once upon a time, Axel Thimm <Axel.Thimm at ATrpms.net> said:
> 
>>Indeed, I always wondered why the certificates had been put under
>>/usr/share/ssl and by whom. The FHS had been quite strict on this from
>>the very beginning.
>>
>>/etc seems a rather sane place. Perhaps /etc/ssl/?
> 
> 
> You'll need to modify OpenSSL to handle multiple "default" directories.
> Currently I think you can only specify a single directory for certs (the
> certs setting under the CA_default section in openssl.cnf).
> Applications use OpenSSL calls to validate the cert chain, so it'll need
> to look in the local directory (/etc/ssl/certs) first and then the other
> directory (/usr/share/ssl/certs) when walking the cert chain.  The crl

why we need /usr/share/ssl/ at all? /etc/ssl would be enough (as one 
directory)!

-- 
   Levente                               "Si vis pacem para bellum!"



From skvidal at phy.duke.edu  Wed Dec 22 15:13:18 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 22 Dec 2004 10:13:18 -0500
Subject: SSL cert/key location
In-Reply-To: <41C98E9B.6050504@bppiac.hu>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
	<20041222145825.GA1324747@hiwaay.net> <41C98E9B.6050504@bppiac.hu>
Message-ID: <1103728398.1007.0.camel@opus.phy.duke.edu>

On Wed, 2004-12-22 at 16:11 +0100, Farkas Levente wrote:
> Chris Adams wrote:
> > Once upon a time, Axel Thimm <Axel.Thimm at ATrpms.net> said:
> > 
> >>Indeed, I always wondered why the certificates had been put under
> >>/usr/share/ssl and by whom. The FHS had been quite strict on this from
> >>the very beginning.
> >>
> >>/etc seems a rather sane place. Perhaps /etc/ssl/?
> > 
> > 
> > You'll need to modify OpenSSL to handle multiple "default" directories.
> > Currently I think you can only specify a single directory for certs (the
> > certs setting under the CA_default section in openssl.cnf).
> > Applications use OpenSSL calls to validate the cert chain, so it'll need
> > to look in the local directory (/etc/ssl/certs) first and then the other
> > directory (/usr/share/ssl/certs) when walking the cert chain.  The crl
> 
> why we need /usr/share/ssl/ at all? /etc/ssl would be enough (as one 
> directory)!
> 

And /etc/ssl would be FHS Compliant b/c the certs look a lot like a
configuration/data file. At the very least the certs should be in /var
but definitely not /usr

-sv




From hp at redhat.com  Wed Dec 22 15:19:46 2004
From: hp at redhat.com (Havoc Pennington)
Date: Wed, 22 Dec 2004 10:19:46 -0500
Subject: gconftool-2 failing in rpm scriptlets?
In-Reply-To: <20041221153251.2c7ecd5a.fedora@wir-sind-cool.org>
References: <20041221153251.2c7ecd5a.fedora@wir-sind-cool.org>
Message-ID: <1103728786.581.120.camel@localhost.localdomain>

On Tue, 2004-12-21 at 15:32 +0100, Michael Schwendt wrote:
> Under which circumstances might a GConf2 post-install scriptlet like
> this fail to create application's default settings unreproducibly?
> 
> export GCONF_CONFIG_SOURCE="$(gconftool-2 --get-default-source)"
> gconftool-2 --makefile-install-rule /etc/gconf/schemas/celestia.schemas &>/dev/null || :
> 
> If after package installation, the application's GConf2 defaults
> cannot be found in /etc/gconf/gconf.xml.defaults/, is that an
> indication that the post-install scriptlet was not executed at all
> (and e.g. Yum could be involved) or that only GConf2 failed somehow?
> 
> Theories, anyone?
> 

I don't have theories but AFAIK there are not known issues with
gconftool in %post

Havoc




From symbiont at berlios.de  Wed Dec 22 15:48:29 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 22 Dec 2004 23:48:29 +0800
Subject: %ghost .pyo
In-Reply-To: <20041222052917.A7913@tiki-lounge.com>
References: <200412220032.25687.symbiont@berlios.de>
	<200412220833.14523.symbiont@berlios.de>
	<20041222052917.A7913@tiki-lounge.com>
Message-ID: <200412222348.29752.symbiont@berlios.de>

On Wednesday 22 December 2004 21:29, Toshio Kuratomi wrote:
> > Do note that the base python package does distribute pyo, it's the
> > modules and apps that %ghost them in the fedora.us template.
> > ?(Unless the python package has been changed in Rawhide...)
>
> Yep. ?And that's 17 MB I have to reclaim manually on my laptop.

Fun. Is it worth it? Technically, you can also manually reclaim all the 
*.py files from your disk and still operate. You'd save roughly 2 times 
the amount of pyo reclamation.  Do you do that too?

-- 
-jeff



From dpaun at rogers.com  Wed Dec 22 16:22:52 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Wed, 22 Dec 2004 11:22:52 -0500
Subject: svn or arch
In-Reply-To: <1103713964.25633.4.camel@ulysse.olympe.o2t>
References: <20041217213044.12517.qmail@web8502.mail.in.yahoo.com>
	<200412172355.17027.dries@ulyssis.org>
	<1103327594.12552.155.camel@nexus.verbum.private>
	<Pine.LNX.4.61.0412171818290.14188@asterix>
	<1103330023.1186.3.camel@nexus.verbum.private>
	<1103713964.25633.4.camel@ulysse.olympe.o2t>
Message-ID: <20041222162252.GA1672@rogers.com>

On Wed, Dec 22, 2004 at 12:12:44PM +0100, Nicolas Mailhot wrote:
> Please don't.
> I can happily work with a few cds on SRPMS.

No worries, we're just talking about a better system to *manage*
and *create* SRPMs, not replace them. Users of *.rpm packages
will see no change.

-- 
Dimi.



From toshio at tiki-lounge.com  Wed Dec 22 16:29:49 2004
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 22 Dec 2004 08:29:49 -0800
Subject: %ghost .pyo
In-Reply-To: <200412222348.29752.symbiont@berlios.de>;
	from symbiont@berlios.de on Wed, Dec 22, 2004 at 11:48:29PM +0800
References: <200412220032.25687.symbiont@berlios.de>
	<200412220833.14523.symbiont@berlios.de>
	<20041222052917.A7913@tiki-lounge.com>
	<200412222348.29752.symbiont@berlios.de>
Message-ID: <20041222082949.B7913@tiki-lounge.com>

On Wed, Dec 22, 2004 at 11:48:29PM +0800, Jeff Pitman wrote:
> On Wednesday 22 December 2004 21:29, Toshio Kuratomi wrote:
> > > Do note that the base python package does distribute pyo, it's the
> > > modules and apps that %ghost them in the fedora.us template.
> > > ?(Unless the python package has been changed in Rawhide...)
> >
> > Yep. ?And that's 17 MB I have to reclaim manually on my laptop.
> 
> Fun. Is it worth it? Technically, you can also manually reclaim all the 
> *.py files from your disk and still operate. You'd save roughly 2 times 
> the amount of pyo reclamation.  Do you do that too?
> 
Nope. But I have considered deleting the .pyc files when I'm in a crunch.
(I need the space, but I'm also developing in python and sometimes it's
handy to reference python source of the libraries.)  That said, if python
was split so I could uninstall an rpm package that had all the py files, I
might do that.

Like I say, it's not worth it on my desktop.  But on my laptop with limited
HD, there are times when it's necessary to free up a few extra MB to make
things fit.  As you marvelously deadpan, Fun.

-Toshio



From toshio at tiki-lounge.com  Wed Dec 22 16:43:44 2004
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 22 Dec 2004 08:43:44 -0800
Subject: %ghost .pyo
In-Reply-To: <200412221131.29131.symbiont@berlios.de>;
	from symbiont@berlios.de on Wed, Dec 22, 2004 at 11:31:28AM +0800
References: <200412220032.25687.symbiont@berlios.de>
	<20041221184241.GF5001@angus.ind.WPI.EDU>
	<20041222032413.GX20813@neu.nirvana>
	<200412221131.29131.symbiont@berlios.de>
Message-ID: <20041222084344.C7913@tiki-lounge.com>

On Wed, Dec 22, 2004 at 11:31:28AM +0800, Jeff Pitman wrote:
> On Wednesday 22 December 2004 11:24, Axel Thimm wrote:
> > On Tue, Dec 21, 2004 at 01:42:41PM -0500, Charles R. Anderson wrote:
> > > On Wed, Dec 22, 2004 at 12:52:30AM +0800, Jeff Pitman wrote:
> > > > issue, I'm wondering out loud if we should even care about
> > > > %ghost.
> > >
> > > I've heard that %ghost was on its deathbed anyway.
> >
> > Don't you need %ghost for logfiles?
> 
> Yep. %ghost is great for /var, but it seems /usr would have issues.  Is 
> it even FHS-compliant to have a program write files in /usr during 
> program execution?  If there is a compliancy issue and setup 
> complications in Tripwire or SELinux, then it seems packaging pyo is 
> the way to go.
> 
I'll have to reread the FHS to see about the letter of the FHS, but the
spirit is to enable /usr to be mounted read-only.  As python transparently
tries to create these files and has no problems if that fails, I don't see
it as violating the FHS.

I think Tripwire is the only piece that's really hurt here because
it's taking a hash of the actual file contents.  It's probably wrong to do
what rpm does and specify not to check a hash for pyo files as that would
lead to the possibility of executing pyo files placed there maliciously.
If you have set up root to do something nonstandard like running python in
optimized byte comilation mode is the onus also on you to create the pyos
so you can create tripwire hashes?  (Or set /usr ro or [untested] an SELinux
context to keep pyo's from being written?)

-Toshio



From pekkas at netcore.fi  Wed Dec 22 17:03:12 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 22 Dec 2004 19:03:12 +0200 (EET)
Subject: SSL cert/key location
In-Reply-To: <41C98E9B.6050504@bppiac.hu>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
	<20041222145825.GA1324747@hiwaay.net> <41C98E9B.6050504@bppiac.hu>
Message-ID: <Pine.LNX.4.61.0412221901530.1314@netcore.fi>

On Wed, 22 Dec 2004, Farkas Levente wrote:
>>> Indeed, I always wondered why the certificates had been put under
>>> /usr/share/ssl and by whom. The FHS had been quite strict on this from
>>> the very beginning.
>>> 
>>> /etc seems a rather sane place. Perhaps /etc/ssl/?
>> 
>> 
>> You'll need to modify OpenSSL to handle multiple "default" directories.
>> Currently I think you can only specify a single directory for certs (the
>> certs setting under the CA_default section in openssl.cnf).
>> Applications use OpenSSL calls to validate the cert chain, so it'll need
>> to look in the local directory (/etc/ssl/certs) first and then the other
>> directory (/usr/share/ssl/certs) when walking the cert chain.  The crl
>
> why we need /usr/share/ssl/ at all? /etc/ssl would be enough (as one 
> directory)!

Because it may not be able to change all the apps and libraries at 
once which put stuff or expect to find stuff in /usr/share/ssl ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From symbiont at berlios.de  Wed Dec 22 17:21:14 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Thu, 23 Dec 2004 01:21:14 +0800
Subject: %ghost .pyo
In-Reply-To: <20041222084344.C7913@tiki-lounge.com>
References: <200412220032.25687.symbiont@berlios.de>
	<200412221131.29131.symbiont@berlios.de>
	<20041222084344.C7913@tiki-lounge.com>
Message-ID: <200412230121.14395.symbiont@berlios.de>

On Thursday 23 December 2004 00:43, Toshio Kuratomi wrote:
> If you have set up root to do something nonstandard like running
> python in optimized byte comilation mode is the onus also on you to
> create the pyos so you can create tripwire hashes? ?(Or set /usr ro
> or [untested] an SELinux context to keep pyo's from being written?)

rpmlint comes to mind as "something nonstandard".  If you so happen to 
run it has root, of course.  To truly be FHS-compliant, yes, the burden 
is on an integrator or user to keep Python from writing to /usr.  From 
FHS v2.3:
"""
/usr is the second major section of the filesystem. /usr is shareable, 
read-only data. That means that /usr should be shareable between 
various FHS-compliant hosts and must not be written to. Any information 
that is host-specific or varies with time is stored elsewhere.
"""

Technically pyo, when auto-generated by Python during execution, should 
be written under /var.  One could then create a system to allow 
user-executed pythons to generate pyo for each other based on group 
permissions.  This would be especially cool if pyo actually provided a 
significant optimization besides a minor startup boost.

Since Python is cross-platform, moving things around like that would be 
too platform specific and most likely rejected.  Interestingly enough a 
related RFE was filed a few years back:
http://sourceforge.net/tracker/index.php?func=detail&aid=588756&group_id=5470&atid=355470

So, to %ghost or not to %ghost, that is the question! 

-- 
-jeff



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 18:12:57 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 19:12:57 +0100
Subject: %ghost .pyo
In-Reply-To: <200412230121.14395.symbiont@berlios.de> (Jeff Pitman's message
	of "Thu, 23 Dec 2004 01:21:14 +0800")
References: <200412220032.25687.symbiont@berlios.de>
	<200412221131.29131.symbiont@berlios.de>
	<20041222084344.C7913@tiki-lounge.com>
	<200412230121.14395.symbiont@berlios.de>
Message-ID: <87k6raxkuu.fsf@kosh.ultra.csn.tu-chemnitz.de>

symbiont at berlios.de (Jeff Pitman) writes:

> This would be especially cool if pyo actually provided a significant
> optimization besides a minor startup boost.

.pyo resp. 'python -O' does not execute statements which depend on
'__debug__'. This includes e.g. every 'assert()' so you can see speedup
on programs using such code.



Enrico



From florin at andrei.myip.org  Wed Dec 22 18:34:59 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 22 Dec 2004 10:34:59 -0800
Subject: CD burner that Just Works
Message-ID: <1103740499.3558.7.camel@stantz.corp.sgi.com>

Well, K3B is nice and all, but it's a KDE application. While there's
nothing wrong with KDE per se, if you're using Gnome there's a
noticeable delay before starting any KDE application, while all those
components get initialized and so on. Plus, while most applications work
flawlessly in their native environment, there are all kinds of strange
bugs that get uncovered when using them in other environments (this goes
for both KDE and Gnome apps).
In fact, K3B is the only KDE application that must be used on a Gnome
desktop currently. All other basic tasks can be accomplished by native
applications (or by apps that are merely GTK-based, not full Gnome apps,
which is fine).

So... how about including Graveman in Fedora?

http://scresto.site.voila.fr/gravemanuk.html

- It Just Works.
- It has a no-nonsense interface that, to me at least, seems much better
than any other CD burner for Linux. In fact, i think this is The CD-
Burner GUI Metaphor that everyone should look at and learn from. Really.
Any "dummy user" could use it, while it does not step on advanced users'
toes.
- It's GTK-based.

Please?

-- 
Florin Andrei

http://florin.myip.org/



From rdieter at math.unl.edu  Wed Dec 22 18:39:28 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Dec 2004 12:39:28 -0600
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <41C9BF60.2090302@math.unl.edu>

Florin Andrei wrote:

> So... how about including Graveman in Fedora?
> http://scresto.site.voila.fr/gravemanuk.html

And the standard (IMO) response to "Please include app X in Fedora"

I'd suggest submission to Fedora-Extras first.


-- Rex



From rbultje at ronald.bitfreak.net  Wed Dec 22 18:40:15 2004
From: rbultje at ronald.bitfreak.net (Ronald S. Bultje)
Date: Wed, 22 Dec 2004 19:40:15 +0100
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <1103740814.2813.72.camel@tux.lan>

On Wed, 2004-12-22 at 19:34, Florin Andrei wrote:
> - It has a no-nonsense interface that, to me at least, seems much better
> than any other CD burner for Linux. In fact, i think this is The CD-
> Burner GUI Metaphor that everyone should look at and learn from. Really.
> Any "dummy user" could use it, while it does not step on advanced users'
> toes.

The buttons are larger than a New York Pizza! ... How about a toolbar?

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>



From florin at andrei.myip.org  Wed Dec 22 18:44:36 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 22 Dec 2004 10:44:36 -0800
Subject: CD burner that Just Works
In-Reply-To: <1103740814.2813.72.camel@tux.lan>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<1103740814.2813.72.camel@tux.lan>
Message-ID: <1103741076.3558.18.camel@stantz.corp.sgi.com>

On Wed, 2004-12-22 at 19:40 +0100, Ronald S. Bultje wrote:
> On Wed, 2004-12-22 at 19:34, Florin Andrei wrote:
> > - It has a no-nonsense interface that, to me at least, seems much better
> > than any other CD burner for Linux. In fact, i think this is The CD-
> > Burner GUI Metaphor that everyone should look at and learn from. Really.
> > Any "dummy user" could use it, while it does not step on advanced users'
> > toes.
> 
> The buttons are larger than a New York Pizza! ... How about a toolbar?

Large buttons are good when the options are few and the app is uncommon
(not like a browser that everyone is familiar with).

Actually, i just sent an email to Sylvain suggesting an improvement -
change the messages on the buttons to make them more consistent with
each other:

- Create Audio CD
- Create Data CD
- Duplicate Audio or Data CD

-- 
Florin Andrei

http://florin.myip.org/



From rahulsundaram at yahoo.co.in  Wed Dec 22 18:49:30 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 22 Dec 2004 10:49:30 -0800 (PST)
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <20041222184930.80245.qmail@web8508.mail.in.yahoo.com>

Hi


> 
> So... how about including Graveman in Fedora?
> 
> http://scresto.site.voila.fr/gravemanuk.html
> 
> - It Just Works.
> - It has a no-nonsense interface that, to me at
> least, seems much better
> than any other CD burner for Linux. In fact, i think
> this is The CD-
> Burner GUI Metaphor that everyone should look at and
> learn from. Really.
> Any "dummy user" could use it, while it does not
> step on advanced users'
> toes.
> - It's GTK-based.
> 
> Please?


suggestions

* Announce this in Footnotes
* Try moving this into fedora-extras. 
* If you gain popularity you can then propose it for
inclusion in fedora core.


=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250



From enrico.scholz at informatik.tu-chemnitz.de  Wed Dec 22 20:04:04 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Dec 2004 21:04:04 +0100
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com> (Florin Andrei's
	message of "Wed, 22 Dec 2004 10:34:59 -0800")
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <87fz1yxfpn.fsf@kosh.ultra.csn.tu-chemnitz.de>

florin at andrei.myip.org (Florin Andrei) writes:

> Well, K3B is nice and all, but it's a KDE application. While there's
> nothing wrong with KDE per se, if you're using Gnome there's a noticeable
> delay before starting any KDE application, while all those components get
> initialized and so on.

What's wrong with xcdroast? Works both in Gnome and KDE without noticable
startup-delay and is shipped in Fedora Core.



Enrico



From toshio at tiki-lounge.com  Wed Dec 22 19:59:52 2004
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 22 Dec 2004 11:59:52 -0800
Subject: %ghost .pyo
In-Reply-To: <200412230121.14395.symbiont@berlios.de>;
	from symbiont@berlios.de on Thu, Dec 23, 2004 at 01:21:14AM +0800
References: <200412220032.25687.symbiont@berlios.de>
	<200412221131.29131.symbiont@berlios.de>
	<20041222084344.C7913@tiki-lounge.com>
	<200412230121.14395.symbiont@berlios.de>
Message-ID: <20041222115952.D7913@tiki-lounge.com>

On Thu, Dec 23, 2004 at 01:21:14AM +0800, Jeff Pitman wrote:
> On Thursday 23 December 2004 00:43, Toshio Kuratomi wrote:
> > If you have set up root to do something nonstandard like running
> > python in optimized byte comilation mode is the onus also on you to
> > create the pyos so you can create tripwire hashes? ?(Or set /usr ro
> > or [untested] an SELinux context to keep pyo's from being written?)
> 
> rpmlint comes to mind as "something nonstandard".  If you so happen to 
> run it has root, of course.  To truly be FHS-compliant, yes, the burden 
> is on an integrator or user to keep Python from writing to /usr.  From 
> FHS v2.3:

The non-standard was setting root to create optimized byte compiled files.  If
root isn't configured to do that, python won't attempt to create optimized
byte compiled files.

> """
> /usr is the second major section of the filesystem. /usr is shareable, 
> read-only data. That means that /usr should be shareable between 
> various FHS-compliant hosts and must not be written to. Any information 
> that is host-specific or varies with time is stored elsewhere.
> """
> 
So the letter specifies that python should not write to /usr.  OTOH, the
reason given is so /usr can be shared, read-only data.  Since python
doesn't care if it writes the byte compiled files (and will run fine if it
doesn't create them), I claim it's not a violation of the spirit of the FHS.

> Technically pyo, when auto-generated by Python during execution, should 
> be written under /var.  One could then create a system to allow 
> user-executed pythons to generate pyo for each other based on group 
> permissions.  This would be especially cool if pyo actually provided a 
> significant optimization besides a minor startup boost.
> 
Conceptually, pyc/pyo files aren't /var fodder.  Maybe they belong in /srv.
(They aren't cache files like /var/man/catman... they're on the fly compiled
executables/libraries.)

I can foresee potential security issues with pyo's generated from
user-python instances being shared with other people on the system.  These
aren't just data files, they're exectuable content.  This might be
solvable but it has a lot of implications.

> Since Python is cross-platform, moving things around like that would be 
> too platform specific and most likely rejected.  Interestingly enough a 
> related RFE was filed a few years back:
> http://sourceforge.net/tracker/index.php?func=detail&aid=588756&group_id=5470&atid=355470
> 
Aye!  There's the rub!

> So, to %ghost or not to %ghost, that is the question! 
>
I favor ghosting.  But I don't run Tripwire....

-Toshio



From sopwith at redhat.com  Wed Dec 22 20:12:58 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Wed, 22 Dec 2004 15:12:58 -0500
Subject: Fedora Project Mailing Lists reminder
Message-ID: <sopwith.2004-12-22.15.12.58.list-reminder@redhat.com>

This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/

When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!

Mailing Lists

Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.

The following mailing lists are available. To subscribe, send email to <listname>-request at redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.

fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-tools-list - For discussions about the toolchain (gcc, gdb,
etc...) within Fedora
fedora-patches-list - For submitting patches to Fedora maintainers, and
used in line with BugWeek
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-marketing-list - For discussions about marketing and expanding
the Fedora user base
fedora-de-list - For discussions about Fedora in the German language
fedora-es-list - For discussions about Fedora in the Spanish language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw



From denisleroy at yahoo.com  Wed Dec 22 20:26:59 2004
From: denisleroy at yahoo.com (Denis Leroy)
Date: Wed, 22 Dec 2004 12:26:59 -0800 (PST)
Subject: CD burner that Just Works
In-Reply-To: <87fz1yxfpn.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <20041222202659.25730.qmail@web60710.mail.yahoo.com>

--- Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> wrote:

> florin at andrei.myip.org (Florin Andrei) writes:
> 
> > Well, K3B is nice and all, but it's a KDE application. While
> there's
> > nothing wrong with KDE per se, if you're using Gnome there's a
> noticeable
> > delay before starting any KDE application, while all those
> components get
> > initialized and so on.
> 
> What's wrong with xcdroast? Works both in Gnome and KDE without
> noticable
> startup-delay and is shipped in Fedora Core.

Don't miss to diss the xcdroast authors, but it really has one of worst
GUIs i've ever seen.

There's also gcdmaster (for audio CDs), but we haven't had time to work
on it in a while....

http://bugzilla.fedora.us/show_bug.cgi?id=1780

-denis



From Axel.Thimm at ATrpms.net  Wed Dec 22 20:30:17 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 22 Dec 2004 21:30:17 +0100
Subject: %ghost .pyo
In-Reply-To: <200412230121.14395.symbiont@berlios.de>
References: <200412220032.25687.symbiont@berlios.de>
	<200412221131.29131.symbiont@berlios.de>
	<20041222084344.C7913@tiki-lounge.com>
	<200412230121.14395.symbiont@berlios.de>
Message-ID: <20041222203017.GH13187@neu.nirvana>

On Thu, Dec 23, 2004 at 01:21:14AM +0800, Jeff Pitman wrote:
> So, to %ghost or not to %ghost, that is the question! 

Don't %ghost them.

If the optimization is worth while it the packager should decide to
create the *.pyo files and have them properly placed into the rpm.

If it isn't worth while they should be created neither at build, nor
at runtime.

So keep this a packager's decision and never %ghost anything besides
/var/log :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041222/61f63946/attachment.sig>

From mr700 at globalnet.bg  Wed Dec 22 21:28:54 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Wed, 22 Dec 2004 23:28:54 +0200
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <200412222328.55252@-mr700>

On 2004-12-22 (Wednesday) 20:34, Florin Andrei wrote:
> Well, K3B is nice and all, but it's a KDE application. While there's
> nothing wrong with KDE per se, if you're using Gnome there's a
> noticeable delay before starting any KDE application, while all those
> components get initialized and so on. Plus, while most applications work
> flawlessly in their native environment, there are all kinds of strange
> bugs that get uncovered when using them in other environments (this goes
> for both KDE and Gnome apps).

    OT: Now you know how the KDE users feel when they have all defaults
to Gnome applications (editors, evolution mail) and up2date icon:) I was
thinking to fill a bug/rfe for this when I have time / and you can add
comments for Gnome or you fill it (please mail me if you do) and I add
comments about KDE :) /.

> In fact, K3B is the only KDE application that must be used on a Gnome
> desktop currently. All other basic tasks can be accomplished by native
> applications (or by apps that are merely GTK-based, not full Gnome apps,
> which is fine).
> 
> So... how about including Graveman in Fedora?
> 
> http://scresto.site.voila.fr/gravemanuk.html
> 
> - It Just Works.
> - It has a no-nonsense interface that, to me at least, seems much better
> than any other CD burner for Linux. In fact, i think this is The CD-
> Burner GUI Metaphor that everyone should look at and learn from. Really.
> Any "dummy user" could use it, while it does not step on advanced users'
> toes.
> - It's GTK-based.
> 
> Please?
> 

--- cut ---
Warning: Please note that this program has not yet been extensively
tested, this is a beta release!
--- cut ---
    Maybe it should be tested in extras first. Looks good...

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From gafton at redhat.com  Wed Dec 22 21:50:06 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Wed, 22 Dec 2004 16:50:06 -0500 (EST)
Subject: CVS bugzillas
In-Reply-To: <1103662157.8764.4.camel@jdub.homelinux.org>
References: <1103662157.8764.4.camel@jdub.homelinux.org>
Message-ID: <Pine.LNX.4.61.0412221649001.30497@alien.devel.redhat.com>

On Tue, 21 Dec 2004, Josh Boyer wrote:

> If there are issues with either the CVS server itself or the contents in
> a package directory (i.e. make doesn't complete, etc), should we file
> bugs against the CVS infrastructure?
>
> If so, there doesn't seem to be a good target.  I could open a bug to
> get a target in bugzilla for this, but I'd like to know if this is
> desired or not.  Or maybe there is (or should be) a fedora-cvs list?  I
> don't mean fedora-cvs-commits either, that's a bit different.

For lack of a better target the folks that can do something about this are 
listening on this list (myself included)

Cristian
-- 
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
     -- Kenneth Brown, President, Alexis de Tocqueville Institution



From pschobel at porchlight.ca  Wed Dec 22 16:54:46 2004
From: pschobel at porchlight.ca (Peter Schobel)
Date: Wed, 22 Dec 2004 16:54:46 +0000
Subject: Fedora Stateless: stateless-snapshooter modified
Message-ID: <1103734486.2359.69.camel@shiva>

what is the status on the stateless-snapshooter mod? does it work yet?

-- 
Peter Schobel
~



From florin at andrei.myip.org  Wed Dec 22 21:54:57 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 22 Dec 2004 13:54:57 -0800
Subject: CD burner that Just Works
In-Reply-To: <20041222202659.25730.qmail@web60710.mail.yahoo.com>
References: <20041222202659.25730.qmail@web60710.mail.yahoo.com>
Message-ID: <1103752497.3558.34.camel@stantz.corp.sgi.com>

On Wed, 2004-12-22 at 12:26 -0800, Denis Leroy wrote:
> --- Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> wrote:

> > What's wrong with xcdroast? Works both in Gnome and KDE without
> > noticable
> > startup-delay and is shipped in Fedora Core.
> 
> Don't miss to diss the xcdroast authors, but it really has one of worst
> GUIs i've ever seen.

Exactly. There was no thought whatsoever given to usability et al. when
that application was written.
Sure, it works fine, after you wrap your mind around all the quircks of
the interface.

-- 
Florin Andrei

http://florin.myip.org/



From pschobel at porchlight.ca  Wed Dec 22 16:58:44 2004
From: pschobel at porchlight.ca (Peter Schobel)
Date: Wed, 22 Dec 2004 16:58:44 +0000
Subject: stateless linux
Message-ID: <1103734724.2359.72.camel@shiva>

I have seen next to nothing on this list recently from stateless linux
developers

What is the status of this project? Is it in active development?

-- 
Peter Schobel
~



From pschobel at porchlight.ca  Wed Dec 22 17:00:20 2004
From: pschobel at porchlight.ca (Peter Schobel)
Date: Wed, 22 Dec 2004 17:00:20 +0000
Subject: stateless linux project status
Message-ID: <1103734820.2359.74.camel@shiva>

I have seen next to nothing on this list recently from stateless linux
developers

What is the status of this project? Is it in active development?

-- 
Peter Schobel
~



From erc.caldera at gmx.net  Wed Dec 22 22:42:22 2004
From: erc.caldera at gmx.net (=?ISO-8859-9?Q?Er=E7in_EKER?=)
Date: Thu, 23 Dec 2004 00:42:22 +0200
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <41C9F84E.7090005@gmx.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Florin Andrei, 22-12-2004 20:34 tarihinde ?unlar? yazd?:

| So... how about including Graveman in Fedora?
|
| http://scresto.site.voila.fr/gravemanuk.html
|
| - It Just Works. - It has a no-nonsense interface that, to me at
| least, seems much better than any other CD burner for Linux. In
| fact, i think this is The CD- Burner GUI Metaphor that everyone
| should look at and learn from. Really. Any "dummy user" could use
| it, while it does not step on advanced users' toes. - It's
| GTK-based.
|
| Please?
|
Coaster looks good, is in development too and didn't used yet.


http://www.coaster-burn.org/

- --
Er?in EKER
UIN: 82166138
Jabber: ercineker at jabber.org



Convention organizer to Linus Torvalds: "You might like to come with us
to some licensed[1] place, and have some pizza."

Linus: "Oh, I did not know that you needed a license to eat pizza".

[1] Licenced - refers in Australia to a restaurant which has government
licence to sell liquor.
~    -- Linus at a talk at the Melbourne University



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFByfhMjUM+8D3W35ERAh5JAJ9Qy/nUsJpUjF9YNkrUZToX0G5N5gCgiIj1
vZRasmUZy4YIF9Wq9bPp67I=
=Wvwr
-----END PGP SIGNATURE-----



From denisleroy at yahoo.com  Wed Dec 22 23:03:39 2004
From: denisleroy at yahoo.com (Denis Leroy)
Date: Wed, 22 Dec 2004 15:03:39 -0800 (PST)
Subject: CD burner that Just Works
In-Reply-To: <41C9F84E.7090005@gmx.net>
Message-ID: <20041222230339.73937.qmail@web60709.mail.yahoo.com>


--- Er?in EKER <erc.caldera at gmx.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Florin Andrei, 22-12-2004 20:34 tarihinde ?unlar? yazd?:
> 
> | So... how about including Graveman in Fedora?
> |
> | http://scresto.site.voila.fr/gravemanuk.html
> |
> | - It Just Works. - It has a no-nonsense interface that, to me at
> | least, seems much better than any other CD burner for Linux. In
> | fact, i think this is The CD- Burner GUI Metaphor that everyone
> | should look at and learn from. Really. Any "dummy user" could use
> | it, while it does not step on advanced users' toes. - It's
> | GTK-based.
> |
> | Please?
> |
> Coaster looks good, is in development too and didn't used yet.
> 
> 
> http://www.coaster-burn.org/

Coaster is a nice project. Unfortunately it has complicated
dependencies. I'm in the process of preparing a bakery package to
submit to Extras, but it also has an agressive dependency to
libnautilus-burn (nautilus-cd-burner) that is two versions ahead of
FC3's...



From florin at andrei.myip.org  Thu Dec 23 00:05:37 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 22 Dec 2004 16:05:37 -0800
Subject: CD burner that Just Works
In-Reply-To: <41C9F84E.7090005@gmx.net>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<41C9F84E.7090005@gmx.net>
Message-ID: <1103760337.3558.41.camel@stantz.corp.sgi.com>

On Thu, 2004-12-23 at 00:42 +0200, Er?in EKER wrote:

> Coaster looks good, is in development too and didn't used yet.

Can it burn audio CDs already? Last time i checked it couldn't.

-- 
Florin Andrei

http://florin.myip.org/



From florin at andrei.myip.org  Thu Dec 23 00:07:28 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 22 Dec 2004 16:07:28 -0800
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <1103760448.3558.44.camel@stantz.corp.sgi.com>

On Wed, 2004-12-22 at 10:34 -0800, Florin Andrei wrote:

> So... how about including Graveman in Fedora?
> 
> http://scresto.site.voila.fr/gravemanuk.html

Ok, i slapped together some quick packages for Fedora 3:

ftp://andrei.myip.org/graveman/

-- 
Florin Andrei

http://florin.myip.org/



From rahulsundaram at yahoo.co.in  Wed Dec 22 23:43:50 2004
From: rahulsundaram at yahoo.co.in (Rahul Sundaram)
Date: Wed, 22 Dec 2004 15:43:50 -0800 (PST)
Subject: CD burner that Just Works
In-Reply-To: <20041222230339.73937.qmail@web60709.mail.yahoo.com>
Message-ID: <20041222234350.65944.qmail@web8503.mail.in.yahoo.com>

Hi


> > http://www.coaster-burn.org/
> 
> Coaster is a nice project. Unfortunately it has
> complicated
> dependencies. 

coaster is removing the bakery dependency. 

http://www.reigndropsfall.net/


the gktmm and other dependencies is already in rawhide.

=====
Regards
Rahul Sundaram


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From hp at redhat.com  Thu Dec 23 00:50:19 2004
From: hp at redhat.com (Havoc Pennington)
Date: Wed, 22 Dec 2004 19:50:19 -0500
Subject: stateless linux project status
In-Reply-To: <1103734820.2359.74.camel@shiva>
References: <1103734820.2359.74.camel@shiva>
Message-ID: <1103763019.11975.6.camel@localhost.localdomain>

On Wed, 2004-12-22 at 17:00 +0000, Peter Schobel wrote:
> I have seen next to nothing on this list recently from stateless linux
> developers
> 
> What is the status of this project? Is it in active development?
> 

It isn't in active development right now; the initial release was a
prototype to gather data on what people thought of the idea.

Now we are looking at the feedback and looking at overall Red Hat
priorities and have to decide whether to create a project team to
continue with stateless Linux (and related technology). If we do decide
to continue then there will probably be a number of people working on
it.

Of course nothing is stopping others outside Red Hat from working on it,
would love to see it.

Havoc




From mr700 at globalnet.bg  Thu Dec 23 00:52:09 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Thu, 23 Dec 2004 02:52:09 +0200
Subject: rawhide report: 20041222 changes
In-Reply-To: <cqbsbn$g7c$1@sea.gmane.org>
References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com>
	<cqbsbn$g7c$1@sea.gmane.org>
Message-ID: <200412230252.10364@-mr700>

On 2004-12-22 (Wednesday) 15:20, Neal D. Becker wrote:
> Build System wrote:
> 
> > New package GFS
> > GFS - The Global File System
> > 
> 
> Yummy!  I wonder if this stuff would work on an otherwise up-to-date FC3?
> 

    And you are not alone :) +2 here.

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From cknowlton at science.edu  Thu Dec 23 01:23:24 2004
From: cknowlton at science.edu (Carlos Knowlton)
Date: Wed, 22 Dec 2004 19:23:24 -0600
Subject: stateless linux project status
In-Reply-To: <1103763019.11975.6.camel@localhost.localdomain>
References: <1103734820.2359.74.camel@shiva>
	<1103763019.11975.6.camel@localhost.localdomain>
Message-ID: <41CA1E0C.6050109@science.edu>

Havoc Pennington wrote:

>On Wed, 2004-12-22 at 17:00 +0000, Peter Schobel wrote:
>  
>
>>I have seen next to nothing on this list recently from stateless linux
>>developers
>>
>>What is the status of this project? Is it in active development?
>>
>>    
>>
>
>It isn't in active development right now; the initial release was a
>prototype to gather data on what people thought of the idea.
>
>Now we are looking at the feedback and looking at overall Red Hat
>priorities and have to decide whether to create a project team to
>continue with stateless Linux (and related technology). If we do decide
>to continue then there will probably be a number of people working on
>it.
>
>Of course nothing is stopping others outside Red Hat from working on it,
>would love to see it.
>
>Havoc
>
>  
>
I hope they do continue it.  I think this project really has promise!   
I'm not much of a developer, but I'm a willing tester, and happy to help 
out where I can!

Carlos



From mlauterbach at mail.wtamu.edu  Thu Dec 23 01:32:16 2004
From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach)
Date: Wed, 22 Dec 2004 19:32:16 -0600
Subject: CD burner that Just Works
In-Reply-To: <41C9F84E.7090005@gmx.net>
Message-ID: <20041223013219.2A65E3E62F5@mail.wtamu.edu>



On Wednesday, December 22, 2004 4:42 PM, Er?in EKER wrote:
> Florin Andrei, 22-12-2004 20:34 tarihinde ?unlar? yazd?:
> 
> | So... how about including Graveman in Fedora?
> |
> | http://scresto.site.voila.fr/gravemanuk.html
> |
> | - It Just Works. - It has a no-nonsense interface that, to me at
> | least, seems much better than any other CD burner for Linux. In
> | fact, i think this is The CD- Burner GUI Metaphor that everyone
> | should look at and learn from. Really. Any "dummy user" could use
> | it, while it does not step on advanced users' toes. - It's
> | GTK-based.
> |
> | Please?
> |
> Coaster looks good, is in development too and didn't used yet.
> 
> 
> http://www.coaster-burn.org/
> 
Can they burn DVDs?

Matthew E. Lauterbach





From dpaun at rogers.com  Thu Dec 23 06:25:58 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Thu, 23 Dec 2004 01:25:58 -0500
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <20041223062558.GH7176@rogers.com>

On Wed, Dec 22, 2004 at 10:34:59AM -0800, Florin Andrei wrote:
> Well, K3B is nice and all, but it's a KDE application. 

Actually, I do have a problem with it. While I quite like the
app when it's working, I've had no end of trouble with it
recognizing my CR-Writer! And the strange things is that it
used to work, then misteriously (maybe after an update that
modified some permissions), it stops working.

For example, now I have a system, FC3+updates, that has
a Plextor PX-W1210A. Now, this system used to work just
fine IIRC with FC2, but it stopped recognizing the burner
at a certain point. I've upgraded it to FC3test3, nothing.
Then I've updated it to FC3, again nothing. Then I've applied
all the latest updates, nothing!

And all this after running K3bsetup, of course.

Right now the situation is as follows:
  -- if run as a regular user, k3b sees my burner as a
     regular CDROM, so it list it as a Reader. Obviously
     I can't burn :) No amount of upgrading/updating/k3bsetup
     fixed that problem.
  -- if I run it as root, it sees the burner as a burner.

What gives? This is driving me *INSANE*. A similar story
happend on another box of mine (this time with a
HL-DT-ST GCE-8525B drive):
  -- installed FC3test3, it worked
  -- after a while it stopped seeing the burner
  -- upgraded to FC3, updated, k3bsetup, now it sees it

I can not describe how !@#$%^ frustrating this experience
is. I really think this needs fixing. Burning CDs is a
*important* desktop activity on a modern desktop. I'm
an experienced Linux hardcore guy (been using it exclusively
since 96), and this stuff simply gets the better of me.
I can't imagine how a normal person would react to this.

-- 
Dimi.



From edg at greenberg.org  Thu Dec 23 06:10:09 2004
From: edg at greenberg.org (Ed Greenberg)
Date: Wed, 22 Dec 2004 22:10:09 -0800
Subject: php4 source rpm fails to compile on FC3
Message-ID: <A40AEA00993E394C45BD2F63@localhost.localdomain>

I have a freshly installed FC3 on which I installed all packages. I need to 
have MySQL4, so I first uninstalled the MySQL Database package group which 
consisted of:

Transaction Listing:
  Remove: MyODBC.i386 0:2.50.39-19.1
  Remove: MySQL-python.i386 0:0.9.2-4
  Remove: libdbi-dbd-mysql.i386 0:0.6.5-9
  Remove: mod_auth_mysql.i386 0:20030510-5
  Remove: mysql.i386 0:3.23.58-13
  Remove: mysql-bench.i386 0:3.23.58-13
  Remove: mysql-devel.i386 0:3.23.58-13
  Remove: mysql-server.i386 0:3.23.58-13
  Remove: perl-DBD-MySQL.i386 0:2.9003-5
  Remove: php-mysql.i386 0:4.3.10-3.2
  Remove: qt-MySQL.i386 1:3.3.3-8
  Remove: qt-ODBC.i386 1:3.3.3-8

Performing the following to resolve dependencies:
  Remove: cyrus-sasl-sql.i386 0:2.1.19-3
  Remove: dovecot.i386 0:0.99.11-1.FC3.4
  Remove: freeradius-mysql.i386 0:1.0.1-1
  Remove: gda-mysql.i386 1:1.0.4-3

I then installed:
MySQL-bench-4.1.8-0.i386.rpm
MySQL-client-4.1.8-0.i386.rpm
MySQL-devel-4.1.8-0.i386.rpm
MySQL-server-4.1.8-0.i386.rpm
MySQL-shared-4.1.8-0.i386.rpm

Finally, I downloaded php-4.3.10-3.2.src.rpm with the intent of building it 
against the newly installed MySQL.

The build was started with
[root at localhost SPECS]# rpmbuild -ba php.spec
and it fails.

The test summary is:
---------------------------------------------------------------------
Number of tests :  608
Tests skipped   :  219 (36.0%)
Tests warned    :    0 (0.0%)
Tests failed    :    2 (0.3%)
Tests passed    :  387 (63.7%)
---------------------------------------------------------------------
Time taken      :   63 seconds

The two failures are:
Bug #26938 (exec does not read consecutive long lines correctly) 
[ext/standard/tests/file/bug26938.phpt]
proc_open() regression test 1 (proc_open() leak) 
[ext/standard/tests/file/proc_open01.phpt]

There's also a warning about
001+ PHP Warning:  Unknown(): Unable to load dynamic library 
'/usr/lib/php4/odbc
.so' - libodbc.so.1: cannot open shared object file: No such file or 
directory i
n Unknown on line 0
which is interesting since the file /usr/lib/php4/odbc.so is indeed there 
and is indeed an ELF shared library.

Can anyone spot what might be wrong?

Thanks,
</edg>
Ed Greenberg
San Jose, CA



From nandox7 at myrealbox.com  Thu Dec 23 09:22:16 2004
From: nandox7 at myrealbox.com (Nando)
Date: Thu, 23 Dec 2004 09:22:16 +0000
Subject: CD burner that Just Works
In-Reply-To: <1103740499.3558.7.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
Message-ID: <41CA8E48.3040800@myrealbox.com>


One question, isn't all those app's being refered only to burn cd's? 
What about dvd's?
Wasn't it better to have  a solution that can deals correctly with both? 
The good looks is no everything...
Just a remark.



From mr700 at globalnet.bg  Thu Dec 23 10:24:13 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Thu, 23 Dec 2004 12:24:13 +0200
Subject: CD burner that Just Works
In-Reply-To: <41CA8E48.3040800@myrealbox.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<41CA8E48.3040800@myrealbox.com>
Message-ID: <200412231224.13440@-mr700>

On 2004 12 23 (Thursday) 11:22, Nando wrote:
> 
> One question, isn't all those app's being refered only to burn cd's? 
> What about dvd's?

    k3b burns DVDs for me just fine. Look at the features page :)

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79



From nandox7 at myrealbox.com  Thu Dec 23 10:57:20 2004
From: nandox7 at myrealbox.com (Nando)
Date: Thu, 23 Dec 2004 10:57:20 +0000
Subject: CD burner that Just Works
In-Reply-To: <200412231224.13440@-mr700>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<41CA8E48.3040800@myrealbox.com>
	<200412231224.13440@-mr700>
Message-ID: <41CAA490.8090003@myrealbox.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041223/20dea689/attachment.htm>

From fedora-devel at camperquake.de  Thu Dec 23 12:53:26 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Thu, 23 Dec 2004 13:53:26 +0100
Subject: CD burner that Just Works
In-Reply-To: <20041223062558.GH7176@rogers.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
Message-ID: <20041223135326.7166cb56@nausicaa.camperquake.de>

Hi.

"Dimitrie O. Paun" <dpaun at rogers.com> wrote:

> For example, now I have a system, FC3+updates, that has
> a Plextor PX-W1210A. Now, this system used to work just
> fine IIRC with FC2, but it stopped recognizing the burner
> at a certain point. I've upgraded it to FC3test3, nothing.
> Then I've updated it to FC3, again nothing. Then I've applied
> all the latest updates, nothing!

There was a kernel issue which produced results like this introduced
into the FC3test cycle. It was still present when FC3 was released,
but was fixed meanwhile in rawhide. I do not know the current state
of FC3 update kernels.


-- 
"A friend of mine is into Voodoo Acupuncture. You don't have to go.
You'll just be walking down the street, and........... ooooohhhhhh,
that's much better..." -- Steven Wright



From Manfred.Schirmer at cse.de  Thu Dec 23 13:25:43 2004
From: Manfred.Schirmer at cse.de (Manfred Schirmer)
Date: Thu, 23 Dec 2004 14:25:43 +0100
Subject: yum and up2date broken after last update
Message-ID: <200412231425.43219.Manfred.Schirmer@cse.de>

After updating FC3 from fedora-devel repository yum got broken:

Traceback (most recent call last):
  File "/usr/bin/yum", line 6, in ?
    import yummain
  File "/usr/share/yum-cli/yummain.py", line 23, in ?
    import yum
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 21, in ?
    import rpm
ImportError: No module named rpm

Same with up2date:

Traceback (most recent call last):
  File "/usr/sbin/up2date", line 11, in ?
    import rpm
ImportError: No module named rpm

How can I add the missinig module 'rpm'?
-- 
Manfred Schirmer



From buildsys at redhat.com  Thu Dec 23 13:30:25 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 23 Dec 2004 08:30:25 -0500
Subject: rawhide report: 20041223 changes
Message-ID: <200412231330.iBNDUPU32626@porkchop.devel.redhat.com>

 

 
Updated Packages:

gnumeric-1:1.4.1-5
------------------
* Wed Dec 22 2004 Caolan McNamara <caolanm at redhat.com> 1.4.1-5
- RH#143587# pango-devel >= 1.4.0

guile-5:1.6.4-16
----------------
* Tue Dec 21 2004 Phil Knirsch <pknirsch at redhat.com> 5:1.6.4-16
- Moved info files to base package as they are not devel related (#139948)
- Moved static guilereadline and guile-srfi-srfi libs to devel package (#140893)
- Fixed guile-tools not finding guile lib dir (#142642)
- Added some nice tools (#142642)
- Removed smp build, seems to be broken atm

inn-2.4.1-2
-----------
* Thu Dec 23 2004 Martin Stransky <stransky at redhat.com> 2.4.1-2
- fix array overflow / uninitialized pointer (#143592)

kernel-2.6.9-1.1049_FC4
-----------------------
* Wed Dec 22 2004 Dave Jones <davej at redhat.com>
- Re-add missing part of the exit() race fix. (#142505, #141896)

libtiff-3.7.1-2
---------------
* Wed Dec 22 2004 Matthias Clasen <mclasen at redhat.com> - 3.7.1-2
- Readd the largefile patch (#143560)

* Wed Dec 22 2004 Matthias Clasen <mclasen at redhat.com> - 3.7.1-1
- Upgrade to 3.7.1
- Remove upstreamed patches
- Remove specfile cruft
- make check

lvm2-2.00.32-1.0
----------------
* Wed Dec 22 2004 Alasdair Kergon <agk at redhat.com> - 2.00.32-1.0
- More fixes (143501).

* Sun Dec 12 2004 Alasdair Kergon <agk at redhat.com> - 2.00.31-1.0
- Fix pvcreate install issues.

* Fri Dec 10 2004 Alasdair Kergon <agk at redhat.com> - 2.00.30-1.0
- Additional debugging code.
- Some trivial man page corrections.

mikmod-3.1.6-33
---------------
* Tue Dec 21 2004 Martin Stransky <stransky at redhat.com> 3.1.6-33
- strip library (#143258)

* Mon Dec 13 2004 Bill Nottingham <notting at redhat.com> 3.1.6-31
- move mikmod binary back to main package (#142668)

* Fri Oct 08 2004 Bill Nottingham <notting at redhat.com> 3.1.6-30
- add texinfo buildreqs (#135088)

nc-1.10-24
----------
* Wed Dec 22 2004 Radek Vokal <rvokal at redhat.com> 1.10-24
- enabling telnet support (#143498)
- removed static linking
- array range fixed

* Mon Nov 01 2004 Radek Vokal <rvokal at redhat.com> 1.10-23
- return value of help function fixed (#137785)

* Tue Sep 21 2004 Radek Vokal <rvokal at redhat.com> 1.10-22
- timeout option patch when SIGALRM blocked (#132973)

rpmdb-fedora-1:4-0.20041223
---------------------------

selinux-policy-strict-1.19.15-5
-------------------------------
* Wed Dec 22 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-5
- Allow reading of udev_tdb_t directory
- Change /etc/init.d/sendmail to bin_t for targeted policy to make 
- it to run unconfined.

* Wed Dec 22 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-3
- Add sendmail

* Wed Dec 22 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-2
- Remove transition rules for unconfined_t to domains, must run initrc scripts.
- Add init and initrc to targeted policy

selinux-policy-targeted-1.19.15-5
---------------------------------
* Wed Dec 22 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-5
- Allow reading of udev_tdb_t directory
- Change /etc/init.d/sendmail to bin_t for targeted policy to make 
- it to run unconfined.

* Wed Dec 22 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-2
- Remove transition rules for unconfined_t to domains, must run initrc scripts.
- Add init and initrc to targeted policy

xpdf-1:3.00-14
--------------
* Wed Dec 22 2004 Tim Waugh <twaugh at redhat.com> 1:3.00-14
- Applied patch to fix CAN-2004-1125 (bug #143500).



From tjarls at iee.lu  Thu Dec 23 13:31:43 2004
From: tjarls at iee.lu (Charles Lopes)
Date: Thu, 23 Dec 2004 14:31:43 +0100
Subject: hdlist order tag problem
In-Reply-To: <7f48492a0412210614318f507c@mail.gmail.com>
References: <7f48492a041218182116d975ab@mail.gmail.com>
	<7f48492a0412210614318f507c@mail.gmail.com>
Message-ID: <41CAC8BF.2080402@iee.lu>

Christopher Hotchkiss wrote:

>I am trying to add a custom rpm (my netexec script posted earlier to
>fedora-devel), to a nfs kickstart install. I copied the rpm to the
>RPMS/ directory and added the following to
>/install/fedora/Fedora/base/comps.xml
>
><group>
>    <id>netexec-sc</id>
>
>    <name>Netexec Client/Server</name>
>
>    <description>Network command queueing program</description>
>
>    <uservisible>false</uservisible>
>
>    <packagelist>
>      <packagereq type="default"
>requires="perl-Frontier-RPC">netexec</packagereq>
>    </packagelist>
>  </group>
>
>Then I ran: /usr/lib/anaconda-runtime/genhdlist --productpath Fedora
>/data/install/fedora
>
>When I started the kickstart install it produced the following error and died:
>WARNING: not all packages in hdlist had order tag.
>
>Any clue as to why this died? The most recent information on custom
>nfs installs that I
>can find is from RedHat 8.0.
>The rpm in question is attached.
>  
>
I ran into the same type of problem when I tried to create a local 
network installation point including the packages from the updates. 
Because of the warning I rerun the whole process using a pkgorder file 
and that worked. Because I didn't look into it any further I wasn't sure 
that the first problem was due to a missing pkgorder or not.  
Nevertheless you may want to try it as well. Here's approximatively the 
commands I used:

PYTHONPATH=/usr/lib/anaconda /usr/lib/anaconda-runtime/pkgorder <top dir> i386 > <pkgorder file>

/usr/lib/anaconda-runtime/genhdlist --productpath Fedora --pkgorder <pkgorder file> <top dir>

/usr/lib/anaconda-runtime/buildinstall --product "Fedora Core" --version 3 --release "Fedora Core 3" --pkgorder <pkgorder file> --prodpath Fedora <top dir>






From mandreiana at rdslink.ro  Thu Dec 23 14:08:43 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Thu, 23 Dec 2004 16:08:43 +0200
Subject: CD burner that Just Works
In-Reply-To: <1103760448.3558.44.camel@stantz.corp.sgi.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<1103760448.3558.44.camel@stantz.corp.sgi.com>
Message-ID: <1103810923.3838.1.camel@marte.biciclete.ro>

On Wed, 2004-12-22 at 16:07 -0800, Florin Andrei wrote:
> On Wed, 2004-12-22 at 10:34 -0800, Florin Andrei wrote:
> 
> > So... how about including Graveman in Fedora?
> > 
> > http://scresto.site.voila.fr/gravemanuk.html
> 
> Ok, i slapped together some quick packages for Fedora 3:
> 
> ftp://andrei.myip.org/graveman/
Please submit them to fedora extras and let us know bug # to do QA :-D

-- 
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro



From fedora at wir-sind-cool.org  Thu Dec 23 14:09:00 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 23 Dec 2004 15:09:00 +0100
Subject: CD burner that Just Works
In-Reply-To: <20041223062558.GH7176@rogers.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
Message-ID: <20041223150900.4898fb79.fedora@wir-sind-cool.org>

On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:

> And all this after running K3bsetup, of course.

You should not even be able to, since k3bsetup is NOT included
in Fedora Core 3. This sounds again as if you picked up a k3b
package somewhere else. I've seen a number of users have problems
with such packages, sometimes because patches were not included.
A downgrade to FC3 k3b and latest kernel fixed it for them.
 
> Right now the situation is as follows:
>   -- if run as a regular user, k3b sees my burner as a
>      regular CDROM, so it list it as a Reader. Obviously
>      I can't burn :) No amount of upgrading/updating/k3bsetup
>      fixed that problem.
>   -- if I run it as root, it sees the burner as a burner.
> 
> What gives? This is driving me *INSANE*. A similar story
> happend on another box of mine (this time with a
> HL-DT-ST GCE-8525B drive):
>   -- installed FC3test3, it worked
>   -- after a while it stopped seeing the burner
>   -- upgraded to FC3, updated, k3bsetup, now it sees it



From rdieter at math.unl.edu  Thu Dec 23 14:14:41 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 23 Dec 2004 08:14:41 -0600
Subject: k3b on fc3
In-Reply-To: <20041223150900.4898fb79.fedora@wir-sind-cool.org>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
Message-ID: <41CAD2D1.8010900@math.unl.edu>

Michael Schwendt wrote:
> On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:
> 
> 
>>And all this after running K3bsetup, of course.
> 
> 
> You should not even be able to, since k3bsetup is NOT included
> in Fedora Core 3. This sounds again as if you picked up a k3b
> package somewhere else. 

For the record, an "unpatched" k3b-0.11.18 (with k3bsetup) *should* work 
just fine on FC3, provided you use a kernel that actually suports cd 
burning (ie, not kernel-2.6.8(.1) ).  See also:
http://www.k3b.org/ "Latest News" items:
"Update on the kernel 2.6.9 issue"
"Do not use Kernel 2.6.8"

-- Rex



From casimiro.barreto at gmail.com  Thu Dec 23 14:23:07 2004
From: casimiro.barreto at gmail.com (casimiro barreto)
Date: Thu, 23 Dec 2004 12:23:07 -0200
Subject: k3b on fc3
In-Reply-To: <41CAD2D1.8010900@math.unl.edu>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<41CAD2D1.8010900@math.unl.edu>
Message-ID: <578ed591041223062369613e67@mail.gmail.com>

BTW,

Even kernel 2.6.8-1.681_FC3 shows problems in burning CDs in USB CD
recorders. Among other problems:

a) CD recorder status is not read properly
b) There are writing problems whenever higher recording speeds are
requested. To give an idea of the annoyance, in an IOMEGA Predator,
the max recording speed allowed is 2x (!!! ????)

Best regards,

Casimiro


On Thu, 23 Dec 2004 08:14:41 -0600, Rex Dieter <rdieter at math.unl.edu> wrote:
> Michael Schwendt wrote:
> > On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:
> >
> >
> >>And all this after running K3bsetup, of course.
> >
> >
> > You should not even be able to, since k3bsetup is NOT included
> > in Fedora Core 3. This sounds again as if you picked up a k3b
> > package somewhere else.
> 
> For the record, an "unpatched" k3b-0.11.18 (with k3bsetup) *should* work
> just fine on FC3, provided you use a kernel that actually suports cd
> burning (ie, not kernel-2.6.8(.1) ).  See also:
> http://www.k3b.org/ "Latest News" items:
> "Update on the kernel 2.6.9 issue"
> "Do not use Kernel 2.6.8"
> 
> -- Rex
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
The information contained in this message is confidential and
intended to the recipients specified in the headers. If you received
this message by error, notify the sender immediately. The
unauthorized use, disclosure, copy or alteration of this message
are strictly forbidden and subjected to civil and criminal sanctions.



From rdieter at math.unl.edu  Thu Dec 23 14:30:52 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 23 Dec 2004 08:30:52 -0600
Subject: k3b on fc3
In-Reply-To: <578ed591041223062369613e67@mail.gmail.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<20041223062558.GH7176@rogers.com>	<20041223150900.4898fb79.fedora@wir-sind-cool.org>	<41CAD2D1.8010900@math.unl.edu>
	<578ed591041223062369613e67@mail.gmail.com>
Message-ID: <41CAD69C.2080906@math.unl.edu>

casimiro barreto wrote:

> Even kernel 2.6.8-1.681_FC3 shows problems in burning CDs in USB CD
> recorders.

Right, ptretty much any 2.6.8(.1) kernel has CD burning issues.  You'd 
best use one of the kernel-2.6.9 errata kernels (or downgrade to 
kernel-2.6.7)

-- Rex



From fedora at wir-sind-cool.org  Thu Dec 23 14:37:11 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 23 Dec 2004 15:37:11 +0100
Subject: k3b on fc3
In-Reply-To: <578ed591041223062369613e67@mail.gmail.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<41CAD2D1.8010900@math.unl.edu>
	<578ed591041223062369613e67@mail.gmail.com>
Message-ID: <20041223153711.11fab80b.fedora@wir-sind-cool.org>

On Thu, 23 Dec 2004 12:23:07 -0200, casimiro barreto wrote:

> BTW,
> 
> Even kernel 2.6.8-1.681_FC3 shows problems in burning CDs in USB CD
> recorders. Among other problems:

You mean 2.6.9-1.681_FC3?



From srinivasg at esntechnologies.co.in  Thu Dec 23 14:09:28 2004
From: srinivasg at esntechnologies.co.in (Srinivas G.)
Date: Thu, 23 Dec 2004 19:39:28 +0530
Subject: (no subject)
Message-ID: <4EE0CBA31942E547B99B3D4BFAB3481125911A@mail.esn.co.in>

subscribe 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041223/50626e61/attachment.htm>

From casimiro.barreto at gmail.com  Thu Dec 23 15:00:07 2004
From: casimiro.barreto at gmail.com (casimiro barreto)
Date: Thu, 23 Dec 2004 13:00:07 -0200
Subject: k3b on fc3
In-Reply-To: <20041223153711.11fab80b.fedora@wir-sind-cool.org>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<41CAD2D1.8010900@math.unl.edu>
	<578ed591041223062369613e67@mail.gmail.com>
	<20041223153711.11fab80b.fedora@wir-sind-cool.org>
Message-ID: <578ed59104122307006c278648@mail.gmail.com>

Yeah... 2.6.9-1.681_FC3. Mistyped...


On Thu, 23 Dec 2004 15:37:11 +0100, Michael Schwendt
<fedora at wir-sind-cool.org> wrote:
> On Thu, 23 Dec 2004 12:23:07 -0200, casimiro barreto wrote:
> 
> > BTW,
> >
> > Even kernel 2.6.8-1.681_FC3 shows problems in burning CDs in USB CD
> > recorders. Among other problems:
> 
> You mean 2.6.9-1.681_FC3?
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
The information contained in this message is confidential and
intended to the recipients specified in the headers. If you received
this message by error, notify the sender immediately. The
unauthorized use, disclosure, copy or alteration of this message
are strictly forbidden and subjected to civil and criminal sanctions.



From dpaun at rogers.com  Thu Dec 23 16:33:55 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Thu, 23 Dec 2004 11:33:55 -0500
Subject: k3b on fc3
In-Reply-To: <41CAD2D1.8010900@math.unl.edu>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<41CAD2D1.8010900@math.unl.edu>
Message-ID: <20041223163355.GA15222@rogers.com>

On Thu, Dec 23, 2004 at 08:14:41AM -0600, Rex Dieter wrote:
> For the record, an "unpatched" k3b-0.11.18 (with k3bsetup) *should* work 
> just fine on FC3, provided you use a kernel that actually suports cd 
> burning (ie, not kernel-2.6.8(.1) ).  See also:
> http://www.k3b.org/ "Latest News" items:
> "Update on the kernel 2.6.9 issue"
> "Do not use Kernel 2.6.8"

Actually, I'm running 2.6.9-1.681_FC3, and I still have said problems.

-- 
Dimi.



From dpaun at rogers.com  Thu Dec 23 16:40:14 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Thu, 23 Dec 2004 11:40:14 -0500
Subject: CD burner that Just Works
In-Reply-To: <20041223150900.4898fb79.fedora@wir-sind-cool.org>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
Message-ID: <20041223164014.GB15222@rogers.com>

On Thu, Dec 23, 2004 at 03:09:00PM +0100, Michael Schwendt wrote:
> On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:
> 
> > And all this after running K3bsetup, of course.
> 
> You should not even be able to, since k3bsetup is NOT included
> in Fedora Core 3. This sounds again as if you picked up a k3b
> package somewhere else. I've seen a number of users have problems
> with such packages, sometimes because patches were not included.
> A downgrade to FC3 k3b and latest kernel fixed it for them.

You are correct:
[root at alina alina]# rpm -q k3b
k3b-0.11.9-1.xcyb

I'll try to downgrade to the FC3 k3b, see if that works.

-- 
Dimi.



From rdieter at math.unl.edu  Thu Dec 23 16:41:18 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 23 Dec 2004 10:41:18 -0600
Subject: k3b on fc3
In-Reply-To: <20041223163355.GA15222@rogers.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<20041223062558.GH7176@rogers.com>	<20041223150900.4898fb79.fedora@wir-sind-cool.org>	<41CAD2D1.8010900@math.unl.edu>
	<20041223163355.GA15222@rogers.com>
Message-ID: <41CAF52E.5090105@math.unl.edu>

Dimitrie O. Paun wrote:
> On Thu, Dec 23, 2004 at 08:14:41AM -0600, Rex Dieter wrote:
> 
>>For the record, an "unpatched" k3b-0.11.18 (with k3bsetup) *should* work 
>>just fine on FC3, provided you use a kernel that actually suports cd 
>>burning (ie, not kernel-2.6.8(.1) ).  See also:
>>http://www.k3b.org/ "Latest News" items:
>>"Update on the kernel 2.6.9 issue"
>>"Do not use Kernel 2.6.8"
> 
> 
> Actually, I'm running 2.6.9-1.681_FC3, and I still have said problems.

You seem to be experiencing a different issue, as burning works for most 
folks (incuding me) now.  Those problems I referred to from k3b.org's 
website affected *everyone*.

-- Rex



From rdieter at math.unl.edu  Thu Dec 23 16:44:35 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 23 Dec 2004 10:44:35 -0600
Subject: CD burner that Just Works
In-Reply-To: <20041223164014.GB15222@rogers.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<20041223062558.GH7176@rogers.com>	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<20041223164014.GB15222@rogers.com>
Message-ID: <41CAF5F3.1080809@math.unl.edu>

Dimitrie O. Paun wrote:
> On Thu, Dec 23, 2004 at 03:09:00PM +0100, Michael Schwendt wrote:
> 
>>On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:
>>
>>
>>>And all this after running K3bsetup, of course.
>>
>>You should not even be able to, since k3bsetup is NOT included
>>in Fedora Core 3. This sounds again as if you picked up a k3b
>>package somewhere else. I've seen a number of users have problems
>>with such packages, sometimes because patches were not included.
>>A downgrade to FC3 k3b and latest kernel fixed it for them.
> 
> 
> You are correct:
> [root at alina alina]# rpm -q k3b
> k3b-0.11.9-1.xcyb
> 
> I'll try to downgrade to the FC3 k3b, see if that works.

FYI, the combination of using k3bsetup < 0.11.18 on kernel >= 2.6.9 also 
leads to non-functional systems, as per k3b-0.11.18 changelog:

Some improvements regarding the kernel >= 2.6.8 issues:
     * Do not warn about cdrecord not running suid root on kernel 2.6.8 
and above
     * K3bSetup now removes the suid root bit on kernel 2.6.8 an above 
systems


-- Rex



From dragoran at feuerpokemon.de  Thu Dec 23 17:03:59 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Thu, 23 Dec 2004 18:03:59 +0100
Subject: k3b on fc3
In-Reply-To: <41CAF52E.5090105@math.unl.edu>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>	<20041223062558.GH7176@rogers.com>	<20041223150900.4898fb79.fedora@wir-sind-cool.org>	<41CAD2D1.8010900@math.unl.edu>	<20041223163355.GA15222@rogers.com>
	<41CAF52E.5090105@math.unl.edu>
Message-ID: <41CAFA7F.7000702@feuerpokemon.de>

Rex Dieter schrieb:

> Dimitrie O. Paun wrote:
>
>> On Thu, Dec 23, 2004 at 08:14:41AM -0600, Rex Dieter wrote:
>>
>>> For the record, an "unpatched" k3b-0.11.18 (with k3bsetup) *should* 
>>> work just fine on FC3, provided you use a kernel that actually 
>>> suports cd burning (ie, not kernel-2.6.8(.1) ).  See also:
>>> http://www.k3b.org/ "Latest News" items:
>>> "Update on the kernel 2.6.9 issue"
>>> "Do not use Kernel 2.6.8"
>>
>>
>>
>> Actually, I'm running 2.6.9-1.681_FC3, and I still have said problems.
>
>
> You seem to be experiencing a different issue, as burning works for 
> most folks (incuding me) now.  Those problems I referred to from 
> k3b.org's website affected *everyone*.
>
> -- Rex
>
"


  Update on the kernel 2.6.9 issue

I finally did some testing and gathered some information on the kernel 
2.6.9 problem. Here is what I can tell you:

    * Cdrecord won't run anymore when configured suid root. The reason
      is that the new kernel forbids suid root programs to use the SCSI
      subsystem (or something like that, correct me if I am wrong :)
      So Cdrecord needs to be configured without suid root and the next
      version of K3bSetup will do that.
      Cdrdao does not have this problem. I think that's becasue it drops
      the root privileges in an earlier stage but I am not sure about that.
    * K3b is unable to properly handle external (USB, Firewire) devices
      on the new kernel. Whenever the tray is open it will not be
      recognized as a CD/DVD device and if K3b is trying to access it
      while the tray is open it will get strange wrong answers from the
      device.
      I don't know how to solve this. Evenmore I think I cannot solve it
      since the dvd+rw-tools have the exact same problem. Hopefully this
      will be fixed in a future kernel version.

So what does that mean for you? Well, you have to decide for yourselves. 
Since I have multiple external DVD devices I still stick to kernel 2.6.7 
since otherwise I would always have to make sure the tray is not open 
when starting K3b and trying to burn something. But if you don't have 
any external devices and configure cdrecord properly using kernel 2.6.9 
should be no problem.

*Update:* This issue seems to be related to SCSI devices rather than 
just external."




From mattwhiteley at gmail.com  Thu Dec 23 17:20:52 2004
From: mattwhiteley at gmail.com (matt whiteley)
Date: Thu, 23 Dec 2004 09:20:52 -0800
Subject: hdlist order tag problem
In-Reply-To: <41CAC8BF.2080402@iee.lu>
References: <7f48492a041218182116d975ab@mail.gmail.com>
	<7f48492a0412210614318f507c@mail.gmail.com> <41CAC8BF.2080402@iee.lu>
Message-ID: <72ae109c04122309203b209790@mail.gmail.com>

On Thu, 23 Dec 2004 14:31:43 +0100, Charles Lopes <tjarls at iee.lu> wrote:
> I ran into the same type of problem when I tried to create a local
> network installation point including the packages from the updates.
> Because of the warning I rerun the whole process using a pkgorder file
> and that worked. Because I didn't look into it any further I wasn't sure
> that the first problem was due to a missing pkgorder or not.
> Nevertheless you may want to try it as well. Here's approximatively the
> commands I used:
> 
> PYTHONPATH=/usr/lib/anaconda /usr/lib/anaconda-runtime/pkgorder <top dir> i386 > <pkgorder file>
> 
> /usr/lib/anaconda-runtime/genhdlist --productpath Fedora --pkgorder <pkgorder file> <top dir>
> 
> /usr/lib/anaconda-runtime/buildinstall --product "Fedora Core" --version 3 --release "Fedora Core 3" --pkgorder <pkgorder file> --prodpath Fedora <top dir>

I got away with:

export PYTHONPATH=/usr/lib/anaconda
/usr/lib/anaconda-runtime/pkgorder <dir> <arch> Fedora > <file>
/usr/lib/anaconda-runtime/genhdlist --productpath Fedora --withnumbers
--pkgorder <file> <dir>
unset PYTHONPATH
run the install

The third argument to pkgorder, I don't remember being in the manpage
but it worked.

good luck,
-- 
matt whiteley <mattwhiteley at gmail.com>



From skvidal at phy.duke.edu  Thu Dec 23 17:29:02 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 23 Dec 2004 12:29:02 -0500
Subject: yum and up2date broken after last update
In-Reply-To: <200412231425.43219.Manfred.Schirmer@cse.de>
References: <200412231425.43219.Manfred.Schirmer@cse.de>
Message-ID: <1103822942.30316.21.camel@cutter>

On Thu, 2004-12-23 at 14:25 +0100, Manfred Schirmer wrote:
> After updating FC3 from fedora-devel repository yum got broken:
> 
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 6, in ?
>     import yummain
>   File "/usr/share/yum-cli/yummain.py", line 23, in ?
>     import yum
>   File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 21, in ?
>     import rpm
> ImportError: No module named rpm
> 
> Same with up2date:
> 
> Traceback (most recent call last):
>   File "/usr/sbin/up2date", line 11, in ?
>     import rpm
> ImportError: No module named rpm
> 
> How can I add the missinig module 'rpm'?

new, different, unhappy rpm in rawhide, maybe?

would be my guess.

-sv




From powers.jason at jimmy.harvard.edu  Thu Dec 23 17:37:24 2004
From: powers.jason at jimmy.harvard.edu (Jason Powers)
Date: Thu, 23 Dec 2004 12:37:24 -0500
Subject: stateless linux project status
In-Reply-To: <41CA1E0C.6050109@science.edu>
References: <1103734820.2359.74.camel@shiva>	<1103763019.11975.6.camel@localhost.localdomain>
	<41CA1E0C.6050109@science.edu>
Message-ID: <41CB0254.30502@jimmy.harvard.edu>

The diskless method has potential applications here, we had a hell of a 
time getting LTSP up by itself but this was pretty easy in comparison. 
Also, the way it stores the snapshots may potentially be useful for me 
to hold images for Win2k desktops, and that would mean we wouldn't have 
to spend $$ on ghost.

Other than the documentation being out of date and the PXE Generation 
script being utterly nonfunctional out of the box and requiring X for 
the config scripts and the idea of having to turn on rsync on every 
machine on my LAN being a little scary, it's a good idea.

I'd offer to help but I'm still a novice when it comes to python, I'm 
not sure my code would stand up. However, when I complete my current 
project (getting your builds of openldap/openssl/postgresql working 
together smoothly), Stateless is next on my list which puts it about 
mid-January.

I do hope you have people work on it, the configuration process needs 
extensive testing, the documentation needs to be updated WITH the code 
and the little bugs in the process could be worked out - there are 
complications inherent in a lot of the dependencies (ldap, dhcp) that 
would take minds much sharper than mine to fix, but I see working on the 
scripts as they are as being a good challenge as I learn more python.

I do appreciate redhat's support of these projects, I've learned a lot 
about linux and computers in general by working with your OSes over the 
past 6 years. Like a lot of people I just wish I could devote a little 
more of my workday to making Fedora better, but every time Lotus or 
another application is set to 'RHEL only,' Fedora has less and less 
opportunity in the workplace to justify people spending work-time on it, 
I end up spending time I could be working on these projects on finding 
the right compat-libs for Lotus, for Oracle, for SAS and SPLUS. Having 
community-developed support for thosewould be a useful project in its 
own right.

Jason

Carlos Knowlton wrote:
> Havoc Pennington wrote:
> 
>> On Wed, 2004-12-22 at 17:00 +0000, Peter Schobel wrote:
>>  
>>
>>> I have seen next to nothing on this list recently from stateless linux
>>> developers
>>>
>>> What is the status of this project? Is it in active development?
>>>
>>>   
>>
>>
>> It isn't in active development right now; the initial release was a
>> prototype to gather data on what people thought of the idea.
>>
>> Now we are looking at the feedback and looking at overall Red Hat
>> priorities and have to decide whether to create a project team to
>> continue with stateless Linux (and related technology). If we do decide
>> to continue then there will probably be a number of people working on
>> it.
>>
>> Of course nothing is stopping others outside Red Hat from working on it,
>> would love to see it.
>>
>> Havoc
>>
>>  
>>
> I hope they do continue it.  I think this project really has promise!   
> I'm not much of a developer, but I'm a willing tester, and happy to help 
> out where I can!
> 
> Carlos
> 



From fedora at wir-sind-cool.org  Thu Dec 23 18:35:41 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 23 Dec 2004 19:35:41 +0100
Subject: CD burner that Just Works
In-Reply-To: <20041223164014.GB15222@rogers.com>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<20041223164014.GB15222@rogers.com>
Message-ID: <20041223193541.696090d5.fedora@wir-sind-cool.org>

On Thu, 23 Dec 2004 11:40:14 -0500, Dimitrie O. Paun wrote:

> On Thu, Dec 23, 2004 at 03:09:00PM +0100, Michael Schwendt wrote:
> > On Thu, 23 Dec 2004 01:25:58 -0500, Dimitrie O. Paun wrote:
> > 
> > > And all this after running K3bsetup, of course.
> > 
> > You should not even be able to, since k3bsetup is NOT included
> > in Fedora Core 3. This sounds again as if you picked up a k3b
> > package somewhere else. I've seen a number of users have problems
> > with such packages, sometimes because patches were not included.
> > A downgrade to FC3 k3b and latest kernel fixed it for them.
> 
> You are correct:
> [root at alina alina]# rpm -q k3b
> k3b-0.11.9-1.xcyb
> 
> I'll try to downgrade to the FC3 k3b, see if that works.

Uhm, that would be an _upgrade_, because your 0.11.9 is even older
than FC3's k3b version. How did you manage to avoid the update to
FC3's k3b? What else is not up-to-date?



From dpaun at rogers.com  Thu Dec 23 20:28:41 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Thu, 23 Dec 2004 15:28:41 -0500
Subject: CD burner that Just Works
In-Reply-To: <20041223193541.696090d5.fedora@wir-sind-cool.org>
References: <1103740499.3558.7.camel@stantz.corp.sgi.com>
	<20041223062558.GH7176@rogers.com>
	<20041223150900.4898fb79.fedora@wir-sind-cool.org>
	<20041223164014.GB15222@rogers.com>
	<20041223193541.696090d5.fedora@wir-sind-cool.org>
Message-ID: <20041223202841.GA15439@rogers.com>

On Thu, Dec 23, 2004 at 07:35:41PM +0100, Michael Schwendt wrote:
> Uhm, that would be an _upgrade_, because your 0.11.9 is even older
> than FC3's k3b version. How did you manage to avoid the update to
> FC3's k3b? What else is not up-to-date?

That's right, I realized it after I've sent the message.
I think that I've installed that package some time ago,
and somehow rpm/anaconda did not upgrade it! It hasn't
even crossed my mind to check, it should have been
upgraded, I did a FCtest3->FC3 upgrade.

Hmm, I've installed the one that comes with the distro,
it now works.

-- 
Dimi.



From srinivasg at esntechnologies.co.in  Fri Dec 24 11:30:21 2004
From: srinivasg at esntechnologies.co.in (Srinivas G.)
Date: Fri, 24 Dec 2004 17:00:21 +0530
Subject: Compilation errors due to spin_locks
Message-ID: <4EE0CBA31942E547B99B3D4BFAB348112B8599@mail.esn.co.in>

Dear All,

I am new to this Fedora Linux. I worked on SuSE and Red Hat Linux.
Now I am using Fedora Core 3 with 2.6.9-1.667 kernel version.

I got a problem while compiling a module, but the same module is 
working under SuSE 9.1 with 2.6.5 and 2.6.6 kernel versions.

I understood that the error messages are related to spin_lock_irqsave
and 
spin_lock_init only. If I comment those two lines the compilation is OK.

Please find the attached txt files for error messages that are occur.

Please any help greatly appreciated. 
Thanks in advance.

Regards,
Srinivas G

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: spin_lock_irqsave.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041224/15e7ba66/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: spin_lock_init.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041224/15e7ba66/attachment-0001.txt>

From ndbecker2 at verizon.net  Fri Dec 24 12:30:25 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 24 Dec 2004 07:30:25 -0500
Subject: preextras announce or rss?
Message-ID: <cqh251$2ht$1@sea.gmane.org>

Is there a mechanism to announce additions to pre-extras?  Mail list, or
maybe rss?



From buildsys at redhat.com  Fri Dec 24 13:11:15 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 24 Dec 2004 08:11:15 -0500
Subject: rawhide report: 20041224 changes
Message-ID: <200412241311.iBODBFC29068@porkchop.devel.redhat.com>



From skvidal at phy.duke.edu  Fri Dec 24 14:23:31 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 24 Dec 2004 09:23:31 -0500
Subject: preextras announce or rss?
In-Reply-To: <cqh251$2ht$1@sea.gmane.org>
References: <cqh251$2ht$1@sea.gmane.org>
Message-ID: <1103898212.7453.2.camel@cutter>

On Fri, 2004-12-24 at 07:30 -0500, Neal D. Becker wrote:
> Is there a mechanism to announce additions to pre-extras?  Mail list, or
> maybe rss?

http://fedoraproject.org/infofeed/

There's an rss feed of new packages there.

-sv




From arjanv at redhat.com  Fri Dec 24 14:26:22 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 24 Dec 2004 15:26:22 +0100
Subject: Compilation errors due to spin_locks
In-Reply-To: <4EE0CBA31942E547B99B3D4BFAB348112B8599@mail.esn.co.in>
References: <4EE0CBA31942E547B99B3D4BFAB348112B8599@mail.esn.co.in>
Message-ID: <1103898385.4131.21.camel@laptopd505.fenrus.org>

On Fri, 2004-12-24 at 17:00 +0530, Srinivas G. wrote:
> Dear All,
> 
> I am new to this Fedora Linux. I worked on SuSE and Red Hat Linux.
> Now I am using Fedora Core 3 with 2.6.9-1.667 kernel version.
> 
> I got a problem while compiling a module, but the same module is 
> working under SuSE 9.1 with 2.6.5 and 2.6.6 kernel versions

how are you compiling the module? Can you provide an URL to the source
and makefile ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041224/e8433231/attachment.sig>

From jaboutboul at speakeasy.net  Fri Dec 24 17:12:43 2004
From: jaboutboul at speakeasy.net (Jack Aboutboul)
Date: Fri, 24 Dec 2004 12:12:43 -0500
Subject: SSL cert/key location
In-Reply-To: <Pine.LNX.4.61.0412221901530.1314@netcore.fi>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
	<20041222145825.GA1324747@hiwaay.net> <41C98E9B.6050504@bppiac.hu>
	<Pine.LNX.4.61.0412221901530.1314@netcore.fi>
Message-ID: <1103908363.30033.35.camel@deepfort>

On Wed, 2004-12-22 at 19:03 +0200, Pekka Savola wrote:
> >> You'll need to modify OpenSSL to handle multiple "default" directories.
> >> Currently I think you can only specify a single directory for certs (the
> >> certs setting under the CA_default section in openssl.cnf).
> >> Applications use OpenSSL calls to validate the cert chain, so it'll need
> >> to look in the local directory (/etc/ssl/certs) first and then the other
> >> directory (/usr/share/ssl/certs) when walking the cert chain.  The crl
> >
> > why we need /usr/share/ssl/ at all? /etc/ssl would be enough (as one 
> > directory)!
> 
> Because it may not be able to change all the apps and libraries at 
> once which put stuff or expect to find stuff in /usr/share/ssl ?

That's trivial because all you need to do for most apps is tweak the
configure script with the new ssl folder.

Jack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041224/bbe00cb1/attachment.sig>

From srinivasg at esntechnologies.co.in  Sat Dec 25 05:52:59 2004
From: srinivasg at esntechnologies.co.in (Srinivas G.)
Date: Sat, 25 Dec 2004 11:22:59 +0530
Subject: Compilation errors due to spin_locks
Message-ID: <4EE0CBA31942E547B99B3D4BFAB348112B85C4@mail.esn.co.in>

> 
> On Fri, 2004-12-24 at 17:00 +0530, Srinivas G. wrote:
> > Dear All,
> >
> > I am new to this Fedora Linux. I worked on SuSE and Red Hat Linux.
> > Now I am using Fedora Core 3 with 2.6.9-1.667 kernel version.
> >
> > I got a problem while compiling a module, but the same module is
> > working under SuSE 9.1 with 2.6.5 and 2.6.6 kernel versions
> 
> how are you compiling the module? Can you provide an URL to the source
> and makefile ?

Dear Arjan,

Please find the attached Makefile which I am using it on Fedora Core 3
with 2.6.9-1.667 kernel version. The same Makefile I used previously on
SuSE 9.1 with 2.6.6, 2.6.8 and 2.6.9 kernel versions. It works fine
under SuSE 9.1

Please correct me if any thing wrong in the Makefile.

Thanks and regards,
Srinivas G
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 384 bytes
Desc: Makefile
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041225/033e3816/attachment.obj>

From srinivasg at esntechnologies.co.in  Sat Dec 25 07:45:57 2004
From: srinivasg at esntechnologies.co.in (Srinivas G.)
Date: Sat, 25 Dec 2004 13:15:57 +0530
Subject: request for member magic in something not a structure or union
Message-ID: <4EE0CBA31942E547B99B3D4BFAB348112B85CF@mail.esn.co.in>

Dear All,
?
I am new to this Fedora Linux. I worked on SuSE and Red Hat Linux. Now I am using Fedora Core 3 with 2.6.9-1.667 kernel version.
?
I got a problem while compiling a module, but the same module is 
working under SuSE 9.1 with 2.6.5 and 2.6.6 kernel versions.
?
I understood that the error messages are related to spin_lock_irqsave and 
spin_lock_init only. If I comment those two lines the compilation is OK.
?
Please find the attached txt file for error messages that are occurred.
?
Please any help greatly appreciated. 
Thanks in advance.
?
Regards,
Srinivas G
?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: spin_lock_irqsave.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041225/e4770761/attachment.txt>

From no-reply-gw at fcp.homelinux.org  Sat Dec 25 14:18:43 2004
From: no-reply-gw at fcp.homelinux.org (=?iso-8859-1?B?bXNpbGJlcg==?=)
Date: Sat, 25 Dec 2004 15:18:43 +0100
Subject: building own RPMs
Message-ID: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>

Hi @ all,

I need to build an own RPM package from my apache source, how can I do that? Found nothing about this in the Web!
I know the rpmbuild command, but I can only build RPMs from src.rpms or prepared tarballs! HELP! Please!  :-?  

your marcel


-- 
This is an email sent via the webforum on http://fcp.homelinux.org



From nandox7 at myrealbox.com  Sat Dec 25 15:43:25 2004
From: nandox7 at myrealbox.com (Nando)
Date: Sat, 25 Dec 2004 15:43:25 +0000
Subject: building own RPMs
In-Reply-To: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
Message-ID: <41CD8A9D.2050605@myrealbox.com>

For example you can try, checkinstall.
Good Luck.

msilber wrote:

>Hi @ all,
>
>I need to build an own RPM package from my apache source, how can I do that? Found nothing about this in the Web!
>I know the rpmbuild command, but I can only build RPMs from src.rpms or prepared tarballs! HELP! Please!  :-?  
>
>your marcel
>
>
>  
>



From thesource at ldb-jab.org  Sat Dec 25 15:44:42 2004
From: thesource at ldb-jab.org (Lawrence Bowie)
Date: Sat, 25 Dec 2004 10:44:42 -0500
Subject: building own RPMs
In-Reply-To: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
Message-ID: <41CD8AEA.80808@ldb-jab.org>

http://www.rpm.org/max-rpm/index.html




msilber wrote:

>Hi @ all,
>
>I need to build an own RPM package from my apache source, how can I do that? Found nothing about this in the Web!
>I know the rpmbuild command, but I can only build RPMs from src.rpms or prepared tarballs! HELP! Please!  :-?  
>
>your marcel
>
>
>  
>



From mattdm at mattdm.org  Sat Dec 25 16:21:16 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 25 Dec 2004 11:21:16 -0500
Subject: building own RPMs
In-Reply-To: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
Message-ID: <20041225162116.GA30296@jadzia.bu.edu>

On Sat, Dec 25, 2004 at 03:18:43PM +0100, msilber wrote:
> I need to build an own RPM package from my apache source, how can I do
> that? Found nothing about this in the Web! I know the rpmbuild command,
> but I can only build RPMs from src.rpms or prepared tarballs! HELP!
> Please! :-?

Start with the existing httpd source rpm, and modify that for your needs.
There isn't very good documentation, but you'll find some at
<http://www.rpm.org/>.

A few key tips: 
 
  - don't build as root -- set up the ~/rpmbuild thing instead
  - make as few changes as possible from the original RPM; this'll make
    your life easier later.
  - put your own 'tag' in the release field. For example, if the release
    of the package is '3', make yours "3msilber1", and the next version
    "3msilber2". (And don't be afraid to increment that number even when
    your changes are tiny -- you're not going to run out of integers, and
    having separately-named files is handy.)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From ejprinz at austin.rr.com  Sat Dec 25 21:23:24 2004
From: ejprinz at austin.rr.com (Erwin J. Prinz)
Date: Sat, 25 Dec 2004 15:23:24 -0600
Subject: building own RPMs
In-Reply-To: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
Message-ID: <41CDDA4C.1090709@austin.rr.com>

http://freshrpms.net/docs/fight/



From rat at mujmail.cz  Sun Dec 26 11:41:58 2004
From: rat at mujmail.cz (RAT)
Date: Sun, 26 Dec 2004 12:41:58 +0100
Subject: building own RPMs
In-Reply-To: <20041225162116.GA30296@jadzia.bu.edu>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
Message-ID: <1104061318.3487.1.camel@localhost.localdomain>

On Sat, 2004-12-25 at 11:21 -0500, Matthew Miller wrote:

> A few key tips: 
>  
>   - don't build as root -- set up the ~/rpmbuild thing instead

Why is it so? What's wrong about building rpms as root? 

>   - make as few changes as possible from the original RPM; this'll make
>     your life easier later.

Well, I think patching is nicer. Create always a patch using diff tool
and add it to a spec file. 

>   - put your own 'tag' in the release field. For example, if the release
>     of the package is '3', make yours "3msilber1", and the next version
>     "3msilber2". (And don't be afraid to increment that number even when
>     your changes are tiny -- you're not going to run out of integers, and
>     having separately-named files is handy.)
> 
> -- 
> Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
> Boston University Linux      ------>                <http://linux.bu.edu/>
> 



From mattdm at mattdm.org  Sun Dec 26 10:57:13 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 26 Dec 2004 05:57:13 -0500
Subject: building own RPMs
In-Reply-To: <1104061318.3487.1.camel@localhost.localdomain>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
Message-ID: <20041226105713.GA4403@jadzia.bu.edu>

On Sun, Dec 26, 2004 at 12:41:58PM +0100, RAT wrote:
> > A few key tips: 
> >   - don't build as root -- set up the ~/rpmbuild thing instead
> Why is it so? What's wrong about building rpms as root? 

Because as root, a mistake in your specfile could hork your whole system.


> >   - make as few changes as possible from the original RPM; this'll make
> >     your life easier later.
> Well, I think patching is nicer. Create always a patch using diff tool
> and add it to a spec file. 

Sure. That's not opposed to what I said at all.



-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From fedora at wir-sind-cool.org  Sun Dec 26 12:36:45 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sun, 26 Dec 2004 13:36:45 +0100
Subject: building own RPMs
In-Reply-To: <20041226105713.GA4403@jadzia.bu.edu>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226105713.GA4403@jadzia.bu.edu>
Message-ID: <20041226133645.418ba712.fedora@wir-sind-cool.org>

On Sun, 26 Dec 2004 05:57:13 -0500, Matthew Miller wrote:

> On Sun, Dec 26, 2004 at 12:41:58PM +0100, RAT wrote:
> > > A few key tips: 
> > >   - don't build as root -- set up the ~/rpmbuild thing instead
> > Why is it so? What's wrong about building rpms as root? 
> 
> Because as root, a mistake in your specfile could hork your whole system.

Not just a mistake in the spec file, but also mistakes or unexpected
behaviour in "configure" scripts and generated Makefiles.



From buildsys at redhat.com  Sun Dec 26 13:09:10 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 26 Dec 2004 08:09:10 -0500
Subject: rawhide report: 20041226 changes
Message-ID: <200412261309.iBQD9Aq00740@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-1:4-0.20041226
---------------------------



From symbiont at berlios.de  Sun Dec 26 14:04:54 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Sun, 26 Dec 2004 22:04:54 +0800
Subject: building own RPMs
In-Reply-To: <1104061318.3487.1.camel@localhost.localdomain>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
Message-ID: <200412262204.54307.symbiont@berlios.de>

On Sunday 26 December 2004 19:41, RAT wrote:
> > ? - don't build as root -- set up the ~/rpmbuild thing instead
>
> Why is it so? What's wrong about building rpms as root?

%clean
rm -rf $RPM_BUiLD_ROOT/

*bam* *shazam*

(though, a nice template can help prevent problems.)

-- 
-jeff



From fedora-devel at camperquake.de  Sun Dec 26 14:58:58 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Sun, 26 Dec 2004 15:58:58 +0100
Subject: building own RPMs
In-Reply-To: <1104061318.3487.1.camel@localhost.localdomain>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
Message-ID: <20041226155858.77c7a525@nausicaa.camperquake.de>

Hi.

RAT <rat at mujmail.cz> wrote:

> Why is it so? What's wrong about building rpms as root? 

Do not do things as root when a normal user will do. It will save you
from pain.

-- 
"There is more to life than increasing its speed."  -- Mahatma Gandhi



From no-reply-gw at fcp.homelinux.org  Sun Dec 26 15:36:54 2004
From: no-reply-gw at fcp.homelinux.org (=?iso-8859-1?B?bXNpbGJlcg==?=)
Date: Sun, 26 Dec 2004 16:36:54 +0100
Subject: building own RPMs
In-Reply-To: <20041226155858.77c7a525@nausicaa.camperquake.de>
Message-ID: <2d81d952edc6764d0b08d6b005963394@fcp.homelinux.org>

but latest at "make install" I need to be root, nor?
and that'll be latest the rpm getting to the %install section of spec file?! anyway, it'll go wrong! ;)

But thx so far! *studying the 2 "manuals"

Marcel


-- 
This is an email sent via the webforum on http://fcp.homelinux.org



From symbiont at berlios.de  Sun Dec 26 15:41:01 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Sun, 26 Dec 2004 23:41:01 +0800
Subject: building own RPMs
In-Reply-To: <2d81d952edc6764d0b08d6b005963394@fcp.homelinux.org>
References: <2d81d952edc6764d0b08d6b005963394@fcp.homelinux.org>
Message-ID: <200412262341.01627.symbiont@berlios.de>

On Sunday 26 December 2004 23:36, msilber wrote:
> but latest at "make install" I need to be root, nor?
> and that'll be latest the rpm getting to the %install section of spec
> file?! anyway, it'll go wrong! ;)

Nope.  $RPM_BUILD_ROOT.

-- 
-jeff



From shiva at sewingwitch.com  Sun Dec 26 18:38:53 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 26 Dec 2004 10:38:53 -0800
Subject: building own RPMs
In-Reply-To: <20041226155858.77c7a525@nausicaa.camperquake.de>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
Message-ID: <2CCC923AB0B3CCA222577A09@[10.0.0.4]>

--On Sunday, December 26, 2004 3:58 PM +0100 Ralf Ertzinger 
<fedora-devel at camperquake.de> wrote:

> Do not do things as root when a normal user will do. It will save you
> from pain.

I just entered this as a bug:

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143746>

Anyone want to take a crack at a patch against rpm.spec to implement this?




From mattdm at mattdm.org  Sun Dec 26 19:24:57 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 26 Dec 2004 14:24:57 -0500
Subject: building own RPMs
In-Reply-To: <20041226133645.418ba712.fedora@wir-sind-cool.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226105713.GA4403@jadzia.bu.edu>
	<20041226133645.418ba712.fedora@wir-sind-cool.org>
Message-ID: <20041226192457.GA16081@jadzia.bu.edu>

On Sun, Dec 26, 2004 at 01:36:45PM +0100, Michael Schwendt wrote:
> > > Why is it so? What's wrong about building rpms as root? 
> > Because as root, a mistake in your specfile could hork your whole system.
> Not just a mistake in the spec file, but also mistakes or unexpected
> behaviour in "configure" scripts and generated Makefiles.

Yeah -- "oops, that's not installing to the buildroot at all!"

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From mattdm at mattdm.org  Sun Dec 26 19:27:31 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 26 Dec 2004 14:27:31 -0500
Subject: building own RPMs
In-Reply-To: <2d81d952edc6764d0b08d6b005963394@fcp.homelinux.org>
References: <20041226155858.77c7a525@nausicaa.camperquake.de>
	<2d81d952edc6764d0b08d6b005963394@fcp.homelinux.org>
Message-ID: <20041226192731.GB16081@jadzia.bu.edu>

On Sun, Dec 26, 2004 at 04:36:54PM +0100, msilber wrote:
> but latest at "make install" I need to be root, nor?

This is *exactly* why you shouldn't be. You need to make it install into the
"buildroot" (a confusing name -- it's where the _package_ is assembled from
generated files, not where the code is built). Many modern makefiles support
this easily -- use the macro "%makeinstall" in the spec file where you would
use 'make install'. However, a lot don't, and require a bit of patching.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From kyrre at solution-forge.net  Sun Dec 26 19:25:42 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Sun, 26 Dec 2004 20:25:42 +0100
Subject: building own RPMs
In-Reply-To: <2CCC923AB0B3CCA222577A09@[10.0.0.4]>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
Message-ID: <1104089141.5592.1.camel@kyrre>

s?n, 26.12.2004 kl. 19.38 skrev Kenneth Porter:
> --On Sunday, December 26, 2004 3:58 PM +0100 Ralf Ertzinger 
> <fedora-devel at camperquake.de> wrote:
> 
> > Do not do things as root when a normal user will do. It will save you
> > from pain.
> 
> I just entered this as a bug:
> 
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143746>

Hmm... seems like a good idea. Then just get the users to su - (or
something) to buildmeister when they want to build something?

What about having rpmbuild dropping privs to buildmeister automagically
when run? So that the user doesn't have to care...



From shiva at sewingwitch.com  Sun Dec 26 19:59:58 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 26 Dec 2004 11:59:58 -0800
Subject: building own RPMs
In-Reply-To: <1104089141.5592.1.camel@kyrre>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]> <1104089141.5592.1.camel@kyrre>
Message-ID: <725CC7BABCA882656C6ED397@[10.0.0.4]>

--On Sunday, December 26, 2004 8:25 PM +0100 Kyrre Ness Sjobak 
<kyrre at solution-forge.net> wrote:

> What about having rpmbuild dropping privs to buildmeister automagically
> when run? So that the user doesn't have to care...

It would be adequate to refuse to run as root, perhaps with an override 
switch for some old kernel packages that insist on being built as root 
(because they have mknod invocations).




From fedora-devel at camperquake.de  Sun Dec 26 20:08:01 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Sun, 26 Dec 2004 21:08:01 +0100
Subject: building own RPMs
In-Reply-To: <725CC7BABCA882656C6ED397@[10.0.0.4]>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
Message-ID: <20041226210801.64808a25@nausicaa.camperquake.de>

Hi.

Kenneth Porter <shiva at sewingwitch.com> wrote:

> It would be adequate to refuse to run as root, perhaps with an override 
> switch for some old kernel packages that insist on being built as root 
> (because they have mknod invocations).

Throw in a small helper script that sets up a rpmbuild environment in the
users home dir (create some directories, add %_topdir to ~/.rpmmacros) on
request, and you're set.

-- 
"a truly cute computer would have to be upholstered, preferably in
mohair or nubuck"  -- Iain Georgeson



From fedora at wir-sind-cool.org  Sun Dec 26 20:22:32 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sun, 26 Dec 2004 21:22:32 +0100
Subject: building own RPMs
In-Reply-To: <20041226210801.64808a25@nausicaa.camperquake.de>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
Message-ID: <20041226212232.0356f911.fedora@wir-sind-cool.org>

On Sun, 26 Dec 2004 21:08:01 +0100, Ralf Ertzinger wrote:

> Hi.
> 
> Kenneth Porter <shiva at sewingwitch.xxx> wrote:
> 
> > It would be adequate to refuse to run as root, perhaps with an override 
> > switch for some old kernel packages that insist on being built as root 
> > (because they have mknod invocations).
> 
> Throw in a small helper script that sets up a rpmbuild environment in the
> users home dir (create some directories, add %_topdir to ~/.rpmmacros) on
> request, and you're set.

http://fedoraproject.org/pre-extras/3/

$ rpm -qf $(which fedora-buildrpmtree)
fedora-rpmdevtools-0.2.0-1

Ralf might enjoy reading the header of the script. ;)



From shiva at sewingwitch.com  Sun Dec 26 20:32:56 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 26 Dec 2004 12:32:56 -0800
Subject: building own RPMs
In-Reply-To: <20041226212232.0356f911.fedora@wir-sind-cool.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
Message-ID: <BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>

--On Sunday, December 26, 2004 9:22 PM +0100 Michael Schwendt 
<fedora at wir-sind-cool.org> wrote:

> http://fedoraproject.org/pre-extras/3/
>
> $ rpm -qf $(which fedora-buildrpmtree)
> fedora-rpmdevtools-0.2.0-1

Where's the SRPMS directory for that release tree? I see only i386 and
x86_64.



From fedora-devel at camperquake.de  Sun Dec 26 20:34:15 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Sun, 26 Dec 2004 21:34:15 +0100
Subject: building own RPMs
In-Reply-To: <20041226212232.0356f911.fedora@wir-sind-cool.org>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
Message-ID: <20041226213415.5f8833ff@nausicaa.camperquake.de>

Hi.

Michael Schwendt <fedora at wir-sind-cool.org> wrote:

> Ralf might enjoy reading the header of the script. ;)

Uuuhm.... I rest my case.

-- 
#!/bin/sh
unzip ; strip; touch ; finger ; mount ; gasp ; yes ; more ; umount ; sleep



From fedora at wir-sind-cool.org  Sun Dec 26 20:43:43 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sun, 26 Dec 2004 21:43:43 +0100
Subject: building own RPMs
In-Reply-To: <BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
	<BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>
Message-ID: <20041226214343.290e02ee.fedora@wir-sind-cool.org>

On Sun, 26 Dec 2004 12:32:56 -0800, Kenneth Porter wrote:

> > http://fedoraproject.org/pre-extras/3/
> >
> > $ rpm -qf $(which fedora-buildrpmtree)
> > fedora-rpmdevtools-0.2.0-1
> 
> Where's the SRPMS directory for that release tree? I see only i386 and
> x86_64.

The pre-Extras packages are built directly from CVS, so where source
access is desired, use CVS.

https://www.redhat.com/archives/fedora-announce-list/2004-December/msg00078.html



From skvidal at phy.duke.edu  Sun Dec 26 23:35:21 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 26 Dec 2004 18:35:21 -0500
Subject: building own RPMs
In-Reply-To: <BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
	<BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>
Message-ID: <1104104121.14106.0.camel@cutter>

On Sun, 2004-12-26 at 12:32 -0800, Kenneth Porter wrote:
> --On Sunday, December 26, 2004 9:22 PM +0100 Michael Schwendt 
> <fedora at wir-sind-cool.org> wrote:
> 
> > http://fedoraproject.org/pre-extras/3/
> >
> > $ rpm -qf $(which fedora-buildrpmtree)
> > fedora-rpmdevtools-0.2.0-1
> 
> Where's the SRPMS directory for that release tree? I see only i386 and
> x86_64.

SRPMS are inside the i386 and x86_64 dirs.

-sv




From fedora at wir-sind-cool.org  Mon Dec 27 00:01:33 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 27 Dec 2004 01:01:33 +0100
Subject: building own RPMs
In-Reply-To: <1104104121.14106.0.camel@cutter>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>
	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
	<BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]>
	<1104104121.14106.0.camel@cutter>
Message-ID: <20041227010133.6c46b5a4.fedora@wir-sind-cool.org>

On Sun, 26 Dec 2004 18:35:21 -0500, seth vidal wrote:

> > 
> > > http://fedoraproject.org/pre-extras/3/
> > >
> > > $ rpm -qf $(which fedora-buildrpmtree)
> > > fedora-rpmdevtools-0.2.0-1
> > 
> > Where's the SRPMS directory for that release tree? I see only i386 and
> > x86_64.
> 
> SRPMS are inside the i386 and x86_64 dirs.

D'oh! Directory is called "srpms". That explains why one needs to
scroll down a lot when browsing the index.



From arjanv at redhat.com  Mon Dec 27 09:30:07 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 27 Dec 2004 10:30:07 +0100
Subject: Compilation errors due to spin_locks
In-Reply-To: <4EE0CBA31942E547B99B3D4BFAB348112B85C4@mail.esn.co.in>
References: <4EE0CBA31942E547B99B3D4BFAB348112B85C4@mail.esn.co.in>
Message-ID: <20041227093007.GA31002@devserv.devel.redhat.com>

On Sat, Dec 25, 2004 at 11:22:59AM +0530, Srinivas G. wrote:
> > 
> > On Fri, 2004-12-24 at 17:00 +0530, Srinivas G. wrote:
> > > Dear All,
> > >
> > > I am new to this Fedora Linux. I worked on SuSE and Red Hat Linux.
> > > Now I am using Fedora Core 3 with 2.6.9-1.667 kernel version.
> > >
> > > I got a problem while compiling a module, but the same module is
> > > working under SuSE 9.1 with 2.6.5 and 2.6.6 kernel versions
> > 
> > how are you compiling the module? Can you provide an URL to the source
> > and makefile ?

you forgot to attach your sourcode



From rat at mujmail.cz  Mon Dec 27 11:32:27 2004
From: rat at mujmail.cz (RAT)
Date: Mon, 27 Dec 2004 12:32:27 +0100
Subject: building own RPMs
In-Reply-To: <200412262204.54307.symbiont@berlios.de>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<200412262204.54307.symbiont@berlios.de>
Message-ID: <1104147147.4316.34.camel@localhost.localdomain>

On Sun, 2004-12-26 at 22:04 +0800, Jeff Pitman wrote:
> 
> %clean
> rm -rf $RPM_BUiLD_ROOT

Yo, this is nice example .. 
-- 
RAT <rat at mujmail.cz>



From ville.skytta at iki.fi  Mon Dec 27 11:57:04 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Mon, 27 Dec 2004 13:57:04 +0200
Subject: SSL cert/key location (was: rawhide report: 20041217 changes)
In-Reply-To: <20041222033027.GY20813@neu.nirvana>
References: <200412171309.iBHD9Ph20939@porkchop.devel.redhat.com>
	<1103503652.5917.1.camel@localhost.localdomain>
	<87652vcs5v.fsf_-_@kosh.ultra.csn.tu-chemnitz.de>
	<20041222033027.GY20813@neu.nirvana>
Message-ID: <1104148624.26050.33.camel@bobcat.mine.nu>

On Wed, 2004-12-22 at 04:30 +0100, Axel Thimm wrote:

> /etc seems a rather sane place. Perhaps /etc/ssl/?

Or /etc/pki or /etc/x509 or /etc/security (or /var/... if that feels
better) + appropriate subdirs.

The use of all certificates and keys isn't necessarily limited to
SSL/TLS, but it could be convenient to have one base dir for all of
them.  In this scenario, "ssl" should be avoided in the base dir name.



From buildsys at redhat.com  Mon Dec 27 13:01:41 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 27 Dec 2004 08:01:41 -0500
Subject: rawhide report: 20041227 changes
Message-ID: <200412271301.iBRD1fc18489@porkchop.devel.redhat.com>

 

 
Updated Packages:

firefox-0:1.0-7
---------------
* Sat Dec 25 2004 Christopher Aillon <caillon at redhat.com> 0:1.0-7
- Make sure we get a URL passed in to firefox (#138861)
- Mark some generated files as ghost (#136015)

nedit-5.5-1
-----------
* Mon Dec 27 2004 Jindrich Novy <jnovy at redhat.com> 5.5-1
- new version 5.5

rpmdb-fedora-1:4-0.20041227
---------------------------

tetex-2.0.2-27
--------------
* Wed Dec 22 2004 Jindrich Novy <jnovy at redhat.com> 2.0.2-27
- xmas security xpdf buffer overflow fix (CAN-2004-1125)



From russell at coker.com.au  Mon Dec 27 14:00:15 2004
From: russell at coker.com.au (Russell Coker)
Date: Tue, 28 Dec 2004 01:00:15 +1100
Subject: initrc, md0, mapper
In-Reply-To: <4c4ba15304120308345888bb62@mail.gmail.com>
References: <4c4ba15304120308345888bb62@mail.gmail.com>
Message-ID: <200412280100.20007.russell@coker.com.au>

On Saturday 04 December 2004 03:34, Tom London <selinux at gmail.com> wrote:
> Running strict/enforcing, latest rawhide
> (selinux-policy-strict-1.19.10-1)
>
> Booting produces following avc:

It seems that you never got a reply to this one.

> Dec  3 08:23:45 fedora kernel: audit(1102090997.316:0): avc:  denied
> { create } for  pid=1348 exe=/sbin/nash name=md0
> scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:device_t tclass=blk_file Dec  3 08:23:45
> fedora kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised:
> dm at uk.sistina.com

This is something that still needs a good solution.  We don't want initrc_t to 
be able to do such things in the strict policy, so udev seems to be the best 
way of doing it.  Maybe getting it added to /sbin/start_udev would be the 
best solution?  start_udev already creates a bunch of other device nodes that 
are too inconvenient to do in other ways.

Of course due to the usual shell script issues udev_t isn't safe from 
initrc_t.  But it's a start at isolating it, we can improve later.

> Dec  3 08:23:45 fedora kernel: audit(1102090997.383:0): avc:  denied
> { create } for  pid=1354 exe=/sbin/nash name=mapper
> scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:device_t tclass=dir

That one should have been fixed quite some time ago, before your message was 
posted.  Either you hadn't updated to all the latest packages or there is a 
corner case we missed.  In either case let me know if it still happens with 
the latest rawhide.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From rhallyx at mindspring.com  Mon Dec 27 14:38:45 2004
From: rhallyx at mindspring.com (Richard Hally)
Date: Mon, 27 Dec 2004 09:38:45 -0500
Subject: xfce dependence problem
Message-ID: <41D01E75.4010903@mindspring.com>

Would someone please fix the dependencce problem xfce has in the 
/development tree? see below for the output from "yum update" :
this has been happening for more than a few days.
Thanks
Richard Hally


Error: missing dep: libxfce4mcs-client.so.1 for pkg xffm
Error: missing dep: libxfcegui4.so.1 for pkg xfce4-systray
Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-iconbox
Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-iconbox
Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce-utils
Error: missing dep: libxfcegui4.so.1 for pkg xfwm4
Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce-utils
Error: missing dep: libxfce4mcs-client.so.1 for pkg xfdesktop
Error: missing dep: libxfcegui4.so.1 for pkg xfprint
Error: missing dep: libxfcegui4.so.1 for pkg xffm
Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-panel
Error: missing dep: libxfcegui4.so.1 for pkg xfdesktop
Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-panel
Error: missing dep: libxfce4mcs-manager.so.1 for pkg xffm
Error: missing dep: libxfcegui4.so.1 for pkg xfce-utils
Error: missing dep: libxfcegui4.so.1 for pkg xfce4-panel
Error: missing dep: libxfcegui4.so.1 for pkg xfce4-iconbox
Error: missing dep: libxfce4mcs-client.so.1 for pkg xfwm4



From ggw at wolves.durham.nc.us  Mon Dec 27 15:46:35 2004
From: ggw at wolves.durham.nc.us (Gregory Woodbury)
Date: Mon, 27 Dec 2004 10:46:35 -0500
Subject: xfce dependence problem
In-Reply-To: <41D01E75.4010903@mindspring.com>
References: <41D01E75.4010903@mindspring.com>
Message-ID: <20041227154635.GA19499@wolves.durham.nc.us>

On Mon, Dec 27, 2004 at 09:38:45AM -0500, Richard Hally wrote:
> Would someone please fix the dependencce problem xfce has in the 
> /development tree? see below for the output from "yum update" :
> this has been happening for more than a few days.
> Thanks
> Richard Hally
> 
> 
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xffm
> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-systray
> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-iconbox
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-iconbox
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce-utils
> Error: missing dep: libxfcegui4.so.1 for pkg xfwm4
> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce-utils
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfdesktop
> Error: missing dep: libxfcegui4.so.1 for pkg xfprint
> Error: missing dep: libxfcegui4.so.1 for pkg xffm
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-panel
> Error: missing dep: libxfcegui4.so.1 for pkg xfdesktop
> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-panel
> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xffm
> Error: missing dep: libxfcegui4.so.1 for pkg xfce-utils
> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-panel
> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-iconbox
> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfwm4

I'll second that request.  I'm seeing it too.

-- 
G.Wolfe Woodbury     `- -'
RHCT                   U
The Line Eater is a boojum!



From ellson at research.att.com  Mon Dec 27 16:35:41 2004
From: ellson at research.att.com (John Ellson)
Date: Mon, 27 Dec 2004 11:35:41 -0500
Subject: xfce dependence problem
In-Reply-To: <20041227154635.GA19499@wolves.durham.nc.us>
References: <41D01E75.4010903@mindspring.com>
	<20041227154635.GA19499@wolves.durham.nc.us>
Message-ID: <41D039DD.3010705@research.att.com>

Gregory Woodbury wrote:

>On Mon, Dec 27, 2004 at 09:38:45AM -0500, Richard Hally wrote:
>  
>
>>Would someone please fix the dependencce problem xfce has in the 
>>/development tree? see below for the output from "yum update" :
>>this has been happening for more than a few days.
>>Thanks
>>Richard Hally
>>
>>
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xffm
>>Error: missing dep: libxfcegui4.so.1 for pkg xfce4-systray
>>Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-iconbox
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-iconbox
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce-utils
>>Error: missing dep: libxfcegui4.so.1 for pkg xfwm4
>>Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce-utils
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xfdesktop
>>Error: missing dep: libxfcegui4.so.1 for pkg xfprint
>>Error: missing dep: libxfcegui4.so.1 for pkg xffm
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-panel
>>Error: missing dep: libxfcegui4.so.1 for pkg xfdesktop
>>Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-panel
>>Error: missing dep: libxfce4mcs-manager.so.1 for pkg xffm
>>Error: missing dep: libxfcegui4.so.1 for pkg xfce-utils
>>Error: missing dep: libxfcegui4.so.1 for pkg xfce4-panel
>>Error: missing dep: libxfcegui4.so.1 for pkg xfce4-iconbox
>>Error: missing dep: libxfce4mcs-client.so.1 for pkg xfwm4
>>    
>>
>
>I'll second that request.  I'm seeing it too.
>
>  
>
The problem is real, but you can work around it by parallel installing 
old versions
of libxfce4mcs and libxfcegui4:

    rpm -ivh --oldpackage libxfce4mcs-4.0.6-1.i386.rpm 
libxfcegui4-4.0.6-1.i386.rpm

These can be obtained from:

    
ftp://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/

John Ellson




From russell at coker.com.au  Mon Dec 27 17:01:52 2004
From: russell at coker.com.au (Russell Coker)
Date: Tue, 28 Dec 2004 04:01:52 +1100
Subject: Me stupid: lost password for gpg
In-Reply-To: <1103231996.4704.7.camel@tuxpaq>
References: <41C1EEDE.1080202@hhs.nl> <1103231996.4704.7.camel@tuxpaq>
Message-ID: <200412280401.56485.russell@coker.com.au>

On Friday 17 December 2004 08:19, Paul Iadonisi <pri.rhl3 at iadonisi.to> wrote:
>   Maybe the new dual Opteron box I just ordered can crack the passwords
> for both our keys. ;-)

I wrote a program to crack keys with a hacked version of gpg (at the point in 
the code where it asks for the pass-phrase my code inserted a loop to go 
through the passwords).  It's ugly but with the recent versions of gpg it 
works reasonably well (I discovered a memory leak whereby gpg would lose a 
couple of hundred bytes every attempt at a pass-phrase).

The program could try over 600 combinations a second on a 2-3yo Athlon giving 
almost 5 digits tested per day if you only use lower-case and digits.  This 
means that a pass-phrase of 6 characters comprising lower-case and digits 
could be reliably cracked in just over a month.  7 characters could be done 
in 3 years with an old Athlon or maybe some reasonable amount of time in a 
dual-Opteron.  8 or more characters would require a large network of 
machines.

Let me know if you want a copy of my code, but be warned, it's really ugly.  
Also it might be possible to optimise things and maybe double the speed if 
you can figure out GPG memory management (I can't).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From kyrre at solution-forge.net  Mon Dec 27 18:41:29 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Mon, 27 Dec 2004 19:41:29 +0100
Subject: building own RPMs
In-Reply-To: <1104104121.14106.0.camel@cutter>
References: <8870d40d81d7c66f05f9311fb364be03@fcp.homelinux.org>
	<20041225162116.GA30296@jadzia.bu.edu>
	<1104061318.3487.1.camel@localhost.localdomain>
	<20041226155858.77c7a525@nausicaa.camperquake.de>
	<2CCC923AB0B3CCA222577A09@[10.0.0.4]>	<1104089141.5592.1.camel@kyrre>
	<725CC7BABCA882656C6ED397@[10.0.0.4]>
	<20041226210801.64808a25@nausicaa.camperquake.de>
	<20041226212232.0356f911.fedora@wir-sind-cool.org>
	<BEFFDFBD0DC080D133A5EA0E@[10.0.0.4]> <1104104121.14106.0.camel@cutter>
Message-ID: <1104172889.2718.27.camel@kyrre>

man, 27.12.2004 kl. 00.35 skrev seth vidal:
> On Sun, 2004-12-26 at 12:32 -0800, Kenneth Porter wrote:
> > --On Sunday, December 26, 2004 9:22 PM +0100 Michael Schwendt 
> > <fedora at wir-sind-cool.org> wrote:
> > 
> > > http://fedoraproject.org/pre-extras/3/
> > >
> > > $ rpm -qf $(which fedora-buildrpmtree)
> > > fedora-rpmdevtools-0.2.0-1
> > 
> > Where's the SRPMS directory for that release tree? I see only i386 and
> > x86_64.
> 
> SRPMS are inside the i386 and x86_64 dirs.

hrr? Are they different? (spec's?)



From selinux at gmail.com  Mon Dec 27 20:54:42 2004
From: selinux at gmail.com (Tom London)
Date: Mon, 27 Dec 2004 12:54:42 -0800
Subject: initrc, md0, mapper
In-Reply-To: <200412280100.20007.russell@coker.com.au>
References: <4c4ba15304120308345888bb62@mail.gmail.com>
	<200412280100.20007.russell@coker.com.au>
Message-ID: <4c4ba1530412271254104b3f01@mail.gmail.com>

On Tue, 28 Dec 2004 01:00:15 +1100, Russell Coker <russell at coker.com.au> wrote:
> On Saturday 04 December 2004 03:34, Tom London <selinux at gmail.com> wrote:
> > Booting produces following avc:
> 
> It seems that you never got a reply to this one.
> 
> > Dec  3 08:23:45 fedora kernel: audit(1102090997.316:0): avc:  denied
> > { create } for  pid=1348 exe=/sbin/nash name=md0
> > scontext=system_u:system_r:initrc_t
> > tcontext=system_u:object_r:device_t tclass=blk_file Dec  3 08:23:45
> > fedora kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised:
> > dm at uk.sistina.com
> 
> This is something that still needs a good solution.  We don't want initrc_t to
> be able to do such things in the strict policy, so udev seems to be the best
> way of doing it.  Maybe getting it added to /sbin/start_udev would be the
> best solution?  start_udev already creates a bunch of other device nodes that
> are too inconvenient to do in other ways.
> 
> Of course due to the usual shell script issues udev_t isn't safe from
> initrc_t.  But it's a start at isolating it, we can improve later.
> 
> > Dec  3 08:23:45 fedora kernel: audit(1102090997.383:0): avc:  denied
> > { create } for  pid=1354 exe=/sbin/nash name=mapper
> > scontext=system_u:system_r:initrc_t
> > tcontext=system_u:object_r:device_t tclass=dir
> 
> That one should have been fixed quite some time ago, before your message was
> posted.  Either you hadn't updated to all the latest packages or there is a
> corner case we missed.  In either case let me know if it still happens with
> the latest rawhide.
> 
> --
Russell, 

This one also has been fixed.  Don't remember exactly when....

tom
-- 
Tom London



From rhally at mindspring.com  Mon Dec 27 21:02:31 2004
From: rhally at mindspring.com (Richard Hally)
Date: Mon, 27 Dec 2004 16:02:31 -0500
Subject: xfce dependence problem
In-Reply-To: <41D039DD.3010705@research.att.com>
References: <41D01E75.4010903@mindspring.com>	<20041227154635.GA19499@wolves.durham.nc.us>
	<41D039DD.3010705@research.att.com>
Message-ID: <41D07867.6010004@mindspring.com>

John Ellson wrote:

> Gregory Woodbury wrote:
>
>> On Mon, Dec 27, 2004 at 09:38:45AM -0500, Richard Hally wrote:
>>  
>>
>>> Would someone please fix the dependencce problem xfce has in the 
>>> /development tree? see below for the output from "yum update" :
>>> this has been happening for more than a few days.
>>> Thanks
>>> Richard Hally
>>>
>>>
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xffm
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-systray
>>> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-iconbox
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-iconbox
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce-utils
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfwm4
>>> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce-utils
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfdesktop
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfprint
>>> Error: missing dep: libxfcegui4.so.1 for pkg xffm
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfce4-panel
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfdesktop
>>> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xfce4-panel
>>> Error: missing dep: libxfce4mcs-manager.so.1 for pkg xffm
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfce-utils
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-panel
>>> Error: missing dep: libxfcegui4.so.1 for pkg xfce4-iconbox
>>> Error: missing dep: libxfce4mcs-client.so.1 for pkg xfwm4
>>>   
>>
>>
>> I'll second that request.  I'm seeing it too.
>>
>>  
>>
> The problem is real, but you can work around it by parallel installing 
> old versions
> of libxfce4mcs and libxfcegui4:
>
>    rpm -ivh --oldpackage libxfce4mcs-4.0.6-1.i386.rpm 
> libxfcegui4-4.0.6-1.i386.rpm
>
>
Sorry, those two libraries are at that version (4.0.6-1) currently. Are 
you suggesting that we parallel install the newer versions (4.1.99.1-1) 
of those libraries?
Richard Hally




From ellson at research.att.com  Mon Dec 27 22:28:12 2004
From: ellson at research.att.com (John Ellson)
Date: Mon, 27 Dec 2004 17:28:12 -0500
Subject: xfce dependence problem
In-Reply-To: <41D07867.6010004@mindspring.com>
References: <41D01E75.4010903@mindspring.com>	<20041227154635.GA19499@wolves.durham.nc.us>	<41D039DD.3010705@research.att.com>
	<41D07867.6010004@mindspring.com>
Message-ID: <41D08C7C.3040103@research.att.com>

Richard Hally wrote:

>
>>>
>> The problem is real, but you can work around it by parallel 
>> installing old versions
>> of libxfce4mcs and libxfcegui4:
>>
>>    rpm -ivh --oldpackage libxfce4mcs-4.0.6-1.i386.rpm 
>> libxfcegui4-4.0.6-1.i386.rpm
>>
>>
> Sorry, those two libraries are at that version (4.0.6-1) currently. 
> Are you suggesting that we parallel install the newer versions 
> (4.1.99.1-1) of those libraries?
> Richard Hally
>
>
Yes.  In which case your won't need --oldpackage.

John



From rhally at mindspring.com  Tue Dec 28 02:07:13 2004
From: rhally at mindspring.com (Richard Hally)
Date: Mon, 27 Dec 2004 21:07:13 -0500
Subject: xfce dependence problem
In-Reply-To: <41D08C7C.3040103@research.att.com>
References: <41D01E75.4010903@mindspring.com>	<20041227154635.GA19499@wolves.durham.nc.us>	<41D039DD.3010705@research.att.com>	<41D07867.6010004@mindspring.com>
	<41D08C7C.3040103@research.att.com>
Message-ID: <41D0BFD1.60505@mindspring.com>

John Ellson wrote:

> Richard Hally wrote:
>
>>
>>>>
>>> The problem is real, but you can work around it by parallel 
>>> installing old versions
>>> of libxfce4mcs and libxfcegui4:
>>>
>>>    rpm -ivh --oldpackage libxfce4mcs-4.0.6-1.i386.rpm 
>>> libxfcegui4-4.0.6-1.i386.rpm
>>>
>>>
>> Sorry, those two libraries are at that version (4.0.6-1) currently. 
>> Are you suggesting that we parallel install the newer versions 
>> (4.1.99.1-1) of those libraries?
>> Richard Hally
>>
>>
> Yes.  In which case your won't need --oldpackage.
>
> John
>
Nope, that doesn't work either. I'm getting conflicts trying to install 
the new libraries as well. I'll just wait patiently for the packagers to 
straighten this one out. Thanks for trying.
Richard Hally 



From dennis at ausil.us  Tue Dec 28 04:30:44 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Mon, 27 Dec 2004 22:30:44 -0600
Subject: Kolab server
Message-ID: <200412272230.49399.dennis@ausil.us>

Hi All,

Ive done some work on the mandrake rpms for kolab.  and nearly have them ready 
to release to the world.  Just wanted to ask if i should bundle in the 
configuration for amavis-new and clamav  so that someone installing kolab  
would have a working mailserver with spam and antivirus scanning out of the 
box.

and if i should replace /etc/sysconfig/saslauthd   as it needs modification.   
my thinking was this   the way kolab runs it keeps the config files 
in /etc/kolab  and runs some macros over them on service start.  and if 
theres changes  put the new config in place. i should just add a template for 
the saslauthd file

i still need to switch over the ftp deamon from proftpd  to vsftpd and tidy up 
some config files but right now after making one chnage to the kolab.schema 
file enabling ldap for sasl authentication   and 
running  /usr/sbin/kolab_bootstrap -b   the kolab server works 


i dont know if the ftp deamon is really necessary as it is only used for 
legacy clients.  but i should do it so kolab is feature complete.


So why will gnome users want kolab.  well at the least it provides an easy way 
to configure cyrus-imapd and get a working setup with ldap authentication  
and kde users will be able to easily setup kontact to run with it.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041227/3da5a037/attachment.sig>

From ramachandran_iyer at sifycorp.com  Tue Dec 28 07:12:08 2004
From: ramachandran_iyer at sifycorp.com (ram)
Date: Tue, 28 Dec 2004 12:42:08 +0530
Subject: reg getch() function
Message-ID: <200412281242.08482.ramachandran_iyer@sifycorp.com>


 Can anyone tell me how to write a getch fucntion using the GETATTR and 
SETATTR  commands.The functions should be like " when we click the button the 
key board should display the button pressed.THis can be done but what about 
the escape sequence buttons like uparrow and down arrow.

-- 
warm regards
Ram
DISCLAIMER:
Information contained and transmitted by this E-MAIL is proprietary to 
Sify Limited and is intended for use only by the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If this is a 
forwarded message, the content of this E-MAIL may not have been sent with 
the authority of the Company. If you are not the intended recipient, an 
agent of the intended recipient or a  person responsible for delivering the 
information to the named recipient,  you are notified that any use, 
distribution, transmission, printing, copying or dissemination of this 
information in any way or in any manner is strictly prohibited. If you have 
received this communication in error, please delete this mail & notify us 
immediately at admin at sifycorp.com



From symbiont at berlios.de  Tue Dec 28 07:27:47 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Tue, 28 Dec 2004 15:27:47 +0800
Subject: reg getch() function
In-Reply-To: <200412281242.08482.ramachandran_iyer@sifycorp.com>
References: <200412281242.08482.ramachandran_iyer@sifycorp.com>
Message-ID: <200412281527.48401.symbiont@berlios.de>

On Tuesday 28 December 2004 15:12, ram wrote:
> Can anyone tell me how to write a getch fucntion using the GETATTR
> and SETATTR ?commands.The functions should be like " when we click
> the button the key board should display the button pressed.THis can
> be done but what about the escape sequence buttons like uparrow and
> down arrow.

This is the wrong list for this question, I'm pretty sure. But, just for 
fun, I'm including code that answers your question. The up and down 
arrows are shown by a sequence of ascii chars ^[[A ^[[B, etc. etc.

have fun,
-- 
-jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keys.c
Type: text/x-csrc
Size: 822 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041228/34824270/attachment.bin>

From j.w.r.degoede at hhs.nl  Tue Dec 28 08:25:02 2004
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 28 Dec 2004 09:25:02 +0100
Subject: Me stupid: lost password for gpg
In-Reply-To: <200412280401.56485.russell@coker.com.au>
References: <41C1EEDE.1080202@hhs.nl> <1103231996.4704.7.camel@tuxpaq>
	<200412280401.56485.russell@coker.com.au>
Message-ID: <41D1185E.7000106@hhs.nl>



Russell Coker wrote:
> On Friday 17 December 2004 08:19, Paul Iadonisi <pri.rhl3 at iadonisi.to> wrote:
> 
>>  Maybe the new dual Opteron box I just ordered can crack the passwords
>>for both our keys. ;-)
> 
> 
> I wrote a program to crack keys with a hacked version of gpg (at the point in 
> the code where it asks for the pass-phrase my code inserted a loop to go 
> through the passwords).  It's ugly but with the recent versions of gpg it 
> works reasonably well (I discovered a memory leak whereby gpg would lose a 
> couple of hundred bytes every attempt at a pass-phrase).
> 
> The program could try over 600 combinations a second on a 2-3yo Athlon giving 
> almost 5 digits tested per day if you only use lower-case and digits.  This 
> means that a pass-phrase of 6 characters comprising lower-case and digits 
> could be reliably cracked in just over a month.  7 characters could be done 
> in 3 years with an old Athlon or maybe some reasonable amount of time in a 
> dual-Opteron.  8 or more characters would require a large network of 
> machines.
> 
> Let me know if you want a copy of my code, but be warned, it's really ugly.  
> Also it might be possible to optimise things and maybe double the speed if 
> you can figure out GPG memory management (I can't).
> 

1) Thanks, but I finally remembered my password
2) This is worry some, so a passphrase really should be 8 chars minimal?

Regards,

Hans



From avibrazil at gmail.com  Tue Dec 28 11:50:29 2004
From: avibrazil at gmail.com (Avi Alkalay)
Date: Tue, 28 Dec 2004 08:50:29 -0300
Subject: New unified and updated Linux Font HOWTO
Message-ID: <ed0efd3104122803501906e91@mail.gmail.com>

http://tldp.org/HOWTO/Font-HOWTO



Table of Contents
1. Introduction
2. Why Fonts on Linux Aren't Straight Forward ?
3. Font Packages

    3.1. Bitstream Vera Fonts
    3.2. Microsoft Fonts

4. The Easy Steps to Enlighten Your Desktop

    4.1. Get a Better FreeType RPM
    4.2. Configure Your Desktop

5. Producing Portable Documents

    5.1. Linux to Windows and vice-versa
    5.2. Linux to Linux
    5.3. Any to Any with OpenOffice.org and Bitstream Vera Fonts
    5.4. A Very Small Guide of Style

6. Create RPMs of Your Fonts

    6.1. Step 1: Prepare Your Environment to Build The Package
    6.2. Step 2: Prepare the Fonts Files to Package
    6.3. Step 3: Create a .spec File With This Template
    6.4. Step 4: Build It

7. Designer's Guide for Modern Good Looking Documents

    7.1. Families of Typefaces
    7.2. Classifications of Typefaces
    7.3. Ligatures, Small caps fonts and expert fonts
    7.4. Font Metrics and Shapes

8. Font Technologies

    8.1. Bitmap Fonts
    8.2. TrueType Fonts
    8.3. Type 1 Fonts
    8.4. Type3 Fonts
    8.5. Type 42 Fonts
    8.6. Type 1 vs TrueType -- a comparison

9. Getting Fonts For Linux

    9.1. True Type
    9.2. Type 1 Fonts and Metafont

10. Useful Font Software for Linux
11. Ethics and Licensing Issues Related to Type
12. References

    12.1. Font Information
    12.2. Postscript and Printing Information

13. Glossary
A. Enabling Bytecode Interpreter in FreeType
B. We Need Your Help
C. About this Document



From d.lesca at solinos.it  Tue Dec 28 12:31:34 2004
From: d.lesca at solinos.it (Dario Lesca)
Date: Tue, 28 Dec 2004 13:31:34 +0100
Subject: FC3: install: Howto generate a new dvd tree with recent update?
Message-ID: <1104237093.2479.78.camel@lesca.home.solinos.it>

Another question:

What is the correct option fo /usr/lib/anaconda-runtime/buildinstall for
rebuild a fc3 tree ?

I have use this:
/usr/lib/anaconda-runtime/buildinstall \
        --comp dist-9 --pkgorder /u/fc3/pkgorder.txt \
        --product 'Fedora Core 3.b' --release 3 --version b \
        --prodpath Fedora /u/fc3

but I got this error:
> Getting pango modules
> /usr/sbin/chroot: cannot execute /usr/bin/pango-querymodules: No such
> file or directory
> 
> I've confirmed that pango-querymodules exists in the instimage
> and bash does as well.

there are a howto or doc for this procedure?

Many thanks
Dario Lesca

-----Messaggio Inoltrato-----
From: Dario Lesca <d.lesca at solinos.it>
To: fedora-list at redhat.com
Subject: FC3: install: Howto generate a dvd whit recent update?
Date: Sat, 25 Dec 2004 20:34:12 +0100


I have fount this howto for FC1:

http://www.coolgoose.com/sites/lal_tvm/anaconda.html

But some files (es.: getfullcomps.py) not there are into package for FC3...

I want only update the Fedora/RPMS dir, after I run the command
/usr/lib/anaconda-runtime/genhdlist for rebuild base/hdlist* and check the
new structure via nfs setup .... but somethink is wrong ... when the
anaconda check the package dependencies exit and stop the installation.

Someone can point me on right way?

Many thanks and sorry for my bad english

d.l.
-- 
Dario Lesca <d.lesca at solinos.it>



From buildsys at redhat.com  Tue Dec 28 12:34:08 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 28 Dec 2004 07:34:08 -0500
Subject: rawhide report: 20041228 changes
Message-ID: <200412281234.iBSCY8Q05475@porkchop.devel.redhat.com>

 

 
Updated Packages:

coreutils-5.2.1-35
------------------
* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 5.2.1-35
- Change install to restorecon if it can

* Wed Dec 15 2004 Tim Waugh <twaugh at redhat.com>
- Fixed small bug in i18n patch.

libselinux-1.19.3-2
-------------------
* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 1.19.3-2
- Fix unitialized variable in avcstat.c

net-snmp-5.2-2
--------------
* Mon Dec 27 2004 Radek Vokal <rvokal at redhat.com> 5.2-2
- patch adding ipv6 support to ip system stats

rpmdb-fedora-1:4-0.20041228
---------------------------

selinux-policy-strict-1.19.15-9
-------------------------------
* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-9
- Try to fix certain scripts to not transition to initrc_t
	* sendmail, sshd, prefdm, crond

* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-8
- Add Russell patches to udev, modutil

selinux-policy-targeted-1.19.15-9
---------------------------------
* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-9
- Try to fix certain scripts to not transition to initrc_t
	* sendmail, sshd, prefdm, crond

* Mon Dec 27 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-8
- Add Russell patches to udev, modutil

slrn-0.9.8.1-3
--------------
* Mon Dec 27 2004 Jindrich Novy <jnovy at redhat.com> 0.9.8.1-3
- package contrib subdir because of slrn-conv script (#73451)
- slrnpull.conf is now %config(noreplace), original config
  won't be overwritten (#56001)
- include slrnpull man page



From ee21rh at surrey.ac.uk  Tue Dec 28 13:12:32 2004
From: ee21rh at surrey.ac.uk (ee21rh)
Date: Tue, 28 Dec 2004 13:12:32 -0000
Subject: First packaging attempt : atmel-firmware
Message-ID: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>

I have made a simple package that I think would be suitable for 
fedora-extras/pre-extras - but I would like some feedback frrom the list.

The spec file is located at 
http://hughsie.no-ip.com/linux/atmel-firmware/atmel-firmware.spec
 - I have based this on the existing firmware packages from dag, and a 
couple of spec files for fedora that I found. 

Notes about the package: I've not included the firmware loader (atmel_fwl)
 - as this would force me to create i386 packages and the like, but by 
packaging the firmware alone, the package can be a noarch. I've not needed
 to use the firmware loader once in all my testing, hotplug works just fine.

By installing the rpm, my belkin 802.11b wireless card works first time, 
loading the firmware from /lib/firmware 

The firmware is freely re-distributable (see COPYING)

Simon Kelley http://www.thekelleys.org.uk/atmel (original packager) has no 
problems with a fedora rpm, as debian and slackware already package the 
firmware themselves.

Comments?

Richard Hughes

url: http://hughsie.no-ip.com/linux/atmel-firmware/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041228/ec2e993d/attachment.htm>

From symbiont at berlios.de  Tue Dec 28 13:42:39 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Tue, 28 Dec 2004 21:42:39 +0800
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
Message-ID: <200412282142.40111.symbiont@berlios.de>

On Tuesday 28 December 2004 21:12, ee21rh wrote:
> Comments?

Now we need a kernel-module-at76c503a-2.6.9 package that deps on this 
one.  Know any floating around? I've got a at76c503a-based Corega USB 
wireless that I can run tests on including firmware upload via hotplug, 
etc.

take care,
-- 
-jeff



From rms at 1407.org  Tue Dec 28 15:33:38 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 28 Dec 2004 15:33:38 +0000
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <200412282142.40111.symbiont@berlios.de>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<200412282142.40111.symbiont@berlios.de>
Message-ID: <1104248018.3071.25.camel@roque>

On Tue, 2004-12-28 at 21:42 +0800, Jeff Pitman wrote:
> On Tuesday 28 December 2004 21:12, ee21rh wrote:
> > Comments?
> 
> Now we need a kernel-module-at76c503a-2.6.9 package that deps on this 
> one.  Know any floating around? I've got a at76c503a-based Corega USB 
> wireless that I can run tests on including firmware upload via hotplug, 
> etc.

I'm using it from berlios:

http://at76c503a.berlios.de/

For my wifi usb device I needed to get the CVS version, but the dang
thing still requires root to compile (I have to fix that before
submitting this spec).

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041228/f4be6d2f/attachment.sig>

From symbiont at berlios.de  Tue Dec 28 16:08:29 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 29 Dec 2004 00:08:29 +0800
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <1104248018.3071.25.camel@roque>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<200412282142.40111.symbiont@berlios.de>
	<1104248018.3071.25.camel@roque>
Message-ID: <200412290008.29365.symbiont@berlios.de>

On Tuesday 28 December 2004 23:33, Rui Miguel Seabra wrote:
> I'm using it from berlios:
>
> http://at76c503a.berlios.de/
>
> For my wifi usb device I needed to get the CVS version, but the dang
> thing still requires root to compile (I have to fix that before
> submitting this spec).

Yep, I've got a local compile from CVS too (Corega is only in CVS).  
Let's hope they cut a release soon and I hope to see a kernel-module 
rpm come out of it.

take care,
-- 
-jeff



From Peter.Dedecker at vtk2.UGent.be  Tue Dec 28 18:58:41 2004
From: Peter.Dedecker at vtk2.UGent.be (Peter Dedecker - FSU)
Date: Tue, 28 Dec 2004 18:58:41 +0000
Subject: stateless linux project status
Message-ID: <41D1ACE1.6000408@VTK.UGent.be>

Havoc Pennington wrote:
> On Wed, 2004-12-22 at 17:00 +0000, Peter Schobel wrote:
>> I have seen next to nothing on this list recently from stateless linux
>> developers
>> 
>> What is the status of this project? Is it in active development?
>> 
> 
> It isn't in active development right now; the initial release was a
> prototype to gather data on what people thought of the idea.
> 
> Now we are looking at the feedback and looking at overall Red Hat
> priorities and have to decide whether to create a project team to
> continue with stateless Linux (and related technology). If we do decide
> to continue then there will probably be a number of people working on
> it.

Do you know when you will take the decision?  We really like the project 
and its goals and we hope it will continu very soon.

-- 
Peter Dedecker
The Fedora Stateless @ UGent project
http://blog.eikke.com/index.php/fedorastateless



From pp at ee.oulu.fi  Tue Dec 28 18:00:05 2004
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Tue, 28 Dec 2004 20:00:05 +0200
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <200412282142.40111.symbiont@berlios.de>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<200412282142.40111.symbiont@berlios.de>
Message-ID: <20041228180004.GA11001@ee.oulu.fi>

On Tue, Dec 28, 2004 at 09:42:39PM +0800, Jeff Pitman wrote:
> On Tuesday 28 December 2004 21:12, ee21rh wrote:
> > Comments?
> 
> Now we need a kernel-module-at76c503a-2.6.9 package that deps on this 
> one.  Know any floating around? I've got a at76c503a-based Corega USB 
> wireless that I can run tests on including firmware upload via hotplug, 
> etc.
Oh, which reminds me. If someone does a package like that and the firmware
has redistribution problems I think it's almost best if there are no
dependancies between the packages. Well, it's really a balance between

1) User is told to add repo X and "yum install kernel-module-foo" which
doesn't work since he's missing a dependancy, then has to grab a .nosrc.rpm
(or spec file), build a rpm, install it and try again. He's probably given
up already after step #1

2) User gets driver installed but it doesn't work and he has no idea that a
firmware file is needed as well. Since he doesn't watch his dmesg/syslog he
never finds out either. If he does, he can grab the firmware straight from
the net or in .src.rpm/.nosrc.rpm or .noarch.rpm form.

There's already quite a few in-kernel drivers that need a firmware file to
work and the kernel doesn't have dependancies for those, so #2 would fit 
that policy (or lack of one :-) )

Or maybe we just need a fedora-firmwares.org/fedora-binary-only-blobs.org yum
repo located in a suitable country ;)

Then there's the userland stuff requiring kernel-module-xxx stuff (nvidia ;) )
which I've also found to cause some annoyances. I just nuke the dependancy
in my own builds of the thing :-) 

-- 
Pekka Pietikainen



From ee21rh at surrey.ac.uk  Tue Dec 28 18:22:48 2004
From: ee21rh at surrey.ac.uk (Richard Hughes)
Date: Tue, 28 Dec 2004 18:22:48 +0000
Subject: First packaging attempt : atmel-firmware
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<200412282142.40111.symbiont@berlios.de>
Message-ID: <pan.2004.12.28.18.22.44.766871@surrey.ac.uk>

But I'm not using the at76c5xxx drivers! I'm using the in-kernel
atmel_cs driver. If I insert my card on a fresh install, I get the message
in dmesg: "Unable to load firmware". By installing the rpm, and supplying
the firmware for hotplug to load (by installing the rpm), nothing more has
to be done. 

Richard Hughes

On Tue, 28 Dec 2004 21:42:39 +0800, Jeff Pitman wrote:

> On Tuesday 28 December 2004 21:12, ee21rh wrote:
>> Comments?
> 
> Now we need a kernel-module-at76c503a-2.6.9 package that deps on this 
> one.  Know any floating around? I've got a at76c503a-based Corega USB 
> wireless that I can run tests on including firmware upload via hotplug, 
> etc.
> 
> take care,
> -- 
> -jeff




From russell at coker.com.au  Tue Dec 28 19:58:48 2004
From: russell at coker.com.au (Russell Coker)
Date: Wed, 29 Dec 2004 06:58:48 +1100
Subject: Me stupid: lost password for gpg
In-Reply-To: <41D1185E.7000106@hhs.nl>
References: <41C1EEDE.1080202@hhs.nl> <200412280401.56485.russell@coker.com.au>
	<41D1185E.7000106@hhs.nl>
Message-ID: <200412290658.52027.russell@coker.com.au>

On Tuesday 28 December 2004 19:25, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> > The program could try over 600 combinations a second on a 2-3yo Athlon
> > giving almost 5 digits tested per day if you only use lower-case and
> > digits.  This means that a pass-phrase of 6 characters comprising
> > lower-case and digits could be reliably cracked in just over a month.  7
> > characters could be done in 3 years with an old Athlon or maybe some
> > reasonable amount of time in a dual-Opteron.  8 or more characters would
> > require a large network of machines.
> >
> > Let me know if you want a copy of my code, but be warned, it's really
> > ugly. Also it might be possible to optimise things and maybe double the
> > speed if you can figure out GPG memory management (I can't).
>
> 1) Thanks, but I finally remembered my password
> 2) This is worry some, so a passphrase really should be 8 chars minimal?

Given that anyone can crack 6 characters, 7 characters could be cracked easily 
by hardware that will be cheap in a few years, and 8 can be easily cracked 
with a network of machines I think that you need at least 10 characters for 
the pass-phrase to be worth much.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From shiva at sewingwitch.com  Tue Dec 28 21:22:43 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 28 Dec 2004 13:22:43 -0800
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.
	uk>
Message-ID: <E12A2976489E75193F44DBBE@[10.0.0.4]>

Please change the package name. Atmel is a supplier of lots of different 
things, notably programmable logic of all kinds. When I saw the thread 
subject, I thought this might be a package for programming those. 
"atmel-firmware" is way too generic for what it does.

I'd recommend at76c50x-firmware, instead.



From pbruna at linuxcenterla.com  Tue Dec 28 22:06:00 2004
From: pbruna at linuxcenterla.com (Patricio Bruna V)
Date: Tue, 28 Dec 2004 19:06:00 -0300
Subject: apt question
Message-ID: <1104271560.2898.2.camel@p.linuxcenter.cl>

will be apt include in any version of fedora?
and if so, there will be metapackages?
-- 
Patricio Bruna                                  http://www.linuxcenterla.com
Ingeniero de Proyectos                  Mariano S?nchez Fontecilla 310, piso 2
Red Hat Certified Engineer              Las Condes, Santiago - CHILE
Linux Center Latinoamerica              Fono: +56 2 2745000, Fax : +56 22747075
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041228/6ef3c044/attachment.sig>

From alan at redhat.com  Tue Dec 28 22:46:31 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Dec 2004 17:46:31 -0500
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <E12A2976489E75193F44DBBE@[10.0.0.4]>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<E12A2976489E75193F44DBBE@[10.0.0.4]>
Message-ID: <20041228224631.GB11314@devserv.devel.redhat.com>

On Tue, Dec 28, 2004 at 01:22:43PM -0800, Kenneth Porter wrote:
> I'd recommend at76c50x-firmware, instead.

If you are only included the pcmcia/cf firmware in the package make it
explicitly at76c50x-pcmcia-firmware as there are USB ones that need firmware
sets too and I'm under the impression the firmware is different



From Atchley.Van at inventec.com  Tue Dec 28 22:52:09 2004
From: Atchley.Van at inventec.com (Atchley.Van at inventec.com)
Date: Tue, 28 Dec 2004 16:52:09 -0600
Subject: First packaging attempt : atmel-firmware
Message-ID: <522542BB9F49DC448A94F871EA58DCA51A5625@ihs-mx01.iec.inventec>

Is this about my installation problem? If so it's an internal 1,600 Gig
HDD. I am have 6 300Gig HDDs grouped together using HPs Smart Array card

-----Original Message-----
From: Alan Cox [mailto:alan at redhat.com] 
Sent: Tuesday, December 28, 2004 4:47 PM
To: Development discussions related to Fedora Core
Subject: Re: First packaging attempt : atmel-firmware

On Tue, Dec 28, 2004 at 01:22:43PM -0800, Kenneth Porter wrote:
> I'd recommend at76c50x-firmware, instead.

If you are only included the pcmcia/cf firmware in the package make it
explicitly at76c50x-pcmcia-firmware as there are USB ones that need
firmware
sets too and I'm under the impression the firmware is different

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list



From kyrre at solution-forge.net  Tue Dec 28 22:58:31 2004
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 28 Dec 2004 23:58:31 +0100
Subject: Me stupid: lost password for gpg
In-Reply-To: <200412280401.56485.russell@coker.com.au>
References: <41C1EEDE.1080202@hhs.nl> <1103231996.4704.7.camel@tuxpaq>
	<200412280401.56485.russell@coker.com.au>
Message-ID: <1104272147.4994.6.camel@kyrre>

man, 27.12.2004 kl. 18.01 skrev Russell Coker:
> On Friday 17 December 2004 08:19, Paul Iadonisi <pri.rhl3 at iadonisi.to> wrote:
> >   Maybe the new dual Opteron box I just ordered can crack the passwords
> > for both our keys. ;-)
> 
> I wrote a program to crack keys with a hacked version of gpg (at the point in 
> the code where it asks for the pass-phrase my code inserted a loop to go 
> through the passwords).  It's ugly but with the recent versions of gpg it 
> works reasonably well (I discovered a memory leak whereby gpg would lose a 
> couple of hundred bytes every attempt at a pass-phrase).
> 

What if it tried a dictionary first?

> The program could try over 600 combinations a second on a 2-3yo Athlon giving 
> almost 5 digits tested per day if you only use lower-case and digits.  This 
> means that a pass-phrase of 6 characters comprising lower-case and digits 
> could be reliably cracked in just over a month.  7 characters could be done 
> in 3 years with an old Athlon or maybe some reasonable amount of time in a 
> dual-Opteron.  8 or more characters would require a large network of 
> machines.
> 
> Let me know if you want a copy of my code, but be warned, it's really ugly.  
> Also it might be possible to optimise things and maybe double the speed if 
> you can figure out GPG memory management (I can't).
> 
> -- 
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page



From ee21rh at surrey.ac.uk  Tue Dec 28 23:25:17 2004
From: ee21rh at surrey.ac.uk (Richard Hughes)
Date: Tue, 28 Dec 2004 23:25:17 +0000
Subject: First packaging attempt : atmel-firmware
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.	uk>
	<E12A2976489E75193F44DBBE@[10.0.0.4]>
Message-ID: <pan.2004.12.28.23.25.16.157902@surrey.ac.uk>

But the kernel module that uses the firmware is called atmel_cs. Would
atmel_cs-firmware be a better name?

Richard Hughes

On Tue, 28 Dec 2004 13:22:43 -0800, Kenneth Porter wrote:

> Please change the package name. Atmel is a supplier of lots of different 
> things, notably programmable logic of all kinds. When I saw the thread 
> subject, I thought this might be a package for programming those. 
> "atmel-firmware" is way too generic for what it does.
> 
> I'd recommend at76c50x-firmware, instead.




From ee21rh at surrey.ac.uk  Tue Dec 28 23:34:34 2004
From: ee21rh at surrey.ac.uk (Richard Hughes)
Date: Tue, 28 Dec 2004 23:34:34 +0000
Subject: First packaging attempt : atmel-firmware
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<E12A2976489E75193F44DBBE@[10.0.0.4]>
	<20041228224631.GB11314@devserv.devel.redhat.com>
Message-ID: <pan.2004.12.28.23.34.32.226115@surrey.ac.uk>

I included both the usb and pcmcia firmware.

The atmel driver I am referring to is the
linux/drivers/net/wireless/atmel* ones, not the
atmelwlandriver.sourceforge.net, which if I understand right are quite
different. I never could get the atmelwlandriver ones working right, but
the in-kernel driver seemed to work fine with the firmware from Simon
Kelly.

Ohh, I agree, at76c50x-firmware seems a more sensible name.

Any issues with the .spec file?

Richard Hughes

On Tue, 28 Dec 2004 17:46:31 -0500, Alan Cox wrote:

> On Tue, Dec 28, 2004 at 01:22:43PM -0800, Kenneth Porter wrote:
>> I'd recommend at76c50x-firmware, instead.
> 
> If you are only included the pcmcia/cf firmware in the package make it
> explicitly at76c50x-pcmcia-firmware as there are USB ones that need firmware
> sets too and I'm under the impression the firmware is different




From frauc at ace.ocn.ne.jp  Wed Dec 29 03:25:23 2004
From: frauc at ace.ocn.ne.jp (T.T. Eiji Sato)
Date: Wed, 29 Dec 2004 12:25:23 +0900
Subject: Plese make.
Message-ID: <008301c4ed56$087b86a0$35ab9c71@y>

Please make Internet Radio...Monitor...portable...car accessary...in car
navi.(World Wide Satellite.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041229/c6fe4488/attachment.htm>

From russell at coker.com.au  Wed Dec 29 06:23:03 2004
From: russell at coker.com.au (Russell Coker)
Date: Wed, 29 Dec 2004 17:23:03 +1100
Subject: Me stupid: lost password for gpg
In-Reply-To: <1104272147.4994.6.camel@kyrre>
References: <41C1EEDE.1080202@hhs.nl> <200412280401.56485.russell@coker.com.au>
	<1104272147.4994.6.camel@kyrre>
Message-ID: <200412291723.06067.russell@coker.com.au>

On Wednesday 29 December 2004 09:58, Kyrre Ness Sjobak 
<kyrre at solution-forge.net> wrote:
> man, 27.12.2004 kl. 18.01 skrev Russell Coker:
> > On Friday 17 December 2004 08:19, Paul Iadonisi <pri.rhl3 at iadonisi.to> 
wrote:
> > >   Maybe the new dual Opteron box I just ordered can crack the passwords
> > > for both our keys. ;-)
> >
> > I wrote a program to crack keys with a hacked version of gpg (at the
> > point in the code where it asks for the pass-phrase my code inserted a
> > loop to go through the passwords).  It's ugly but with the recent
> > versions of gpg it works reasonably well (I discovered a memory leak
> > whereby gpg would lose a couple of hundred bytes every attempt at a
> > pass-phrase).
>
> What if it tried a dictionary first?

Using a dictionary might get a faster attack or make cracking a long password 
feasible.  But surely no-one is using a password that would be so easily 
cracked...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From parklee_sel at yahoo.com  Wed Dec 29 06:34:30 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Tue, 28 Dec 2004 22:34:30 -0800 (PST)
Subject: Issue on the relationship of the three rpms
Message-ID: <20041229063430.78158.qmail@web51506.mail.yahoo.com>

Hi,
  In fedora/linux/core/updates/2/SRPMS/, we can see
there is a kernel-2.6.9-1.6_FC2.src.rpm, while, in
fedora/linux/core/updates/2/i386/, there also is a
kernel-sourcecode-2.6.9-1.6_FC2.noarch.rpm.
  Since these two rpms both contain kernel source,
What is the difference with the two?
  And, What's the relationship between them and
kernel-2.6.9-1.6_FC2.i686.rpm ?

  Thanks a lot.

  

=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250



From symbiont at berlios.de  Wed Dec 29 07:15:26 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Wed, 29 Dec 2004 15:15:26 +0800
Subject: Issue on the relationship of the three rpms
In-Reply-To: <20041229063430.78158.qmail@web51506.mail.yahoo.com>
References: <20041229063430.78158.qmail@web51506.mail.yahoo.com>
Message-ID: <200412291515.26736.symbiont@berlios.de>

On Wednesday 29 December 2004 14:34, Park Lee wrote:
> What is the difference with the two?
> ? And, What's the relationship between them and
> kernel-2.6.9-1.6_FC2.i686.rpm ?

kernel-sourcecode is how it used to be distributed.  Now src.rpm is 
used.  FC2 happens to be the distro that is the bridge between the two 
distribution methods.  Since FC2 is still supported by Fedora and not 
Fedora Legacy, the latest kernels still are updated.

I hope I'm not far off on this.  But, check the fedora-devel archives 
around July or so for related "discussion" on the issue.

-- 
-jeff



From rms at 1407.org  Wed Dec 29 10:47:46 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 29 Dec 2004 10:47:46 +0000
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <20041228180004.GA11001@ee.oulu.fi>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<200412282142.40111.symbiont@berlios.de>
	<20041228180004.GA11001@ee.oulu.fi>
Message-ID: <1104317267.3077.15.camel@roque>

On Tue, 2004-12-28 at 20:00 +0200, Pekka Pietikainen wrote:
> Oh, which reminds me. If someone does a package like that and the firmware
> has redistribution problems I think it's almost best if there are no
> dependancies between the packages. Well, it's really a balance between

Firmware is a problem that seriously bothers me :|

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041229/e134fbc8/attachment.sig>

From rms at 1407.org  Wed Dec 29 10:59:37 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 29 Dec 2004 10:59:37 +0000
Subject: First packaging attempt : atmel-firmware
In-Reply-To: <20041228224631.GB11314@devserv.devel.redhat.com>
References: <9C8E8DB5201EDC439187B9902BB35BF60CB625@EVS-EC1-NODE3.surrey.ac.uk>
	<E12A2976489E75193F44DBBE@[10.0.0.4]>
	<20041228224631.GB11314@devserv.devel.redhat.com>
Message-ID: <1104317977.6152.2.camel@roque>

On Tue, 2004-12-28 at 17:46 -0500, Alan Cox wrote:
> On Tue, Dec 28, 2004 at 01:22:43PM -0800, Kenneth Porter wrote:
> > I'd recommend at76c50x-firmware, instead.
> 
> If you are only included the pcmcia/cf firmware in the package make it
> explicitly at76c50x-pcmcia-firmware as there are USB ones that need firmware
> sets too and I'm under the impression the firmware is different

Actually, not knowing enough about drivers to be sure, I think my
particular device is fully Free!

The .c file for my particular driver says:

* This driver contains code specific to Atmel AT76C505A (USB wireless
802.11)
* devices which use radio chips from RF Micro Devices (RFMD).  Almost
* all of the actual driver is handled by the generic at76c503.c module,
this
* file just registers for the USB ids and passes the correct firmware to
* at76c503.

Since I have a 505 I seem to be a happy camper! :)

It _was_ very hard to find a device like this, I returned about 3 cards
before finding one that seems to be fully Free.

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041229/b853829e/attachment.sig>

From parklee_sel at yahoo.com  Wed Dec 29 11:32:11 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Wed, 29 Dec 2004 03:32:11 -0800 (PST)
Subject: Issue on the relationship of the three rpms
In-Reply-To: <200412291515.26736.symbiont@berlios.de>
Message-ID: <20041229113211.34268.qmail@web51507.mail.yahoo.com>

On Wed, 29 Dec 2004 at 15:15, Jeff Pitman wrote:
> kernel-sourcecode is how it used to be 
> distributed.  Now src.rpm is used.  FC2 happens to 
> be the distro that is the bridge between the two 
> distribution methods.  Since FC2 is still supported 
> by Fedora and not Fedora Legacy, the latest kernels 
> still are updated.

Does this means that we can use both of the methods
now in FC2?

Thank you.


=====
Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From ad+lists at uni-x.org  Wed Dec 29 11:35:32 2004
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Wed, 29 Dec 2004 12:35:32 +0100
Subject: Issue on the relationship of the three rpms
In-Reply-To: <20041229063430.78158.qmail@web51506.mail.yahoo.com>
References: <20041229063430.78158.qmail@web51506.mail.yahoo.com>
Message-ID: <1104320132.13742.201.camel@serendipity.dogma.lan>

Am Mi, den 29.12.2004 schrieb Park Lee um 7:34:

>   In fedora/linux/core/updates/2/SRPMS/, we can see
> there is a kernel-2.6.9-1.6_FC2.src.rpm, while, in
> fedora/linux/core/updates/2/i386/, there also is a
> kernel-sourcecode-2.6.9-1.6_FC2.noarch.rpm.
>   Since these two rpms both contain kernel source,
> What is the difference with the two?

The src.rpm is the basis for building the binary kernels for different
architectures from it, as well as to generate the kernel-sourcecode rpm.

rpmbuild -ba --target=i386,i686,noarch kernel-2.6.9-1.6_FC2.src.rpm

will do so. kernel-sourcecode-2.6.9-1.6_FC2.noarch.rpm contains the
patched kernel sources and deflates during installation to /usr/src/.
While the kernel src.rpm will install/deflate to /usr/src/redhat/.

With FC3 there is no more kernel-sourcecode rpm, because the src.rpm
contains the same and a bit more. See the FC3 release notes about this
and how to get the sourcecode package if really needed.

>   And, What's the relationship between them and
> kernel-2.6.9-1.6_FC2.i686.rpm ?

That is the kernel binary for the i686 architecture.

> Park Lee

Alexander


-- 
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp 
Serendipity 12:30:27 up 6 days, 14:14, load average: 0.37, 0.80, 0.72 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041229/da001378/attachment.sig>

From casimiro.barreto at gmail.com  Wed Dec 29 12:57:41 2004
From: casimiro.barreto at gmail.com (casimiro barreto)
Date: Wed, 29 Dec 2004 10:57:41 -0200
Subject: Me stupid: lost password for gpg
In-Reply-To: <200412291723.06067.russell@coker.com.au>
References: <41C1EEDE.1080202@hhs.nl> <200412280401.56485.russell@coker.com.au>
	<1104272147.4994.6.camel@kyrre>
	<200412291723.06067.russell@coker.com.au>
Message-ID: <578ed59104122904579980e31@mail.gmail.com>

Ideally, passwords should be phrases with transliterations. If you
don't use English, if you include names of places or people or
anything derived from foreign names (here we can use lots of indian
names) and a personal rule for transliteration, you can have passwords
that won't be easily cracked.


On Wed, 29 Dec 2004 17:23:03 +1100, Russell Coker <russell at coker.com.au> wrote:
> On Wednesday 29 December 2004 09:58, Kyrre Ness Sjobak
> <kyrre at solution-forge.net> wrote:
> > man, 27.12.2004 kl. 18.01 skrev Russell Coker:
> > > On Friday 17 December 2004 08:19, Paul Iadonisi <pri.rhl3 at iadonisi.to>
> wrote:
> > > >   Maybe the new dual Opteron box I just ordered can crack the passwords
> > > > for both our keys. ;-)
> > >
> > > I wrote a program to crack keys with a hacked version of gpg (at the
> > > point in the code where it asks for the pass-phrase my code inserted a
> > > loop to go through the passwords).  It's ugly but with the recent
> > > versions of gpg it works reasonably well (I discovered a memory leak
> > > whereby gpg would lose a couple of hundred bytes every attempt at a
> > > pass-phrase).
> >
> > What if it tried a dictionary first?
> 
> Using a dictionary might get a faster attack or make cracking a long password
> feasible.  But surely no-one is using a password that would be so easily
> cracked...
> 
> --
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 
The information contained in this message is confidential and
intended to the recipients specified in the headers. If you received
this message by error, notify the sender immediately. The
unauthorized use, disclosure, copy or alteration of this message
are strictly forbidden and subjected to civil and criminal sanctions.



From buildsys at redhat.com  Wed Dec 29 13:05:03 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 29 Dec 2004 08:05:03 -0500
Subject: rawhide report: 20041229 changes
Message-ID: <200412291305.iBTD53m27729@porkchop.devel.redhat.com>

 

 
Updated Packages:

firefox-0:1.0-8
---------------
* Tue Dec 28 2004 Christopher Aillon <caillon at redhat.com> 0:1.0-8
- Add upstream langpacks

gaim-1:1.1.1-1
--------------
* Tue Dec 28 2004 Warren Togami <wtogami at redhat.com> 1.1.1-1
- 1.1.1 (minor bugfixes)

gcc-3.4.3-11
------------
* Mon Dec 27 2004 Jakub Jelinek  <jakub at redhat.com> 3.4.3-11
- update from gcc-3_4-branch
  - PRs c++/17972, c++/18962, c++/18975, java/14104, libobjc/12035,
	middle-end/17930, middle-end/18424, middle-end/18493,
	middle-end/18590, middle-end/18730, middle-end/18882,
	middle-end/19068, other/18508, other/18665, other/19093,
	preprocessor/15167, rtl-optimization/16968, target/16819,
	target/17990, target/18002, target/18153, target/19005,
	target/19010, target/19028, target/19102, target/19147
- fix ICE in dwarf2out (Devang Patel, Eric Botcazou, #143719,
  PR debug/16261)
- fix ICE in reshape_init_array (#143034, PRs c++/18384, c++/18327)

* Mon Dec 13 2004 Jakub Jelinek  <jakub at redhat.com> 3.4.3-10
- update from gcc-3_4-branch
  - PRs target/18932, target/17025, c++/18731
- fix _Jv_{Start,End}OfInterpreter computation (Andrew Haley, #142611,
  PRs java/18036, java/13468)
- avoid multiple evaluation of sqrt and other math builtins when
  not -ffast-math (#142603, PR middle-end/18951)
- remove leading underscore from /usr/libexec/getconf/default
  symlink target

* Thu Dec 09 2004 Jakub Jelinek  <jakub at redhat.com> 3.4.3-9
- update from gcc-3_4-branch
  - PRs target/18443, c++/18100, java/14853, c++/16681
- fix creation of /usr/libexec/getconf/default symlink

gcc4-4.0.0-0.16
---------------
* Tue Dec 28 2004 Jakub Jelinek  <jakub at redhat.com> 4.0.0-0.16
- update from trunk
- include also gcc4-java, libgcj4 and libgcj4-devel subpackages

libselinux-1.19.3-3
-------------------
* Tue Dec 28 2004 Dan Walsh <dwalsh at redhat.com> 1.19.3-3
- Fix link devel libraries

rpmdb-fedora-1:4-0.20041229
---------------------------

selinux-policy-strict-1.19.15-10
--------------------------------
* Tue Dec 28 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-10
- Fix transition rules for initrc->unconfined_t

selinux-policy-targeted-1.19.15-11
----------------------------------
* Tue Dec 28 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-11
- Change sshd, xdm, crond, sendmail to run under different context
- in targeted policy

* Tue Dec 28 2004 Dan Walsh <dwalsh at redhat.com> 1.19-15-10
- Fix transition rules for initrc->unconfined_t



From elanthis at awesomeplay.com  Wed Dec 29 14:53:50 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Wed, 29 Dec 2004 09:53:50 -0500
Subject: apt question
In-Reply-To: <1104271560.2898.2.camel@p.linuxcenter.cl>
References: <1104271560.2898.2.camel@p.linuxcenter.cl>
Message-ID: <1104332030.2462.0.camel@stargrazer.home.awesomeplay.com>

On Tue, 2004-12-28 at 19:06 -0300, Patricio Bruna V wrote:
> will be apt include in any version of fedora?
> and if so, there will be metapackages?

I don't see why it would.  We already have both yum and up2date.  We
don't need two different update managers, much less three.  At least not
in Core.  In Extras, sure (apt is already there, is it not?)

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list



From wrrhdev at riede.org  Wed Dec 29 15:06:51 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Wed, 29 Dec 2004 15:06:51 +0000
Subject: rpmbuild of dovecot fails on my machine
Message-ID: <1104332811l.8732l.1l@serve.riede.org>

I'm trying to rebuild a dovecot rpm here from dovecot-0.99.11-7.devel.src.rpm   
(don't want to get into "why" as that would only be a distraction at this  
time), and it fails:

+ rm -f ./configure
+ aclocal
configure.in:279: warning: underquoted definition of AC_TYPEOF
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:504: warning: underquoted definition of AC_CHECKTYPE2
aclocal:configure.in:15: warning: macro `AM_ICONV' not found in library
configure.in:13: warning: AC_ARG_PROGRAM invoked multiple times
+ automake -a
configure.in:13: warning: AC_ARG_PROGRAM invoked multiple times
src/auth/Makefile.am: installing `./depcomp'
+ autoconf
configure.in:13: warning: AC_ARG_PROGRAM invoked multiple times
configure.in:15: error: possibly undefined macro: AM_ICONV
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
error: Bad exit status from /var/tmp/rpm-tmp.78046 (%build)


So something isn't quite right (read not the same as in the fc build  
environment) with my autoconfig setup, I guess. This is on a FC3 system.
Rebuilding the FC3 dovecot rpm fails in the same way. Is anyone with autoconf  
experience able to suggest a course of action for me?

Thanks, Willem Riede.




From parklee_sel at yahoo.com  Wed Dec 29 16:09:35 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Wed, 29 Dec 2004 08:09:35 -0800 (PST)
Subject: Differences between the kernel source in FC2 and the kernel
	source obtained from kernel.org?
Message-ID: <20041229160935.19029.qmail@web51502.mail.yahoo.com>

On Thu, 16 Dec 2004 at 18:22, Stephen J. Smoogen
wrote:
> On Tue, 14 Dec 2004 22:46:47 -0800 (PST), Park Lee
wrote:
> > Hi,
> > Is there any difference between the kernel source
in
> > FC2(version 2.6.5-1.358) and the kernel source
> > (version 2.6.5)obtained from kernel.org?
>
> There are probably several 'differences' and patches
between the 2
> kernels. THe best way to look at it would be to get
the kernel.src.rpm
> from Fedora tree and then do a rpm -ivh of it. Look
at the spec file
> and the patches to see what the differences are.

I've downloaded the kernel-2.6.9-1.6_FC2.src.rpm. and
run 

	rpm -ivh kernel-2.6.9-1.6_FC2.src.rpm

In /usr/src/redhat/SOURCE, I see a linux-2.6.9.tar.bz2
file as well as lots of *.patch files and other files.

I think that this linux-2.6.9.tar.bz2 file is
identical to the linux kernel source with the same
version form kernel.org, and those patches show the
differences between the kernel source in FC2 and the
kernel source obtained from kernel.org. Am I right?

Thank you.


=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com



From parklee_sel at yahoo.com  Wed Dec 29 16:10:12 2004
From: parklee_sel at yahoo.com (Park Lee)
Date: Wed, 29 Dec 2004 08:10:12 -0800 (PST)
Subject: Isson on relationship between .config and config-2.6.5-1.358
Message-ID: <20041229161012.80666.qmail@web51504.mail.yahoo.com>

Hi,
  I'm using FC2. 
  In /usr/src/linux-2.6.5-1.358 there is a file
".config", while in /boot there is another file
"config-2.6.5-1.358". 
  Then, What's the relationship between these two
files? Why should there be two such files?

  Thank you.


=====
Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 



From fedora-devel at camperquake.de  Wed Dec 29 16:14:51 2004
From: fedora-devel at camperquake.de (Ralf Ertzinger)
Date: Wed, 29 Dec 2004 17:14:51 +0100
Subject: Differences between the kernel source in FC2 and the kernel
	source obtained from kernel.org?
In-Reply-To: <20041229160935.19029.qmail@web51502.mail.yahoo.com>;
	from parklee_sel@yahoo.com on Wed, Dec 29, 2004 at 08:09:35AM
	-0800
References: <20041229160935.19029.qmail@web51502.mail.yahoo.com>
Message-ID: <20041229171451.A6505@ryoko.camperquake.de>

On Wed, Dec 29, 2004 at 08:09:35AM -0800, Park Lee wrote:

> I think that this linux-2.6.9.tar.bz2 file is
> identical to the linux kernel source with the same
> version form kernel.org, and those patches show the
> differences between the kernel source in FC2 and the
> kernel source obtained from kernel.org. Am I right?

Usually yes. There are some .src.rpms which do not contain
the source as provided by the original vendor (be it kernel.org,
gnome.org, or whatever else is shipped with FC), but a modified
version (ssh comes to mind, due to some issues I can not recall
right now), but the kernel package ought to be original.



From arjanv at redhat.com  Wed Dec 29 16:37:36 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 29 Dec 2004 17:37:36 +0100
Subject: Isson on relationship between .config and config-2.6.5-1.358
In-Reply-To: <20041229161012.80666.qmail@web51504.mail.yahoo.com>
References: <20041229161012.80666.qmail@web51504.mail.yahoo.com>
Message-ID: <1104338257.4168.21.camel@laptopd505.fenrus.org>

On Wed, 2004-12-29 at 08:10 -0800, Park Lee wrote:
> Hi,
>   I'm using FC2. 
>   In /usr/src/linux-2.6.5-1.358 there is a file
> ".config", while in /boot there is another file
> "config-2.6.5-1.358". 
>   Then, What's the relationship between these two
> files? Why should there be two such files?

the file in /boot is the config file of the currently running kernel,
while the one on /usr/src/linux-<version>/configs is a suggested
configuration if you want to compile your own kernel. It's similar but
not identical to the file in /boot.

there is no file /usr/src/linux-<version>/.config shipped, that must be
created by something you did.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041229/17e50182/attachment.sig>

From hp at redhat.com  Wed Dec 29 18:26:28 2004
From: hp at redhat.com (Havoc Pennington)
Date: Wed, 29 Dec 2004 13:26:28 -0500
Subject: stateless linux project status
In-Reply-To: <41D1ACE1.6000408@VTK.UGent.be>
References: <41D1ACE1.6000408@VTK.UGent.be>
Message-ID: <1104344789.29189.75.camel@localhost.localdomain>

On Tue, 2004-12-28 at 18:58 +0000, Peter Dedecker - FSU wrote:
> Havoc Pennington wrote:
> > On Wed, 2004-12-22 at 17:00 +0000, Peter Schobel wrote:
> >> I have seen next to nothing on this list recently from stateless linux
> >> developers
> >> 
> >> What is the status of this project? Is it in active development?
> >> 
> > 
> > It isn't in active development right now; the initial release was a
> > prototype to gather data on what people thought of the idea.
> > 
> > Now we are looking at the feedback and looking at overall Red Hat
> > priorities and have to decide whether to create a project team to
> > continue with stateless Linux (and related technology). If we do decide
> > to continue then there will probably be a number of people working on
> > it.
> 
> Do you know when you will take the decision?  We really like the project 
> and its goals and we hope it will continu very soon.
> 

It isn't clear yet...

Havoc




From josh-tmda at yucs.org  Wed Dec 29 18:56:05 2004
From: josh-tmda at yucs.org (josh)
Date: Wed, 29 Dec 2004 18:56:05 +0000 (UTC)
Subject: storage status
Message-ID: <loom.20041229T195334-649@post.gmane.org>

What's the status of gnome storage?

Does redhat have anybody officially working on it?



From Atchley.Van at inventec.com  Wed Dec 29 22:04:37 2004
From: Atchley.Van at inventec.com (Atchley.Van at inventec.com)
Date: Wed, 29 Dec 2004 16:04:37 -0600
Subject: Installation HDD Capacity
Message-ID: <522542BB9F49DC448A94F871EA58DCA51A567C@ihs-mx01.iec.inventec>

Does anyone know how to install Fedora Core 2 on a whole 1,600 Gig HDD
not just 1,000 Gig?



From mattdm at mattdm.org  Wed Dec 29 22:33:28 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Dec 2004 17:33:28 -0500
Subject: Installation HDD Capacity
In-Reply-To: <522542BB9F49DC448A94F871EA58DCA51A567C@ihs-mx01.iec.inventec>
References: <522542BB9F49DC448A94F871EA58DCA51A567C@ihs-mx01.iec.inventec>
Message-ID: <20041229223328.GA2618@jadzia.bu.edu>

On Wed, Dec 29, 2004 at 04:04:37PM -0600, Atchley.Van at inventec.com wrote:
> Does anyone know how to install Fedora Core 2 on a whole 1,600 Gig HDD
> not just 1,000 Gig?

This isn't right for thie -devel mailing list -- try again on the regular
one. (Also, when you post there -- is the "," a thousands separator or a
decimal point? That is, do you mean one point six terabytes, or one point
six gigabytes?)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From Atchley.Van at inventec.com  Wed Dec 29 22:36:02 2004
From: Atchley.Van at inventec.com (Atchley.Van at inventec.com)
Date: Wed, 29 Dec 2004 16:36:02 -0600
Subject: Installation HDD Capacity
Message-ID: <522542BB9F49DC448A94F871EA58DCA51A5684@ihs-mx01.iec.inventec>

1.6 Terabytes. Sorry I joined a few sections but I wasn't sure witch one
to post at. Sorry again.

-----Original Message-----
From: Matthew Miller [mailto:mattdm at mattdm.org] 
Sent: Wednesday, December 29, 2004 4:33 PM
To: Development discussions related to Fedora Core
Subject: Re: Installation HDD Capacity

On Wed, Dec 29, 2004 at 04:04:37PM -0600, Atchley.Van at inventec.com
wrote:
> Does anyone know how to install Fedora Core 2 on a whole 1,600 Gig HDD
> not just 1,000 Gig?

This isn't right for thie -devel mailing list -- try again on the
regular
one. (Also, when you post there -- is the "," a thousands separator or a
decimal point? That is, do you mean one point six terabytes, or one
point
six gigabytes?)

-- 
Matthew Miller           mattdm at mattdm.org
<http://www.mattdm.org/>
Boston University Linux      ------>
<http://linux.bu.edu/>

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list



From shiva at sewingwitch.com  Thu Dec 30 00:00:18 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 29 Dec 2004 16:00:18 -0800
Subject: Installation HDD Capacity
In-Reply-To: <522542BB9F49DC448A94F871EA58DCA51A5684@ihs-mx01.iec.inventec>
References: <522542BB9F49DC448A94F871EA58DCA51A5684@ihs-mx01.iec.inventec>
Message-ID: <3EFDEF430625C0F8E7FC1FD4@[10.0.0.4]>

--On Wednesday, December 29, 2004 4:36 PM -0600 Atchley.Van at inventec.com 
wrote:

> 1.6 Terabytes. Sorry I joined a few sections but I wasn't sure witch one
> to post at. Sorry again.

The dev list is for people writing code for the system. The users list is 
for people installing and, well, using it.

It sounds like you're asking if the kernel was compiled with large 
filesystem support. I don't know, but my approach would be to inspect the 
config files in the kernel source RPM.




From buildsys at redhat.com  Thu Dec 30 12:57:24 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 30 Dec 2004 07:57:24 -0500
Subject: rawhide report: 20041230 changes
Message-ID: <200412301257.iBUCvO015265@porkchop.devel.redhat.com>

 

 
Updated Packages:

coreutils-5.2.1-36
------------------
* Tue Dec 28 2004 Dan Walsh <dwalsh at redhat.com> 5.2.1-36
- Fix to only setdefaultfilecon if not overridden by command line

gimp-2:2.2.1-1
--------------
* Wed Dec 29 2004 Nils Philippsen <nphilipp at redhat.com>
- version 2.2.1
- pygimp-logo.png included in tarball again

libselinux-1.19.4-1
-------------------
* Wed Dec 29 2004 Dan Walsh <dwalsh at redhat.com> 1.19.4-1
- Update to latest from upstream
	* Changed matchpathcon to return -1 with errno ENOENT for 
	  <<none>> entries, and also for an empty file_contexts configuration.

policycoreutils-1.19.2-1
------------------------
* Wed Dec 29 2004 Dan Walsh <dwalsh at redhat.com> 1.19.2-1
- Update to latest from NSA
	* Changed restorecon to ignore ENOENT errors from matchpathcon.
	* Merged nonls patch from Chris PeBenito.

rpmdb-fedora-1:4-0.20041230
---------------------------

selinux-doc-1.15.2-1
--------------------
* Mon Dec 20 2004 Dan Walsh <dwalsh at redhat.com> 1.15-2
- Upgrade to match NSA
	* Updated CREDITS.
	* Updated README.
	* Merged SGML fixes from Manoj Srivastava.



From srinivasg at esntechnologies.co.in  Thu Dec 30 13:19:00 2004
From: srinivasg at esntechnologies.co.in (Srinivas G.)
Date: Thu, 30 Dec 2004 18:49:00 +0530
Subject: kernel panic: Attempted to kill init!
Message-ID: <4EE0CBA31942E547B99B3D4BFAB348112B8875@mail.esn.co.in>

Dear All,

I downloaded the Fedora Core 3 (kernel 2.6.9-1.667) ISO CDs from the
following link. 
http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/iso/
I burn the CDs. I installed the Fedora Core 3 in an Intel Machine. It
was working fine. 

Now I want to build the 2.6.6 kernel image. Then I downloaded the kernel
tar file from the following link.
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz


After that I did the following steps.

1.	I copied the downloaded tar file to the /usr/src directory.
2.	I un tar the downloaded tar file.
3.	I changed the owner to ROOT by 
	#chown -R root:root /usr/src/linux-2.6.6

After this I compiled the kernel by the following steps.

4.	#make menuconfig	-	to creating the config file
5.	#make clean
6.	#make bzImage

Now I changed the EXTRAVERSION in Makefile

7.	#make modules
8.	#make modules_install
9.	#make install	-	this will copy the bzImage file to /boot

					directory and also updates the
menu.list 
					i.e. grub.conf file and copies
System.map file etc.

Every thing goes fine. After rebooting the system through this new
kernel image I got the following error messages and system halted.

Red Hat nash version 4.1.18 starting 
Enforcing mode requested but no policy loaded. Halting now. 
Kernel panic: Attempted to kill init!

I succeeded in building the new kernel image, but un succeeded in
booting from the new image. I tried 2 to 3 times. I got the same error.
  
What am I doing wrong here? Please advice me with right one.

Thanks in advance.

Regards,
Srinivas G




From arjanv at redhat.com  Thu Dec 30 14:04:04 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 30 Dec 2004 15:04:04 +0100
Subject: kernel panic: Attempted to kill init!
In-Reply-To: <4EE0CBA31942E547B99B3D4BFAB348112B8875@mail.esn.co.in>
References: <4EE0CBA31942E547B99B3D4BFAB348112B8875@mail.esn.co.in>
Message-ID: <1104415445.4170.15.camel@laptopd505.fenrus.org>

On Thu, 2004-12-30 at 18:49 +0530, Srinivas G. wrote:
> Dear All,
> 
> I downloaded the Fedora Core 3 (kernel 2.6.9-1.667) ISO CDs from the
> following link. 
> http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/iso/
> I burn the CDs. I installed the Fedora Core 3 in an Intel Machine. It
> was working fine. 
> 
> Now I want to build the 2.6.6 kernel image. Then I downloaded the kernel
> tar file from the following link.
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz

2.6.6 is too old for FC3 if you have selinux enabled

> Enforcing mode requested but no policy loaded. Halting now. 
> Kernel panic: Attempted to kill init!

see ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041230/023290c4/attachment.sig>

From nbargnesi at gmail.com  Thu Dec 30 16:49:10 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Thu, 30 Dec 2004 11:49:10 -0500
Subject: kernel panic: Attempted to kill init!
In-Reply-To: <1104415445.4170.15.camel@laptopd505.fenrus.org>
References: <4EE0CBA31942E547B99B3D4BFAB348112B8875@mail.esn.co.in>
	<1104415445.4170.15.camel@laptopd505.fenrus.org>
Message-ID: <3077b8a004123008496faea2cf@mail.gmail.com>

On Thu, 30 Dec 2004 15:04:04 +0100, Arjan van de Ven <arjanv at redhat.com> wrote:
> On Thu, 2004-12-30 at 18:49 +0530, Srinivas G. wrote:
> > Dear All,
> >
> > I downloaded the Fedora Core 3 (kernel 2.6.9-1.667) ISO CDs from the
> > following link.
> > http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/iso/
> > I burn the CDs. I installed the Fedora Core 3 in an Intel Machine. It
> > was working fine.
> >
> > Now I want to build the 2.6.6 kernel image. Then I downloaded the kernel
> > tar file from the following link.
> > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz
> 
> 2.6.6 is too old for FC3 if you have selinux enabled
> 
> > Enforcing mode requested but no policy loaded. Halting now.
> > Kernel panic: Attempted to kill init!
> 
> see ;)
> 

Any chance it would help booting with selinux=0?

> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From kevymac at yahoo.com  Fri Dec 31 05:39:39 2004
From: kevymac at yahoo.com (Kevin McConnell)
Date: Thu, 30 Dec 2004 21:39:39 -0800 (PST)
Subject: building own RPMs
In-Reply-To: <20041226212232.0356f911.fedora@wir-sind-cool.org>
Message-ID: <20041231053939.23343.qmail@web50507.mail.yahoo.com>


--- Michael Schwendt <fedora at wir-sind-cool.org> wrote:
> http://fedoraproject.org/pre-extras/3/
> 
> $ rpm -qf $(which fedora-buildrpmtree)
> fedora-rpmdevtools-0.2.0-1
> 
> Ralf might enjoy reading the header of the script.
> ;)

Coulda saved an extra character by doing:
$ rpm -qf `which fedora-buildrpmtree`
fedora-rpmdevtools-0.2.0-1

;) keep it lean 


=====
Kevin C. McConnell --RHCE # 805299480800193 since July 2, 1999-- <Red Hat Certified Engineer>
Freedom in software, now freedom in life.
http://www.freestateproject.org/


		
__________________________________ 
Do you Yahoo!? 
Send a seasonal email greeting and help others. Do good. 
http://celebrity.mail.yahoo.com



From jwz at jwz.org  Fri Dec 31 06:36:29 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Thu, 30 Dec 2004 22:36:29 -0800
Subject: why doesn't yum cache anything?
Message-ID: <41D4F36D.B7DA877@jwz.org>

Here's a typical use case for yum with me:

  - notice that "xmtr" is not installed (but "mtr" is)
  - yum list '*mtr*'
  - wait through ~60 seconds of:

    Setting up Repo:  base
    repomd.xml                100% |=================| 1.1 kB   
00:00     
    Setting up Repo:  updates-released
    repomd.xml                100% |=================|  951 B   
00:00     
    Reading repository metadata in from local files
    base      : ############################################# 2622/2622
    updates-re: ############################################# 405/405

  - yum -y install mtr-gtk
  - wait through that same ~60 seconds of junk before it actually
    starts downloading the package.

So my questions are:

  - Is there some way to make yum cache all that crap?  I'd be 
    perfectly ok with it just reusing the same repository data
    for days at a time.  Certainly there's no need to re-download
    it every single time I invoke yum.

  - If there's no way to do that... how can you guys stand it?
    Do you really suffer through this every time, or do you just
    not use yum?  Is there something else I should be using instead?

-- 
Jamie Zawinski         jwz at jwz.org                  http://www.jwz.org/
                       jwz at dnalounge.com      http://www.dnalounge.com/
                                            http://jwz.livejournal.com/



From elanthis at awesomeplay.com  Fri Dec 31 06:44:10 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Fri, 31 Dec 2004 01:44:10 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F36D.B7DA877@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
Message-ID: <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>

On Thu, 2004-12-30 at 22:36 -0800, Jamie Zawinski wrote:
> Here's a typical use case for yum with me:
> 
>   - notice that "xmtr" is not installed (but "mtr" is)
>   - yum list '*mtr*'
>   - wait through ~60 seconds of:
> 
>     Setting up Repo:  base
>     repomd.xml                100% |=================| 1.1 kB   
> 00:00     
>     Setting up Repo:  updates-released
>     repomd.xml                100% |=================|  951 B   
> 00:00     
>     Reading repository metadata in from local files
>     base      : ############################################# 2622/2622
>     updates-re: ############################################# 405/405
> 
>   - yum -y install mtr-gtk
>   - wait through that same ~60 seconds of junk before it actually
>     starts downloading the package.
> 
> So my questions are:
> 
>   - Is there some way to make yum cache all that crap?  I'd be 

All of the above *IS* the cache.  The repomd.xml lookups are the only
non-cache bits - those are the files yum checks online to see if there
are only real updates.  Notice their very small size.

The later bits (the hash marks) are yum reading the cache files from the
disk.

The problem you're perceiving (slow operation as yum starts up) isn't at
all due to lack of caching, but perhaps very inefficient handling of the
cache - a lot of data has to be parsed and such, when it could perhaps
be stored in a more ready-to-process format.



From remco at rvt.com  Fri Dec 31 06:48:13 2004
From: remco at rvt.com (Remco Treffkorn)
Date: Thu, 30 Dec 2004 22:48:13 -0800
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F36D.B7DA877@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
Message-ID: <200412302248.13976.remco@rvt.com>

On Thursday 30 December 2004 22:36, Jamie Zawinski wrote:
>     not use yum?  Is there something else I should be using instead?

Apt.

"apt-get update" reads the crap and caches it.
"apt-get upgrade" uses the cached crap to upgrade your system.
"apt-get install whatever" installs the current (according to the cached crap) 
version of  "whatever".

I really like Apt, but it seems to be less supported than yum and up2date.

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201



From jwz at jwz.org  Fri Dec 31 06:50:26 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Thu, 30 Dec 2004 22:50:26 -0800
Subject: why doesn't yum cache anything?
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
Message-ID: <41D4F6B2.183B0FA4@jwz.org>

Sean Middleditch wrote:
> 
> The problem you're perceiving (slow operation as yum starts up) isn't at
> all due to lack of caching, but perhaps very inefficient handling of the
> cache - a lot of data has to be parsed and such, when it could perhaps
> be stored in a more ready-to-process format.

It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
If it's not hitting the net, what's it doing, raytracing?

-- 
Jamie Zawinski         jwz at jwz.org                  http://www.jwz.org/
                       jwz at dnalounge.com      http://www.dnalounge.com/
                                            http://jwz.livejournal.com/



From jspaleta at gmail.com  Fri Dec 31 06:57:55 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Dec 2004 01:57:55 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F36D.B7DA877@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
Message-ID: <604aa7910412302257183b64a3@mail.gmail.com>

On Thu, 30 Dec 2004 22:36:29 -0800, Jamie Zawinski <jwz at jwz.org> wrote:
> So my questions are:
> 
>   - Is there some way to make yum cache all that crap?  I'd be
>     perfectly ok with it just reusing the same repository data
>     for days at a time.  Certainly there's no need to re-download
>     it every single time I invoke yum.

Are you sure its not caching?
/var/cache/yum/base/*.pickle  should exist, and those pickle files are
cached versions of the binary data python needs in a form already
interpretted from the xml.  I naively assume they are created using
python's pickle module
http://www.network-theory.co.uk/docs/pytut/tut_58.html

My understanding is ==== hash bars are downloads and ###### hash bars
are reading things into memory. repomd.xml is a very very small file
and its used to get the checksums of the important metadata files...
like primary and filelists, with are used for dependancy resolution.
repomd is what is downloaded from each repo to see if the cached
versions of the important xml files are still valid.   How else would
you cache information and be sure the cached versions are in sync with
the versions at the repos? You have to download something to check for
sync...and repomd is pretty small...its basically an xmlized directory
listing with md5sum information, take a look for yourself: 
/var/cache/yum/base/repomd.xml

I bet you will see a difference in operation if you do yum clean
headers and make sure the cached versions. You will definitely see
primary.xml.gz being downloaded with === hash bars as an extra output.

you can also run yum makecache   to force yum to cache all the xml
files from a repository's metadata and then use yum -C to  run queries
or get listing information. Clever people even script yum makecache to
run periodically to keep the local cache synced.
yum -C  removes all network activity and uses only the local cache so
unless you cache the packages locally as well.. you cant easily use
yum -C to do installs or updates.. its very useful for check-update,
list, search, and provides  functionality.


-jef



From jspaleta at gmail.com  Fri Dec 31 07:00:04 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Dec 2004 02:00:04 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <604aa7910412302300450c5822@mail.gmail.com>

On Thu, 30 Dec 2004 22:50:26 -0800, Jamie Zawinski <jwz at jwz.org> wrote:
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

yes

-jef"ask a silly question...."spaleta



From technojoecoolusa at charter.net  Fri Dec 31 07:11:13 2004
From: technojoecoolusa at charter.net (Joseph D. Wagner)
Date: Fri, 31 Dec 2004 01:11:13 -0600
Subject: Kernel 2.6.10 Can't Open Initial Console on FC3
Message-ID: <3k789p$kn0fji@mxip11a.cluster1.charter.net>

The newly compiled kernel gets through everything OK including mounting the root file system as read-only EXT3.  However, it freezes on the very last line, which says:

     Warning: unable to open an initial console

If I switch back over to the kernel that came with the distribution, everything boots fine, so I'm assuming the problem lies in the way I configured the kernel.

I ran "find / -name genromfs" which found nothing.

I feel like an idiot for posting this.  I'm probably missing something obvious.

I have:
* Pentium 3
* 256 MB RAM
* PCI ATI Rage 128 Graphics Card
* PS/2 Mouse
* PS/2 Keyboard
* Fedora Core 3

Thanks in advance.

Joseph D. Wagner

".config" file included below.
---------------------------------------------------------------------------
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10
# Thu Dec 30 19:07:10 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION="-experimental"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=2001
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
CONFIG_PARPORT_SERIAL=y
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_NETFILTER is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
CONFIG_INPUT_UINPUT=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_VESA is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
CONFIG_FB_ATY128=y
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
# CONFIG_USB_STORAGE is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
CONFIG_TMPFS_XATTR=y
CONFIG_TMPFS_SECURITY=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_4KSTACKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y
---------------------------------------------------------------------------
/etc/inittab file included below:
---------------------------------------------------------------------------
#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, <miquels at drinkel.nl.mugnet.org>
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
# 
id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.  
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs




From elanthis at awesomeplay.com  Fri Dec 31 07:20:45 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Fri, 31 Dec 2004 02:20:45 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <1104477645.3324.7.camel@stargrazer.home.awesomeplay.com>

On Thu, 2004-12-30 at 22:50 -0800, Jamie Zawinski wrote:
> Sean Middleditch wrote:
> > 
> > The problem you're perceiving (slow operation as yum starts up) isn't at
> > all due to lack of caching, but perhaps very inefficient handling of the
> > cache - a lot of data has to be parsed and such, when it could perhaps
> > be stored in a more ready-to-process format.
> 
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

That or maybe an embedded SETI at home client...?

It only takes a handful of seconds on my machine, which is only 1.5ghz.
Yum is *very* RAM intensive, so if you're low there, that might be the
slow down...?

> 
> -- 
> Jamie Zawinski         jwz at jwz.org                  http://www.jwz.org/
>                        jwz at dnalounge.com      http://www.dnalounge.com/
>                                             http://jwz.livejournal.com/
> 



From arjanv at redhat.com  Fri Dec 31 08:09:45 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 31 Dec 2004 09:09:45 +0100
Subject: Kernel 2.6.10 Can't Open Initial Console on FC3
In-Reply-To: <3k789p$kn0fji@mxip11a.cluster1.charter.net>
References: <3k789p$kn0fji@mxip11a.cluster1.charter.net>
Message-ID: <1104480585.5402.12.camel@laptopd505.fenrus.org>

On Fri, 2004-12-31 at 01:11 -0600, Joseph D. Wagner wrote:
> The newly compiled kernel gets through everything OK including mounting the root file system as read-only EXT3.  However, it freezes on the very last line, which says:
> 
>      Warning: unable to open an initial console
> 
> If I switch back over to the kernel that came with the distribution, everything boots fine, so I'm assuming the problem lies in the way I configured the kernel.
> 
> I ran "find / -name genromfs" which found nothing.
> 
> I feel like an idiot for posting this.  I'm probably missing something obvious.

you most likely forgot to setup or enable the initrd. You need an initrd
in FC3.

(make install in the kernel tree will do this automatically for you, IF
you enabled it in the configs)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041231/71c751fb/attachment.sig>

From jwz at jwz.org  Fri Dec 31 08:12:21 2004
From: jwz at jwz.org (Jamie Zawinski)
Date: Fri, 31 Dec 2004 00:12:21 -0800
Subject: why doesn't yum cache anything?
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
	<1104477645.3324.7.camel@stargrazer.home.awesomeplay.com>
Message-ID: <41D509E5.5576F2E9@jwz.org>

Sean Middleditch wrote:
> 
> It only takes a handful of seconds on my machine, which is only 1.5ghz.
> Yum is *very* RAM intensive, so if you're low there, that might be the
> slow down...?

By "a handful of seconds" do you mean "20"?  I think an acceptable 
number would be, like, "3", but I'm seeing anywhere from 19 to 64, 
on four different FC3 machines on two different networks:


500MB RAM, 1.4GHz -- 1:04

    <root at gronk:~/> time yum list '*mtr*'
    Setting up Repo:  base
    repomd.xml                100% |=========================| 1.1 kB    00:00
    Setting up Repo:  updates-released
    repomd.xml                100% |=========================|  951 B    00:00
    Reading repository metadata in from local files
    base      : ################################################## 2622/2622
    primary.xml.gz            100% |=========================| 180 kB    00:24
    MD Read   : ################################################## 408/408
    updates-re: ################################################## 408/408
    Installed Packages
    mtr.i386                                 2:0.54-10              installed
    mtr-gtk.i386                             2:0.54-10              installed
    8.405u 0.860s 1:04.81 14.2%     0+0k 0+0io 9pf+0w

500MB RAM, 1GHz -- 0:28

    <jwz at codon:~/> time yum list '*mtr*'
    Setting up Repo:  base
    Setting up Repo:  updates-released
    Reading repository metadata in from local files
    base      : ################################################## 2622/2622
    updates-re: ################################################## 405/405
    Installed Packages
    mtr.i386                                 2:0.54-10              installed
    mtr-gtk.i386                             2:0.54-10              installed
    8.363u 1.310s 0:28.44 34.0%     0+0k 0+0io 60pf+0w

1GB RAM, 2GHz -- 0:28

    <root at cerebellum:~/>  time yum list '*mtr*'
    Setting up Repo:  base
    repomd.xml                100% |=========================| 1.1 kB    00:00
    Setting up Repo:  updates-released
    repomd.xml                100% |=========================|  951 B    00:00
    Reading repository metadata in from local files
    base      : ################################################## 2622/2622
    primary.xml.gz            100% |=========================| 180 kB    00:01
    MD Read   : ################################################## 408/408
    updates-re: ################################################## 408/408
    Installed Packages
    mtr.i386                                 2:0.54-10              installed
    Available Packages
    mtr-gtk.i386                             2:0.54-10              base
    5.836u 0.798s 0:28.18 23.4%     0+0k 0+0io 56pf+0w

1GB RAM, 2.2GHz -- 0:19

    <root at grendel:~/> time yum list '*mtr*'
    Setting up Repo:  livna-stable
    repomd.xml                100% |=========================|  951 B    00:00
    Setting up Repo:  base
    repomd.xml                100% |=========================| 1.1 kB    00:00
    Setting up Repo:  updates-released
    repomd.xml                100% |=========================|  951 B    00:00
    Setting up Repo:  livna-testing
    repomd.xml                100% |=========================|  951 B    00:00
    Reading repository metadata in from local files
    livna-stab: ################################################## 117/117
    base      : ################################################## 2622/2622
    updates-re: ################################################## 408/408
    livna-test: ################################################## 18/18
    Installed Packages
    mtr.i386                                 2:0.54-10              installed
    mtr-gtk.i386                             2:0.54-10              installed
    3.639u 0.409s 0:19.88 20.2%     0+0k 0+0io 0pf+0w


-- 
Jamie Zawinski         jwz at jwz.org                  http://www.jwz.org/
                       jwz at dnalounge.com      http://www.dnalounge.com/
                                            http://jwz.livejournal.com/



From skvidal at phy.duke.edu  Fri Dec 31 08:47:52 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 31 Dec 2004 03:47:52 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D509E5.5576F2E9@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
	<1104477645.3324.7.camel@stargrazer.home.awesomeplay.com>
	<41D509E5.5576F2E9@jwz.org>
Message-ID: <1104482872.3441.2.camel@cutter>

On Fri, 2004-12-31 at 00:12 -0800, Jamie Zawinski wrote:
> Sean Middleditch wrote:
> > 
> > It only takes a handful of seconds on my machine, which is only 1.5ghz.
> > Yum is *very* RAM intensive, so if you're low there, that might be the
> > slow down...?
> 
> By "a handful of seconds" do you mean "20"?  I think an acceptable 
> number would be, like, "3", but I'm seeing anywhere from 19 to 64, 
> on four different FC3 machines on two different networks:
> 



on my speedstepped to 600mhz laptop with 768M of ram:

time yum list '*mtr*'
Setting up Repo:  updates-released
Setting up Repo:  extras
Setting up Repo:  base
Reading repository metadata in from local files
updates-re: ################################################## 408/408
extras    : ################################################## 623/623
base      : ################################################## 1652/1652
Installed Packages
mtr.i386                                 2:0.54-10
installed
Available Packages
mtr-gtk.i386                             2:0.54-10              base

real    0m16.929s
user    0m5.974s
sys     0m0.531s


-sv




From fedora at wir-sind-cool.org  Fri Dec 31 09:10:06 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Fri, 31 Dec 2004 10:10:06 +0100
Subject: building own RPMs
In-Reply-To: <20041231053939.23343.qmail@web50507.mail.yahoo.com>
References: <20041226212232.0356f911.fedora@wir-sind-cool.org>
	<20041231053939.23343.qmail@web50507.mail.yahoo.com>
Message-ID: <20041231101006.7f3d6df4.fedora@wir-sind-cool.org>

On Thu, 30 Dec 2004 21:39:39 -0800 (PST), Kevin McConnell wrote:

> > http://fedoraproject.org/pre-extras/3/
> > 
> > $ rpm -qf $(which fedora-buildrpmtree)
> > fedora-rpmdevtools-0.2.0-1
> > 
> > Ralf might enjoy reading the header of the script.
> > ;)
> 
> Coulda saved an extra character by doing:
> $ rpm -qf `which fedora-buildrpmtree`
> fedora-rpmdevtools-0.2.0-1
> 
> ;) keep it lean 

Well, consider the possibility that I used the $(foo) command
substitution notation deliberately. That decision is not due to
personal preference alone, but it's based on the long-time experience
that it's rather newbie-safe and avoids read errors and type
errors. Depending on what font [or font size] the reader of my message
uses, the difference between a single quote character and the
backquote may not be obvious for everyone.

Btw, I should have typed

  $ which fedora-buildrpmtree
  /usr/bin/fedora-buildrpmtree
  $ rpm --query --file $(which fedora-buildrpmtree)
  fedora-rpmdevtools-0.2.0-1

for increased readability and to save even less space. ;)



From fedora at wir-sind-cool.org  Fri Dec 31 09:13:57 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Fri, 31 Dec 2004 10:13:57 +0100
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <20041231101357.4f7d6e57.fedora@wir-sind-cool.org>

On Thu, 30 Dec 2004 22:50:26 -0800, Jamie Zawinski wrote:

> Sean Middleditch wrote:
> > 
> > The problem you're perceiving (slow operation as yum starts up) isn't at
> > all due to lack of caching, but perhaps very inefficient handling of the
> > cache - a lot of data has to be parsed and such, when it could perhaps
> > be stored in a more ready-to-process format.
> 
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

$ time sudo yum install blurb
Setting up Install Process
Setting up Repo:  fedora-extras-local
repomd.xml                100% |=========================|  951 B    00:00     
Setting up Repo:  base
repomd.xml                100% |=========================|  951 B    00:00     
Setting up Repo:  updates-released
repomd.xml                100% |=========================|  951 B    00:00     
Reading repository metadata in from local files
fedora-ext: ################################################## 421/421
base      : ################################################## 1652/1652
updates-re: ################################################## 405/405
No Match for argument blurb
Nothing to do

real    0m9.838s
user    0m6.556s
sys     0m0.674s


And yes, this machine is clocked at less than 2 GHz, and no dependency
calculation included.



From veillard at redhat.com  Fri Dec 31 09:36:45 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 31 Dec 2004 04:36:45 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <20041231093645.GH31887@redhat.com>

On Thu, Dec 30, 2004 at 10:50:26PM -0800, Jamie Zawinski wrote:
> Sean Middleditch wrote:
> > 
> > The problem you're perceiving (slow operation as yum starts up) isn't at
> > all due to lack of caching, but perhaps very inefficient handling of the
> > cache - a lot of data has to be parsed and such, when it could perhaps
> > be stored in a more ready-to-process format.
> 
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

  Parsing the XML file and building the associated Python objects.

And before bashing XML and the cost of parsing, it's only a very small
fraction of the time spent, building the Python strings and objects is
the really costly part as we found with seth when doing basic tests.
My own test led me to believe that python string interning (take a 
string from the C layer or XML and get the copy from Python own string
implementation) is extremely costly, and of course we are manipulating
an very large amount of strings when collecting the repodata.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From symbiont at berlios.de  Fri Dec 31 10:15:21 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Fri, 31 Dec 2004 18:15:21 +0800
Subject: building own RPMs
In-Reply-To: <20041231101006.7f3d6df4.fedora@wir-sind-cool.org>
References: <20041226212232.0356f911.fedora@wir-sind-cool.org>
	<20041231053939.23343.qmail@web50507.mail.yahoo.com>
	<20041231101006.7f3d6df4.fedora@wir-sind-cool.org>
Message-ID: <200412311815.21773.symbiont@berlios.de>

On Friday 31 December 2004 17:10, Michael Schwendt wrote:
> backquote may not be obvious for everyone.

http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_119.html

-- 
-jeff



From fedora at wir-sind-cool.org  Fri Dec 31 10:28:47 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Fri, 31 Dec 2004 11:28:47 +0100
Subject: building own RPMs
In-Reply-To: <200412311815.21773.symbiont@berlios.de>
References: <20041226212232.0356f911.fedora@wir-sind-cool.org>
	<20041231053939.23343.qmail@web50507.mail.yahoo.com>
	<20041231101006.7f3d6df4.fedora@wir-sind-cool.org>
	<200412311815.21773.symbiont@berlios.de>
Message-ID: <20041231112847.31fb582a.fedora@wir-sind-cool.org>

On Fri, 31 Dec 2004 18:15:21 +0800, Jeff Pitman wrote:

> > backquote may not be obvious for everyone.
> 
> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_119.html
> 

Well, portability to Solaris or other shells is a completely different
matter. Default shell in Fedora Core is Bash.



From alan at redhat.com  Fri Dec 31 10:55:27 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 31 Dec 2004 05:55:27 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <20041231105527.GA24292@devserv.devel.redhat.com>

On Thu, Dec 30, 2004 at 10:50:26PM -0800, Jamie Zawinski wrote:
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

Demonstrating the myth that interpreted languages are fast enough.

It is actually doing a fair bit - its computing the dependancies, checking it
won't clash, checking the files fit etc



From arnaud.abelard at univ-nantes.fr  Fri Dec 31 11:54:55 2004
From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=)
Date: Fri, 31 Dec 2004 12:54:55 +0100
Subject: mozilla policies...
Message-ID: <41D53E0F.5030400@univ-nantes.fr>

Hello,

A post from Alexander Sack on the debian-legal mailing list 
(http://lists.debian.org/debian-legal/2004/12/msg00328.html) is 
announcing that the mozilla foundation asked Debian to remove all 
occurences of "Mozilla" from their mozilla products in order not to 
infrige with the mozilla foundation trademark policies. Especially the 
community editions terms as described in 
http://www.mozilla.org/foundation/trademarks/policy.html

I guess it also applies to Fedora? was Fedora also contacted by the 
Mozilla Foundation?

Unless i'm missing something, it sounds like the Mozilla Foundation is 
asking for a little too much from the packagers...

Usefull links:

Mozilla & Netscape Public Licenses:
http://www.mozilla.org/MPL/
http://www.mozilla.org/MPL/MPL-1.1.html

With annotations:
http://www.mozilla.org/MPL/MPL-1.1-annotated.html


A.



From lfarkas at bppiac.hu  Fri Dec 31 12:22:34 2004
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Fri, 31 Dec 2004 13:22:34 +0100
Subject: why doesn't yum cache anything?
In-Reply-To: <1104482872.3441.2.camel@cutter>
References: <41D4F36D.B7DA877@jwz.org>	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>	<41D4F6B2.183B0FA4@jwz.org>	<1104477645.3324.7.camel@stargrazer.home.awesomeplay.com>	<41D509E5.5576F2E9@jwz.org>
	<1104482872.3441.2.camel@cutter>
Message-ID: <41D5448A.5030602@bppiac.hu>

seth vidal wrote:
> On Fri, 2004-12-31 at 00:12 -0800, Jamie Zawinski wrote:
> 
>>Sean Middleditch wrote:
>>
>>>It only takes a handful of seconds on my machine, which is only 1.5ghz.
>>>Yum is *very* RAM intensive, so if you're low there, that might be the
>>>slow down...?
>>
>>By "a handful of seconds" do you mean "20"?  I think an acceptable 
>>number would be, like, "3", but I'm seeing anywhere from 19 to 64, 
>>on four different FC3 machines on two different networks:
>>
> 
> 
> 
> 
> on my speedstepped to 600mhz laptop with 768M of ram:
> 
> time yum list '*mtr*'
> Setting up Repo:  updates-released
> Setting up Repo:  extras
> Setting up Repo:  base
> Reading repository metadata in from local files
> updates-re: ################################################## 408/408
> extras    : ################################################## 623/623
> base      : ################################################## 1652/1652
> Installed Packages
> mtr.i386                                 2:0.54-10
> installed
> Available Packages
> mtr-gtk.i386                             2:0.54-10              base
> 
> real    0m16.929s
> user    0m5.974s
> sys     0m0.531s

both of you has right. jwz as an old hacker _feel_ there is something 
wrong with it. and he's right. yum is something an ms's product do not 
realy care about system resources and assume everyone has enough(?) cpu 
and memory. the new metadata format is questionable. not at the server 
side (but many people argue about it, see the thread about the smart 
package manager), but on the client side! even if the server use that 
xml format, because assume more different client will access to the same 
repo (like yum, up2date etc) why yum has to keep the xml data localy why 
can use a different sructure in the local cache? i hope the files like: 
primary.xml.gz.4efa5cf08ac4f47d510653cd61128a688bc39188.pickle are the 
binary representation of the xml data, but even in this case the local 
cache file can be separated into different files (eg. in most case the 
package description is not required why all packages description is 
loaded, and there are many other mostly unused data). in this case this 
time probably can be decrease down to a few seconds. and the situation 
linear with the number of repos.
on the other side i understand seth's position, that first create a 
feature rich complete and bug-free version somewhere 2.1 or 2.2. but 
it's clear to everyone that the most anoying think with you it's speed, 
both at startup/load time and both at dependencie resolution time. so 
imho it'd be nice to look into this problems soon. something like the 
bootchart challenge would be useful in case of yum speed.
yours.

-- 
   Levente                               "Si vis pacem para bellum!"



From lfarkas at bppiac.hu  Fri Dec 31 12:27:49 2004
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Fri, 31 Dec 2004 13:27:49 +0100
Subject: why doesn't yum cache anything?
In-Reply-To: <20041231093645.GH31887@redhat.com>
References: <41D4F36D.B7DA877@jwz.org>	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>	<41D4F6B2.183B0FA4@jwz.org>
	<20041231093645.GH31887@redhat.com>
Message-ID: <41D545C5.6010305@bppiac.hu>

Daniel Veillard wrote:
> On Thu, Dec 30, 2004 at 10:50:26PM -0800, Jamie Zawinski wrote:
> 
>>Sean Middleditch wrote:
>>
>>>The problem you're perceiving (slow operation as yum starts up) isn't at
>>>all due to lack of caching, but perhaps very inefficient handling of the
>>>cache - a lot of data has to be parsed and such, when it could perhaps
>>>be stored in a more ready-to-process format.
>>
>>It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
>>If it's not hitting the net, what's it doing, raytracing?
> 
> 
>   Parsing the XML file and building the associated Python objects.
> 
> And before bashing XML and the cost of parsing, it's only a very small
> fraction of the time spent, building the Python strings and objects is
> the really costly part as we found with seth when doing basic tests.
> My own test led me to believe that python string interning (take a 
> string from the C layer or XML and get the copy from Python own string
> implementation) is extremely costly, and of course we are manipulating
> an very large amount of strings when collecting the repodata.

have you already made some real mesurement? than wouldn't be useful to 
implement that small portion in C? or it isn't so small part?

-- 
   Levente                               "Si vis pacem para bellum!"



From buildsys at redhat.com  Fri Dec 31 13:01:30 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 31 Dec 2004 08:01:30 -0500
Subject: rawhide report: 20041231 changes
Message-ID: <200412311301.iBVD1U907523@porkchop.devel.redhat.com>

 

 
Updated Packages:

kernel-2.6.10-1.1056_FC4
------------------------
* Thu Dec 30 2004 Dave Jones <davej at redhat.com>
- Rebase to 2.6.10-bk3

* Tue Dec 28 2004 Dave Jones <davej at redhat.com>
- Drop bogus ethernet slab cache.

* Sun Dec 26 2004 Dave Jones <davej at redhat.com>
- Santa brought a new card reader that needs whitelisting.

lynx-2.8.5-20
-------------
* Thu Dec 30 2004 Tim Waugh <twaugh at redhat.com> 2.8.5-20
- Added --enable-locale-charset compilation option, set LOCALE_CHARSET
  on in the config file and removed i18ncfg patch (bug #124849).

rpmdb-fedora-1:4-0.20041231
---------------------------

texinfo-4.7-6
-------------
* Thu Dec 30 2004 Tim Waugh <twaugh at redhat.com> 4.7-6
- Fixed URL (bug #143729).



From veillard at redhat.com  Fri Dec 31 13:04:59 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 31 Dec 2004 08:04:59 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D545C5.6010305@bppiac.hu>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org> <20041231093645.GH31887@redhat.com>
	<41D545C5.6010305@bppiac.hu>
Message-ID: <20041231130459.GI31887@redhat.com>

On Fri, Dec 31, 2004 at 01:27:49PM +0100, Farkas Levente wrote:
> Daniel Veillard wrote:
> >  Parsing the XML file and building the associated Python objects.
> >
> >And before bashing XML and the cost of parsing, it's only a very small
> >fraction of the time spent, building the Python strings and objects is
> >the really costly part as we found with seth when doing basic tests.
> >My own test led me to believe that python string interning (take a 
> >string from the C layer or XML and get the copy from Python own string
> >implementation) is extremely costly, and of course we are manipulating
> >an very large amount of strings when collecting the repodata.
> 
> have you already made some real mesurement?

  of what ? yes I know exactly how long it takes libxml2 to parse
the data: 

[root at localhost ~]# xmllint --stream --timing /var/cache/yum/base/primary.xml.gzParsing took 1094 ms

  using the reader at the C level, this include decompressing the archive
and walking though all nodes. The main cost is to turn the parsed data into
Python's internal representation as I said.

> than wouldn't be useful to 
> implement that small portion in C? or it isn't so small part?

  The string interning is in the Python lib, probably in C as it's a C API
as far as I can tell. And no I din't looked at python internal code.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From lists at arctur.us  Fri Dec 31 13:19:09 2004
From: lists at arctur.us (Mitch Skinner)
Date: Fri, 31 Dec 2004 05:19:09 -0800
Subject: why doesn't yum cache anything?
In-Reply-To: <20041231105527.GA24292@devserv.devel.redhat.com>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
	<20041231105527.GA24292@devserv.devel.redhat.com>
Message-ID: <1104499149.3875.5.camel@zeitgeist>

On Fri, 2004-12-31 at 05:55 -0500, Alan Cox wrote:
> It is actually doing a fair bit - its computing the dependancies, checking it
> won't clash, checking the files fit etc

Does apt do all of those things every time it starts up?  It certainly
feels a lot faster, more than I would expect from just the language
difference.

I wanted to look at the apt-rpm sources, so I googled for "apt rpm cvs"
and came up with
https://oops.kerneljanitors.org/repos/apt-rpm
but I get an error message there.

Mitch



From caillon at redhat.com  Fri Dec 31 13:35:05 2004
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 31 Dec 2004 08:35:05 -0500
Subject: mozilla policies...
In-Reply-To: <41D53E0F.5030400@univ-nantes.fr>
References: <41D53E0F.5030400@univ-nantes.fr>
Message-ID: <41D55589.5020500@redhat.com>

Arnaud Ab?lard wrote:
> the mozilla foundation asked Debian
...
> I guess it also applies to Fedora? was Fedora also contacted by the 
> Mozilla Foundation?


Since when does Debian == Fedora?  :-)

We have an agreement with the Mozilla Foundation as far as I am aware.


> Unless i'm missing something, it sounds like the Mozilla Foundation is 
> asking for a little too much from the packagers...


You should bring that up with the Mozilla Foundation.



From kaspars at os.lv  Fri Dec 31 13:43:10 2004
From: kaspars at os.lv (Kaspars)
Date: Fri, 31 Dec 2004 15:43:10 +0200
Subject: Compiling src OpenOffice.org 1.1.4 on FC3
Message-ID: <41D5576E.8070102@os.lv>


  Hi,

  I try to compile on FC3 lates OpenOffice.org, but without success.
Maybe somebody have better lack with it? Know what I`m doing wrong.

I`m doing:
$cd OOo_src/config_office/
$./configure --prefix=/opt/OOo --with-jdk-home=/opt/java/ \
--with-x --enable-libart
$tcsh -c "source LinuxIntelEnv.Set; ./bootstrap"
$tcsh -c "source LinuxIntelEnv.Set; dmake"

and thats the error:
STLport-4.5/doc/doc.css
make writeable...
echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak
touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak
echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak
touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak
echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak
touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak
echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak
touch ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak
cd ./unxlngi4.pro/misc/build && cat ../../../STLport-4.5.patch | patch 
-b -p2 &&  touch so_patched_so_stlport
patching file STLport-4.5/src/dll_main.cpp
patching file STLport-4.5/src/gcc-3.0-freebsd.mak
patching file STLport-4.5/src/gcc-3.0-macosx.mak
patching file STLport-4.5/src/gcc-3.0.mak
patching file STLport-4.5/src/gcc-freebsd.mak
patching file STLport-4.5/stlport/config/stl_gcc.h
patching file STLport-4.5/stlport/cwchar
patching file STLport-4.5/stlport/stdexcept
patching file STLport-4.5/stlport/stl/_threads.h
touch ./unxlngi4.pro/misc/build/so_addfiles_so_stlport
touch ./unxlngi4.pro/misc/build/so_patched_so_stlport
touch ./unxlngi4.pro/misc/build/so_configured_so_stlport
mkdir ./unxlngi4.pro/misc/build/STLport-4.5/src
mkdir: cannot create directory 
`./unxlngi4.pro/misc/build/STLport-4.5/src': File  exists
cd ./unxlngi4.pro/misc/build/STLport-4.5/src && make -f gcc-3.0.mak -j1 
&& touch  so_built_so_stlport
mkdir -p ../lib/obj/GCC/ReleaseD
g++ -D_REENTRANT 
-DGXX_INCLUDE_PATH=/usr/lib/gcc/i386-redhat-linux/3.4.2/../../. 
./../include/c++/3.4.2 -fexceptions -I../stlport -Wall -W 
-Wno-sign-compare -Wno -unused -Wno-uninitialized -ftemplate-depth-32 
-O2 -fPIC dll_main.cpp -c -o ../l ib/obj/GCC/ReleaseD/dll_main.o
In file included from stlport_prefix.h:28,
                  from dll_main.cpp:34:
../stlport/ctime:25:44: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++ /3.4.2/ctime: 
No such file or directory
In file included from stlport_prefix.h:28,
                  from dll_main.cpp:34:
../stlport/ctime:32: error: `__std_alias::size_t' has not been declared
../stlport/ctime:33: error: `__std_alias::clock_t' has not been declared
../stlport/ctime:34: error: `__std_alias::time_t' has not been declared
../stlport/ctime:35: error: `__std_alias::tm' has not been declared
../stlport/ctime:37: error: `__std_alias::clock' has not been declared
../stlport/ctime:38: error: `__std_alias::asctime' has not been declared
../stlport/ctime:39: error: `__std_alias::ctime' has not been declared
../stlport/ctime:40: error: `__std_alias::gmtime' has not been declared
../stlport/ctime:41: error: `__std_alias::difftime' has not been declared
../stlport/ctime:42: error: `__std_alias::mktime' has not been declared
../stlport/ctime:43: error: `__std_alias::localtime' has not been declared
../stlport/ctime:44: error: `__std_alias::strftime' has not been declared
../stlport/ctime:45: error: `__std_alias::time' has not been declared
In file included from dll_main.cpp:34:
stlport_prefix.h:30: error: `__std_alias::time_t' has not been declared
In file included from ../stlport/stl/debug/_debug.c:160,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdlib:25:46: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdlib: 
No such file or directory
In file included from ../stlport/stl/debug/_debug.c:160,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdlib:42: error: `__std_alias::div_t' has not been declared
../stlport/cstdlib:43: error: `__std_alias::ldiv_t' has not been declared
../stlport/cstdlib:44: error: `__std_alias::size_t' has not been declared
../stlport/cstdlib:47: error: `__std_alias::abort' has not been declared
../stlport/cstdlib:48: error: `__std_alias::atexit' has not been declared
../stlport/cstdlib:49: error: `__std_alias::exit' has not been declared
../stlport/cstdlib:50: error: `__std_alias::getenv' has not been declared
../stlport/cstdlib:51: error: `__std_alias::calloc' has not been declared
../stlport/cstdlib:52: error: `__std_alias::free' has not been declared
../stlport/cstdlib:53: error: `__std_alias::malloc' has not been declared
../stlport/cstdlib:54: error: `__std_alias::realloc' has not been declared
../stlport/cstdlib:55: error: `__std_alias::atof' has not been declared
../stlport/cstdlib:56: error: `__std_alias::atoi' has not been declared
../stlport/cstdlib:57: error: `__std_alias::atol' has not been declared
../stlport/cstdlib:58: error: `__std_alias::mblen' has not been declared
../stlport/cstdlib:59: error: `__std_alias::mbstowcs' has not been declared
../stlport/cstdlib:60: error: `__std_alias::mbtowc' has not been declared
../stlport/cstdlib:61: error: `__std_alias::strtod' has not been declared
../stlport/cstdlib:62: error: `__std_alias::strtol' has not been declared
../stlport/cstdlib:63: error: `__std_alias::strtoul' has not been declared
../stlport/cstdlib:64: error: `__std_alias::system' has not been declared
../stlport/cstdlib:70: error: `__std_alias::bsearch' has not been declared
../stlport/cstdlib:71: error: `__std_alias::qsort' has not been declared
../stlport/cstdlib:74: error: `__std_alias::abs' has not been declared
../stlport/cstdlib:76: error: `__std_alias::div' has not been declared
../stlport/cstdlib:77: error: `__std_alias::labs' has not been declared
../stlport/cstdlib:78: error: `__std_alias::ldiv' has not been declared
../stlport/cstdlib:79: error: `__std_alias::rand' has not been declared
../stlport/cstdlib:80: error: `__std_alias::srand' has not been declared
In file included from ../stlport/stl/debug/_debug.c:236,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdarg:25:46: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdarg: 
No such file or directory
In file included from ../stlport/stl/debug/_debug.c:236,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdarg:32: error: `__std_alias::va_list' has not been declared
In file included from ../stlport/stl/debug/_debug.c:237,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdio:27:45: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c+ +/3.4.2/cstdio: 
No such file or directory
In file included from ../stlport/stl/debug/_debug.c:237,
                  from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/cstdio:51: error: `__std_alias::FILE' has not been declared
../stlport/cstdio:52: error: `__std_alias::fpos_t' has not been declared
../stlport/cstdio:53: error: `__std_alias::size_t' has not been declared
../stlport/cstdio:64: error: `__std_alias::clearerr' has not been declared
../stlport/cstdio:65: error: `__std_alias::fclose' has not been declared
../stlport/cstdio:66: error: `__std_alias::feof' has not been declared
../stlport/cstdio:67: error: `__std_alias::ferror' has not been declared
../stlport/cstdio:68: error: `__std_alias::fflush' has not been declared
../stlport/cstdio:69: error: `__std_alias::fgetc' has not been declared
../stlport/cstdio:70: error: `__std_alias::fgetpos' has not been declared
../stlport/cstdio:71: error: `__std_alias::fgets' has not been declared
../stlport/cstdio:72: error: `__std_alias::fopen' has not been declared
../stlport/cstdio:73: error: `__std_alias::fprintf' has not been declared
../stlport/cstdio:74: error: `__std_alias::fputc' has not been declared
../stlport/cstdio:75: error: `__std_alias::fputs' has not been declared
../stlport/cstdio:76: error: `__std_alias::fread' has not been declared
../stlport/cstdio:77: error: `__std_alias::freopen' has not been declared
../stlport/cstdio:78: error: `__std_alias::fscanf' has not been declared
../stlport/cstdio:79: error: `__std_alias::fseek' has not been declared
../stlport/cstdio:80: error: `__std_alias::fsetpos' has not been declared
../stlport/cstdio:81: error: `__std_alias::ftell' has not been declared
../stlport/cstdio:82: error: `__std_alias::fwrite' has not been declared
../stlport/cstdio:85: error: `__std_alias::getc' has not been declared
../stlport/cstdio:86: error: `__std_alias::getchar' has not been declared
../stlport/cstdio:87: error: `__std_alias::putc' has not been declared
../stlport/cstdio:88: error: `__std_alias::putchar' has not been declared
../stlport/cstdio:91: error: `__std_alias::gets' has not been declared
../stlport/cstdio:92: error: `__std_alias::perror' has not been declared
../stlport/cstdio:93: error: `__std_alias::printf' has not been declared
../stlport/cstdio:94: error: `__std_alias::puts' has not been declared
../stlport/cstdio:95: error: `__std_alias::remove' has not been declared
../stlport/cstdio:96: error: `__std_alias::rename' has not been declared
../stlport/cstdio:97: error: `__std_alias::rewind' has not been declared
../stlport/cstdio:98: error: `__std_alias::scanf' has not been declared
../stlport/cstdio:99: error: `__std_alias::setbuf' has not been declared
../stlport/cstdio:100: error: `__std_alias::setvbuf' has not been declared
../stlport/cstdio:101: error: `__std_alias::sprintf' has not been declared
../stlport/cstdio:102: error: `__std_alias::sscanf' has not been declared
../stlport/cstdio:103: error: `__std_alias::tmpfile' has not been declared
../stlport/cstdio:104: error: `__std_alias::tmpnam' has not been declared
../stlport/cstdio:105: error: `__std_alias::ungetc' has not been declared
../stlport/cstdio:106: error: `__std_alias::vfprintf' has not been declared
../stlport/cstdio:107: error: `__std_alias::vprintf' has not been declared
../stlport/cstdio:108: error: `__std_alias::vsprintf' has not been declared
../stlport/cstdio:111: error: `__std_alias::vsnprintf' has not been declared
In file included from ../stlport/stl/debug/_debug.h:418,
                  from ../stlport/utility:36,
                  from dll_main.cpp:36:
../stlport/stl/debug/_debug.c: In static member function `static void 
_STL::__st l_debug_engine<_Dummy>::_Message(const char*, ...)':
../stlport/stl/debug/_debug.c:245: error: `va_list' is not a member of 
`__std_al ias'
../stlport/stl/debug/_debug.c:245: error: expected `;' before "__args"
../stlport/stl/debug/_debug.c:246: error: `__args' undeclared (first use 
this fu nction)
../stlport/stl/debug/_debug.c:246: error: (Each undeclared identifier is 
reporte d only once for each function it appears in.)
../stlport/stl/debug/_debug.c:246: error: there are no arguments to 
`va_start' t hat depend on a template parameter, so a declaration of 
`va_start' must be avail able
../stlport/stl/debug/_debug.c:246: error: (if you use `-fpermissive', 
G++ will a ccept your code, but allowing the use of an undeclared name 
is deprecated)
../stlport/stl/debug/_debug.c:263: error: `vfprintf' is not a member of 
`__std_a lias'
../stlport/stl/debug/_debug.c:263: error: `stderr' undeclared (first use 
this fu nction)
../stlport/stl/debug/_debug.c:270: error: there are no arguments to 
`va_end' tha t depend on a template parameter, so a declaration of 
`va_end' must be available
../stlport/stl/debug/_debug.c: In static member function `static void 
_STL::__st l_debug_engine<_Dummy>::_Terminate()':
../stlport/stl/debug/_debug.c:319: error: there are no arguments to 
`abort' that  depend on a template parameter, so a declaration of 
`abort' must be available
In file included from ../stlport/stl/_alloc.h:31,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/cstddef:35:46: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstddef: 
No such file or directory
In file included from ../stlport/stl/_alloc.h:31,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/cstddef: At global scope:
../stlport/cstddef:42: error: `__std_alias::ptrdiff_t' has not been declared
../stlport/cstddef:43: error: `__std_alias::size_t' has not been declared
In file included from ../stlport/stl/_alloc.h:42,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/cstring:25:46: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstring: 
No such file or directory
In file included from ../stlport/cstring:32,
                  from ../stlport/stl/_alloc.h:42,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/using/cstring:1: error: `__std_alias::size_t' has not been 
declared
../stlport/using/cstring:17: error: `__std_alias::memmove' has not been 
declared
../stlport/using/cstring:18: error: `__std_alias::memcpy' has not been 
declared
../stlport/using/cstring:23: error: `__std_alias::memchr' has not been 
declared
../stlport/using/cstring:24: error: `__std_alias::strchr' has not been 
declared
../stlport/using/cstring:25: error: `__std_alias::strpbrk' has not been 
declared
../stlport/using/cstring:26: error: `__std_alias::strrchr' has not been 
declared
../stlport/using/cstring:27: error: `__std_alias::strstr' has not been 
declared
../stlport/using/cstring:30: error: `__std_alias::memcmp' has not been 
declared
../stlport/using/cstring:31: error: `__std_alias::memset' has not been 
declared
../stlport/using/cstring:33: error: `__std_alias::strcat' has not been 
declared
../stlport/using/cstring:36: error: `__std_alias::strcmp' has not been 
declared
../stlport/using/cstring:39: error: `__std_alias::strcoll' has not been 
declared
../stlport/using/cstring:41: error: `__std_alias::strcpy' has not been 
declared
../stlport/using/cstring:43: error: `__std_alias::strcspn' has not been 
declared
../stlport/using/cstring:44: error: `__std_alias::strerror' has not been 
declare d
../stlport/using/cstring:45: error: `__std_alias::strlen' has not been 
declared
../stlport/using/cstring:46: error: `__std_alias::strncat' has not been 
declared
../stlport/using/cstring:47: error: `__std_alias::strncmp' has not been 
declared
../stlport/using/cstring:49: error: `__std_alias::strncpy' has not been 
declared
../stlport/using/cstring:50: error: `__std_alias::strspn' has not been 
declared
../stlport/using/cstring:52: error: `__std_alias::strtok' has not been 
declared
../stlport/using/cstring:53: error: `__std_alias::strxfrm' has not been 
declared
In file included from ../stlport/stl/_alloc.h:60,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/new:50:49: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++/3 .4.2/new: No 
such file or directory
In file included from ../stlport/stl/_alloc.h:60,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/new:58: error: `__std_alias::bad_alloc' has not been declared
../stlport/new:59: error: `__std_alias::nothrow_t' has not been declared
../stlport/new:60: error: `__std_alias::nothrow' has not been declared
../stlport/new:66: error: `__std_alias::new_handler' has not been declared
../stlport/new:67: error: `__std_alias::set_new_handler' has not been 
declared
../stlport/new:112: error: `_STL::__stl_new' declared as an `inline' 
variable
../stlport/new:112: error: `size_t' was not declared in this scope
../stlport/new:112: error: expected `,' or `;' before '{' token
In file included from ../stlport/stl/_alloc.h:64,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_threads.h:53: error: `size_t' does not name a type
In file included from ../stlport/stl/_alloc.h:64,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_threads.h:207: error: expected `,' or `...' before '*' token
../stlport/stl/_threads.h:207: error: ISO C++ forbids declaration of 
`__stl_atom ic_t' with no type
../stlport/stl/_threads.h: In member function `void 
_STL::_STLP_mutex_indirect:: _M_initialize()':
../stlport/stl/_threads.h:340: error: `calloc' is not a member of 
`__std_alias'
../stlport/stl/_threads.h: In member function `void 
_STL::_STLP_mutex_indirect:: _M_destroy()':
../stlport/stl/_threads.h:345: error: `free' undeclared (first use this 
function )
../stlport/stl/_threads.h: At global scope:
../stlport/stl/_threads.h:409: error: `__stl_atomic_t' does not name a type
../stlport/stl/_threads.h:416: error: expected `)' before "__n"
../stlport/stl/_threads.h: In member function `void 
_STL::_Refcount_Base::_M_inc r()':
../stlport/stl/_threads.h:425: error: `_M_ref_count' undeclared (first 
use this function)
../stlport/stl/_threads.h: In member function `void 
_STL::_Refcount_Base::_M_dec r()':
../stlport/stl/_threads.h:430: error: `_M_ref_count' undeclared (first 
use this function)
../stlport/stl/_threads.h: At global scope:
../stlport/stl/_threads.h:458: error: `__stl_atomic_t' does not name a type
In file included from ../stlport/stl/_threads.h:552,
                  from ../stlport/stl/_alloc.h:64,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_threads.c:36: error: `__std_alias::time_t' has not been 
declared
In file included from ../stlport/stl/_threads.h:552,
                  from ../stlport/stl/_alloc.h:64,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_threads.c:98: error: expected `,' or `...' before '*' token
../stlport/stl/_threads.c:99: error: ISO C++ forbids declaration of 
`__stl_atomi c_t' with no type
In file included from ../stlport/stl/_construct.h:43,
                  from ../stlport/stl/_alloc.h:68,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_iterator_base.h:50: error: `ptrdiff_t' has not been declared
../stlport/stl/_iterator_base.h:113: error: `ptrdiff_t' does not name a type
../stlport/stl/_iterator_base.h:122: error: `ptrdiff_t' does not name a type
In file included from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_alloc.h: In static member function `static void* 
_STL::__malloc_ alloc<__inst>::allocate(size_t)':
../stlport/stl/_alloc.h:110: error: there are no arguments to `malloc' 
that depe nd on a template parameter, so a declaration of `malloc' must 
be available
../stlport/stl/_alloc.h: In static member function `static void 
_STL::__malloc_a lloc<__inst>::deallocate(void*, size_t)':
../stlport/stl/_alloc.h:114: error: there are no arguments to `free' 
that depend  on a template parameter, so a declaration of `free' must be 
available
../stlport/stl/_alloc.h: In static member function `static void* 
_STL::__new_all oc::allocate(size_t)':
../stlport/stl/_alloc.h:134: error: `_STL::__stl_new' cannot be used as 
a functi on
../stlport/stl/_alloc.h: In static member function `static void* 
_STL::__node_al loc<__threads, __inst>::allocate(size_t)':
../stlport/stl/_alloc.h:251: error: `_STL::__stl_new' cannot be used as 
a functi on
../stlport/stl/_alloc.h: At global scope:
../stlport/stl/_alloc.h:339: error: `ptrdiff_t' does not name a type
../stlport/stl/_alloc.h:377: error: `ptrdiff_t' does not name a type
../stlport/stl/_alloc.h:416: error: non-template `rebind' used as template
../stlport/stl/_alloc.h:416: note: use `_Allocator::template rebind' to 
indicate  that it is a template
../stlport/stl/_alloc.h:416: error: declaration does not declare anything
../stlport/stl/_alloc.h:417: error: `_Rebind_type' has not been declared
../stlport/stl/_alloc.h:417: error: expected nested-name-specifier 
before "other "
../stlport/stl/_alloc.h:417: error: `other' does not name a type
../stlport/stl/_alloc.h:418: error: `allocator_type' does not name a type
../stlport/stl/_alloc.h: In function `typename _STL::_Alloc_traits<_Tp, 
_Allocat or>::allocator_type _STL::__stl_alloc_create(const _Alloc&, 
const _Tp*)':
../stlport/stl/_alloc.h:460: error: non-template `rebind' used as template
../stlport/stl/_alloc.h:460: note: use `_Alloc::template rebind' to 
indicate tha t it is a template
../stlport/stl/_alloc.h:460: error: declaration does not declare anything
In file included from ../stlport/stl/_alloc.h:517,
                  from ../stlport/memory:28,
                  from dll_main.cpp:38:
../stlport/stl/_alloc.c: In static member function `static void* 
_STL::__malloc_ alloc<__inst>::_S_oom_malloc(size_t)':
../stlport/stl/_alloc.c:69: error: `bad_alloc' is not a member of `_STL'
../stlport/stl/_alloc.c:71: error: there are no arguments to `malloc' 
that depen d on a template parameter, so a declaration of `malloc' must 
be available
../stlport/stl/_alloc.c: In static member function `static char* 
_STL::__node_al loc<__threads, __inst>::_S_chunk_alloc(size_t, int&)':
../stlport/stl/_alloc.c:218: error: `_STL::__stl_new' cannot be used as 
a functi on
../stlport/stl/_alloc.c:239: error: `_STL::__stl_new' cannot be used as 
a functi on
In file included from ../stlport/stl/_tempbuf.h:34,
                  from ../stlport/memory:32,
                  from dll_main.cpp:38:
../stlport/climits:27:46: 
/usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/climits: 
No such file or directory
In file included from ../stlport/stl/_uninitialized.h:38,
                  from ../stlport/stl/_tempbuf.h:40,
                  from ../stlport/memory:32,
                  from dll_main.cpp:38:
../stlport/stl/_algobase.h: In function `void* 
_STL::__copy_trivial(const void*,  const void*, void*)':
../stlport/stl/_algobase.h:149: error: `memmove' undeclared (first use 
this func tion)
../stlport/stl/_algobase.h: In function `void* 
_STL::__copy_trivial_backward(con st void*, const void*, void*)':
../stlport/stl/_algobase.h:183: error: `ptrdiff_t' does not name a type
../stlport/stl/_algobase.h:184: error: `_Num' undeclared (first use this 
functio n)
../stlport/stl/_algobase.h:184: error: `memmove' undeclared (first use 
this func tion)
../stlport/stl/_algobase.h: In function `void _STL::fill(unsigned char*, 
unsigne d char*, const unsigned char&)':
../stlport/stl/_algobase.h:345: error: `memset' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h: In function `void _STL::fill(signed char*, 
signed ch ar*, const signed char&)':
../stlport/stl/_algobase.h:351: error: `memset' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h: In function `void _STL::fill(char*, char*, 
const cha r&)':
../stlport/stl/_algobase.h:356: error: `memset' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h: In function `bool 
_STL::lexicographical_compare(cons t unsigned char*, const unsigned 
char*, const unsigned char*, const unsigned cha r*)':
../stlport/stl/_algobase.h:464: error: `memcmp' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h: In function `int 
_STL::__lexicographical_compare_3wa y(const unsigned char*, const 
unsigned char*, const unsigned char*, const unsign ed char*)':
../stlport/stl/_algobase.h:493: error: `ptrdiff_t' does not name a type
../stlport/stl/_algobase.h:494: error: `ptrdiff_t' does not name a type
../stlport/stl/_algobase.h:495: error: `__len1' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h:495: error: `__len2' undeclared (first use 
this funct ion)
../stlport/stl/_algobase.h:495: error: `memcmp' undeclared (first use 
this funct ion)
In file included from ../stlport/memory:32,
                  from dll_main.cpp:38:
../stlport/stl/_tempbuf.h: At global scope:
../stlport/stl/_tempbuf.h:46: error: `ptrdiff_t' was not declared in 
this scope
../stlport/stl/_tempbuf.h:47: error: template argument 2 is invalid
../stlport/stl/_tempbuf.h:47: error: invalid type in declaration before 
'(' toke n
../stlport/stl/_tempbuf.h:47: error: template declaration of `int 
_STL::__get_te mporary_buffer'
../stlport/stl/_tempbuf.h:47: error: `ptrdiff_t' was not declared in 
this scope
../stlport/stl/_tempbuf.h:47: error: expected primary-expression before 
'*' toke n
../stlport/stl/_tempbuf.h:47: error: expected primary-expression before 
')' toke n
../stlport/stl/_tempbuf.h:47: confused by earlier errors, bailing out
make: *** [../lib/obj/GCC/ReleaseD/dll_main.o] Error 1
dmake:  Error code 2, while making 
'./unxlngi4.pro/misc/build/so_built_so_stlpor t'
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while making 
/home/kaspars/install/ooo/OOo/stlport
dmake:  Error code 1, while making 'build_all'
---* TG_SLO.MK *---


thanks,

Casper



From alan at redhat.com  Fri Dec 31 13:50:45 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 31 Dec 2004 08:50:45 -0500
Subject: mozilla policies...
In-Reply-To: <41D53E0F.5030400@univ-nantes.fr>
References: <41D53E0F.5030400@univ-nantes.fr>
Message-ID: <20041231135045.GA22343@devserv.devel.redhat.com>

On Fri, Dec 31, 2004 at 12:54:55PM +0100, Arnaud Ab?lard wrote:
> Unless i'm missing something, it sounds like the Mozilla Foundation is 
> asking for a little too much from the packagers...

Apache asks much the same. Thats why we ship httpd. Fedora likewise asks much
the same. Without that kind of control trademarks mean nothing and a poor
distributor can really damage a products reputation.

It is a pain sometimes - eg the Firefox people appear to be ignoring the Welsh
language request bug for months so technically I'd have to rename Firefox in
order to make it useful in this part of the world, but thats a failure of the
Firefox bug management not of the trademark policy.

It is also _very_ hard to write a sane trademark policy in the open source
world. The Fedora one took a lot of doing and isn't perfect. The Gnome people
have been failing for about four years to write a workable trademark policy,
but in the end shipped the logo in question as part of GPL packages so probably
made it irrelevant.

See::

http://forums.mozillazine.org/viewtopic.php?p=366523



From paul at all-the-johnsons.co.uk  Fri Dec 31 14:42:58 2004
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 31 Dec 2004 14:42:58 +0000
Subject: Compiling src OpenOffice.org 1.1.4 on FC3
In-Reply-To: <41D5576E.8070102@os.lv>
References: <41D5576E.8070102@os.lv>
Message-ID: <1104504178.3588.86.camel@localhost.localdomain>

Hi,

> ../stlport/ctime:25:44: 
> /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++ /3.4.2/ctime: 
> No such file or directory

That's insane!

It moves into the lib area and then goes back to /usr and then into
include. Is the space a typo? If it isn't, then that is the problem

find /usr/include/c++/ -name ctime*
/usr/include/c++/3.4.3/ctime

TTFN

Paul

-- 
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041231/e6e40bd5/attachment.sig>

From lists at arctur.us  Fri Dec 31 15:15:57 2004
From: lists at arctur.us (Mitch Skinner)
Date: Fri, 31 Dec 2004 07:15:57 -0800
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F36D.B7DA877@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
Message-ID: <1104506157.3875.25.camel@zeitgeist>

A sample profile of a yum -C list command from my machine (1.4GHz, 1GB
RAM):

         223695 function calls (223189 primitive calls) in 14.600 CPU
seconds

   Ordered by: internal time
   List reduced from 358 to 20 due to restriction <20>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        4    2.150    0.538    2.150    0.538 mdcache.py:58(_unpickle)
        1    1.680    1.680    3.680    3.680 packageSack.py:168
(buildIndexes)
    83615    1.680    0.000    1.680    0.000 packageSack.py:136
(_addToDictAsList)
     3485    1.650    0.000    1.650    0.000 packages.py:402
(importFromDict)
     8149    0.910    0.000    1.390    0.000 packageObject.py:50
(returnNevraTuple)
        1    0.790    0.790    0.810    0.810 __init__.py:59(addDB)
     3485    0.780    0.000    2.820    0.001 packages.py:305(__init__)
     3485    0.770    0.000    0.770    0.000 output.py:43
(simpleProgressBar)
    68424    0.730    0.000    0.730    0.000 packageObject.py:36
(returnSimple)
        1    0.720    0.720    0.720    0.720 __init__.py:88(getHdrList)
        1    0.340    0.340   13.860   13.860 __init__.py:598
(doPackageLists)
        4    0.300    0.075    5.230    1.307 repos.py:40(addDict)
     6090    0.290    0.000    0.290    0.000 packages.py:194(tagByName)
     3485    0.280    0.000    1.220    0.000 packageSack.py:155
(addPackage)
     3485    0.150    0.000    0.150    0.000 packageObject.py:207
(__init__)
     1015    0.100    0.000    0.410    0.000 packages.py:173(__init__)
     6996    0.100    0.000    0.100    0.000 packageObject.py:290
(returnFileEntries)
     2114    0.100    0.000    0.200    0.000 sre.py:177(compile)
        1    0.100    0.100    7.500    7.500 repos.py:164(populateSack)
        2    0.090    0.045    0.090    0.045 packages.py:34
(buildPkgRefDict)

The profile was produced by the bit of python below.  It looks like the
biggest user is _unpickle in mdcache.py, which just calls python's
built-in deserialization that's implemented in C (cPickle), which is
about as close as it gets to pure caching, I think.

I notice that the following two lines are taking up a fair chunk of
time:
        1    1.680    1.680    3.680    3.680 packageSack.py:168
(buildIndexes)
    83615    1.680    0.000    1.680    0.000 packageSack.py:136
(_addToDictAsList)
and it looks like they're (only?) used in dependency solving; could we
leave that work out of commands like list and search?

Certainly, depsolving is a lot faster than it used to be, and I think
the indexing is great if it speeds that up; I just wish I didn't have to
wait for it when I don't need to depsolve.

Mitch

import sys
sys.path.insert(0, '/usr/share/yum-cli')
import yummain
import profile
import pstats

p = profile.Profile()
try:
    p.run('yummain.main(["-C", "list", "*mtr*"])')
except SystemExit, e:
    pass

pst = pstats.Stats(p)
pst.strip_dirs().sort_stats('time').print_stats(20)




From lists at sapience.com  Fri Dec 31 15:22:34 2004
From: lists at sapience.com (Mail Lists)
Date: Fri, 31 Dec 2004 10:22:34 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F36D.B7DA877@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
Message-ID: <20041231152234.GA20113@sapience.com>

On Thu, Dec 30, 2004 at 10:36:29PM -0800, Jamie Zawinski wrote:
>   - Is there some way to make yum cache all that crap?  I'd be 
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

 (speed of yum discussion exceised).


  Related yum question on (lack of?) speed when large number of
  updates to do.

 After doing a fresh install, the first yum update can 
 take (for me) hours - this is after I have pre populated 
 the local cache (/var/cache/yum) from another just 
 installed/updated machine - so no downloads 
 to do at all.  The number of updates to be done is of course quite 
 large at this point.

 By breaking this update up into a few separate upates

  e.g
  yum update x*;  yum update kern*; yum update g*; yum udpate

  The time taken seems to be very substantially less (human perception
  unfortunatly I have no benchmarks). 

  I wonder if there is some inefficiency with the dependency tree
  when the number of updates is large that is reduced by
  hand breaking the updates into smaller chunks.
  

  regards,

g/



From rdieter at math.unl.edu  Fri Dec 31 16:23:32 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 31 Dec 2004 10:23:32 -0600 (CST)
Subject: Compiling src OpenOffice.org 1.1.4 on FC3
In-Reply-To: <41D5576E.8070102@os.lv>
References: <41D5576E.8070102@os.lv>
Message-ID: <Pine.LNX.4.61.0412311022230.5869@math.unl.edu>

On Fri, 31 Dec 2004, Kaspars wrote:

> I try to compile on FC3 lates OpenOffice.org, but without success.
> Maybe somebody have better lack with it? Know what I`m doing wrong.

AFAIK, ooo is buildable only with gcc < 3.4

-- Rex



From skvidal at phy.duke.edu  Fri Dec 31 16:41:32 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 31 Dec 2004 11:41:32 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <20041231105527.GA24292@devserv.devel.redhat.com>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
	<20041231105527.GA24292@devserv.devel.redhat.com>
Message-ID: <1104511292.3441.8.camel@cutter>

On Fri, 2004-12-31 at 05:55 -0500, Alan Cox wrote:
> On Thu, Dec 30, 2004 at 10:50:26PM -0800, Jamie Zawinski wrote:
> > It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> > If it's not hitting the net, what's it doing, raytracing?
> 
> Demonstrating the myth that interpreted languages are fast enough.
> 
> It is actually doing a fair bit - its computing the dependancies, checking it
> won't clash, checking the files fit etc

To be clear. The part I _think_ Jamie is complaining about is just
importing the metadata. And I agree with Daniel, it's all tied up in the
python interning of the strings.

There are a few ways to 'solve' the problem:
1. use a python xml library that does it all internal to python which
should remove the translation issue.
2. thin out the metadata (reduce the number of nodes).
 2a. alternatively, reorganize some of the metadata so it's faster to
get to specific information.
3. write the xml importing layer in C. Since this would require that I
learn how to adequately program in C before going on I think this part
is unlikely.
4. ignore it for long enough and machines will just speed up. :)

-sv




 



From skvidal at phy.duke.edu  Fri Dec 31 16:45:20 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 31 Dec 2004 11:45:20 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <20041231152234.GA20113@sapience.com>
References: <41D4F36D.B7DA877@jwz.org> <20041231152234.GA20113@sapience.com>
Message-ID: <1104511520.3441.11.camel@cutter>

On Fri, 2004-12-31 at 10:22 -0500, Mail Lists wrote:
> On Thu, Dec 30, 2004 at 10:36:29PM -0800, Jamie Zawinski wrote:
> >   - Is there some way to make yum cache all that crap?  I'd be 
> > http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
>  (speed of yum discussion exceised).
> 
> 
>   Related yum question on (lack of?) speed when large number of
>   updates to do.
> 
>  After doing a fresh install, the first yum update can 
>  take (for me) hours - this is after I have pre populated 
>  the local cache (/var/cache/yum) from another just 
>  installed/updated machine - so no downloads 
>  to do at all.  The number of updates to be done is of course quite 
>  large at this point.
> 
>  By breaking this update up into a few separate upates
> 
>   e.g
>   yum update x*;  yum update kern*; yum update g*; yum udpate
> 
>   The time taken seems to be very substantially less (human perception
>   unfortunatly I have no benchmarks). 
> 
>   I wonder if there is some inefficiency with the dependency tree
>   when the number of updates is large that is reduced by
>   hand breaking the updates into smaller chunks.
>   

You can time the dep resolution.

yum -d4 update

look for two strings like  this.
1104511430.1813159

They're the output of time.time()

they are the start and end time of the dep resolution process.


in very large transactions I've found that most of the time is spent in
the 'testing transaction' phase. That's entirely inside rpm at that
point though. 

-sv




From skvidal at phy.duke.edu  Fri Dec 31 16:48:19 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 31 Dec 2004 11:48:19 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <20041231130459.GI31887@redhat.com>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org> <20041231093645.GH31887@redhat.com>
	<41D545C5.6010305@bppiac.hu>  <20041231130459.GI31887@redhat.com>
Message-ID: <1104511699.3441.15.camel@cutter>


>   using the reader at the C level, this include decompressing the archive
> and walking though all nodes. The main cost is to turn the parsed data into
> Python's internal representation as I said.
> 
> > than wouldn't be useful to 
> > implement that small portion in C? or it isn't so small part?
> 
>   The string interning is in the Python lib, probably in C as it's a C API
> as far as I can tell. And no I din't looked at python internal code.

I'm talking from ignorance here:
 Would it be possible to speed up the string interning by providing your
own __repr__ methods in the libxml2 python module?

-sv





From skvidal at phy.duke.edu  Fri Dec 31 16:51:33 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 31 Dec 2004 11:51:33 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <41D4F6B2.183B0FA4@jwz.org>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
Message-ID: <1104511893.3441.19.camel@cutter>

On Thu, 2004-12-30 at 22:50 -0800, Jamie Zawinski wrote:
> Sean Middleditch wrote:
> > 
> > The problem you're perceiving (slow operation as yum starts up) isn't at
> > all due to lack of caching, but perhaps very inefficient handling of the
> > cache - a lot of data has to be parsed and such, when it could perhaps
> > be stored in a more ready-to-process format.
> 
> It takes *nearly a minute* to do that!  I'm on a 2GHz machine.
> If it's not hitting the net, what's it doing, raytracing?

are you using mirrorlists or are you using baseurls?

look in your *.repo files.

if you're using mirrorlists then it IS hitting the net. A point of some
contention. Some folks think I shouldn't hit the net to check to see if
the mirrorlists exists, others don't want yum to continue if the
mirrorlists are invalid.


If you'd like to check to see how much of it is mirrorlists download
simply comment out the mirrorlist line in your *.repo files
in /etc/yum.repo.d/ and uncomment the baseurl lines.

then time it.

-sv




From mricon at gmail.com  Fri Dec 31 19:06:14 2004
From: mricon at gmail.com (Konstantin Ryabitsev)
Date: Fri, 31 Dec 2004 14:06:14 -0500
Subject: why doesn't yum cache anything?
In-Reply-To: <1104511893.3441.19.camel@cutter>
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter>
Message-ID: <f8f6300f0412311106695d8217@mail.gmail.com>

On Fri, 31 Dec 2004 11:51:33 -0500, seth vidal <skvidal at phy.duke.edu> wrote:
> are you using mirrorlists or are you using baseurls?

There is a rather annoying side-effect of mirrorlists -- mirrors may
not always be in sync, so quite often I issue "yum list updates" and
see that there are updates, but when I run "yum update" it hits a
different mirror, where these updates are not yet available. As a
side-effect, it has to download and parse primary.xml.gz for updates
each time the mirrors are not in sync, which depending on the
connection and processor can take a significant amount of time. I get
around it by forcing -C (cache-only mode) after initially running yum
to get the repomd.xml, but others may not know about it.

I don't have any solutions to propose, unfortunately, other than
mirroring an admittedly confusing behavior of apt, which requires
specifically issuing "apt update" to get new repository medatada.

However, especially in the cases where domain resolution takes forever
(some ISPs, in a vain attempt to combat spamming from zombie clients,
throttle down DNS responses to take 10-15 seconds), non-cache
operations with mirrorlists take quite some time more than -C.

Happy New Year,
-- 
Konstantin Ryabitsev
Zlotniks, INC



From florin at andrei.myip.org  Fri Dec 31 19:53:55 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: Fri, 31 Dec 2004 11:53:55 -0800
Subject: "vanilla" kernel closest to Fedora kernel
Message-ID: <1104522835.12925.2.camel@rivendell.home.local>

I normally try and use the distribution-provided kernel for pretty much
everything, because it's simpler this way. But sometimes it's just not
possible. E.g., for some DVB cards, one needs a vanilla kernel, patched.

So here's my question: what is the best way to configure a vanilla
kernel so that it is as close to the Fedora kernel as possible?
I was thinking to just get the .config file used to generate the Fedora
kernel and use it to configure/make the vanilla kernel and let the
kernel build system deal with the differences.

Is that a good approach? I don't need a perfect match (indeed, it is not
possible), but just a reasonable closeness.

-- 
Florin Andrei

http://florin.myip.org/



From dpaun at rogers.com  Fri Dec 31 20:24:09 2004
From: dpaun at rogers.com (Dimitrie O. Paun)
Date: Fri, 31 Dec 2004 15:24:09 -0500
Subject: "vanilla" kernel closest to Fedora kernel
In-Reply-To: <1104522835.12925.2.camel@rivendell.home.local>
References: <1104522835.12925.2.camel@rivendell.home.local>
Message-ID: <20041231202409.GB12487@rogers.com>

On Fri, Dec 31, 2004 at 11:53:55AM -0800, Florin Andrei wrote:
> Is that a good approach? I don't need a perfect match (indeed, it is not
> possible), but just a reasonable closeness.

Thing is, Fedora's kernel is heavily patched, so just twicking the
.config file may not give you a close enough kernel.

-- 
Dimi.



From susan_geller at speakeasy.net  Fri Dec 31 20:40:49 2004
From: susan_geller at speakeasy.net (susan_geller at speakeasy.net)
Date: Fri, 31 Dec 2004 20:40:49 +0000
Subject: media check message
Message-ID: <W253132710898011104525649@webmail1>

I was able to burn FC3 cd's that passed the media check and installed by using the -dao option with cdrecord on my Fedora Core 2 system.  The ones without the -dao option failed the media check and also failed during the installation.

Susan






From nbargnesi at gmail.com  Fri Dec 31 20:45:42 2004
From: nbargnesi at gmail.com (Nick Bargnesi)
Date: Fri, 31 Dec 2004 15:45:42 -0500
Subject: media check message
In-Reply-To: <W253132710898011104525649@webmail1>
References: <W253132710898011104525649@webmail1>
Message-ID: <3077b8a00412311245205195d9@mail.gmail.com>

On Fri, 31 Dec 2004 20:40:49 +0000, susan_geller at speakeasy.net
<susan_geller at speakeasy.net> wrote:
> I was able to burn FC3 cd's that passed the media check and installed by using the -dao option with cdrecord on my Fedora Core 2 system.  The ones without the -dao option failed the media check and also failed during the installation.
> 

I thought cdrecord defaulted to sao/dao?  If it was defaulting to tao
mode, that typically is reserved for multisession cds.

> Susan
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
> 


-- 

Nick Bargnesi
http://www.den-4.com
Den 4 Software

pub  1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi at gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A  0F9D A1ED C1B0 E8BD 2FD0
sub  2048g/56C5D45B 2004-12-02



From peter.backlund at home.se  Fri Dec 31 21:38:11 2004
From: peter.backlund at home.se (Peter Backlund)
Date: Fri, 31 Dec 2004 22:38:11 +0100
Subject: "vanilla" kernel closest to Fedora kernel
In-Reply-To: <1104522835.12925.2.camel@rivendell.home.local>
References: <1104522835.12925.2.camel@rivendell.home.local>
Message-ID: <1104529091.9057.1.camel@ua2-124.cust.blixtvik.net>

fre 2004-12-31 klockan 11:53 -0800 skrev Florin Andrei:
> I normally try and use the distribution-provided kernel for pretty much
> everything, because it's simpler this way. But sometimes it's just not
> possible. E.g., for some DVB cards, one needs a vanilla kernel, patched.
> 
> So here's my question: what is the best way to configure a vanilla
> kernel so that it is as close to the Fedora kernel as possible?
> I was thinking to just get the .config file used to generate the Fedora
> kernel and use it to configure/make the vanilla kernel and let the
> kernel build system deal with the differences.

Run the kernel src.rpm through the rpmbuild -bp stage, and try your
patch. If it doesn't apply, comment out patches in the spec until it
does. Also, you'll see what base kernel is used in the spec file.

/Peter





From arjanv at redhat.com  Fri Dec 31 21:36:44 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 31 Dec 2004 22:36:44 +0100
Subject: "vanilla" kernel closest to Fedora kernel
In-Reply-To: <20041231202409.GB12487@rogers.com>
References: <1104522835.12925.2.camel@rivendell.home.local>
	<20041231202409.GB12487@rogers.com>
Message-ID: <1104529004.5402.38.camel@laptopd505.fenrus.org>

On Fri, 2004-12-31 at 15:24 -0500, Dimitrie O. Paun wrote:
> On Fri, Dec 31, 2004 at 11:53:55AM -0800, Florin Andrei wrote:
> > Is that a good approach? I don't need a perfect match (indeed, it is not
> > possible), but just a reasonable closeness.
> 
> Thing is, Fedora's kernel is heavily patched, so just twicking the
> .config file may not give you a close enough kernel.

it's not THAT heavily patched. it's somewhere between 2.6.9 and 2.6.10,
sure, but heavily patched it's not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041231/5f382925/attachment.sig>

From ich at Frank-Schmitt.net  Fri Dec 31 19:58:58 2004
From: ich at Frank-Schmitt.net (Frank Schmitt)
Date: Fri, 31 Dec 2004 20:58:58 +0100
Subject: why doesn't yum cache anything?
References: <41D4F36D.B7DA877@jwz.org>
	<1104475450.3324.5.camel@stargrazer.home.awesomeplay.com>
	<41D4F6B2.183B0FA4@jwz.org>
	<20041231105527.GA24292@devserv.devel.redhat.com>
	<1104511292.3441.8.camel@cutter>
Message-ID: <m3652ib5od.fsf@fed1.frank-schmitt.net>

seth vidal <skvidal at phy.duke.edu> writes:

> 4. ignore it for long enough and machines will just speed up. :)

I just bought a PII 350 as a home server...

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.