From tmus at tmus.dk  Mon Oct  1 00:22:39 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sun, 30 Sep 2007 22:22:39 -0200
Subject: Kernel VMI (Virtual Machine Interface) in F7/F8?
In-Reply-To: <4700244D.30900@fedoraproject.org>
References: <fdp2jf$59a$1@sea.gmane.org>	<364d303b0709301447x267ed64bi13dd366cf5dbeb8@mail.gmail.com>	<fdp7mc$i54$1@sea.gmane.org>
	<4700244D.30900@fedoraproject.org>
Message-ID: <fdpekh$1fh$1@sea.gmane.org>

Rahul Sundaram wrote:
> Thomas M Steenholdt wrote:
>> Christopher Brown wrote:
>>> Could you point me to where it says this in the release notes - I 
>>> cant see it.
>>>
>> http://fedoraproject.org/wiki/F7ReleaseSummary
> 
> I wrote up the release summary and release notes overview based on what 
> I saw in the kernel configuration. Looks like a bug that needs to be fixed.
> 
> Rahul
> 
I went ahead and filed Bug #313391 on this issue. Let's see what turns up :)

Thanks a lot for input.

/Thomas



From berrange at redhat.com  Mon Oct  1 00:36:02 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 1 Oct 2007 01:36:02 +0100
Subject: Kernel VMI (Virtual Machine Interface) in F7/F8?
In-Reply-To: <20070930215255.GB26047@auslistsprd01.us.dell.com>
References: <fdp2jf$59a$1@sea.gmane.org>
	<20070930215255.GB26047@auslistsprd01.us.dell.com>
Message-ID: <20071001003602.GA16860@redhat.com>

On Sun, Sep 30, 2007 at 04:52:55PM -0500, Matt Domsch wrote:
> On Sun, Sep 30, 2007 at 06:57:17PM -0200, Thomas M Steenholdt wrote:
> > Hi there...
> > 
> > It seems (noted in releasenotes) that F7 should have a VMI (Virtual 
> > Machine Interface) enabled kernel by default, but from what I can find 
> > in the .config files it doesn't... Do I need a special kernel (i.e. only 
> > the XEN kernel has VMI or something) or was it lost in a kernel update 
> > or...?
> 
> in config-x86-generic:
> 
> CONFIG_VIRTUALIZATION=y
> CONFIG_VMI=y
> CONFIG_LGUEST=m
> 
> but it doesn't appear that CONFIG_VMI is enabled on the x86_64 kernel
> in config-2.6.23-0.214.rc8.git2.fc8.  Unless there's a better answer
> shortly, please file this as a bug against the kernel.  It may just be
> an oversight.

paravirt_ops (and thus VMI & LGuedst) only exists on i686. There is no x86_64
or other arch support for any of this yet.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From rodd at clarkson.id.au  Mon Oct  1 04:11:29 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 01 Oct 2007 14:11:29 +1000
Subject: rawhide report: 20070929 changes
In-Reply-To: <200709291041.l8TAf7VE028023@porkchop.devel.redhat.com>
References: <200709291041.l8TAf7VE028023@porkchop.devel.redhat.com>
Message-ID: <1191211899.2886.28.camel@localhost.localdomain>


On Sat, 2007-09-29 at 06:41 -0400, Build System wrote:
> 
> Removed package i810switch
> 
> Updated Packages:
> 
> NetworkManager-1:0.7.0-0.3.svn2914.fc8
> --------------------------------------
> * Fri Sep 28 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2914
> - New snapshot
> 	- Add WPA passphrase support to password dialog
> 	- Applet now reflects actual VPN behavior of one active connection
> 	- Applet now notices VPN active connections on startup
> 	- Fix connections with some WPA and WEP keys
> 
> * Thu Sep 27 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2907
> - New snapshot
> 	- VPN support (only vpnc plugin ported at this time)
> 
> * Tue Sep 25 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2886
> - New snapshot
> 	- Make wired device carrier state work in the applet
> 	- Fix handling of errors with unencrypted APs
> 	- Fix "frozen" applet icon by reporting NM state better
> 	- Fix output of AP frequency in nm-tool

Okay, a couple of comments about this.

I had to generate the hex key for this to connect to a WPA encrypted
connection, but since this it's just worked, with the following caveats:

Each time I un-hibernate, I have to manually select the network to
reconnect.

I had to restart nm-applet after the upgrade and now I'm seeing the
following output on the terminal:

        [rodd at localhost ~]$ 
        ** (nm-applet:7127): WARNING **: Found connection Auto tundra to
        activate at /org/freedesktop/NetworkManagerSettings/0.
        
        (nm-applet:7127): GLib-GObject-CRITICAL **:
        g_signal_emit_valist: assertion `signal_id > 0' failed
        
        [rodd at localhost ~]$ 

And finally (and this is nitpicking in the whole scheme of things) the
nm-applet icon is horrible.  It's like the old nm-applet icon, except
that it's blurry and looks like it's been resized from an icon that's
way to small (see attached small screenshot).


R.

-- 
"It's a fine line between denial and faith.
 It's much better on my side"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nm-applet.png
Type: image/png
Size: 7844 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071001/4bb304fd/attachment.png>

From dmc.fedora at filteredperception.org  Mon Oct  1 08:54:34 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Mon, 01 Oct 2007 03:54:34 -0500
Subject: Fedora spin from RpmFusion
In-Reply-To: <20070930214438.GA26047@auslistsprd01.us.dell.com>
References: <46FDBD57.6090409@fedoraproject.org>	<20070929025629.GA32005@nostromo.devel.redhat.com>	<46FDBFBE.9050708@fedoraproject.org>	<46FEF33E.3000506@filteredperception.org>	<46FF9BBA.4030002@fedoraproject.org>	<46FFA2E2.6030504@filteredperception.org>	<46FFA54B.9020005@fedoraproject.org>	<46FFD506.6080708@filteredperception.org>	<20070930181115.GA14773@auslistsprd01.us.dell.com>	<470013D5.8010905@filteredperception.org>
	<20070930214438.GA26047@auslistsprd01.us.dell.com>
Message-ID: <4700B5CA.8060604@filteredperception.org>

Matt Domsch wrote:
> On Sun, Sep 30, 2007 at 04:23:33PM -0500, Douglas McClendon wrote:
>> Matt Domsch wrote:
>>> On Sun, Sep 30, 2007 at 11:55:34AM -0500, Douglas McClendon wrote:
>>>> Can trademark guidelines on free software restrict the ability to 
>>>> redistribuite bit-for-bit copies of the software, that don't use the 
>>>> trademarks in any other way than the fact that they are included in 
>>>> those bits?
>>> yes, they can, which is why one of the feature of Fedora 8 is to clean
>>> up the fedora-logos and redhat-artwork packages, and the addition of
>>> the generic-logos package, exactly so one can create a derivative of
>>> Fedora using and containing only Free Software, easily, without including
>>> the Fedora trademarks.  
>> Certainly for derivatives and any other modification, it seems obvious 
>> that trademarks are protected.  My question rather involved bundling an 
>> unmodified copy of free software with other (free and/or non-free) software.
>>
>> My not-a-lawyer hunch is that the nature of free software suggests that 
>> it may be redistributed unmodified in any and all manner.  But a hunch 
>> is hardly anything to go by.
>>
>> My scenario involved supplying the end-user with software that makes it 
>> dirt-simple (i.e. a bootloader choice) for the end-user to apply 
>> patches.  This is somewhat similar to the ideas I have heard kicked 
>> around regarding supplying kernel modules as source along with scripts 
>> that make it as simple for the end-user to turn the source into the 
>> binary, which for obscure legal reasons could not be distributed as a 
>> binary.
> 
> AIUI, the obscure legal reasoning seems to be that if the distribution
> delivers pre-linked kernel modules, such infringes the kernel's
> copyright; but if the linking is done by end users, that it somehow
> doesn't infringe that copyright.  I've never been comfortable with
> this line of thinking myself.  If true, it feels like passing the
> buck, and I grew up in Independence, MO[1].

Sure, but it appears the point is passing the buck of a distributor who 
is not legally allowed to do something, to the end-user who is legally 
allowed to do something.  The question is, since it is obviously a silly 
legal hack, whether it should be legal for the distributor to do the 
patching prior to distribution, or whether it should be illegal for the 
user to do the patching after distribution.


> One challenge to Free Software is that it's based upon copyright
> law. The other two pillars of "intellectual property law" are patents
> and trademarks, neither of which are often adequately addressed in
> copyright licenses, insofar as they're not even mentioned.  GNU GPL v2
> does include some text regarding patents; v3 even more so.  So unless
> you adequately license patents and trademarks too, copyright licenses
> don't convey "all" the rights one might need to do "anything you
> want".  GPL doesn't speak to modifications - it's obligations are
> incurred at point of distribution of the work, modified or not.

 From my not-a-lawyer understanding, the trademark issues don't come 
into play if the trademarks are not actually used in any way other than 
merely existing as part and parcel of the original software package 
distributed by the tradmark rights holder.

And yes, then there are patents.  Of course the predominant wisdom seems 
to be that just like the rest of our legal system, the best tactic is to 
always assume that what you want to do is legal, until someone who can 
afford more lawyers than you tells you otherwise.  Certainly that seems 
to be the example the executive branch is setting...

-dmc



From mcepl at redhat.com  Mon Oct  1 09:08:52 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 01 Oct 2007 11:08:52 +0200
Subject: Can we please stop with the stupid add you Xorg.log canned
 response to X and OpenGL bugs?
References: <46FD17EF.9090501@hhs.nl>
Message-ID: <42q6t4x1rl.ln2@hubmaier.ceplovi.cz>

On Fri, 28 Sep 2007 17:04:15 +0200, Hans de Goede scripst:
> A couple of days ago I filed this (fairly detailed bug):
> https://bugzilla.redhat.com/show_bug.cgi?id=304551
> 
> About opengl rendering problems with a certain app on an other wise
> perfectly fine working opengl setup, and explaining that downgrading
> mesa-libGL and not making any other changes fixes this. Notice the and
> not making any other changes. Iow this is in no way a configuration
> problem.

When I was asking you about these two files (how difficult it is attach 
instead of this bitching on the list?), I was not that much concerned 
with the configuration of your computer (although, it may be nice to see 
whether you haven't done something entirely stupid there) as much I was 
interested in what xorg thinks your hardware is, whether it isn't 
possible that some hardware failure happens, whatever. And of course, it 
was easier for me to use canned text which includes both of these files. 
Again, how difficult is it just to attach two files?

Now, to the whole idea of canned comments. If I had enough time to write 
nice novels about each bug, I would certainly did, and believe Dickens 
would envy the beauty of my prose. However, I am the only bugmaster for 
all Xorg/Gecko/Evolution/OpenOffice bugs (not dealing with each of these 
groups with same level of thoroughness) and I have to deal with hundreds 
of bug comments every day. If you want to have more beautiful comments in 
bugzilla, you are very welcome to contact me and help me bug triaging all 
those desktop bugs.

Best,

Mat?j



From buildsys at redhat.com  Mon Oct  1 09:28:32 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 1 Oct 2007 05:28:32 -0400
Subject: rawhide report: 20071001 changes
Message-ID: <200710010928.l919SWsO005650@porkchop.devel.redhat.com>

 

Removed package csync2

Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
	osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
	osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
	osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
	osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
	osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
	osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgText.so.1
	osgal - 20060903-3.fc7.i386 requires libosg.so.1
	osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit)
	osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
	osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
	osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
	osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
	osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
	osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
	osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgText.so.1
	osgal - 20060903-3.fc7.i386 requires libosg.so.1
	osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.ppc requires libosgDB.so.1
	osgal - 20060903-3.fc7.ppc requires libosgFX.so.1
	osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1
	osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1
	osgal - 20060903-3.fc7.ppc requires libosgSim.so.1
	osgal - 20060903-3.fc7.ppc requires libosgGA.so.1
	osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.ppc requires libosgText.so.1
	osgal - 20060903-3.fc7.ppc requires libosg.so.1
	osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From j.w.r.degoede at hhs.nl  Mon Oct  1 11:56:57 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 01 Oct 2007 13:56:57 +0200
Subject: Can we please stop with the stupid add you Xorg.log canned
 response to X and OpenGL bugs?
In-Reply-To: <42q6t4x1rl.ln2@hubmaier.ceplovi.cz>
References: <46FD17EF.9090501@hhs.nl> <42q6t4x1rl.ln2@hubmaier.ceplovi.cz>
Message-ID: <4700E089.4030301@hhs.nl>

Matej Cepl wrote:
> On Fri, 28 Sep 2007 17:04:15 +0200, Hans de Goede scripst:
>> A couple of days ago I filed this (fairly detailed bug):
>> https://bugzilla.redhat.com/show_bug.cgi?id=304551
>>
>> About opengl rendering problems with a certain app on an other wise
>> perfectly fine working opengl setup, and explaining that downgrading
>> mesa-libGL and not making any other changes fixes this. Notice the and
>> not making any other changes. Iow this is in no way a configuration
>> problem.
> 
> When I was asking you about these two files (how difficult it is attach 
> instead of this bitching on the list?)

You were not asking me to simply attach 2 files, you were also asking me to 
remove my xorg.conf, restart X (iow logout) and attach the resulting logs of 
that too, after which I probably want to restore xorg.conf again, logout again 
etc. Also this was not the first bug of mine that got this response.

> Now, to the whole idea of canned comments. If I had enough time to write 
> nice novels about each bug, I would certainly did, and believe Dickens 
> would envy the beauty of my prose. However, I am the only bugmaster for 
> all Xorg/Gecko/Evolution/OpenOffice bugs (not dealing with each of these 
> groups with same level of thoroughness) and I have to deal with hundreds 
> of bug comments every day. If you want to have more beautiful comments in 
> bugzilla, you are very welcome to contact me and help me bug triaging all 
> those desktop bugs.

I'm not against canned response, for example the canned kernel responses to 
please retry with the latest kernel are fine. As they are on topic. What you 
did is asking for more information and setting the need info status flag on bug 
reports which already include tons of info:
-which card I'm using
-what is the last known version of the affected package where it worked, and
  the first version where it breaks
-Notice I pinpointed it to a single sub-package by demonstrating that the bug
  goes away by downgrading that single package, so I'm also providing accurate
  info as to in which package the bug is
-that it breaks even more in a later version of this package
-that I also filed it upstream including a link to upstreams bug report.

And IMHO asking for more info when I spend a lot of time to file a proper bug 
report is annoying if not just plain rude. IOW its not the canned response that 
annoys me but the total irrelevance of said canned response to the bug report 
in question, esp. after all the time I took to debug this issue myself and to 
file a detailed bug report!

Regards,

Hans



From alexm at asic.udl.cat  Mon Oct  1 12:37:18 2007
From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=)
Date: Mon, 01 Oct 2007 14:37:18 +0200
Subject: LTSP 5 on Fedora
Message-ID: <4700E9FE.8000409@asic.udl.cat>

Hi,
While searching for LTSP 5 for Fedora, I didn't find anything but this 
bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also, 
I've not found anything regarding LTSP in this list.

So, Is someone working on LTSP 5 support for Fedora? Is there some 
repository were pick code from or anything?

Thanks,
?lex



From cdhouch at gmail.com  Mon Oct  1 13:29:45 2007
From: cdhouch at gmail.com (Caerie Houchins)
Date: Mon, 1 Oct 2007 08:29:45 -0500
Subject: bluetooth not working automatically
In-Reply-To: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
References: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
Message-ID: <f0ad54e30710010629v35530d29q595e9a2ede5018dc@mail.gmail.com>

On 9/29/07, Thomas J. Baker <tjb at unh.edu> wrote:
>
> Does bluetooth automatically work for anyone? I'm seeing the following
> problems:
>
> bluetooth service always fails to start at boot - address in use
>         - can be started by hand after
>
> bluetooth-applet doesn't seem to get run at login
>         - works fine if started by hand
>
> It seems like stuff is working, just not automatically.
>
> tjb
> --
> =======================================================================
> | Thomas Baker                                  email: tjb at unh.edu    |
> | Systems Programmer                                                  |
> | Research Computing Center                     voice: (603) 862-4490 |
> | University of New Hampshire                     fax: (603) 862-1761 |
> | 332 Morse Hall                                                      |
> | Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
> =======================================================================
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Yes I am seeing the same thing on my Dell Vostro 1500.  Do you have a bug
report # for this already?


-- 
Caerie Houchins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071001/4d8ab88e/attachment.htm>

From jonathan.underwood at gmail.com  Mon Oct  1 13:31:33 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 1 Oct 2007 14:31:33 +0100
Subject: LTSP 5 on Fedora
In-Reply-To: <4700E9FE.8000409@asic.udl.cat>
References: <4700E9FE.8000409@asic.udl.cat>
Message-ID: <645d17210710010631h570cb167q77e209b86bf58bfa@mail.gmail.com>

On 01/10/2007, Alexandre Magaz Gra?a <alexm at asic.udl.cat> wrote:
> Hi,
> While searching for LTSP 5 for Fedora, I didn't find anything but this
> bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also,
> I've not found anything regarding LTSP in this list.
>
> So, Is someone working on LTSP 5 support for Fedora? Is there some
> repository were pick code from or anything?
>
> Thanks,
> ?lex

Does the k21ltsp project do what you're asking?

http://www.k12ltsp.org/



From wtogami at redhat.com  Mon Oct  1 13:43:03 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 01 Oct 2007 09:43:03 -0400
Subject: LTSP 5 on Fedora
In-Reply-To: <4700E9FE.8000409@asic.udl.cat>
References: <4700E9FE.8000409@asic.udl.cat>
Message-ID: <4700F967.9010808@redhat.com>

Alexandre Magaz Gra?a wrote:
> Hi,
> While searching for LTSP 5 for Fedora, I didn't find anything but this 
> bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also, 
> I've not found anything regarding LTSP in this list.
> 
> So, Is someone working on LTSP 5 support for Fedora? Is there some 
> repository were pick code from or anything?
> 
> Thanks,
> ?lex
> 

Eric Harrison said that he's hoping to get the LTSP 5 bits into Fedora, 
after that point he'll need other people to help maintain the packages 
in Fedora.  I'm meeting him in Oregon next weekend to get started on this.

Warren Togami
wtogami at redhat.com



From ajackson at redhat.com  Mon Oct  1 13:23:30 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 09:23:30 -0400
Subject: Experiences with F8T2 on Thinkpad T61
In-Reply-To: <1191015563.12995.21.camel@vincent52.localdomain>
References: <1190410702.5762.26.camel@valkyrie.localdomain>
	<1190647285.3418.2.camel@localhost.localdomain>
	<1191015563.12995.21.camel@vincent52.localdomain>
Message-ID: <1191245010.31421.21.camel@localhost.localdomain>

On Fri, 2007-09-28 at 17:39 -0400, Matthew Saltzman wrote:
> On Mon, 2007-09-24 at 11:21 -0400, Adam Jackson wrote: 
> > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote:
> > > - Suspend doesn't work at all.  Select Suspend from the power applet and
> > > the machine starts to suspend, the light comes on, then the light goes
> > > off and the machine is live, except that the display is black.  I can
> > > reboot as above.
> > 
> > As always, suspend on nv graphics chips is a disaster.
> 
> Indeed.  This is and wireless are the most important things for me to
> get working.  What's the best way to help debug.  What component should
> I bugzilla?

It's not really something that needs a bugzilla in Fedora, it's just a
problem we don't have a solution for yet.

http://marc.info/?l=fedora-test-list&m=119003866809039&w=2

for the details.

- ajax



From ajackson at redhat.com  Mon Oct  1 13:24:39 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 09:24:39 -0400
Subject: i810switch -> xrandr for F8
In-Reply-To: <20070928002343.GA12138@auslistsprd01.us.dell.com>
References: <20070928002343.GA12138@auslistsprd01.us.dell.com>
Message-ID: <1191245079.31421.23.camel@localhost.localdomain>

On Thu, 2007-09-27 at 19:23 -0500, Matt Domsch wrote:
> The i810switch program has been around for a while, and it forces the
> Intel i810 - i945 series video chips to enable or disable the external
> VGA or LCD panel video output devices on a laptop.  i810switch has not
> had an update since June 2005.
> 
> In Fedora 8, the xrandr application provides this same functionality,
> natively in the Xorg subsystem.
> 
> In my limited testing, xrandr works on the i810 class hardware I have
> access to.
> 
> I'd like to drop i810switch from the distribution for Fedora 8, and
> add a release note suggesting users of i810switch use xrandr instead.

I heartily endorse this product and/or service.

- ajax



From ajackson at redhat.com  Mon Oct  1 13:28:23 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 09:28:23 -0400
Subject: /etc/hosts and system entries
In-Reply-To: <544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
Message-ID: <1191245303.31421.26.camel@localhost.localdomain>

On Fri, 2007-09-28 at 14:27 +0100, Bill Crawford wrote:
> On 27/09/2007, Adam Jackson <ajackson at redhat.com> wrote:
> > Why is this not a bug in kerberos?  If the application knows that the IP
> > address it wants for the name needs to be globally routable, then the
> > application should be responsible for walking the list of IPs for that
> > name to find the routable ones.
> 
> Another point being missed, is that if the hostname gets changed the
> moment an external IP interface is brought up, X becomes unusable
> because suddenly the magic cookie isn't found (the server and
> .Xauthority think it's "localhost" and the client thinks it's
> "some-dynamic-ip-xx-yy-zz.imaginative-dsl-provider.com").

I think there's something more subtle going on in this case.  What we do
at least in startx(1) is add the cookie to ~/.Xauthority twice, once
for :0 and once for foo:0, so the first one should always win.

- ajax



From mjs at CLEMSON.EDU  Mon Oct  1 13:55:14 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 01 Oct 2007 09:55:14 -0400
Subject: Experiences with F8T2 on Thinkpad T61
In-Reply-To: <1191245010.31421.21.camel@localhost.localdomain>
References: <1190410702.5762.26.camel@valkyrie.localdomain>
	<1190647285.3418.2.camel@localhost.localdomain>
	<1191015563.12995.21.camel@vincent52.localdomain>
	<1191245010.31421.21.camel@localhost.localdomain>
Message-ID: <1191246914.23208.20.camel@vincent52.localdomain>

On Mon, 2007-10-01 at 09:23 -0400, Adam Jackson wrote:
> On Fri, 2007-09-28 at 17:39 -0400, Matthew Saltzman wrote:
> > On Mon, 2007-09-24 at 11:21 -0400, Adam Jackson wrote: 
> > > On Fri, 2007-09-21 at 17:38 -0400, Matthew Saltzman wrote:
> > > > - Suspend doesn't work at all.  Select Suspend from the power applet and
> > > > the machine starts to suspend, the light comes on, then the light goes
> > > > off and the machine is live, except that the display is black.  I can
> > > > reboot as above.
> > > 
> > > As always, suspend on nv graphics chips is a disaster.
> > 
> > Indeed.  This is and wireless are the most important things for me to
> > get working.  What's the best way to help debug.  What component should
> > I bugzilla?
> 
> It's not really something that needs a bugzilla in Fedora, it's just a
> problem we don't have a solution for yet.
> 
> http://marc.info/?l=fedora-test-list&m=119003866809039&w=2
> 
> for the details.

OK That's informative, thanks.

Does it help to know that the vesa driver exhibits the same behavior?
(The nv driver still doesn't work at all with this card--Quadro NV140M.)

I will try to play with the nvidia binary driver sometime.  I'm pretty
sure, however, that when I had F7 on the machine, the nvidia driver also
behaved the same way.  (I do recall that I couldn't change screen
brightness with that driver.)  Will try to verify.

> 
> - ajax
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From ajackson at redhat.com  Mon Oct  1 13:54:54 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 09:54:54 -0400
Subject: Experiences with F8T2 on Thinkpad T61
In-Reply-To: <1191246914.23208.20.camel@vincent52.localdomain>
References: <1190410702.5762.26.camel@valkyrie.localdomain>
	<1190647285.3418.2.camel@localhost.localdomain>
	<1191015563.12995.21.camel@vincent52.localdomain>
	<1191245010.31421.21.camel@localhost.localdomain>
	<1191246914.23208.20.camel@vincent52.localdomain>
Message-ID: <1191246894.31421.44.camel@localhost.localdomain>

On Mon, 2007-10-01 at 09:55 -0400, Matthew Saltzman wrote:
> On Mon, 2007-10-01 at 09:23 -0400, Adam Jackson wrote:
> > It's not really something that needs a bugzilla in Fedora, it's just a
> > problem we don't have a solution for yet.
> > 
> > http://marc.info/?l=fedora-test-list&m=119003866809039&w=2
> > 
> > for the details.
> 
> OK That's informative, thanks.
> 
> Does it help to know that the vesa driver exhibits the same behavior?
> (The nv driver still doesn't work at all with this card--Quadro NV140M.)

I assume "same behaviour" means regarding suspend, in which case, no, it
doesn't help, it's exactly what I would expect.  The vesa driver is
entirely reliant on the VBIOS for chip setup, which is exactly the thing
that the nv firmware stubs out after suspend.

- ajax



From overholt at redhat.com  Mon Oct  1 14:37:31 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 1 Oct 2007 10:37:31 -0400
Subject: Developer SIG mailing list
Message-ID: <20071001143731.GB28514@redhat.com>

Hi,

We now have a mailing list for the Developer SIG:

  https://www.redhat.com/mailman/listinfo/fedora-developer-sig

Please subscribe and post there to discuss the SIG and the spin.

Thanks,

Andrew
-------------- 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/20071001/681314b1/attachment.sig>

From billcrawford1970 at gmail.com  Mon Oct  1 14:47:36 2007
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Mon, 1 Oct 2007 15:47:36 +0100
Subject: /etc/hosts and system entries
In-Reply-To: <1191245303.31421.26.camel@localhost.localdomain>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
	<1191245303.31421.26.camel@localhost.localdomain>
Message-ID: <544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>

On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:

> I think there's something more subtle going on in this case.  What we do
> at least in startx(1) is add the cookie to ~/.Xauthority twice, once
> for :0 and once for foo:0, so the first one should always win.

I noticed that. Still got this in my output (shortly before a crash in
libGLcore, which I'm guessing is unrelated to the network issue):

_IceTransSocketUNIXConnect: Cannot connect to non-local host bill.wcn.co.uk
Warning: Tried to connect to session manager, Could not open network socket

It looks like the server crashed due to the VT-switching, rather than
the network stuff, so I won't bother attaching the rest .... :)



From ajackson at redhat.com  Mon Oct  1 14:33:16 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 10:33:16 -0400
Subject: /etc/hosts and system entries
In-Reply-To: <544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
	<1191245303.31421.26.camel@localhost.localdomain>
	<544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
Message-ID: <1191249196.31421.47.camel@localhost.localdomain>

On Mon, 2007-10-01 at 15:47 +0100, Bill Crawford wrote:
> On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:
> 
> > I think there's something more subtle going on in this case.  What we do
> > at least in startx(1) is add the cookie to ~/.Xauthority twice, once
> > for :0 and once for foo:0, so the first one should always win.
> 
> I noticed that. Still got this in my output (shortly before a crash in
> libGLcore, which I'm guessing is unrelated to the network issue):
> 
> _IceTransSocketUNIXConnect: Cannot connect to non-local host bill.wcn.co.uk
> Warning: Tried to connect to session manager, Could not open network socket

Oooh.  I've seen that bug before, but had never gotten any debug output
from it.  Let me see if I can't chase that down.

- ajax



From dcbw at redhat.com  Mon Oct  1 15:01:43 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 01 Oct 2007 11:01:43 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <20070930002552.GA8910@jadzia.bu.edu>
References: <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com>
	<20070928063428.1a6cb2fe@redhat.com>
	<1190996852.10569.4.camel@vincent52.localdomain>
	<4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com>
	<1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
Message-ID: <1191250903.5368.4.camel@xo-3E-67-34.localdomain>

On Sat, 2007-09-29 at 20:25 -0400, Matthew Miller wrote:
> On Sat, Sep 29, 2007 at 01:32:38PM -0400, Matthew Saltzman wrote:
> > Also noticed that (now that I have a connection defined) it doesn't
> > connect automatically when NM/nm-applet starts (e.g., when I log in).  I
> > have to pull down the menu and select it.  My F7 machine NM-0.6.5
> > connects to the most recently used WAP in range when it starts.
> 
> You can use gconf-editor to toggle the autoconnect flag for the connections,
> once you've connected once. This seems to work.
> 
> (With the caveat that the whole thing is acting really flaky for me. Once
> I connect to one network -- or even *try* to connect -- the network card
> then loses the ability to scan for any networks or connect to other ones
> until I reboot.)

A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
been pretty stable for me; I have also tried rt76_usb + mac80211 and
that's been OK.

Dan




From tjb at unh.edu  Mon Oct  1 15:23:09 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Mon, 01 Oct 2007 11:23:09 -0400
Subject: bluetooth not working automatically
In-Reply-To: <f0ad54e30710010629v35530d29q595e9a2ede5018dc@mail.gmail.com>
References: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
	<f0ad54e30710010629v35530d29q595e9a2ede5018dc@mail.gmail.com>
Message-ID: <1191252189.27486.1.camel@neuromancer>

On Mon, 2007-10-01 at 08:29 -0500, Caerie Houchins wrote:
> On 9/29/07, Thomas J. Baker <tjb at unh.edu> wrote:
>         Does bluetooth automatically work for anyone? I'm seeing the
>         following
>         problems:
>         
>         bluetooth service always fails to start at boot - address in
>         use
>                 - can be started by hand after
>         
>         bluetooth-applet doesn't seem to get run at login 
>                 - works fine if started by hand
>         
>         It seems like stuff is working, just not automatically.
>         
>         tjb
>         --
>         =======================================================================
>         | Thomas Baker                                  email:
>         tjb at unh.edu    |
>         | Systems
>         Programmer                                                  |
>         | Research Computing Center                     voice: (603)
>         862-4490 |
>         | University of New Hampshire                     fax: (603)
>         862-1761 | 
>         | 332 Morse
>         Hall                                                      |
>         | Durham, NH 03824
>         USA              http://wintermute.sr.unh.edu/~tjb |
>         ======================================================================= 
>         
>         --
>         fedora-devel-list mailing list
>         fedora-devel-list at redhat.com
>         https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> Yes I am seeing the same thing on my Dell Vostro 1500.  Do you have a
> bug report # for this already?
> 

No, ran out of time. I'll try to later today if you don't beat me to it.

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From lesmikesell at gmail.com  Mon Oct  1 15:38:11 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 01 Oct 2007 10:38:11 -0500
Subject: LTSP 5 on Fedora
In-Reply-To: <4700F967.9010808@redhat.com>
References: <4700E9FE.8000409@asic.udl.cat> <4700F967.9010808@redhat.com>
Message-ID: <47011463.5030805@gmail.com>

Warren Togami wrote:
> Alexandre Magaz Gra?a wrote:
>> Hi,
>> While searching for LTSP 5 for Fedora, I didn't find anything but this 
>> bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also, 
>> I've not found anything regarding LTSP in this list.
>>
>> So, Is someone working on LTSP 5 support for Fedora? Is there some 
>> repository were pick code from or anything?
>>
>> Thanks,
>> ?lex
>>
> 
> Eric Harrison said that he's hoping to get the LTSP 5 bits into Fedora, 
> after that point he'll need other people to help maintain the packages 
> in Fedora.  I'm meeting him in Oregon next weekend to get started on this.

For anyone who doesn't already know: Eric Harrison is the person behind 
the k12ltsp distribution which is fedora or centos (depending on the 
version) with LTSP and some other additions and configuration scripts to 
make it all come up working automatically.  The main web page is often 
outdated - I usually start at the wiki:
http://k12ltsp.org/mediawiki/index.php/Main_Page
or browse the download site:
ftp://k12linux.mesd.k12.or.us/pub/K12LTSP/
for new releases or to see what is new under the testing directory.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mattdm at mattdm.org  Mon Oct  1 15:38:50 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 1 Oct 2007 11:38:50 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <1191250903.5368.4.camel@xo-3E-67-34.localdomain>
References: <1190996852.10569.4.camel@vincent52.localdomain>
	<4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com>
	<1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
Message-ID: <20071001153850.GA804@jadzia.bu.edu>

On Mon, Oct 01, 2007 at 11:01:43AM -0400, Dan Williams wrote:
> > (With the caveat that the whole thing is acting really flaky for me. Once
> > I connect to one network -- or even *try* to connect -- the network card
> > then loses the ability to scan for any networks or connect to other ones
> > until I reboot.)
> A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
> been pretty stable for me; I have also tried rt76_usb + mac80211 and
> that's been OK.

orinoco_pci....

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fedora at leemhuis.info  Mon Oct  1 17:16:50 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 01 Oct 2007 19:16:50 +0200
Subject: EPEL report week 39 2007
Message-ID: <47012B82.1030805@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week39

= Weekly EPEL Summary =

Week 39/2007 

== Most important happenings ==

 * Nothing major

== EPEL SIG Meeting ==

=== Attending ===

 * [:DennisGilmore:dgilmore] 
 * [:JesseKeating:f13] 
 * [:ThorstenLeemhuis:knurd] 
 * [:MarekMahut:marek]
 * [:MikeMcGrath:mmcgrath] 
 * [:KevinFenzi:nirik] 
 * [:KarstenWade:quaid] 
 * [:WarrenTogami:warren] 

=== Summary ===

 * http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription and http://fedoraproject.org/wiki/EPEL/CommunicationPlan -- quaid 

  * both were approved -- nobody complained on the list last time it was discussed (that was some weeks ago) and we can easily updated when people want to see something changed

  * task--quaid: put it properly in the wiki (link on the frontpage, everywhere else where needed? and similar stuff)

 * http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51  -- unassigned

  * new ask page created by knurd to track preparations we likely should do for 5.1 

   * when to remove yum-utils and other packages that are not part of RHEL? 

   * leave the package in the repo until at least CentOS catches up, then drop them?

   * nirik> | I'm happy to work on bugging people about broken deps and trying to work on the repo for the next testing/final move. 

 * http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma 

  * skipped

 * http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel -- unassigned 

  * moving to bodhi requires that we switch to koji, which first needs the ability to hide RHEL binaries from the world

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc 

  * yum-cron 

   * things are in the works to get this issue fixed; see https://www.redhat.com/archives/epel-devel-list/2007-September/msg00087.html

  * do more on the list and less in the meetings; "Power to the people with no delay." aka "make Steering Committee nearly unimportant" and "new schedule page"

   * some discussions around this to improve workflow and do stuff like "if nobody complains on the list (or in the IRC meetings) its simply considered accepted" 

   * knurd> | it's just a general idea IMHO; we just need to find way to realize that idea; the new stuff in the wiki is a first step for I hope we do more, but I don't know yet exactly what to do; suggestions welcomed 

 * Free discussion around EPEL 
  
  * nirik> | I have almost caught up on security checking for epel... 

  * nirik> | there are some packages that were never built, but have branches. Might be good if we could gather a list of those and ping maintainers to build or work on deps to build 

  * nirik> | finally, did we ever determine about pushing from testing->stable more often? Or should I bring that up on the list again? 

   * we prepare one; will decide if we just do it or if we do it together with 5.1

  * dep scripts running for testing these days? mmcgrath> | knurd: I don't think they are, I'll do that now. 

   * task--mmcgrath --   dep scripts running for testing

=== Full Log ===

https://www.redhat.com/archives/epel-devel-list/2007-September/msg00110.html

== Stats ==



=== General ===



Number of EPEL Contributors 1



We welcome 1 new contributors: till



=== EPEL 5 ===



Number of source packages: 670



Number of binary packages:  1299 



There are 9 new Packages:



 * amavisd-new | Email filter with virus scanner and spamassassin support

 * fedora-package-config-smart | Fedora EPEL configuration files for the Smart package manager

 * jack-audio-connection-kit | The Jack Audio Connection Kit

 * libid3tag | ID3 tag manipulation library

 * mathml-fonts | Mathematical symbol fonts

 * optipng | A PNG optimizer and converter

 * python-fedora | Python modules for talking to Fedora Infrastructure Services

 * smart | Next generation package handling tool

 * wavpack | A completely open audiocodec



=== EPEL 4 ===



Number of source packages: 421



Number of binary packages:  859 



There are 1 new Packages:



 * wavpack | A completely open audiocodec



----

["CategoryEPELReports"]



From dcbw at redhat.com  Mon Oct  1 18:25:09 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 01 Oct 2007 14:25:09 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <20071001153850.GA804@jadzia.bu.edu>
References: <1190996852.10569.4.camel@vincent52.localdomain>
	<4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com>
	<1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
Message-ID: <1191263109.19127.0.camel@xo-3E-67-34.localdomain>

On Mon, 2007-10-01 at 11:38 -0400, Matthew Miller wrote:
> On Mon, Oct 01, 2007 at 11:01:43AM -0400, Dan Williams wrote:
> > > (With the caveat that the whole thing is acting really flaky for me. Once
> > > I connect to one network -- or even *try* to connect -- the network card
> > > then loses the ability to scan for any networks or connect to other ones
> > > until I reboot.)
> > A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
> > been pretty stable for me; I have also tried rt76_usb + mac80211 and
> > that's been OK.
> 
> orinoco_pci....

I've got an orinoco pcmcia part, will test with that.

Dan




From ville.skytta at iki.fi  Mon Oct  1 18:41:57 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 1 Oct 2007 21:41:57 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
Message-ID: <200710012141.58217.ville.skytta@iki.fi>

Hello,

I went through current devel packages that use htmlview or have unnecessarily 
hardwired dependencies to firefox or evince.  Most of these should be using 
xdg-open from xdg-utils instead.  Not hardcoding firefox as the browser and 
evince as the PDF viewer should be trivial to understand, but why use 
xdg-open instead of htmlview?  xdg-utils/xdg-open compared to htmlview:

- Works better in non-GNOME setups
- Is a more standard implementation (more likely to be adopted upstream)
- Understands the $BROWSER environment variable
- Has slightly smaller dependency chain

So far, the only drawback of xdg-open compared to htmlview I've found is that 
there doesn't seem to be real support for just opening a browser without an 
URL to show in it.  "xdg-open about:blank" is one hacky workaround for this, 
but I don't know how portable it is accross browsers (works at least in 
Firefox and friends, and Konqueror).

List of packages follows, I'd appreciate if their maintainers could have a 
look and apply where appropriate.  Most of these changes have been made 
without testing but then again, most of them are so trivial that no testing 
is required, but keep the above paragraph in mind if your package just needs 
to open a browser without showing anything in particular in it (IIRC icewm is 
one such case).  For some packages I have patches available, some have 
already been reported in Bugzilla, and some already applied in bleeding edge 
upstream versions.

Patches available at http://scop.fedorapeople.org/patches/xdg-utils/ :

- amsn
- ddd
- fvwm
- gmrun
- gnome-libs
- grace
- grisbi
- icewm
- ipe
- keepassx
- R
- streamtuner
- system-config-date
- system-config-nfs
- system-config-samba
- system-config-services
- system-config-users
- tcldebugger
- xarchiver

Reported in Bugzilla:

- licq, #314231
- pinfo, #312471
- xfig, #313321
- xpdf, #313311

Already reported and applied in upstream devel versions, Fedora
packages should be adjusted to Require/BuildRequire xdg-utils instead
of htmlview when those are out:

- fontforge
- wireshark-gnome



From wwoods at redhat.com  Mon Oct  1 18:49:47 2007
From: wwoods at redhat.com (Will Woods)
Date: Mon, 01 Oct 2007 14:49:47 -0400
Subject: bluetooth not working automatically
In-Reply-To: <1191252189.27486.1.camel@neuromancer>
References: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
	<f0ad54e30710010629v35530d29q595e9a2ede5018dc@mail.gmail.com>
	<1191252189.27486.1.camel@neuromancer>
Message-ID: <1191264587.3020.3.camel@metroid.rdu.redhat.com>

On Mon, 2007-10-01 at 11:23 -0400, Thomas J. Baker wrote:
> On Mon, 2007-10-01 at 08:29 -0500, Caerie Houchins wrote:
> > On 9/29/07, Thomas J. Baker <tjb at unh.edu> wrote:
> >         Does bluetooth automatically work for anyone? I'm seeing the
> >         following
> >         problems:
> >         
> >         bluetooth service always fails to start at boot - address in
> >         use
> >                 - can be started by hand after
> >         
> >         bluetooth-applet doesn't seem to get run at login 
> >                 - works fine if started by hand
> >         
> >         It seems like stuff is working, just not automatically.

I've been messing with bluetooth stuff as well, and noticed the same
thing. I think some of the bluetooth daemons require dbus access now -
bluetooth seems to start OK if it starts *after* messagebus. 

I changed the chkconfig line in /etc/init.d/bluetooth from:
# chkconfig:    2345 25 90
to:
# chkconfig:    2345 30 90

The second number controls startup priority; messagebus is currently at
28. After making that change, you can do:
chkconfig bluetooth off
chkconfig bluetooth on

Restarting the system after these changes, bluetooth started OK. The
bluetooth applet still doesn't seem to start right, though.

Did you file that bug report? This information should probably be
attached to it.

-w
-------------- 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/20071001/750a3a4c/attachment.sig>

From zcerza at redhat.com  Mon Oct  1 18:49:59 2007
From: zcerza at redhat.com (Zack Cerza)
Date: Mon, 01 Oct 2007 14:49:59 -0400
Subject: bluetooth not working automatically
In-Reply-To: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
References: <1191092462.4968.4.camel@continuity.bakerconsulting.com>
Message-ID: <47014157.1080506@redhat.com>

Thomas J. Baker wrote:
> Does bluetooth automatically work for anyone? I'm seeing the following
> problems:
> 
> bluetooth service always fails to start at boot - address in use 
> 	- can be started by hand after

https://bugzilla.redhat.com/show_bug.cgi?id=279291

Zack



From mattdm at mattdm.org  Mon Oct  1 18:56:52 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 1 Oct 2007 14:56:52 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <1191263109.19127.0.camel@xo-3E-67-34.localdomain>
References: <1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
Message-ID: <20071001185652.GA24204@jadzia.bu.edu>

On Mon, Oct 01, 2007 at 02:25:09PM -0400, Dan Williams wrote:
> > > A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
> > > been pretty stable for me; I have also tried rt76_usb + mac80211 and
> > > that's been OK.
> > orinoco_pci....
> I've got an orinoco pcmcia part, will test with that.

Cool, thanks.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From notting at redhat.com  Mon Oct  1 19:11:44 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 1 Oct 2007 15:11:44 -0400
Subject: When should sysctl be run during boot?
In-Reply-To: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
Message-ID: <20071001191144.GB16413@nostromo.devel.redhat.com>

Jonathan Underwood (jonathan.underwood at gmail.com) said: 
> Thoughts?

As modules could be loaded at any time, it would seem the most
correct way would be to do it via a modprobe.d or udev rule.

Bill



From mjs at CLEMSON.EDU  Mon Oct  1 19:18:40 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 01 Oct 2007 15:18:40 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <1191250903.5368.4.camel@xo-3E-67-34.localdomain>
References: <4c4ba1530709280728g880ef46x2582fe3ae931e338@mail.gmail.com>
	<20070928063428.1a6cb2fe@redhat.com>
	<1190996852.10569.4.camel@vincent52.localdomain>
	<4c4ba1530709281024t30022f8fr438e34ba9bb6765@mail.gmail.com>
	<1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
Message-ID: <1191266320.25159.17.camel@vincent52.localdomain>

On Mon, 2007-10-01 at 11:01 -0400, Dan Williams wrote:
> On Sat, 2007-09-29 at 20:25 -0400, Matthew Miller wrote:
> > On Sat, Sep 29, 2007 at 01:32:38PM -0400, Matthew Saltzman wrote:
> > > Also noticed that (now that I have a connection defined) it doesn't
> > > connect automatically when NM/nm-applet starts (e.g., when I log in).  I
> > > have to pull down the menu and select it.  My F7 machine NM-0.6.5
> > > connects to the most recently used WAP in range when it starts.
> > 
> > You can use gconf-editor to toggle the autoconnect flag for the connections,
> > once you've connected once. This seems to work.
> > 
> > (With the caveat that the whole thing is acting really flaky for me. Once
> > I connect to one network -- or even *try* to connect -- the network card
> > then loses the ability to scan for any networks or connect to other ones
> > until I reboot.)
> 
> A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
> been pretty stable for me; I have also tried rt76_usb + mac80211 and
> that's been OK.

In my case, iwl3945.  But I haven't been in a situation where I could
encounter Matthew Miller's issue, yet.

If I could connect to a hidden network at all, I could try this...

> 
> Dan
> 
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From gunchev at gmail.com  Mon Oct  1 19:29:53 2007
From: gunchev at gmail.com (Doncho N. Gunchev)
Date: Mon, 1 Oct 2007 22:29:53 +0300
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com>
References: <46F8F5E8.3000801@hhs.nl> <46F9440E.4070402@hhs.nl>
	<604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com>
Message-ID: <200710012229.54051.gunchev@gmail.com>

On Tuesday 2007-09-25 21:47:48 Jeff Spaleta wrote:
> On 9/25/07, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> > Well, the live cd has a modifiable filesystem and I'm sure it will contain a
> > texteditor so yes the script can be disabled (by commenting out the check),
> 
> I was thinking more like a environment variable that the script can
> check for. So that on a per-user basis this can be disabled quickly
> for all games just by exporting the environment variable.  Since you
> are asking for the games packages to use this by default, there needs
> to be a per-user way to disable the script action on multi-user
> configurations.
> 
> -jef
> 

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.

I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

-- 
Regards,
  Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu



From drago01 at gmail.com  Mon Oct  1 19:44:20 2007
From: drago01 at gmail.com (dragoran)
Date: Mon, 1 Oct 2007 21:44:20 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <46F94464.602@hhs.nl>
References: <46F8F5E8.3000801@hhs.nl>
	<1190727884.21155.32.camel@home.alexander.bostrom.net>
	<20070925152315.GA31821@jadzia.bu.edu>
	<46F92B3A.40102@herr-schmitt.de> <46F94464.602@hhs.nl>
Message-ID: <f6ca9fed0710011244o31e13f6cpac42f54fab8a83ee@mail.gmail.com>

On 9/25/07, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Jochen Schmitt wrote:
> > Matthew Miller schrieb:
> >> On Tue, Sep 25, 2007 at 03:44:44PM +0200, Alexander Bostr?m wrote:
> >>
> >>> Actually, I would consider that a bug in the application/game. If it's
> >>>
> >> Yeah, but since there's thousands of programs with that "bug", the wrapper
> >> is a nicer solution.
> >>
> >>
> > For me, this wrapper is not a solution, because I have got a error
> > message. I'm using the
> > nvidia driver from rpm.livna.org and stellarium is running fine with
> > this driver.
> >
> > So I was force to block BZ #304851
> >
>
> Ugh, I agree this is bad, but not using the wrapper is not the solution, the
> wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
> where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
> give it a try).

fglrx does while nvidia does _NOT_  use dri



From wart at kobold.org  Mon Oct  1 19:53:57 2007
From: wart at kobold.org (Wart)
Date: Mon, 01 Oct 2007 12:53:57 -0700
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <f6ca9fed0710011244o31e13f6cpac42f54fab8a83ee@mail.gmail.com>
References: <46F8F5E8.3000801@hhs.nl>	<1190727884.21155.32.camel@home.alexander.bostrom.net>	<20070925152315.GA31821@jadzia.bu.edu>	<46F92B3A.40102@herr-schmitt.de>
	<46F94464.602@hhs.nl>
	<f6ca9fed0710011244o31e13f6cpac42f54fab8a83ee@mail.gmail.com>
Message-ID: <47015055.2020602@kobold.org>

dragoran wrote:
> On 9/25/07, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>> Jochen Schmitt wrote:
>>> Matthew Miller schrieb:
>>>> On Tue, Sep 25, 2007 at 03:44:44PM +0200, Alexander Bostr?m wrote:
>>>>
>>>>> Actually, I would consider that a bug in the application/game. If it's
>>>>>
>>>> Yeah, but since there's thousands of programs with that "bug", the wrapper
>>>> is a nicer solution.
>>>>
>>>>
>>> For me, this wrapper is not a solution, because I have got a error
>>> message. I'm using the
>>> nvidia driver from rpm.livna.org and stellarium is running fine with
>>> this driver.
>>>
>>> So I was force to block BZ #304851
>>>
>> Ugh, I agree this is bad, but not using the wrapper is not the solution, the
>> wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
>> where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
>> give it a try).
> 
> fglrx does while nvidia does _NOT_  use dri

Are you sure?  On my system with the nvidia binary drivers from livna:

$ glxinfo | grep -i direct
direct rendering: Yes

...and neverball/neverputt work fine with the wrapper.

Now, the nvidia driver does not load the dri module in xorg.conf, 
presumably because the binary driver has DRI built-in.

--Wart



From ajackson at redhat.com  Mon Oct  1 19:41:05 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 01 Oct 2007 15:41:05 -0400
Subject: /etc/hosts and system entries
In-Reply-To: <544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
	<1191245303.31421.26.camel@localhost.localdomain>
	<544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
Message-ID: <1191267665.31421.66.camel@localhost.localdomain>

On Mon, 2007-10-01 at 15:47 +0100, Bill Crawford wrote:
> On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:
> 
> > I think there's something more subtle going on in this case.  What we do
> > at least in startx(1) is add the cookie to ~/.Xauthority twice, once
> > for :0 and once for foo:0, so the first one should always win.
> 
> I noticed that. Still got this in my output (shortly before a crash in
> libGLcore, which I'm guessing is unrelated to the network issue):
> 
> _IceTransSocketUNIXConnect: Cannot connect to non-local host bill.wcn.co.uk
> Warning: Tried to connect to session manager, Could not open network socket

Okay, I think I have a fix for this.

The bug is that the ICE sockets are bound at session startup by
gnome-session (or whatever), and the path to them is stashed in
$SESSION_MANAGER in the environment as a tuple of (transport, hostname,
port).  But the hostname in that tuple is whatever you got back from
gethostname().  NetworkManager won't change the system hostname when
changing DHCP leases, but dhclient will, and more generally we can't
rely on the user to not set the hostname to whatever they want.

Fortunately, there's a special case in the xtrans code that treats the
hostname "unix" as meaning "no, really, local machine", so for AF_UNIX
transports we just lie and set the "hostname" in the above tuple to be
"unix" and avoid that whole mess.

Fixed in xorg-x11-xtrans-devel 1.0.3-5 and libICE 1.0.4-2 (currently
building).  Anyone who was seeing X app launch stalling or failing after
changing networks/IPs/hostnames/whatever, please update libICE and see
if you can still repro it.

- ajax



From drago01 at gmail.com  Mon Oct  1 20:04:08 2007
From: drago01 at gmail.com (dragoran)
Date: Mon, 1 Oct 2007 22:04:08 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <47015055.2020602@kobold.org>
References: <46F8F5E8.3000801@hhs.nl>
	<1190727884.21155.32.camel@home.alexander.bostrom.net>
	<20070925152315.GA31821@jadzia.bu.edu>
	<46F92B3A.40102@herr-schmitt.de> <46F94464.602@hhs.nl>
	<f6ca9fed0710011244o31e13f6cpac42f54fab8a83ee@mail.gmail.com>
	<47015055.2020602@kobold.org>
Message-ID: <f6ca9fed0710011304u1400239fmede218fe15953367@mail.gmail.com>

On 10/1/07, Wart <wart at kobold.org> wrote:
> > fglrx does while nvidia does _NOT_  use dri
>
> Are you sure?  On my system with the nvidia binary drivers from livna:
>
> $ glxinfo | grep -i direct
> direct rendering: Yes

sure it does provide direct rendering else the driver would be useless ;)

> ...and neverball/neverputt work fine with the wrapper.

ok looked at the warpper code and it seems that it just looks for
direct rendering: Yes in the glxinfo output which should work on any
card providing direct rendering.

> Now, the nvidia driver does not load the dri module in xorg.conf,
> presumably because the binary driver has DRI built-in.

no, there are not using the dri/drm infrastructure at all there using their own.



From packages at amiga-hardware.com  Mon Oct  1 20:39:15 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Mon, 01 Oct 2007 21:39:15 +0100
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <200710012229.54051.gunchev@gmail.com>
References: <46F8F5E8.3000801@hhs.nl>
	<46F9440E.4070402@hhs.nl>	<604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com>
	<200710012229.54051.gunchev@gmail.com>
Message-ID: <47015AF3.307@amiga-hardware.com>

Doncho N. Gunchev wrote:

>> for all games just by exporting the environment variable.  Since you
>> are asking for the games packages to use this by default, there needs
>> to be a per-user way to disable the script action on multi-user
>> configurations.

> 
> Why not a checkbox - don't show this warning again? If checked - touch
> a file (say ~/.no_video_warning) and don't bother the user again.
> 
> I think the user should be able to abort the game start, to start anyway
> and to start anyway and never be bothered again.
> 

+1

To be fair I haven't see the script (yet) but that sounds a like a 
sensible suggestion to me. The user should have the option of continuing 
regardless, if they so choose, and not to be bothered again. This should 
be as simple as possible and done graphically, ideally at launch time.

-- 
Ian Chapman.



From tmus at tmus.dk  Mon Oct  1 21:13:35 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 01 Oct 2007 19:13:35 -0200
Subject: Kernel VMI (Virtual Machine Interface) in F7/F8?
In-Reply-To: <fdp2jf$59a$1@sea.gmane.org>
References: <fdp2jf$59a$1@sea.gmane.org>
Message-ID: <fdrntv$dcs$1@sea.gmane.org>

Thomas M Steenholdt wrote:
> Hi there...
> 
> It seems (noted in releasenotes) that F7 should have a VMI (Virtual 
> Machine Interface) enabled kernel by default, but from what I can find 
> in the .config files it doesn't... Do I need a special kernel (i.e. only 
> the XEN kernel has VMI or something) or was it lost in a kernel update 
> or...?
> 

The bug regarding this, 
https://bugzilla.redhat.com/show_bug.cgi?id=313391 has been closed...

Basically it was never in F7, but might make it into F8.

/Thomas



From drago01 at gmail.com  Mon Oct  1 21:30:32 2007
From: drago01 at gmail.com (dragoran)
Date: Mon, 1 Oct 2007 23:30:32 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <47015AF3.307@amiga-hardware.com>
References: <46F8F5E8.3000801@hhs.nl> <46F9440E.4070402@hhs.nl>
	<604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com>
	<200710012229.54051.gunchev@gmail.com>
	<47015AF3.307@amiga-hardware.com>
Message-ID: <f6ca9fed0710011430o28119ec1s4f93c65bb38b49f@mail.gmail.com>

On 10/1/07, Ian Chapman <packages at amiga-hardware.com> wrote:
> Doncho N. Gunchev wrote:
>
> >> for all games just by exporting the environment variable.  Since you
> >> are asking for the games packages to use this by default, there needs
> >> to be a per-user way to disable the script action on multi-user
> >> configurations.
>
> >
> > Why not a checkbox - don't show this warning again? If checked - touch
> > a file (say ~/.no_video_warning) and don't bother the user again.
> >
> > I think the user should be able to abort the game start, to start anyway
> > and to start anyway and never be bothered again.
> >
>
> +1
>
> To be fair I haven't see the script (yet) but that sounds a like a
> sensible suggestion to me. The user should have the option of continuing
> regardless, if they so choose, and not to be bothered again. This should
> be as simple as possible and done graphically, ideally at launch time.

another thing....
the text should be translateable imho...



From kevin.kofler at chello.at  Mon Oct  1 22:18:07 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 1 Oct 2007 22:18:07 +0000 (UTC)
Subject: Using xdg-utils instead of htmlview, other hardwired apps
References: <200710012141.58217.ville.skytta@iki.fi>
Message-ID: <loom.20071001T221653-273@post.gmane.org>

Ville Skytt? <ville.skytta <at> iki.fi> writes:
> I went through current devel packages that use htmlview or have unnecessarily 
> hardwired dependencies to firefox or evince.

You should also check for hardcoded use of gnome-open, which should be changed 
to xdg-open these days (so it will honor the KDE settings under KDE, not the 
GNOME ones). Though gnome-open is still better than hardcoded firefox of 
course.

        Kevin Kofler



From wart at kobold.org  Mon Oct  1 22:27:57 2007
From: wart at kobold.org (Wart)
Date: Mon, 01 Oct 2007 15:27:57 -0700
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710012141.58217.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
Message-ID: <4701746D.9010605@kobold.org>

Ville Skytt? wrote:
> Hello,
> 
> I went through current devel packages that use htmlview or have unnecessarily 
> hardwired dependencies to firefox or evince.  Most of these should be using 
> xdg-open from xdg-utils instead.  Not hardcoding firefox as the browser and 
> evince as the PDF viewer should be trivial to understand, but why use 
> xdg-open instead of htmlview?  xdg-utils/xdg-open compared to htmlview:
[...]
> - tcldebugger

Fixed in Rawhide.

--Wart



From jonathan.underwood at gmail.com  Mon Oct  1 22:26:54 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 1 Oct 2007 23:26:54 +0100
Subject: When should sysctl be run during boot?
In-Reply-To: <20071001191144.GB16413@nostromo.devel.redhat.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
	<20071001191144.GB16413@nostromo.devel.redhat.com>
Message-ID: <645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>

On 01/10/2007, Bill Nottingham <notting at redhat.com> wrote:
> Jonathan Underwood (jonathan.underwood at gmail.com) said:
> > Thoughts?
>
> As modules could be loaded at any time, it would seem the most
> correct way would be to do it via a modprobe.d or udev rule.
>

I see your point. But, taken to it's logical conclusion, we'd scrap sysctl.conf
completely.

Actually, that would be the right thing to do - it's currently a badly defined
ad hock kludge.

I presume this issue will be shaken out during the initscripts reworking and
NetworkManager revisions in any case.

J.

(In stereo :)



From Matt_Domsch at dell.com  Tue Oct  2 00:25:27 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Mon, 1 Oct 2007 19:25:27 -0500
Subject: When should sysctl be run during boot?
In-Reply-To: <645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
	<20071001191144.GB16413@nostromo.devel.redhat.com>
	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
Message-ID: <20071002002527.GA23057@auslistsprd01.us.dell.com>

On Mon, Oct 01, 2007 at 11:26:54PM +0100, Jonathan Underwood wrote:
> On 01/10/2007, Bill Nottingham <notting at redhat.com> wrote:
> > Jonathan Underwood (jonathan.underwood at gmail.com) said:
> > > Thoughts?
> >
> > As modules could be loaded at any time, it would seem the most
> > correct way would be to do it via a modprobe.d or udev rule.
> >
> 
> I see your point. But, taken to it's logical conclusion, we'd scrap sysctl.conf
> completely.
> 
> Actually, that would be the right thing to do - it's currently a badly defined
> ad hock kludge.


How many modules export sysctls instead of module parameters?

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From tmus at tmus.dk  Tue Oct  2 00:43:12 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 01 Oct 2007 22:43:12 -0200
Subject: When should sysctl be run during boot?
In-Reply-To: <645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>	<20071001191144.GB16413@nostromo.devel.redhat.com>
	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
Message-ID: <fds472$g35$1@sea.gmane.org>

Jonathan Underwood wrote:
> On 01/10/2007, Bill Nottingham <notting at redhat.com> wrote:
>> Jonathan Underwood (jonathan.underwood at gmail.com) said:
>>> Thoughts?
>> As modules could be loaded at any time, it would seem the most
>> correct way would be to do it via a modprobe.d or udev rule.
>>
> 
> I see your point. But, taken to it's logical conclusion, we'd scrap sysctl.conf
> completely.
> 
> Actually, that would be the right thing to do - it's currently a badly defined
> ad hock kludge.
> 
> I presume this issue will be shaken out during the initscripts reworking and
> NetworkManager revisions in any case.
> 

As discussed in the bug 
https://bugzilla.redhat.com/show_bug.cgi?id=312481 , we might be able to 
solve this in a good way, with a few updated tools. I'll outline the 
thoughts here and let everybody join the discussion...

What Jonathan and I discussed, was the possibility of having the module 
loading mechanism (modprobe) figure out what proc nodes a newly loaded 
module provides and selectively, apply settings to those nodes only.

That would make it possible to have a single, system-wide sysctl.conf 
file with settings for all sorts of modules, and we would no longer need 
to worry, that perhaps our modules isn't loaded when the settings are 
applied etc. Also, it makes sure that manually applied settings are not 
touched.
See the following sniplet from the bugzilla discussion for an example:

-- snip --
My system is configured with net.ipv4.ip_forward = 0... But I'm plying 
with routing so I did an echo -n 1 >/proc/sys/net/ipv4/ip_forward to 
enable forwarding. Now I plug in my USB disk and modules gets loaded. 
It's really important that ip_forward is still "1" at this point
-- snap --

This should work for boot, randomly loading and unloading modules, 
manually changing /proc/sys settings at runtime etc.

Perhaps the heuristic needs to be: when loading a module, modprobe 
should (using sysctl or otherwise) look at sysctl.conf and set any 
values for entries created by the loading of this module, and disregard 
all others. sysctl -p would then serve the purpose of resetting all 
values to those in sysctl.conf, if needed by the user.


/Thomas (with random exempts from the BZ dialog with Jonathan Underwood)



From tmus at tmus.dk  Tue Oct  2 00:58:40 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 01 Oct 2007 22:58:40 -0200
Subject: When should sysctl be run during boot?
In-Reply-To: <20071002002527.GA23057@auslistsprd01.us.dell.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>	<20071001191144.GB16413@nostromo.devel.redhat.com>	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
	<20071002002527.GA23057@auslistsprd01.us.dell.com>
Message-ID: <fds542$hu3$1@sea.gmane.org>

Matt Domsch wrote:
> 
> How many modules export sysctls instead of module parameters?
> 

Those are not really exported in a special way for sysctl. They are 
simply proc nodes (files) under /proc/sys, and a *lot* of modules put 
stuff in there for runtime configuration. I have 615 files in there on 
this laptop.

/Thomas



From buytenh at wantstofly.org  Tue Oct  2 01:29:43 2007
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Tue, 2 Oct 2007 03:29:43 +0200
Subject: Fedora -> Fedora cross binutils/gcc/gdb packages
Message-ID: <20071002012943.GA1253@xi.wantstofly.org>

Hi,

I've uploaded a set of prebuilt Fedora -> Fedora cross
binutils/gcc/gdb packages (and their corresponding spec diffs[*]) to:

	http://ftp.linux.org.uk/pub/linux/arm/fedora/cross/latest/

Currently, only i386 -> arm and x86_64 -> arm binary RPMS are
provided.  Non-arm target architectures aren't tested, but should
be possible to make work without too much effort.

These RPMS can be used to cross-compile kernels, and to
cross-compile binaries that are to be run on Fedora systems -- i.e.,
built binaries are built against glibc (so, you can't use these RPMS
to build uClibc binaries, for example) and against other libraries as
included in Fedora.

These RPMS expect a couple of target libraries such as glibc to be
installed in the standard sysroot location, /usr/$target/sys-root/.
There is a script called repack_cross.pl which can convert a target
binary RPM to a noarch RPM with all files moved to
/usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
is included in the abovementioned repository (and pulled in when
you install the cross-compiler.)

There is no support for building the required target libraries without
building the compiler first.  In other words, since the build process
for the cross-compiler depends on there being a suitable target glibc
already, these RPMS and spec diffs can not be used to bootstrap a new
Fedora architecture port from scratch.

Feedback appreciated.


cheers,
Lennert


[*] The included cross-binutils patch is based on an earlier
    cross-binutils patch by David Woodhouse.



From roland at redhat.com  Tue Oct  2 02:25:37 2007
From: roland at redhat.com (Roland McGrath)
Date: Mon,  1 Oct 2007 19:25:37 -0700 (PDT)
Subject: Fedora -> Fedora cross binutils/gcc/gdb packages
In-Reply-To: Lennert Buytenhek's message of  Tuesday,
	2 October 2007 03:29:43 +0200
	<20071002012943.GA1253@xi.wantstofly.org>
References: <20071002012943.GA1253@xi.wantstofly.org>
Message-ID: <20071002022537.519B24D0544@magilla.localdomain>

> There is a script called repack_cross.pl which can convert a target
> binary RPM to a noarch RPM with all files moved to
> /usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
> is included in the abovementioned repository (and pulled in when
> you install the cross-compiler.)

Is there a benefit to this approach vs rpm --root /usr/$target/sys-root
or something along those lines?  It would be nice if all you needed were:
  yum --installroot=/usr/$target/sys-root --arch=$arch groupinstall Development


Thanks,
Roland



From buytenh at wantstofly.org  Tue Oct  2 02:37:39 2007
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Tue, 2 Oct 2007 04:37:39 +0200
Subject: Fedora -> Fedora cross binutils/gcc/gdb packages
In-Reply-To: <20071002022537.519B24D0544@magilla.localdomain>
References: <20071002012943.GA1253@xi.wantstofly.org>
	<20071002022537.519B24D0544@magilla.localdomain>
Message-ID: <20071002023739.GA2649@xi.wantstofly.org>

On Mon, Oct 01, 2007 at 07:25:37PM -0700, Roland McGrath wrote:

> > There is a script called repack_cross.pl which can convert a target
> > binary RPM to a noarch RPM with all files moved to
> > /usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
> > is included in the abovementioned repository (and pulled in when
> > you install the cross-compiler.)
> 
> Is there a benefit to this approach vs rpm --root /usr/$target/sys-root
> or something along those lines?  It would be nice if all you needed were:
>   yum --installroot=/usr/$target/sys-root --arch=$arch groupinstall Development

In your approach, the sys-root would have its own rpm database, which
would make expressing target (build) dependencies somewhat harder,
since rpm wouldn't be able to query the set of installed target rpms.

In my approach target deps are specified by saying something like
"BuildRequires: foo-%{target_triple}".  It would be nice if you could
say something like this instead:

	BuildRequires(target): foo

and if rpm would then know it should query the rpm database in the
sysroot.



From rc040203 at freenet.de  Tue Oct  2 02:46:17 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 02 Oct 2007 04:46:17 +0200
Subject: Fedora -> Fedora cross binutils/gcc/gdb packages
In-Reply-To: <20071002022537.519B24D0544@magilla.localdomain>
References: <20071002012943.GA1253@xi.wantstofly.org>
	<20071002022537.519B24D0544@magilla.localdomain>
Message-ID: <1191293178.3395.105.camel@mccallum.corsepiu.local>

On Mon, 2007-10-01 at 19:25 -0700, Roland McGrath wrote:
> > There is a script called repack_cross.pl which can convert a target
> > binary RPM to a noarch RPM with all files moved to
> > /usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
> > is included in the abovementioned repository (and pulled in when
> > you install the cross-compiler.)
> 
> Is there a benefit to this approach vs rpm --root /usr/$target/sys-root
> or something along those lines?

The "rpm --root" approach is not applicable to cross toolchains, because
cross tools are native host binaries and produce binaries for a target.

The "rpm --root" approach would be applicable to set up a
cross-toolchain's target environment (i.e. the target environment being
_used_ by a cross-toolchain)

Ralf




From buytenh at wantstofly.org  Tue Oct  2 02:49:13 2007
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Tue, 2 Oct 2007 04:49:13 +0200
Subject: Fedora -> Fedora cross binutils/gcc/gdb packages
In-Reply-To: <1191293178.3395.105.camel@mccallum.corsepiu.local>
References: <20071002012943.GA1253@xi.wantstofly.org>
	<20071002022537.519B24D0544@magilla.localdomain>
	<1191293178.3395.105.camel@mccallum.corsepiu.local>
Message-ID: <20071002024913.GA2836@xi.wantstofly.org>

On Tue, Oct 02, 2007 at 04:46:17AM +0200, Ralf Corsepius wrote:

> > > There is a script called repack_cross.pl which can convert a target
> > > binary RPM to a noarch RPM with all files moved to
> > > /usr/$target/sys-root/, and a set of such pre-generated noarch RPMS
> > > is included in the abovementioned repository (and pulled in when
> > > you install the cross-compiler.)
> > 
> > Is there a benefit to this approach vs rpm --root /usr/$target/sys-root
> > or something along those lines?
> 
> The "rpm --root" approach is not applicable to cross toolchains, because
> cross tools are native host binaries and produce binaries for a target.
> 
> The "rpm --root" approach would be applicable to set up a
> cross-toolchain's target environment (i.e. the target environment being
> _used_ by a cross-toolchain)

He was talking about that latter case, though.

I.e., what you put into /usr/$target/sys-root _are_ target packages.



From ville.skytta at iki.fi  Tue Oct  2 06:42:10 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Tue, 2 Oct 2007 09:42:10 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <loom.20071001T221653-273@post.gmane.org>
References: <200710012141.58217.ville.skytta@iki.fi>
	<loom.20071001T221653-273@post.gmane.org>
Message-ID: <200710020942.10330.ville.skytta@iki.fi>

On Tuesday 02 October 2007, Kevin Kofler wrote:
> Ville Skytt? <ville.skytta <at> iki.fi> writes:
> > I went through current devel packages that use htmlview or have
> > unnecessarily hardwired dependencies to firefox or evince.
>
> You should also check for hardcoded use of gnome-open, which should be
> changed to xdg-open these days (so it will honor the KDE settings under
> KDE, not the GNOME ones).

Yep, that's essentially the same improvement that xdg-open has over htmlview 
(and similarly for XFCE).

The first batch was done by going through packages returned 
by "repoquery --repoid=development --whatrequires --alldeps htmlview" and 
similarly for firefox and evince.  I plan to do some grepping later as for 
example repoquery might not be the best tool to find out uses of gnome-open, 
and some packages have missing dependencies (eg. to htmlview) which means 
they're not found by repoquery anyway.



From kraxel at redhat.com  Tue Oct  2 07:33:08 2007
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Tue, 02 Oct 2007 09:33:08 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710012141.58217.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
Message-ID: <4701F434.80604@redhat.com>

Ville Skytt? wrote:
> Hello,
> 
> I went through current devel packages that use htmlview or have unnecessarily 
> hardwired dependencies to firefox or evince.  Most of these should be using 
> xdg-open from xdg-utils instead.

Oh, btw: suggestions how do display manual pages?  xdg-utils
documentation says nothing about it.

xdg-open "man:ls(1)" seems to work ok in kde and gnome.  Dunno whenever
that is just good luck or supposed to work that way?

cheers,
  Gerd



From pertusus at free.fr  Tue Oct  2 07:38:21 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 2 Oct 2007 09:38:21 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <4701F434.80604@redhat.com>
References: <200710012141.58217.ville.skytta@iki.fi>
	<4701F434.80604@redhat.com>
Message-ID: <20071002073821.GB3535@free.fr>

On Tue, Oct 02, 2007 at 09:33:08AM +0200, Gerd Hoffmann wrote:
> Ville Skytt? wrote:
> > Hello,
> > 
> > I went through current devel packages that use htmlview or have unnecessarily 
> > hardwired dependencies to firefox or evince.  Most of these should be using 
> > xdg-open from xdg-utils instead.
> 
> Oh, btw: suggestions how do display manual pages?  xdg-utils
> documentation says nothing about it.
> 
> xdg-open "man:ls(1)" seems to work ok in kde and gnome.  Dunno whenever
> that is just good luck or supposed to work that way?

It doesn't work with mimeopen:
Could not determine mimetype for file: man:ls(1)

Its doesn't seems to work with firefox.

It works with exo-open.

--
Pat



From buildsys at redhat.com  Tue Oct  2 09:01:28 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 2 Oct 2007 05:01:28 -0400
Subject: rawhide report: 20071002 changes
Message-ID: <200710020901.l9291SgZ012106@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
	osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
	osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
	osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
	osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
	osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
	osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgText.so.1
	osgal - 20060903-3.fc7.i386 requires libosg.so.1
	osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit)
	osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit)
	osgal - 20060903-3.fc7.i386 requires libosgDB.so.1
	osgal - 20060903-3.fc7.i386 requires libosgFX.so.1
	osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1
	osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1
	osgal - 20060903-3.fc7.i386 requires libosgSim.so.1
	osgal - 20060903-3.fc7.i386 requires libosgGA.so.1
	osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.i386 requires libosgText.so.1
	osgal - 20060903-3.fc7.i386 requires libosg.so.1
	osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1
	osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit)
	osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.ppc requires libosgDB.so.1
	osgal - 20060903-3.fc7.ppc requires libosgFX.so.1
	osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1
	osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1
	osgal - 20060903-3.fc7.ppc requires libosgSim.so.1
	osgal - 20060903-3.fc7.ppc requires libosgGA.so.1
	osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1
	osgal - 20060903-3.fc7.ppc requires libosgText.so.1
	osgal - 20060903-3.fc7.ppc requires libosg.so.1
	osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1
	osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	resapplet - 0.1.1-6.fc8.ppc64 requires system-config-display
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From jonathan.underwood at gmail.com  Tue Oct  2 09:27:10 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 2 Oct 2007 10:27:10 +0100
Subject: When should sysctl be run during boot?
In-Reply-To: <fds542$hu3$1@sea.gmane.org>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
	<20071001191144.GB16413@nostromo.devel.redhat.com>
	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
	<20071002002527.GA23057@auslistsprd01.us.dell.com>
	<fds542$hu3$1@sea.gmane.org>
Message-ID: <645d17210710020227wc498701y2a41b3768706f603@mail.gmail.com>

On 02/10/2007, Thomas M Steenholdt <tmus at tmus.dk> wrote:
> Matt Domsch wrote:
> >
> > How many modules export sysctls instead of module parameters?
> >
>
> Those are not really exported in a special way for sysctl. They are
> simply proc nodes (files) under /proc/sys, and a *lot* of modules put
> stuff in there for runtime configuration. I have 615 files in there on
> this laptop.

I could be wrong, but I don't think anything exports a seetting that
is only changeable with sysctl that is not also changeable by echo'ing
to a file under /proc/sys - sysctl seems rather obsolete in this
respect.



From fedora at camperquake.de  Tue Oct  2 09:33:13 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 2 Oct 2007 11:33:13 +0200
Subject: When should sysctl be run during boot?
In-Reply-To: <645d17210710020227wc498701y2a41b3768706f603@mail.gmail.com>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>
	<20071001191144.GB16413@nostromo.devel.redhat.com>
	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>
	<20071002002527.GA23057@auslistsprd01.us.dell.com>
	<fds542$hu3$1@sea.gmane.org>
	<645d17210710020227wc498701y2a41b3768706f603@mail.gmail.com>
Message-ID: <20071002113313.6ca7441e@banea.int.addix.net>

Hi.

On Tue, 2 Oct 2007 10:27:10 +0100, Jonathan Underwood wrote:

> I could be wrong, but I don't think anything exports a seetting that
> is only changeable with sysctl that is not also changeable by echo'ing
> to a file under /proc/sys - sysctl seems rather obsolete in this
> respect.

Personally, I prefer sysctl for that. Works better with sudo.



From aportal at univ-montp2.fr  Tue Oct  2 09:29:47 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Tue, 2 Oct 2007 11:29:47 +0200
Subject: FC-6: automake-1.9 on ppc
Message-ID: <200710021129.47993.aportal@univ-montp2.fr>

Hi,

PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and 
automake-1.9 were not found:
http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2.4-1.fc6/

Can somebody help me to fix?

Regards,
Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From pertusus at free.fr  Tue Oct  2 10:09:11 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 2 Oct 2007 12:09:11 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <200710021129.47993.aportal@univ-montp2.fr>
References: <200710021129.47993.aportal@univ-montp2.fr>
Message-ID: <20071002100910.GD3535@free.fr>

On Tue, Oct 02, 2007 at 11:29:47AM +0200, Alain PORTAL wrote:
> Hi,
> 
> PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and 
> automake-1.9 were not found:
> http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2.4-1.fc6/
> 
> Can somebody help me to fix?

There is more than one way to fix such issues, but in that case it is 
a bit strange that autotools are rerun since you didn't patch the
corresponding files (as far as I can tell from looking at the build 
log). Maybe the timestamps are not right in the upstream tarball? 
The make commands calling the autotools should only be called if a 
resulting file is older than the file it comes from.

A ugly workaround -- but I doubt it is right in that case -- could also
be to package automake19 and BuildRequires it.

--
Pat



From tmus at tmus.dk  Tue Oct  2 10:31:42 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Tue, 02 Oct 2007 08:31:42 -0200
Subject: When should sysctl be run during boot?
In-Reply-To: <20071002113313.6ca7441e@banea.int.addix.net>
References: <645d17210709291548w455acd2dr9605533fa8f4eb61@mail.gmail.com>	<20071001191144.GB16413@nostromo.devel.redhat.com>	<645d17210710011526g6746f34em839b19c91af3a6b1@mail.gmail.com>	<20071002002527.GA23057@auslistsprd01.us.dell.com>	<fds542$hu3$1@sea.gmane.org>	<645d17210710020227wc498701y2a41b3768706f603@mail.gmail.com>
	<20071002113313.6ca7441e@banea.int.addix.net>
Message-ID: <fdt6mg$stj$1@sea.gmane.org>

Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 2 Oct 2007 10:27:10 +0100, Jonathan Underwood wrote:
> 
>> I could be wrong, but I don't think anything exports a seetting that
>> is only changeable with sysctl that is not also changeable by echo'ing
>> to a file under /proc/sys - sysctl seems rather obsolete in this
>> respect.
> 
> Personally, I prefer sysctl for that. Works better with sudo.
> 

I agree that sysctl (or a similar tool - i'm not religious in this area) 
is probably wanted, albeit not required on a system. Like I stated 
somewhere else, sysctl "only" modifies things in /proc/sys that you 
could easili do with something else. There is nothing that you can do 
with sysctl that you can't do with echo, cat and find. Apart from having 
a simple way to set a lot of different values in one go.

/Thomas

/Thomas



From howard at cohtech.com  Tue Oct  2 10:36:07 2007
From: howard at cohtech.com (Howard Wilkinson)
Date: Tue, 02 Oct 2007 11:36:07 +0100
Subject: Latest kernel still has Bonding bug report on startup!
Message-ID: <47021F17.7060806@cohtech.com>

I reported a bug against a previous version of the kernel with the 
bonding network interface - somebody else raised the bug. I have just 
installed the latest development kernel and it still reports a problem. 
Dmesg trace attached.

-- 

Howard Wilkinson

	

Phone:

	

+44(20)76907075

Coherent Technology Limited

	

Fax:

	

 

23 Northampton Square,

	

Mobile:

	

+44(7980)639379

United Kingdom, EC1V 0HL

	

Email:

	

howard at cohtech.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/8b93a59a/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kernel-2.6.23-0.214.rc8.git2.fc8
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/8b93a59a/attachment.ksh>

From oliver at linux-kernel.at  Tue Oct  2 10:38:21 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 02 Oct 2007 12:38:21 +0200
Subject: pungi, python and the question: where are the python gurus?
Message-ID: <47021F9D.7060103@linux-kernel.at>

Hi!

It might be likely possible, that nobody using Fedora and using pungi
ever tried creating isos, is that right? I don't think so. But it might
likely be possible, that nobody ever tried to create non-DVD isos and
therefor nobody encountered the following problem:

[root at gosa pungi]# sh ~/bin/run_pungi.sh
Traceback (most recent call last):
  File "/usr/bin/pungi", line 178, in <module>
    main()
  File "/usr/bin/pungi", line 43, in main
    config.set('default', 'cdsize', part.size)
  File "/usr/lib/python2.5/ConfigParser.py", line 639, in set
    raise TypeError("option values must be strings")
TypeError: option values must be strings


This came up after I enabled the following in my pungi (ks/kickstart)
config:

part iso --size=650

Well, no 650 is not a string (is it?), but for me option values in this
case are allowed to be instance of int as well and in any other case
that might be true also. Therefor my suggested patch attached; Simply
checks if option value is instance string OR int. And it also prints out
the value in case it's not a string/int, for easier debugging.

And before someone asks:
[oliver at gosa devel]$ rpm -q pungi python
pungi-1.1.3-1.fc8
python-2.5.1-11.fc8

So please python geeks/gurus and/or python guys with good connections to
upstream python. Fix/nring it upstream. :-)

Thanks a lot for listening,
 Oliver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python2.5_configparser.fix.patch
Type: text/x-patch
Size: 607 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/0aa172f6/attachment.bin>

From billcrawford1970 at gmail.com  Tue Oct  2 10:47:30 2007
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 2 Oct 2007 11:47:30 +0100
Subject: /etc/hosts and system entries
In-Reply-To: <1191267665.31421.66.camel@localhost.localdomain>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
	<1191245303.31421.26.camel@localhost.localdomain>
	<544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
	<1191267665.31421.66.camel@localhost.localdomain>
Message-ID: <544eb990710020347l270ec4e8y9362aa2e91b05682@mail.gmail.com>

On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:

> Okay, I think I have a fix for this.
>
> The bug is that the ICE sockets are bound at session startup by
> gnome-session (or whatever), and the path to them is stashed in
> $SESSION_MANAGER in the environment as a tuple of (transport, hostname,
> port).  But the hostname in that tuple is whatever you got back from
> gethostname().  NetworkManager won't change the system hostname when
> changing DHCP leases, but dhclient will, and more generally we can't
> rely on the user to not set the hostname to whatever they want.

Aha!

Yes, that would do it.

> Fortunately, there's a special case in the xtrans code that treats the
> hostname "unix" as meaning "no, really, local machine", so for AF_UNIX
> transports we just lie and set the "hostname" in the above tuple to be
> "unix" and avoid that whole mess.

That makes sense.

> Fixed in xorg-x11-xtrans-devel 1.0.3-5 and libICE 1.0.4-2 (currently
> building).  Anyone who was seeing X app launch stalling or failing after
> changing networks/IPs/hostnames/whatever, please update libICE and see
> if you can still repro it.

Any chance of an F7 update for that? I can't really justify pushing
rawhide (or test3) onto my workstation here ...

> - ajax



From harald at redhat.com  Tue Oct  2 10:53:42 2007
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 02 Oct 2007 12:53:42 +0200
Subject: NO CD/DVD's detected
In-Reply-To: <1190946567.32697.3.camel@scrappy.miketc.com>
References: <1190946567.32697.3.camel@scrappy.miketc.com>
Message-ID: <47022336.8000901@redhat.com>

Mike Chambers schrieb:
> I don't know about after an initial f8t2 install, but at least since the
> updates, k3b nor xcdroast can detect a cdrom nor dvd drive.  It wasn't
> detected on my last updated system before I did a reinstall yesterday.
> I can see the devices in the kernel messages.  Would this have to do
> with cdrecord or something about that, as I thought there were license
> problems with that program and therefore is maybe screwing things up?
> 

Hmm, k3b WORKSFORME.. Is ConsoleKit running?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: k3b-out.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/92f96b17/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3623 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/92f96b17/attachment.bin>

From alexm at asic.udl.cat  Tue Oct  2 11:16:46 2007
From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=)
Date: Tue, 02 Oct 2007 13:16:46 +0200
Subject: LTSP 5 on Fedora
In-Reply-To: <645d17210710010631h570cb167q77e209b86bf58bfa@mail.gmail.com>
References: <4700E9FE.8000409@asic.udl.cat>
	<645d17210710010631h570cb167q77e209b86bf58bfa@mail.gmail.com>
Message-ID: <4702289E.4030202@asic.udl.cat>

En/na Jonathan Underwood ha escrit:
> On 01/10/2007, Alexandre Magaz Gra?a <alexm at asic.udl.cat> wrote:
>> Hi,
>> While searching for LTSP 5 for Fedora, I didn't find anything but this
>> bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also,
>> I've not found anything regarding LTSP in this list.
>>
>> So, Is someone working on LTSP 5 support for Fedora? Is there some
>> repository were pick code from or anything?
>>
>> Thanks,
>> ?lex
> 
> Does the k21ltsp project do what you're asking?
> 
> http://www.k12ltsp.org/
> 

Not exactly, the last version still uses LTSP 4.2. I've have to look 
whether they are working on LTSP 5.



From alexm at asic.udl.cat  Tue Oct  2 11:38:27 2007
From: alexm at asic.udl.cat (=?ISO-8859-1?Q?Alexandre_Magaz_Gra=E7a?=)
Date: Tue, 02 Oct 2007 13:38:27 +0200
Subject: LTSP 5 on Fedora
In-Reply-To: <4700F967.9010808@redhat.com>
References: <4700E9FE.8000409@asic.udl.cat> <4700F967.9010808@redhat.com>
Message-ID: <47022DB3.30408@asic.udl.cat>

En/na Warren Togami ha escrit:
> Alexandre Magaz Gra?a wrote:
>> Hi,
>> While searching for LTSP 5 for Fedora, I didn't find anything but this 
>> bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also, 
>> I've not found anything regarding LTSP in this list.
>>
>> So, Is someone working on LTSP 5 support for Fedora? Is there some 
>> repository were pick code from or anything?
>>
>> Thanks,
>> ?lex
>>
> 
> Eric Harrison said that he's hoping to get the LTSP 5 bits into Fedora, 
> after that point he'll need other people to help maintain the packages 
> in Fedora.  I'm meeting him in Oregon next weekend to get started on this.
> 
> Warren Togami
> wtogami at redhat.com
> 

Then I suppose I won't be in time to test it. But it's great to see that 
someone is working on this.



From dcbw at redhat.com  Tue Oct  2 11:59:10 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 02 Oct 2007 07:59:10 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <20071001185652.GA24204@jadzia.bu.edu>
References: <1191004430.12453.4.camel@vincent52.localdomain>
	<1191014980.12995.14.camel@vincent52.localdomain>
	<4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
Message-ID: <1191326350.21429.24.camel@xo-3E-67-34.localdomain>

On Mon, 2007-10-01 at 14:56 -0400, Matthew Miller wrote:
> On Mon, Oct 01, 2007 at 02:25:09PM -0400, Dan Williams wrote:
> > > > A driver based on mac80211 perhaps?  which one?  At least ipw2200 has
> > > > been pretty stable for me; I have also tried rt76_usb + mac80211 and
> > > > that's been OK.
> > > orinoco_pci....
> > I've got an orinoco pcmcia part, will test with that.
> 
> Cool, thanks.

So I tried this.  It sucks.  The orinoco driver has problems scanning
when wpa_supplicant is active, which it really shouldn't care about.
Plus, I only get 2 or 3 results from the driver anyway, when my internal
ipw2200 card gets 10.  Maybe the internal Thinkpad antenna is just that
much better.  I _was_ able to connect with the orinoco card and keep the
connection, but gradually all scan results dropped out of the list, and
even 'iwlist eth2 scan' would only return the AP I was connected to,
even though there are other strong APs nearby.

I think there's a lot of room for improvement in the driver.  It's
pretty racy with scan results.  First, reading of scan results should be
decoupled from the actual process of scanning, and scan results should
be aged before being dropped completely.  There's a fairly large window
of time where scan results won't be available to the caller even though
a successful scan could have happened a second ago.  The scan_inprogress
flag shouldn't have any semantics leak out to userspace.

I did a patch for airo a year or two ago that cleaned exactly this sort
of behavior up.  Not sure that really helps you much.  As a quick test,
what happens if you do a few back-to-back 'iwlist ethX scan' commands?

Dan




From jkeating at redhat.com  Tue Oct  2 12:36:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 2 Oct 2007 08:36:28 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <47021F9D.7060103@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
Message-ID: <20071002083628.1de8ff80@redhat.com>

On Tue, 02 Oct 2007 12:38:21 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> It might be likely possible, that nobody using Fedora and using pungi
> ever tried creating isos, is that right? I don't think so. But it
> might likely be possible, that nobody ever tried to create non-DVD
> isos 

That's far more likely.  In fact, my last couple releases the
validation I did didn't include split iso tests, so this code path is a
bit unused.

> and therefor nobody encountered the following problem:
> 
> [root at gosa pungi]# sh ~/bin/run_pungi.sh
> Traceback (most recent call last):
>   File "/usr/bin/pungi", line 178, in <module>
>     main()
>   File "/usr/bin/pungi", line 43, in main
>     config.set('default', 'cdsize', part.size)
>   File "/usr/lib/python2.5/ConfigParser.py", line 639, in set
>     raise TypeError("option values must be strings")
> TypeError: option values must be strings
> 
> 
> This came up after I enabled the following in my pungi (ks/kickstart)
> config:
> 
> part iso --size=650

Ok, yeah, this is just clearly a bug in pungi.  Pykickstart hands this
back as an int, but pungi is trying to stuff that into a ConfigParser
set, which requires strings.  The correct thing to do here is to wrap
that stuffing in str().

I've made that change and done some local testing and this appears to
solve the problem.  I'll commit to tip and get a new build out today.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/c32ac475/attachment.sig>

From oliver at linux-kernel.at  Tue Oct  2 12:47:06 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 02 Oct 2007 14:47:06 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <20071002083628.1de8ff80@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
Message-ID: <47023DCA.5050506@linux-kernel.at>

On 10/02/2007 02:36 PM, Jesse Keating wrote:
> On Tue, 02 Oct 2007 12:38:21 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
> 
>> It might be likely possible, that nobody using Fedora and using pungi
>> ever tried creating isos, is that right? I don't think so. But it
>> might likely be possible, that nobody ever tried to create non-DVD
>> isos 
> 
> That's far more likely.  In fact, my last couple releases the
> validation I did didn't include split iso tests, so this code path is a
> bit unused.

No problem. I'll (have to) validate this code path frequently, since
most Alphas dont' have a DVD ROM. None of mine has one...

And oh well, that reminds me, that a need to submit some patch for
anaconda...

>> and therefor nobody encountered the following problem:
>>
>> [root at gosa pungi]# sh ~/bin/run_pungi.sh
>> Traceback (most recent call last):
>>   File "/usr/bin/pungi", line 178, in <module>
>>     main()
>>   File "/usr/bin/pungi", line 43, in main
>>     config.set('default', 'cdsize', part.size)
>>   File "/usr/lib/python2.5/ConfigParser.py", line 639, in set
>>     raise TypeError("option values must be strings")
>> TypeError: option values must be strings
>>
>>
>> This came up after I enabled the following in my pungi (ks/kickstart)
>> config:
>>
>> part iso --size=650
> 
> Ok, yeah, this is just clearly a bug in pungi.  Pykickstart hands this
> back as an int, but pungi is trying to stuff that into a ConfigParser
> set, which requires strings.  The correct thing to do here is to wrap
> that stuffing in str().

OK, that might be the better fix. But doesn't it make sense ConfigParser
also allows int as values? I mean any kind of number (int, float,
complex) could be handled as string...

> I've made that change and done some local testing and this appears to
> solve the problem.  I'll commit to tip and get a new build out today.

Thx Jesse, it's great you're there; We can always count on you, your
quick responses and lighting-speed fast actions! :-)

-of



From mattdm at mattdm.org  Tue Oct  2 15:00:16 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 2 Oct 2007 11:00:16 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <1191326350.21429.24.camel@xo-3E-67-34.localdomain>
References: <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
	<1191326350.21429.24.camel@xo-3E-67-34.localdomain>
Message-ID: <20071002150016.GA26688@jadzia.bu.edu>

On Tue, Oct 02, 2007 at 07:59:10AM -0400, Dan Williams wrote:
> So I tried this.  It sucks.  The orinoco driver has problems scanning

:) Glad to have confirmation, at least.

> I did a patch for airo a year or two ago that cleaned exactly this sort
> of behavior up.  Not sure that really helps you much.  As a quick test,
> what happens if you do a few back-to-back 'iwlist ethX scan' commands?

Initially, works fine. But if I connect to a network once and then try
again, I get a lot of "Failed to read scan data : resource temporarily
available". Once I see that message, it isn't going to connect until I
reboot.

And not a soft reboot -- has to be powered off. 






-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jkeating at redhat.com  Tue Oct  2 15:02:23 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 2 Oct 2007 11:02:23 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <47023DCA.5050506@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
	<47023DCA.5050506@linux-kernel.at>
Message-ID: <20071002110223.5cfb5e45@redhat.com>

On Tue, 02 Oct 2007 14:47:06 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> OK, that might be the better fix. But doesn't it make sense
> ConfigParser also allows int as values? I mean any kind of number
> (int, float, complex) could be handled as string...

I know not the history of ConfigParser and why it's only strings.  I
suspect it's because ConfigParser's primary usage is to parse config
files, and in a file it may be non-obvious how to mark something as an
int/float rather than a string.  The reason pungi uses ConfigParser is
that prior to using kickstart files we had our own config files.  I'm
not entirely happy with ConfigParser, but it'd be something of an
overhaul to switch to some other config system, and not one I was
willing to make at this point.  Maybe during F9...

> 
> > I've made that change and done some local testing and this appears
> > to solve the problem.  I'll commit to tip and get a new build out
> > today.  
> 
> Thx Jesse, it's great you're there; We can always count on you, your
> quick responses and lighting-speed fast actions! :-)

Hah, thanks.  If only all my bugs were this easy.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/ca000ca4/attachment.sig>

From j.w.r.degoede at hhs.nl  Tue Oct  2 15:05:38 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 02 Oct 2007 17:05:38 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <47015AF3.307@amiga-hardware.com>
References: <46F8F5E8.3000801@hhs.nl>	<46F9440E.4070402@hhs.nl>	<604aa7910709251147v614239a5r5b5e49289503f8fc@mail.gmail.com>	<200710012229.54051.gunchev@gmail.com>
	<47015AF3.307@amiga-hardware.com>
Message-ID: <47025E42.2030604@hhs.nl>

Ian Chapman wrote:
> Doncho N. Gunchev wrote:
> 
>>> for all games just by exporting the environment variable.  Since you
>>> are asking for the games packages to use this by default, there needs
>>> to be a per-user way to disable the script action on multi-user
>>> configurations.
> 
>>
>> Why not a checkbox - don't show this warning again? If checked - touch
>> a file (say ~/.no_video_warning) and don't bother the user again.
>>
>> I think the user should be able to abort the game start, to start anyway
>> and to start anyway and never be bothered again.
>>
> 
> +1
> 
> To be fair I haven't see the script (yet) but that sounds a like a 
> sensible suggestion to me. The user should have the option of continuing 
> regardless, if they so choose, and not to be bothered again. This should 
> be as simple as possible and done graphically, ideally at launch time.
> 

There are 2 issues with these train of thoughts:
1) There really is no reason to want to run fullscreen OpenGL programs without
    hardware acceleration, they will not be usable <period>. If you don't
    believe me, try it!
2) The current wrapper uses zenity, so it cannot do the advenced kind of
    dialogs with a checkbox people ask for.

All in all I believe less is more, so that things are fine as is, the menu 
entries all launch foo-wrapper, if a user _really_ think he / she knows better, 
all she needs todo is to launch foo, or to modify the menu entry and strip the 
wrapper.

Regards,

Hans



From oliver at linux-kernel.at  Tue Oct  2 15:18:01 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 02 Oct 2007 17:18:01 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <20071002110223.5cfb5e45@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
Message-ID: <47026129.2080001@linux-kernel.at>

On 10/02/2007 05:02 PM, Jesse Keating wrote:
> On Tue, 02 Oct 2007 14:47:06 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
> 
>> OK, that might be the better fix. But doesn't it make sense
>> ConfigParser also allows int as values? I mean any kind of number
>> (int, float, complex) could be handled as string...
> 
> I know not the history of ConfigParser and why it's only strings.  I
> suspect it's because ConfigParser's primary usage is to parse config
> files, and in a file it may be non-obvious how to mark something as an
> int/float rather than a string.  The reason pungi uses ConfigParser is
> that prior to using kickstart files we had our own config files.  I'm
> not entirely happy with ConfigParser, but it'd be something of an
> overhaul to switch to some other config system, and not one I was
> willing to make at this point.  Maybe during F9...

I c. Well. I don't mind what pungi uses to parse configs, but it
MustWork(tm) :-)

Kickstart files aren't pretty, but we already know them well. Maybe it
would be better to switch to xml with 'em, but... Forget... That's
another story, isn't it? :-)

>>> I've made that change and done some local testing and this appears
>>> to solve the problem.  I'll commit to tip and get a new build out
>>> today.  
>> Thx Jesse, it's great you're there; We can always count on you, your
>> quick responses and lighting-speed fast actions! :-)
> 
> Hah, thanks.  If only all my bugs were this easy.

*grin* I can assign all my easy bugs to you, this way you might reach 90
% easy bugs... :-) And you can say, ey' guys I solved 50 bugs this day. :-)

Best,
 Oliver



From dcbw at redhat.com  Tue Oct  2 15:26:19 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 02 Oct 2007 11:26:19 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <20071002150016.GA26688@jadzia.bu.edu>
References: <4c4ba1530709281441s79944ecewf6952b7b331a0975@mail.gmail.com>
	<1191018515.12995.30.camel@vincent52.localdomain>
	<1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
	<1191326350.21429.24.camel@xo-3E-67-34.localdomain>
	<20071002150016.GA26688@jadzia.bu.edu>
Message-ID: <1191338779.31874.5.camel@xo-3E-67-34.localdomain>

On Tue, 2007-10-02 at 11:00 -0400, Matthew Miller wrote:
> On Tue, Oct 02, 2007 at 07:59:10AM -0400, Dan Williams wrote:
> > So I tried this.  It sucks.  The orinoco driver has problems scanning
> 
> :) Glad to have confirmation, at least.
> 
> > I did a patch for airo a year or two ago that cleaned exactly this sort
> > of behavior up.  Not sure that really helps you much.  As a quick test,
> > what happens if you do a few back-to-back 'iwlist ethX scan' commands?
> 
> Initially, works fine. But if I connect to a network once and then try
> again, I get a lot of "Failed to read scan data : resource temporarily
> available". Once I see that message, it isn't going to connect until I
> reboot.
> 
> And not a soft reboot -- has to be powered off. 

Does rmmoding orinoco_pci reset it sufficiently?

"resource temporarily unavailable" I believe means -EAGAIN, which means
the card is currently scanning.  However, ideally that shouldn't stop
the driver from returning the previous scan results to you (as long as
they aren't too old of course, at which point they should be culled).
If a program wants the latest results, it can certainly listen for the
netlink messages the driver sends when it has updated results.

I think this requires a driver update; maybe wpa_supplicant needs to be
more lenient in its timeouts for getting scan data out of the card, but
I'm pretty sure it's waiting ~ 10s max before asking the card for
results explicitly.

Dan




From Curtis at GreenKey.net  Tue Oct  2 15:49:10 2007
From: Curtis at GreenKey.net (Curtis Doty)
Date: Tue, 2 Oct 2007 08:49:10 -0700 (PDT)
Subject: crystal-project crashes repoquery
In-Reply-To: <1191180624.10605.4.camel@rousalka.dyndns.org>
References: <20070930191835.D90536F1C2@alopias.GreenKey.net>
	<1191180624.10605.4.camel@rousalka.dyndns.org>
Message-ID: <20071002154910.EF1AB6F1C2@alopias.GreenKey.net>

Sunday Nicolas Mailhot said:

> Le dimanche 30 septembre 2007 ? 12:18 -0700, Curtis Doty a ?crit :
>
>> It's been most annoying due to its wholesale breakage of my favorite
>> "repoquery -qal |grep foo" without providing any helpful info.
>>
>> It appears the problem stems from some corrupt filenames in
>> crystal_project.tar.gz: crystal_project/*/apps/softwareD???.png Where
>> those three oddball 8-bit chars are 0xEF, 0x80 and 0x83.
>
> It's probably a repoquery bug ?? our python tools are supposed to handle
> UTF-8 but this has not been impressed strongly enough on their writers
> at the right time. And current python is a mess on the unicode front, so
> software writers have to care about it for stuff to work.
>

Ok, I've opened bz#315491 against yum-utils.

../C

From ajackson at redhat.com  Tue Oct  2 15:37:37 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 02 Oct 2007 11:37:37 -0400
Subject: /etc/hosts and system entries
In-Reply-To: <544eb990710020347l270ec4e8y9362aa2e91b05682@mail.gmail.com>
References: <46FBB734.90403@ip-solutions.net>
	<20070927100229.36836163.dcantrell@redhat.com>
	<1190902242.3476.8.camel@hopeson>
	<1190912434.30715.1.camel@localhost.localdomain>
	<544eb990709280627h2166ac36mf38ee6e8239efe48@mail.gmail.com>
	<1191245303.31421.26.camel@localhost.localdomain>
	<544eb990710010747u32c58288oe9ffaf64a90a566f@mail.gmail.com>
	<1191267665.31421.66.camel@localhost.localdomain>
	<544eb990710020347l270ec4e8y9362aa2e91b05682@mail.gmail.com>
Message-ID: <1191339457.31421.124.camel@localhost.localdomain>

On Tue, 2007-10-02 at 11:47 +0100, Bill Crawford wrote:
> On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:
> > Fixed in xorg-x11-xtrans-devel 1.0.3-5 and libICE 1.0.4-2 (currently
> > building).  Anyone who was seeing X app launch stalling or failing after
> > changing networks/IPs/hostnames/whatever, please update libICE and see
> > if you can still repro it.
> 
> Any chance of an F7 update for that? I can't really justify pushing
> rawhide (or test3) onto my workstation here ...

Why sure.  Just built libICE 1.0.3-2.1.fc7, should be headed to
updates-testing soon.

- ajax



From tla at rasmil.dk  Tue Oct  2 16:04:47 2007
From: tla at rasmil.dk (Tim Lauridsen)
Date: Tue, 02 Oct 2007 18:04:47 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <20071002110223.5cfb5e45@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
Message-ID: <47026C1F.7060808@rasmil.dk>

Jesse Keating wrote:
> On Tue, 02 Oct 2007 14:47:06 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
>
>   
>> OK, that might be the better fix. But doesn't it make sense
>> ConfigParser also allows int as values? I mean any kind of number
>> (int, float, complex) could be handled as string...
>>     
>
> I know not the history of ConfigParser and why it's only strings.  I
> suspect it's because ConfigParser's primary usage is to parse config
> files, and in a file it may be non-obvious how to mark something as an
> int/float rather than a string.  The reason pungi uses ConfigParser is
> that prior to using kickstart files we had our own config files.  I'm
> not entirely happy with ConfigParser, but it'd be something of an
> overhaul to switch to some other config system, and not one I was
> willing to make at this point.  Maybe during F9...
>   
You can take a look at the config classes in yum (yum/config.py) it let 
you define different kind of options types.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/44b6c31f/attachment.htm>

From skvidal at fedoraproject.org  Tue Oct  2 16:08:43 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 02 Oct 2007 12:08:43 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <47026C1F.7060808@rasmil.dk>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>  <47026C1F.7060808@rasmil.dk>
Message-ID: <1191341323.6741.17.camel@cutter>


On Tue, 2007-10-02 at 18:04 +0200, Tim Lauridsen wrote:
> Jesse Keating wrote: 
> > On Tue, 02 Oct 2007 14:47:06 +0200
> > Oliver Falk &lt;oliver at linux-kernel.at&gt; wrote:
> > 
> >   
> > > OK, that might be the better fix. But doesn't it make sense
> > > ConfigParser also allows int as values? I mean any kind of number
> > > (int, float, complex) could be handled as string...
> > >     
> > 
> > I know not the history of ConfigParser and why it's only strings.  I
> > suspect it's because ConfigParser's primary usage is to parse config
> > files, and in a file it may be non-obvious how to mark something as an
> > int/float rather than a string.  The reason pungi uses ConfigParser is
> > that prior to using kickstart files we had our own config files.  I'm
> > not entirely happy with ConfigParser, but it'd be something of an
> > overhaul to switch to some other config system, and not one I was
> > willing to make at this point.  Maybe during F9...
> >   
> You can take a look at the config classes in yum (yum/config.py) it
> let you define different kind of options types.
> 

I've also made a yum-free config.py that takes all the advantages of the
yum config file w/o needing the yum-ness of it.

you can find it here:
http://skvidal.fedorapeople.org/config.py

we just used in in func and it's rather handy.

-sv




From oliver at linux-kernel.at  Tue Oct  2 16:24:38 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 02 Oct 2007 18:24:38 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <47026129.2080001@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
	<47026129.2080001@linux-kernel.at>
Message-ID: <470270C6.60309@linux-kernel.at>

On 10/02/2007 05:18 PM, Oliver Falk wrote:
> On 10/02/2007 05:02 PM, Jesse Keating wrote:
>> On Tue, 02 Oct 2007 14:47:06 +0200
>> Oliver Falk <oliver at linux-kernel.at> wrote:
>>
>>> OK, that might be the better fix. But doesn't it make sense
>>> ConfigParser also allows int as values? I mean any kind of number
>>> (int, float, complex) could be handled as string...
>> I know not the history of ConfigParser and why it's only strings.  I
>> suspect it's because ConfigParser's primary usage is to parse config
>> files, and in a file it may be non-obvious how to mark something as an
>> int/float rather than a string.  The reason pungi uses ConfigParser is
>> that prior to using kickstart files we had our own config files.  I'm
>> not entirely happy with ConfigParser, but it'd be something of an
>> overhaul to switch to some other config system, and not one I was
>> willing to make at this point.  Maybe during F9...
> 
> I c. Well. I don't mind what pungi uses to parse configs, but it
> MustWork(tm) :-)
> 
> Kickstart files aren't pretty, but we already know them well. Maybe it
> would be better to switch to xml with 'em, but... Forget... That's
> another story, isn't it? :-)
> 
>>>> I've made that change and done some local testing and this appears
>>>> to solve the problem.  I'll commit to tip and get a new build out
>>>> today.  
>>> Thx Jesse, it's great you're there; We can always count on you, your
>>> quick responses and lighting-speed fast actions! :-)
>> Hah, thanks.  If only all my bugs were this easy.
> 
> *grin* I can assign all my easy bugs to you, this way you might reach 90
> % easy bugs... :-) And you can say, ey' guys I solved 50 bugs this day. :-)

Jesse, just in case you have some more time that you want to spend:

Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/pkgorder
/data/koji/pungi/20071002/alpha/os alpha Packages
Pungi.Pungi:ERROR: Got an error from /usr/lib/anaconda-runtime/pkgorder
Pungi.Pungi:ERROR: Traceback (most recent call last):
  File "/usr/lib/anaconda-runtime/pkgorder", line 34, in <module>
    from yuminstall import YumSorter
  File "/usr/lib/anaconda/yuminstall.py", line 34, in <module>
    from backend import AnacondaBackend
  File "/usr/lib/anaconda/backend.py", line 25, in <module>
    import kickstart
  File "/usr/lib/anaconda/kickstart.py", line 181, in <module>
    class IgnoreDisk(commands.ignoredisk.F8_IgnoreDisk):
AttributeError: 'module' object has no attribute 'F8_IgnoreDisk'

Anyone else is also invited to check this...

I'll leave for today and have no more time to debug this...

Best,
 Oliver



From jkeating at redhat.com  Tue Oct  2 16:52:10 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 2 Oct 2007 12:52:10 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <470270C6.60309@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
	<47026129.2080001@linux-kernel.at> <470270C6.60309@linux-kernel.at>
Message-ID: <20071002125210.7b0d5cb5@redhat.com>

On Tue, 02 Oct 2007 18:24:38 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/pkgorder
> /data/koji/pungi/20071002/alpha/os alpha Packages
> Pungi.Pungi:ERROR: Got an error
> from /usr/lib/anaconda-runtime/pkgorder Pungi.Pungi:ERROR: Traceback
> (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder",
> line 34, in <module> from yuminstall import YumSorter
>   File "/usr/lib/anaconda/yuminstall.py", line 34, in <module>
>     from backend import AnacondaBackend
>   File "/usr/lib/anaconda/backend.py", line 25, in <module>
>     import kickstart
>   File "/usr/lib/anaconda/kickstart.py", line 181, in <module>
>     class IgnoreDisk(commands.ignoredisk.F8_IgnoreDisk):
> AttributeError: 'module' object has no attribute 'F8_IgnoreDisk'
> 
> Anyone else is also invited to check this...

Oh fun, that looks like a pykickstart bug, I'll chase it up with those
guys.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/ac61ecbc/attachment.sig>

From mjs at CLEMSON.EDU  Tue Oct  2 16:55:33 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Tue, 02 Oct 2007 12:55:33 -0400
Subject: Building Livna RPMs (slightly OT)
Message-ID: <1191344133.1986.5.camel@vincent52.localdomain>

I'm trying to build the NVidia proprietary driver for the latest F8T2
kernels, but the Livna RPM requires RPMs from the kmod-helpers-livna
SRPM.  These have buit-in lists of kernels that don't reflect the latest
ones.

Any place where using those tools is documented?  Or is it possible at
all to build Livna kmods independently?

Also, how does the new "no kmods" policy affect how Livna will provide
these modules?

TIA.
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From tcallawa at redhat.com  Tue Oct  2 17:23:08 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 02 Oct 2007 13:23:08 -0400
Subject: Building Livna RPMs (slightly OT)
In-Reply-To: <1191344133.1986.5.camel@vincent52.localdomain>
References: <1191344133.1986.5.camel@vincent52.localdomain>
Message-ID: <1191345788.3553.147.camel@localhost.localdomain>


On Tue, 2007-10-02 at 12:55 -0400, Matthew Saltzman wrote:
> I'm trying to build the NVidia proprietary driver for the latest F8T2
> kernels, but the Livna RPM requires RPMs from the kmod-helpers-livna
> SRPM.  These have buit-in lists of kernels that don't reflect the latest
> ones.
> 
> Any place where using those tools is documented?  Or is it possible at
> all to build Livna kmods independently?
> 
> Also, how does the new "no kmods" policy affect how Livna will provide
> these modules?

It should not affect the way they are built at Livna. We're still
planning on keeping the kmod infrastructure bits in the Fedora kernel
package (DaveJ, correct me if you disagree).

~spot



From tibbs at math.uh.edu  Tue Oct  2 18:12:31 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 02 Oct 2007 13:12:31 -0500
Subject: Summary of the 2007-10-02 Packaging Committee meeting
Message-ID: <ufa1wcde67k.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the packaging committee meeting which
occurred on 2007-10-02 are online:

http://fedoraproject.org/wiki/Packaging/Minutes
http://fedoraproject.org/wiki/Packaging/Minutes20071002

Executive summary:

The following draft is now an official guideline, having been accepted
by FESCO last week:

 * Python Eggs: http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs

It should be written into the guidelines soon if this hasn't
already been done by the time you read this.

Issues pending FESCO ratification:
 * Naming of TeX-related packages:
  * http://www.redhat.com/archives/fedora-packaging/2007-September/msg00066.html
  * Accepted (5 - 0)

Misc business:
 * FPC meetings will now be held every other week; the next meeting
   will be 2007-10-16T15:00Z, October 16 15:00UTC.

 - J<



From jkeating at redhat.com  Tue Oct  2 18:27:22 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 2 Oct 2007 14:27:22 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <470270C6.60309@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
	<47026129.2080001@linux-kernel.at> <470270C6.60309@linux-kernel.at>
Message-ID: <20071002142722.1857e919@redhat.com>

On Tue, 02 Oct 2007 18:24:38 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/pkgorder
> /data/koji/pungi/20071002/alpha/os alpha Packages
> Pungi.Pungi:ERROR: Got an error
> from /usr/lib/anaconda-runtime/pkgorder Pungi.Pungi:ERROR: Traceback
> (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder",
> line 34, in <module> from yuminstall import YumSorter
>   File "/usr/lib/anaconda/yuminstall.py", line 34, in <module>
>     from backend import AnacondaBackend
>   File "/usr/lib/anaconda/backend.py", line 25, in <module>
>     import kickstart
>   File "/usr/lib/anaconda/kickstart.py", line 181, in <module>
>     class IgnoreDisk(commands.ignoredisk.F8_IgnoreDisk):
> AttributeError: 'module' object has no attribute 'F8_IgnoreDisk'
> 
> Anyone else is also invited to check this...
> 
> I'll leave for today and have no more time to debug this...

I was not able to duplicate this.  Please state the versions of pungi,
anaconda-runtime and pykickstart used for this compose (IE installed on
the system doing the compose).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/f39f1644/attachment.sig>

From buildsys at fedoraproject.org  Tue Oct  2 19:31:40 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue,  2 Oct 2007 15:31:40 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-02
Message-ID: <20071002193140.22C8015212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 9

    chmlib-0.39-5.fc6
    cupsddk-1.2.2-1.fc6
    cyrus-imapd-2.3.9-7.fc6
    fuse-2.7.0-6.fc6
    perl-MP3-Info-1.23-1.fc6
    php-pecl-radius-1.2.5-2.fc6
    php-pecl-xdebug-2.0.0-2.fc6
NEW qwt-doc-5.0.2-4.fc6 : Documentation of qwt
    yum-cron-0.5-1.fc6


Changes in Fedora Extras 6: 


chmlib-0.39-5.fc6
-----------------
* Sun Sep 30 2007 Peter Lemenkov <lemenkov at gmail.com> 0.39-5
- Changel license tag from LGPL to LGPLv2+

* Sun Aug 05 2007 Peter Lemenkov <lemenkov at gmail.com> 0.39-4
- Better fix for multi-arch issues

cupsddk-1.2.2-1.fc6
-------------------
* Tue Oct 02 2007 Tim Waugh <twaugh at redhat.com> 1.2.2-1
- 1.2.2 (with patch to fix build).

cyrus-imapd-2.3.9-7.fc6
-----------------------
* Sun Sep 23 2007 Tomas Janousek <tjanouse at redhat.com> - 2.3.9-7
- updated the getgrouplist patch
- fixed a few undeclared functions (and int to pointer conversions)

fuse-2.7.0-6.fc6
----------------
* Mon Oct 01 2007 Peter Lemenkov <lemenkov at gmail.com> 2.7.0-6
- Added Require: which (BZ#312511)

perl-MP3-Info-1.23-1.fc6
------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 1.23-1
- Upstream sync

php-pecl-radius-1.2.5-2.fc6
---------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 1.2.5-2
- Update to new standards

php-pecl-xdebug-2.0.0-2.fc6
---------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 2.0.0-2
- Update to latest standards
- Fix encoding on Changelog

qwt-doc-5.0.2-4.fc6
-------------------
* Sun Sep 30 2007 Frank B?ttner <frank-buettner at gmx.net - 5.0.2-4
- modify the file encoding

* Sat Sep 29 2007 Frank B?ttner <frank-buettner at gmx.net - 5.0.2-3
- add EPEL support

* Sat Sep 29 2007 Frank B?ttner <frank-buettner at gmx.net - 5.0.2-2
- fix spec file

yum-cron-0.5-1.fc6
------------------
* Sat Sep 29 2007 Alec Habig <ahabig at umn.edu> - 0.5-1
- Added a lockfile to prevent multiple instances of the cron scripts
  from running and hanging, see bug 311661



From ville.skytta at iki.fi  Tue Oct  2 21:09:53 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 3 Oct 2007 00:09:53 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710020942.10330.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
	<loom.20071001T221653-273@post.gmane.org>
	<200710020942.10330.ville.skytta@iki.fi>
Message-ID: <200710030009.54891.ville.skytta@iki.fi>

On Tuesday 02 October 2007, Ville Skytt? wrote:

> I plan to do some grepping later

Did some now on my F7 box, new patches in addition to the previous ones at 
http://scop.fedorapeople.org/patches/xdg-utils/ are available for:

amarok
bittorrent
dvdisaster
gimp
git
ImageMagick
kdepim
mailcap
notification-daemon
pidgin
python

Additionally, bug against emacs filed.

Note to maintainers: do not apply blindly, review if it's the right thing to 
do and adjust/reject as appropriate (and notify me if you decide against a 
patch and I'll remove it from the above URL (if I agree ;)).  If you decide 
to apply a patch, changes are also pretty good that those changes would be 
acceptable upstream, so don't hesitate to send them.



From s.adam at diffingo.com  Tue Oct  2 21:08:07 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 02 Oct 2007 17:08:07 -0400
Subject: Building Livna RPMs (slightly OT)
In-Reply-To: <1191344133.1986.5.camel@vincent52.localdomain>
References: <1191344133.1986.5.camel@vincent52.localdomain>
Message-ID: <1191359287.28406.23.camel@Diffingo.localdomain>

On Tue, 2007-10-02 at 12:55 -0400, Matthew Saltzman wrote:
> I'm trying to build the NVidia proprietary driver for the latest F8T2
> kernels, but the Livna RPM requires RPMs from the kmod-helpers-livna
> SRPM.  These have buit-in lists of kernels that don't reflect the latest
> ones.
> 
> Any place where using those tools is documented?  Or is it possible at
> all to build Livna kmods independently?
> 
> Also, how does the new "no kmods" policy affect how Livna will provide
> these modules?
> 
> TIA.
Thorsten Leemhuis (knurd in #livna) is the one working on the this
package. I'm not 100% sure how it works but I know it will help make the
building of Livna kmods much easier. I looked at it brieflya few weeks
back, I think you just need to edit the "newest-kernels" and
"latest-kernels" files in /usr/share/kmod-helpers-livna and it will
rebuild properly.

Stewart



From jspaleta at gmail.com  Tue Oct  2 22:28:39 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 2 Oct 2007 14:28:39 -0800
Subject: LTSP 5 on Fedora
In-Reply-To: <4700F967.9010808@redhat.com>
References: <4700E9FE.8000409@asic.udl.cat> <4700F967.9010808@redhat.com>
Message-ID: <604aa7910710021528j1a4112f9x2bf66ae5f0b57b4d@mail.gmail.com>

On 10/1/07, Warren Togami <wtogami at redhat.com> wrote:
> Eric Harrison said that he's hoping to get the LTSP 5 bits into Fedora,
> after that point he'll need other people to help maintain the packages
> in Fedora.  I'm meeting him in Oregon next weekend to get started on this.

I blame myself.  I meant to work on this over the summer, but I never
was able to cobble together a couple of spare systems to start working
on the client/server packages in a coordinated way. Everytime I was
able to snag a spare computer I ended up needing to put qnx on it and
use it for software development for real work.

-jef



From sundaram at fedoraproject.org  Tue Oct  2 23:21:51 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 03 Oct 2007 04:51:51 +0530
Subject: Notes for Fedora 8 Test 3
Message-ID: <4702D28F.1050705@fedoraproject.org>

Hi

Fedora 8 Test 3 has been pushed to mirrors and will be available as per 
the release schedule. In the official announcement, we intend to list 
any import changes as well as bugs and since I haven't been paying close 
attention as before in between the last test release and this one, I 
would love to get some help with that.

If you are a rawhide user and noticed any major changes after test 3 
(new features, new packages, user visible things) and if there are major 
issues that we need to highlight, do let me know either here or offlist. 
Thanks.

Rahul



From bpepple at fedoraproject.org  Tue Oct  2 23:29:22 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 2 Oct 2007 19:29:22 -0400
Subject: rpms/empathy/devel .cvsignore, 1.6, 1.7 empathy.spec, 1.7,
	1.8 sources, 1.6, 1.7
In-Reply-To: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
References: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
Message-ID: <c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>

On 10/2/07, pgordon Peter Gordon <fedora-extras-commits at redhat.com> wrote:
>
> @@ -163,7 +163,9 @@
>  %{_sysconfdir}/gconf/schemas/GNOME_Megaphone_Applet.schemas
>  %{_bindir}/empathy
>  %{_bindir}/empathy-accounts
> +%{_bindir}/empathy-call-chandler
>  %{_datadir}/dbus-1/services/org.gnome.Empathy.Chat.service
> +%{_datadir}/dbus-1/services/org.gnome.Empathy.Call.service
>  %{_datadir}/empathy/
>  %{_datadir}/applications/fedora-%{name}.desktop
>  %{_datadir}/icons/hicolor/*/apps/%{name}*

Ummm, haven't we been in feature freeze for a bit?
http://fedoraproject.org/wiki/Releases/8/Schedule
http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy



From sundaram at fedoraproject.org  Tue Oct  2 23:25:40 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 03 Oct 2007 04:55:40 +0530
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <4702D28F.1050705@fedoraproject.org>
References: <4702D28F.1050705@fedoraproject.org>
Message-ID: <4702D374.2090906@fedoraproject.org>

Rahul Sundaram wrote:
> Hi
> 
> Fedora 8 Test 3 has been pushed to mirrors and will be available as per 
> the release schedule. In the official announcement, we intend to list 
> any import changes as well as bugs and since I haven't been paying close 
> attention as before in between the last test release and this one, I 
> would love to get some help with that.
> 
> If you are a rawhide user and noticed any major changes after test 3 
                                                                 ^^^^^^
I meant after test 2 here.

Rahul



From kevin.kofler at chello.at  Wed Oct  3 00:02:25 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 3 Oct 2007 00:02:25 +0000 (UTC)
Subject: rpms/empathy/devel .cvsignore, 1.6, 1.7 empathy.spec, 1.7,	1.8
	sources, 1.6, 1.7
References: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
	<c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>
Message-ID: <loom.20071003T000210-178@post.gmane.org>

Brian Pepple <bpepple <at> fedoraproject.org> writes:
> Ummm, haven't we been in feature freeze for a bit?

Let's be realistic, what is an extra D-Bus service going to break? Especially 
in an application like Empathy which isn't even a default app (Pidgin is).

        Kevin Kofler



From peter at thecodergeek.com  Wed Oct  3 01:23:43 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 02 Oct 2007 18:23:43 -0700
Subject: rpms/empathy/devel .cvsignore, 1.6, 1.7 empathy.spec, 1.7, 1.8
	sources, 1.6, 1.7
In-Reply-To: <c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>
References: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
	<c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>
Message-ID: <1191374623.8239.9.camel@localhost.localdomain>

On Tue, 2007-10-02 at 19:29 -0400, Brian Pepple wrote:
> Ummm, haven't we been in feature freeze for a bit?
> http://fedoraproject.org/wiki/Releases/8/Schedule
> http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy

Hmm. I didn't think this feature was significant enough that it would
break the freeze (since Empathy isn't an "essential" or default
package); but if I can disable it if that would be preferred. (It's
theoretically just an additional "--disable-voip" option to the
configure script.) 

My thinking on it is (as Kevin pointed out in an earlier reply) that
it's an additional feature that does not alter anything already
in-place. Also, if I disabled it now it would probably end up being
re-enabled after GA, so enabling it now means that we get that extra bit
of testing from Rawhide users.

If needed, I can happily push a new build with the VoIP stuff disabled.

Thanks; and sorry for the slight confusion.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071002/7ba06e26/attachment.sig>

From jdennis at redhat.com  Wed Oct  3 01:57:03 2007
From: jdennis at redhat.com (John Dennis)
Date: Tue, 02 Oct 2007 21:57:03 -0400
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710030009.54891.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>	<loom.20071001T221653-273@post.gmane.org>	<200710020942.10330.ville.skytta@iki.fi>
	<200710030009.54891.ville.skytta@iki.fi>
Message-ID: <4702F6EF.8040708@redhat.com>

When I was updating my package to use xdg-utils I noticed that xdg-utils 
is not in RHEL5. I bet I'm not the only one who needs to maintain a 
package for both Fedora and RHEL, so for those who are interested this 
is how I solved it, you will need to modify the approach for your 
particulars.

In configure.ac add:

AC_PATH_PROGS([html_browser_open], [xdg-open htmlview])
if test -z $html_browser_open; then
     AC_MSG_ERROR([cannot find utility to launch browser])
fi
AC_SUBST(html_browser_open)

Somewhere in your code that is processed by config.status add something
like this:

web_browser_launcher = '@html_browser_open@'

In the spec file add:

%if 0%{?fedora}
BuildRequires: xdg-utils
Requires: xdg-utils
%endif

%if 0%{?rhel}
BuildRequires: htmlview
Requires: htmlview
%endif

What all this does is the following: AC_PATH_PROGS finds the full path
of xdg-open if its installed otherwise htmlview if its installed, and 
stores the result in the config shell variable html_browser_open. If 
neither is found the variable will be set to the empty string. You may 
or may not want to abort in this situation, the code above does abort, 
if you don't want to abort don't use the 3 lines following AC_PATH_PROGS.

Then config.status will substitute that value in your
source code or config file. The spec file does a conditional requires
depending on whether its fedora or rhel. You need the BuildRequires in
addition to the Requires because configure is run on the build host and
that is where the AC_PATH_PROGS expansion is evaluated.

HTH,

John



From adam at spicenitz.org  Wed Oct  3 02:11:45 2007
From: adam at spicenitz.org (Adam Goode)
Date: Tue, 02 Oct 2007 22:11:45 -0400
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710012141.58217.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
Message-ID: <4702FA61.4090302@spicenitz.org>

Thanks!

I have built a new fvwm for Rawhide.



Adam


Ville Skytt? wrote:
> Hello,
> 
> I went through current devel packages that use htmlview or have unnecessarily 
> hardwired dependencies to firefox or evince.  Most of these should be using 
> xdg-open from xdg-utils instead.  Not hardcoding firefox as the browser and 
> evince as the PDF viewer should be trivial to understand, but why use 
> xdg-open instead of htmlview?  xdg-utils/xdg-open compared to htmlview:
> 
> - Works better in non-GNOME setups
> - Is a more standard implementation (more likely to be adopted upstream)
> - Understands the $BROWSER environment variable
> - Has slightly smaller dependency chain
> 
> So far, the only drawback of xdg-open compared to htmlview I've found is that 
> there doesn't seem to be real support for just opening a browser without an 
> URL to show in it.  "xdg-open about:blank" is one hacky workaround for this, 
> but I don't know how portable it is accross browsers (works at least in 
> Firefox and friends, and Konqueror).
> 
> List of packages follows, I'd appreciate if their maintainers could have a 
> look and apply where appropriate.  Most of these changes have been made 
> without testing but then again, most of them are so trivial that no testing 
> is required, but keep the above paragraph in mind if your package just needs 
> to open a browser without showing anything in particular in it (IIRC icewm is 
> one such case).  For some packages I have patches available, some have 
> already been reported in Bugzilla, and some already applied in bleeding edge 
> upstream versions.
> 
> Patches available at http://scop.fedorapeople.org/patches/xdg-utils/ :
> 
> - amsn
> - ddd
> - fvwm
> - gmrun
> - gnome-libs
> - grace
> - grisbi
> - icewm
> - ipe
> - keepassx
> - R
> - streamtuner
> - system-config-date
> - system-config-nfs
> - system-config-samba
> - system-config-services
> - system-config-users
> - tcldebugger
> - xarchiver
> 
> Reported in Bugzilla:
> 
> - licq, #314231
> - pinfo, #312471
> - xfig, #313321
> - xpdf, #313311
> 
> Already reported and applied in upstream devel versions, Fedora
> packages should be adjusted to Require/BuildRequire xdg-utils instead
> of htmlview when those are out:
> 
> - fontforge
> - wireshark-gnome
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071002/44ee526b/attachment.sig>

From bpepple at fedoraproject.org  Wed Oct  3 02:14:12 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 2 Oct 2007 22:14:12 -0400
Subject: rpms/empathy/devel .cvsignore, 1.6, 1.7 empathy.spec, 1.7,
	1.8 sources, 1.6, 1.7
In-Reply-To: <1191374623.8239.9.camel@localhost.localdomain>
References: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
	<c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>
	<1191374623.8239.9.camel@localhost.localdomain>
Message-ID: <c6534ba10710021914o2597607y788fb240dec42c0b@mail.gmail.com>

On 10/2/07, Peter Gordon <peter at thecodergeek.com> wrote:
>
> My thinking on it is (as Kevin pointed out in an earlier reply) that
> it's an additional feature that does not alter anything already
> in-place. Also, if I disabled it now it would probably end up being
> re-enabled after GA, so enabling it now means that we get that extra bit
> of testing from Rawhide users.
>
> If needed, I can happily push a new build with the VoIP stuff disabled.

I would lean toward disabling the voip stuff, since Xavier has said it
isn't stable yet, and by default it is disabled.



From sandeen at redhat.com  Wed Oct  3 02:31:18 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 02 Oct 2007 21:31:18 -0500
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <4702D28F.1050705@fedoraproject.org>
References: <4702D28F.1050705@fedoraproject.org>
Message-ID: <4702FEF6.8070507@redhat.com>

Rahul Sundaram wrote:
> Hi
> 
> Fedora 8 Test 3 has been pushed to mirrors and will be available as per 
> the release schedule. In the official announcement, we intend to list 
> any import changes as well as bugs and since I haven't been paying close 
> attention as before in between the last test release and this one, I 
> would love to get some help with that.
> 
> If you are a rawhide user and noticed any major changes after test 3 
> (new features, new packages, user visible things) and if there are major 
> issues that we need to highlight, do let me know either here or offlist. 
> Thanks.
> 
> Rahul
> 

One thing I noticed from last go-round, not strictly related to notes,
but in the release announcement I think we should link directly to:

http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/

instead of:

http://fedoraproject.org/get-fedora.html

imho... the latter is too many clicks away from what you're announcing.

Thanks,
-Eric



From peter at thecodergeek.com  Wed Oct  3 02:32:26 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 02 Oct 2007 19:32:26 -0700
Subject: rpms/empathy/devel .cvsignore, 1.6, 1.7 empathy.spec, 1.7, 1.8
	sources, 1.6, 1.7
In-Reply-To: <c6534ba10710021914o2597607y788fb240dec42c0b@mail.gmail.com>
References: <200710022230.l92MU9dS013790@cvs-int.fedora.redhat.com>
	<c6534ba10710021629l212dcf07n241a2c35e189e036@mail.gmail.com>
	<1191374623.8239.9.camel@localhost.localdomain>
	<c6534ba10710021914o2597607y788fb240dec42c0b@mail.gmail.com>
Message-ID: <1191378746.8239.17.camel@localhost.localdomain>

On Tue, 2007-10-02 at 22:14 -0400, Brian Pepple wrote:
> I would lean toward disabling the voip stuff, since Xavier has said it
> isn't stable yet, and by default it is disabled.

That sounds reasonable. I apologize for the slight mishap, and thanks
for pointing out my mistake. :) 

I'll push a build momentarily with the VoIP stuff disabled.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071002/011d7d3d/attachment.sig>

From jdieter at gmail.com  Wed Oct  3 04:10:31 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Wed, 03 Oct 2007 07:10:31 +0300
Subject: Pulseaudio bug in F7
Message-ID: <1191384631.4512.35.camel@jndwidescreen.lesbg.loc>

I know that the focus is on F8, but there's a bug in pulseaudio's
zeroconf module in Fedora 7, namely if a sink name is over 64 bytes, it
won't get published.

This has been fixed in the version in Rawhide, and I've backported the
fix to the version in F7.  See
https://bugzilla.redhat.com/show_bug.cgi?id=313141

I've been running with the fix for a couple of days now with no
problems.  Can we get this fix into updates-testing?

Jonathan
-------------- 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/20071003/3b6ddbad/attachment.sig>

From rc040203 at freenet.de  Wed Oct  3 04:42:44 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Oct 2007 06:42:44 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
Message-ID: <1191386564.3395.146.camel@mccallum.corsepiu.local>

Hi,

I am facing what I presume to be caused by a divergence between the
default set of packages in a built-root in mock and koji:


koji --scratch building a package succeeds:

# koji build --scratch --arch=i386 dist-fc7 Coin2-2.5.0-2.fc7.src.rpm

c.f. http://koji.fedoraproject.org/koji/taskinfo?taskID=181197


while rebuilding the identical src.rpm in a local mock on FC-7 fails:

# mock  -r fedora-7-i386.cfg Coin2-2.5.0-2.fc7.src.rpm
...
./configure: line 37448: cmp: command not found
...
error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
...
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
...


Seemingly, "cmp" is in FC-7's default packages in koji, but not in
FC-7's mock.


Ralf





From gunchev at gmail.com  Wed Oct  3 07:13:28 2007
From: gunchev at gmail.com (Doncho N. Gunchev)
Date: Wed, 3 Oct 2007 10:13:28 +0300
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <47025E42.2030604@hhs.nl>
References: <46F8F5E8.3000801@hhs.nl> <47015AF3.307@amiga-hardware.com>
	<47025E42.2030604@hhs.nl>
Message-ID: <200710031013.28627.gunchev@gmail.com>

On Tuesday 2007-10-02 18:05:38 Hans de Goede wrote:
> Ian Chapman wrote:
> > Doncho N. Gunchev wrote:
> > 
> >>> for all games just by exporting the environment variable.  Since you
> >>> are asking for the games packages to use this by default, there needs
> >>> to be a per-user way to disable the script action on multi-user
> >>> configurations.
> > 
> >>
> >> Why not a checkbox - don't show this warning again? If checked - touch
> >> a file (say ~/.no_video_warning) and don't bother the user again.
> >>
> >> I think the user should be able to abort the game start, to start anyway
> >> and to start anyway and never be bothered again.
> >>
> > 
> > +1
> > 
> > To be fair I haven't see the script (yet) but that sounds a like a 
> > sensible suggestion to me. The user should have the option of continuing 
> > regardless, if they so choose, and not to be bothered again. This should 
> > be as simple as possible and done graphically, ideally at launch time.
> > 
> 
> There are 2 issues with these train of thoughts:
> 1) There really is no reason to want to run fullscreen OpenGL programs without
>     hardware acceleration, they will not be usable <period>. If you don't
>     believe me, try it!

I know, from a long time. Users *should* be able to see it with their own eyes.

> 2) The current wrapper uses zenity, so it cannot do the advenced kind of
>     dialogs with a checkbox people ask for.
>

Well... improvise:

ans=$(zenity  --list  --text "Your video..." --radiolist  --column "Pick"  \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
 FALSE "Always run regardless"); echo $ans

Doesn't this look OK?

> All in all I believe less is more, so that things are fine as is, the menu 
> entries all launch foo-wrapper, if a user _really_ think he / she knows better, 
> all she needs todo is to launch foo, or to modify the menu entry and strip the 
> wrapper.
> 

I wish you were correct, but most users have no idea they can edit their menu,
let alone what wrapper is. If I do such wrapper, will you get it in fedora?
I can also make it open terminal and use text mode dialog if zenity is not
installed or even fallback to plain text questions. The translation should be
no problem too (echo $"Translatable text" AFAIK)[1].

[1] - http://tiswww.case.edu/php/chet/bash/bashref.html#SEC13

-- 
Regards,
  Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu



From tla at rasmil.dk  Wed Oct  3 07:15:59 2007
From: tla at rasmil.dk (Tim Lauridsen)
Date: Wed, 03 Oct 2007 09:15:59 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <1191341323.6741.17.camel@cutter>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>
	<47026C1F.7060808@rasmil.dk> <1191341323.6741.17.camel@cutter>
Message-ID: <470341AF.3000707@rasmil.dk>

seth vidal wrote:
> On Tue, 2007-10-02 at 18:04 +0200, Tim Lauridsen wrote:
>   
>> Jesse Keating wrote: 
>>     
>>> On Tue, 02 Oct 2007 14:47:06 +0200
>>> Oliver Falk &lt;oliver at linux-kernel.at&gt; wrote:
>>>
>>>   
>>>       
>>>> OK, that might be the better fix. But doesn't it make sense
>>>> ConfigParser also allows int as values? I mean any kind of number
>>>> (int, float, complex) could be handled as string...
>>>>     
>>>>         
>>> I know not the history of ConfigParser and why it's only strings.  I
>>> suspect it's because ConfigParser's primary usage is to parse config
>>> files, and in a file it may be non-obvious how to mark something as an
>>> int/float rather than a string.  The reason pungi uses ConfigParser is
>>> that prior to using kickstart files we had our own config files.  I'm
>>> not entirely happy with ConfigParser, but it'd be something of an
>>> overhaul to switch to some other config system, and not one I was
>>> willing to make at this point.  Maybe during F9...
>>>   
>>>       
>> You can take a look at the config classes in yum (yum/config.py) it
>> let you define different kind of options types.
>>
>>     
>
> I've also made a yum-free config.py that takes all the advantages of the
> yum config file w/o needing the yum-ness of it.
>
> you can find it here:
> http://skvidal.fedorapeople.org/config.py
>
> we just used in in func and it's rather handy.
>
> -sv
>
>
>   
Maybe, it should be out into its own package (python module), so that 
potential users could pull it in (yum, func, yumex, pungi etc).
and it could be maintained in one place.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/be24e8b3/attachment.htm>

From frank-buettner at gmx.net  Wed Oct  3 08:49:35 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Wed, 03 Oct 2007 10:49:35 +0200
Subject: Qt Jambi
Message-ID: <4703579F.2050105@gmx.net>

Hello,
are somebody working on an package for Qt Jambi?
http://trolltech.com/products/qt/jambi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/e1e20b74/attachment.bin>

From mschwendt.tmp0701.nospam at arcor.de  Wed Oct  3 09:00:22 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 3 Oct 2007 11:00:22 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <1191386564.3395.146.camel@mccallum.corsepiu.local>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
Message-ID: <20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 03 Oct 2007 06:42:44 +0200, Ralf Corsepius wrote:

> Hi,
> 
> I am facing what I presume to be caused by a divergence between the
> default set of packages in a built-root in mock and koji:
> 
> 
> koji --scratch building a package succeeds:
> 
> # koji build --scratch --arch=i386 dist-fc7 Coin2-2.5.0-2.fc7.src.rpm
> 
> c.f. http://koji.fedoraproject.org/koji/taskinfo?taskID=181197
> 
> 
> while rebuilding the identical src.rpm in a local mock on FC-7 fails:
> 
> # mock  -r fedora-7-i386.cfg Coin2-2.5.0-2.fc7.src.rpm
> ...
> ./configure: line 37448: cmp: command not found
> ...
> error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> ...
> RPM build errors:
>     Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> ...
> 
> 
> Seemingly, "cmp" is in FC-7's default packages in koji, but not in
> FC-7's mock.

It's the same old "diffutils is missing" problem that has been found
recently. Normally, "rpm-build" used to require "diffutils", because
it uses diff in scripts like check-files. But the RPM update for
F7 and FC6 has dropped the diffutils "Requires" (the %changelog does
not mention that). The mock buildsys build-group pkg needs an
update.



From oliver at linux-kernel.at  Wed Oct  3 09:53:32 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 03 Oct 2007 11:53:32 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <20071002142722.1857e919@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>
	<20071002142722.1857e919@redhat.com>
Message-ID: <4703669C.2060600@linux-kernel.at>

Jesse Keating schrieb:
> On Tue, 02 Oct 2007 18:24:38 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
> 
>> Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/pkgorder
>> /data/koji/pungi/20071002/alpha/os alpha Packages
>> Pungi.Pungi:ERROR: Got an error
>> from /usr/lib/anaconda-runtime/pkgorder Pungi.Pungi:ERROR: Traceback
>> (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder",
>> line 34, in <module> from yuminstall import YumSorter
>>   File "/usr/lib/anaconda/yuminstall.py", line 34, in <module>
>>     from backend import AnacondaBackend
>>   File "/usr/lib/anaconda/backend.py", line 25, in <module>
>>     import kickstart
>>   File "/usr/lib/anaconda/kickstart.py", line 181, in <module>
>>     class IgnoreDisk(commands.ignoredisk.F8_IgnoreDisk):
>> AttributeError: 'module' object has no attribute 'F8_IgnoreDisk'
>>
>> Anyone else is also invited to check this...
>>
>> I'll leave for today and have no more time to debug this...
> 
> I was not able to duplicate this.  Please state the versions of pungi,
> anaconda-runtime and pykickstart used for this compose (IE installed on
> the system doing the compose).

[oliver at gosa devel]$ rpm -q pungi anaconda-runtime pykickstart
pungi-1.1.3-1.fc8
anaconda-runtime-11.3.0.36-1axp
pykickstart-1.2-2.fc8

Best,
 Oliver



From fedora at leemhuis.info  Wed Oct  3 10:30:49 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 03 Oct 2007 12:30:49 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <4702F6EF.8040708@redhat.com>
References: <200710012141.58217.ville.skytta@iki.fi>	<loom.20071001T221653-273@post.gmane.org>	<200710020942.10330.ville.skytta@iki.fi>	<200710030009.54891.ville.skytta@iki.fi>
	<4702F6EF.8040708@redhat.com>
Message-ID: <47036F59.7010400@leemhuis.info>

On 03.10.2007 03:57, John Dennis wrote:
> When I was updating my package to use xdg-utils I noticed that xdg-utils 
> is not in RHEL5. I bet I'm not the only one who needs to maintain a 
> package for both Fedora and RHEL, so for those who are interested this 
> is how I solved it, you will need to modify the approach for your 
> particulars. [...]

Note, xdg-utils is in EPEL5, thus is you maintain your packages for
Fedora and EPEL (and not Fedora and RHEL) then it should be no problem
to just use xdg-utils for both.

Cu
knurd



From fedora at leemhuis.info  Wed Oct  3 10:50:31 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 03 Oct 2007 12:50:31 +0200
Subject: Building Livna RPMs (slightly OT)
In-Reply-To: <1191359287.28406.23.camel@Diffingo.localdomain>
References: <1191344133.1986.5.camel@vincent52.localdomain>
	<1191359287.28406.23.camel@Diffingo.localdomain>
Message-ID: <470373F7.7080202@leemhuis.info>

On 02.10.2007 23:08, Stewart Adam wrote:
> On Tue, 2007-10-02 at 12:55 -0400, Matthew Saltzman wrote:
>> I'm trying to build the NVidia proprietary driver for the latest F8T2
>> kernels, but the Livna RPM requires RPMs from the kmod-helpers-livna
>> SRPM. 

Use:

$ wget http://livna-dl.reloumirrors.net/fedora/development/SRPMS/nvidia-kmod-100.14.11-4.lvn8.src.rpm 
$ rpmbuild --rebuild nvidia-kmod-100.14.11-4.lvn8.src.rpm --define "kernels $(uname -r)"
[...]
Created: /home/thl/rpmbuild/RPMS/x86_64/kmod-nvidia-2.6.23-0.202.rc8.fc8-100.14.11-4.fc8.4.x86_64.rpm
[...]
$ rpm -ivh /home/thl/rpmbuild/RPMS/x86_64/kmod-nvidia-2.6.23-0.202.rc8.fc8-100.14.11-4.fc8.4.x86_64.rpm

>> These have buit-in lists of kernels that don't reflect the latest
>> ones.

I'll update those today for the test3 kernels. EPEL and rpmfusion 
kept me busy in the past weeks and I didn't found time to update 
the kmod stuff in livna. 

>> Any place where using those tools is documented?

Not yet, sorry. I'm still testing some improvements.

>>  Or is it possible at
>> all to build Livna kmods independently?

See above. You can also build build for multiple kernels in one go by
using "--define "kernels foo bar" -- thos don't have to be packaged 
as RPM, thus you can use it for you self-compiled kernels as well.

>> Also, how does the new "no kmods" policy affect how Livna will provide
>> these modules?

Livna (and rpmfusion sooner or later) will continue to ship kernels
modules. How rpmfusion will do it exatly sill needs to be discussed.

> Thorsten Leemhuis (knurd in #livna) is the one working on the this
> package. I'm not 100% sure how it works but I know it will help make the
> building of Livna kmods much easier. I looked at it brieflya few weeks
> back, I think you just need to edit the "newest-kernels" and
> "latest-kernels" files in /usr/share/kmod-helpers-livna and it will
> rebuild properly.

Still working on it and I need to revert some parts for now as yum and mock
don't work as I expected them to work(?) :-(( So some features will have to wait

CU
knurd 

(?) -- seems at least in the current livna buildsys with not up2date versions 
of rpm/yum/mock only the latest kernel-devel package gets installed if you have
another package that for example has
BuildRequires: kernel-devel-x86_64 = 2.6.23-0.214.rc8.git2.fc8
BuildRequires: kernel-devel-x86_64 = 2.6.23-0.202.rc8.fc8
Not sure yet if thats a bug or a feature. 



From fedora at leemhuis.info  Wed Oct  3 10:52:52 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 03 Oct 2007 12:52:52 +0200
Subject: Building Livna RPMs (slightly OT)
In-Reply-To: <1191345788.3553.147.camel@localhost.localdomain>
References: <1191344133.1986.5.camel@vincent52.localdomain>
	<1191345788.3553.147.camel@localhost.localdomain>
Message-ID: <47037484.3090406@leemhuis.info>

On 02.10.2007 19:23, Tom "spot" Callaway wrote:
> On Tue, 2007-10-02 at 12:55 -0400, Matthew Saltzman wrote:
>> I'm trying to build the NVidia proprietary driver for the latest F8T2
>> kernels, but the Livna RPM requires RPMs from the kmod-helpers-livna
>> SRPM.  These have buit-in lists of kernels that don't reflect the latest
>> ones.
>>
>> Any place where using those tools is documented?  Or is it possible at
>> all to build Livna kmods independently?
>>
>> Also, how does the new "no kmods" policy affect how Livna will provide
>> these modules?
> 
> It should not affect the way they are built at Livna. We're still
> planning on keeping the kmod infrastructure bits in the Fedora kernel
> package (DaveJ, correct me if you disagree).

There is afaik no kmod-specific infra in the Fedora kernel. There are
only sane arch-provides (like "kernel-devel-x86_64 =
2.6.23-0.214.rc8.git2.fc8" ) that get used by kmods (and other packaging
standards as well afaik).

CU
knurd



From ml at deadbabylon.de  Wed Oct  3 10:57:13 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Wed, 3 Oct 2007 12:57:13 +0200
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <4702D28F.1050705@fedoraproject.org>
References: <4702D28F.1050705@fedoraproject.org>
Message-ID: <20071003125713.31ba8619@htpc>

Am Wed, 03 Oct 2007 04:51:51 +0530
schrieb Rahul Sundaram <sundaram at fedoraproject.org>:

> Hi
> 
> Fedora 8 Test 3 has been pushed to mirrors and will be available as
> per the release schedule. In the official announcement, we intend to
> list any import changes as well as bugs and since I haven't been
> paying close attention as before in between the last test release and
> this one, I would love to get some help with that.
> 
> If you are a rawhide user and noticed any major changes after test 3 
> (new features, new packages, user visible things) and if there are
> major issues that we need to highlight, do let me know either here or
> offlist. Thanks.
> 
> Rahul
> 

For KDE: knetworkmanager is probably gone for test3 because it isn't
working with the newest networkmanager. We use nm-applet from
Gnome as a replacement.
See: https://bugzilla.redhat.com/show_bug.cgi?id=298991

Jeremy should confirm this before it gets into the release notes
because he's the one implementing the needed changes for the livecd.

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

From aph at redhat.com  Wed Oct  3 11:08:38 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 3 Oct 2007 12:08:38 +0100
Subject: Problems with clock in f8t2
Message-ID: <18179.30774.903928.719824@zebedee.pink>

There seems to be some problem with the system clock with f8t2.  In
particular, setting the clock via ntp no longer works.

Like this:

zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
 3 Oct 12:03:52 ntpdate[17063]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
 3 Oct 12:03:56 ntpdate[17063]: step time server 134.34.3.18 offset -372.433774 sec
zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
 3 Oct 12:04:01 ntpdate[17064]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
 3 Oct 12:04:05 ntpdate[17064]: step time server 134.34.3.18 offset -372.458162 sec

The kernel:

2.6.23-0.164.rc5.fc8 #1 SMP Tue Sep 4 18:24:12 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

Is anyone else seeing this?

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From pmatilai at laiskiainen.org  Wed Oct  3 11:12:15 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 3 Oct 2007 14:12:15 +0300 (EEST)
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>

On Wed, 3 Oct 2007, Michael Schwendt wrote:

> On Wed, 03 Oct 2007 06:42:44 +0200, Ralf Corsepius wrote:
>
>> Hi,
>>
>> I am facing what I presume to be caused by a divergence between the
>> default set of packages in a built-root in mock and koji:
>>
>>
>> koji --scratch building a package succeeds:
>>
>> # koji build --scratch --arch=i386 dist-fc7 Coin2-2.5.0-2.fc7.src.rpm
>>
>> c.f. http://koji.fedoraproject.org/koji/taskinfo?taskID=181197
>>
>>
>> while rebuilding the identical src.rpm in a local mock on FC-7 fails:
>>
>> # mock  -r fedora-7-i386.cfg Coin2-2.5.0-2.fc7.src.rpm
>> ...
>> ./configure: line 37448: cmp: command not found
>> ...
>> error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
>> ...
>> RPM build errors:
>>     Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
>> ...
>>
>>
>> Seemingly, "cmp" is in FC-7's default packages in koji, but not in
>> FC-7's mock.
>
> It's the same old "diffutils is missing" problem that has been found
> recently. Normally, "rpm-build" used to require "diffutils", because
> it uses diff in scripts like check-files. But the RPM update for
> F7 and FC6 has dropped the diffutils "Requires" (the %changelog does
> not mention that). The mock buildsys build-group pkg needs an
> update.

No it wasn't dropped from rpm-build, it never was there to begin with.
diffutils has always been one of the implicit requirements (for no good 
reason IMO but that's another story) and has only been added recently to 
rawhide rpm.

Next round of rpm updates updates for F7 (and FC6 possibly) is coming 
soonish, I can fix this and bunch of other implicit deps there. Missing 
deps are bugs alright, but I'm just not at all happy to see the build 
environment of already released Fedora versions changing like this.

 	- Panu -



From skvidal at fedoraproject.org  Wed Oct  3 11:14:41 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 03 Oct 2007 07:14:41 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <470341AF.3000707@rasmil.dk>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com> <47026C1F.7060808@rasmil.dk>
	<1191341323.6741.17.camel@cutter>  <470341AF.3000707@rasmil.dk>
Message-ID: <1191410081.6741.61.camel@cutter>


On Wed, 2007-10-03 at 09:15 +0200, Tim Lauridsen wrote:
> seth vidal wrote: 
> > On Tue, 2007-10-02 at 18:04 +0200, Tim Lauridsen wrote:
> >   
> > > Jesse Keating wrote: 
> > >     
> > > > On Tue, 02 Oct 2007 14:47:06 +0200
> > > > Oliver Falk &lt;oliver at linux-kernel.at&gt; wrote:
> > > > 
> > > >   
> > > >       
> > > > > OK, that might be the better fix. But doesn't it make sense
> > > > > ConfigParser also allows int as values? I mean any kind of number
> > > > > (int, float, complex) could be handled as string...
> > > > >     
> > > > >         
> > > > I know not the history of ConfigParser and why it's only strings.  I
> > > > suspect it's because ConfigParser's primary usage is to parse config
> > > > files, and in a file it may be non-obvious how to mark something as an
> > > > int/float rather than a string.  The reason pungi uses ConfigParser is
> > > > that prior to using kickstart files we had our own config files.  I'm
> > > > not entirely happy with ConfigParser, but it'd be something of an
> > > > overhaul to switch to some other config system, and not one I was
> > > > willing to make at this point.  Maybe during F9...
> > > >   
> > > >       
> > > You can take a look at the config classes in yum (yum/config.py) it
> > > let you define different kind of options types.
> > > 
> > >     
> > 
> > I've also made a yum-free config.py that takes all the advantages of the
> > yum config file w/o needing the yum-ness of it.
> > 
> > you can find it here:
> > http://skvidal.fedorapeople.org/config.py
> > 
> > we just used in in func and it's rather handy.
> > 
> > -sv
> > 
> > 
> >   
> Maybe, it should be out into its own package (python module), so that
> potential users could pull it in (yum, func, yumex, pungi etc).
> and it could be maintained in one place.
> 

actually I was thinking that maybe we should see about submitting it to
be in python core.

-sv




From jkeating at redhat.com  Wed Oct  3 11:32:44 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 3 Oct 2007 07:32:44 -0400
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <4703669C.2060600@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
	<47026129.2080001@linux-kernel.at> <470270C6.60309@linux-kernel.at>
	<20071002142722.1857e919@redhat.com>
	<4703669C.2060600@linux-kernel.at>
Message-ID: <20071003073244.538e9091@redhat.com>

On Wed, 03 Oct 2007 11:53:32 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> pykickstart-1.2-2.fc8

This is likely your problem.  pykickstart-1.13-1.fc8 was current when I
did my test.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/b7a47ecc/attachment.sig>

From tla at rasmil.dk  Wed Oct  3 11:51:53 2007
From: tla at rasmil.dk (Tim Lauridsen)
Date: Wed, 03 Oct 2007 13:51:53 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <1191410081.6741.61.camel@cutter>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>
	<47026C1F.7060808@rasmil.dk>	<1191341323.6741.17.camel@cutter>
	<470341AF.3000707@rasmil.dk> <1191410081.6741.61.camel@cutter>
Message-ID: <47038259.302@rasmil.dk>

seth vidal wrote:
> On Wed, 2007-10-03 at 09:15 +0200, Tim Lauridsen wrote:
>   
>> seth vidal wrote: 
>>     
>>> On Tue, 2007-10-02 at 18:04 +0200, Tim Lauridsen wrote:
>>>   
>>>       
>>>> Jesse Keating wrote: 
>>>>     
>>>>         
>>>>> On Tue, 02 Oct 2007 14:47:06 +0200
>>>>> Oliver Falk &lt;oliver at linux-kernel.at&gt; wrote:
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> OK, that might be the better fix. But doesn't it make sense
>>>>>> ConfigParser also allows int as values? I mean any kind of number
>>>>>> (int, float, complex) could be handled as string...
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> I know not the history of ConfigParser and why it's only strings.  I
>>>>> suspect it's because ConfigParser's primary usage is to parse config
>>>>> files, and in a file it may be non-obvious how to mark something as an
>>>>> int/float rather than a string.  The reason pungi uses ConfigParser is
>>>>> that prior to using kickstart files we had our own config files.  I'm
>>>>> not entirely happy with ConfigParser, but it'd be something of an
>>>>> overhaul to switch to some other config system, and not one I was
>>>>> willing to make at this point.  Maybe during F9...
>>>>>   
>>>>>       
>>>>>           
>>>> You can take a look at the config classes in yum (yum/config.py) it
>>>> let you define different kind of options types.
>>>>
>>>>     
>>>>         
>>> I've also made a yum-free config.py that takes all the advantages of the
>>> yum config file w/o needing the yum-ness of it.
>>>
>>> you can find it here:
>>> http://skvidal.fedorapeople.org/config.py
>>>
>>> we just used in in func and it's rather handy.
>>>
>>> -sv
>>>
>>>
>>>   
>>>       
>> Maybe, it should be out into its own package (python module), so that
>> potential users could pull it in (yum, func, yumex, pungi etc).
>> and it could be maintained in one place.
>>
>>     
>
> actually I was thinking that maybe we should see about submitting it to
> be in python core.
>
> -sv
>
>
>   
Sounds like a good idea.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/3e816ccc/attachment.htm>

From mschwendt.tmp0701.nospam at arcor.de  Wed Oct  3 12:09:00 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 3 Oct 2007 14:09:00 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
Message-ID: <20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 3 Oct 2007 14:12:15 +0300 (EEST), Panu Matilainen wrote:

> >> ./configure: line 37448: cmp: command not found
> >> ...
> >> error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> >> ...
> >> RPM build errors:
> >>     Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> >> ...
> >>
> >>
> >> Seemingly, "cmp" is in FC-7's default packages in koji, but not in
> >> FC-7's mock.
> >
> > It's the same old "diffutils is missing" problem that has been found
> > recently. Normally, "rpm-build" used to require "diffutils", because
> > it uses diff in scripts like check-files. But the RPM update for
> > F7 and FC6 has dropped the diffutils "Requires" (the %changelog does
> > not mention that). The mock buildsys build-group pkg needs an
> > update.
> 
> No it wasn't dropped from rpm-build, it never was there to begin with.
> diffutils has always been one of the implicit requirements (for no good 
> reason IMO but that's another story) and has only been added recently to 
> rawhide rpm.

Then we're back at the questions "who dropped diffutils from the
buildsys build-groups for stable dists?" or "why is diffutils missing
suddenly"?



From jonathan.underwood at gmail.com  Wed Oct  3 12:31:48 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 3 Oct 2007 13:31:48 +0100
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
Message-ID: <645d17210710030531s266e7047re9a375d6df40300e@mail.gmail.com>

On 02 Oct 2007 13:12:31 -0500, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
> Issues pending FESCO ratification:
>  * Naming of TeX-related packages:
>   * http://www.redhat.com/archives/fedora-packaging/2007-September/msg00066.html
>   * Accepted (5 - 0)

Presumably package names should be changed for F8?



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Oct  3 12:56:39 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 03 Oct 2007 21:56:39 +0900
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <1191386564.3395.146.camel@mccallum.corsepiu.local>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
Message-ID: <47039187.9060607@ioa.s.u-tokyo.ac.jp>

Ralf Corsepius wrote, at 10/03/2007 01:42 PM +9:00:
> Hi,
> 
> I am facing what I presume to be caused by a divergence between the
> default set of packages in a built-root in mock and koji:
> 
> 
> koji --scratch building a package succeeds:
> 
> # koji build --scratch --arch=i386 dist-fc7 Coin2-2.5.0-2.fc7.src.rpm
> 
> c.f. http://koji.fedoraproject.org/koji/taskinfo?taskID=181197
> 
> 
> while rebuilding the identical src.rpm in a local mock on FC-7 fails:
> 
> # mock  -r fedora-7-i386.cfg Coin2-2.5.0-2.fc7.src.rpm
> ...
> ./configure: line 37448: cmp: command not found
> ...
> error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> ...
> RPM build errors:
>     Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> ...
> 
> 
> Seemingly, "cmp" is in FC-7's default packages in koji, but not in
> FC-7's mock.
> 

Umm.. For me mock build of repo fedora-7-i386 with debug option
(i.e. mock -r fedora-7-i386 --debug ..... ) shows buildsys-build
package is pulled from "groups" repo, i.e. from
http://buildsys.fedoraproject.org/buildgroups/7/i386/

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 buildsys-build          noarch     0.8-1.fc7        groups            2.7 k
Installing for dependencies:
 ConsoleKit-libs         i386       0.2.1-2.fc7      fedora             13 k
 MAKEDEV                 i386       3.23-1.2         fedora            135 k

This is because "local" repo (i.e.
http://koji.fedoraproject.org/static-repos/dist-fc7-build-current/i386/ )
is disabled on fedora-7-i386.cfg .

buildsys-build(-1.1.noarch) under "local" repo surely requires
diffutils, while buildsys-build(-0.8-1.fc7) under "groups" repo does not.

Regards
Mamoru



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Oct  3 13:00:19 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 03 Oct 2007 22:00:19 +0900
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <47039187.9060607@ioa.s.u-tokyo.ac.jp>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<47039187.9060607@ioa.s.u-tokyo.ac.jp>
Message-ID: <47039263.60200@ioa.s.u-tokyo.ac.jp>

Mamoru Tasaka wrote, at 10/03/2007 09:56 PM +9:00:
> buildsys-build(-1.1.noarch) under "local" repo surely requires
> diffutils, while buildsys-build(-0.8-1.fc7) under "groups" repo does not.
> 

More strangely, buildsys-build-0.7-1.fc7 under "groups" repo requires
diffutils, while buildsys-build-0.8-1.fc7 under "groups" repo does not.

Mamoru



From pertusus at free.fr  Wed Oct  3 13:13:26 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Oct 2007 15:13:26 +0200
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <645d17210710030531s266e7047re9a375d6df40300e@mail.gmail.com>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
	<645d17210710030531s266e7047re9a375d6df40300e@mail.gmail.com>
Message-ID: <20071003131326.GD2557@free.fr>

On Wed, Oct 03, 2007 at 01:31:48PM +0100, Jonathan Underwood wrote:
> On 02 Oct 2007 13:12:31 -0500, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
> > Issues pending FESCO ratification:
> >  * Naming of TeX-related packages:
> >   * http://www.redhat.com/archives/fedora-packaging/2007-September/msg00066.html
> >   * Accepted (5 - 0)
> 
> Presumably package names should be changed for F8?

Certainly not. We are past test3, texlive is still not in, and it is not
a big deal. Additionally, it would be nice to have the virtual provides
also in, jindrich was inclined to add them, before we adjust the
packages. F9 would be a more realistic target, in my opinion, without
pressure on the maintainers to change names in case they have more
important business to do.

--
Pat



From buildsys at redhat.com  Wed Oct  3 13:25:19 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 3 Oct 2007 09:25:19 -0400
Subject: rawhide report: 20071003 changes
Message-ID: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>

New package SteGUI
	Graphical front-end to Steghide

New package TnL-data
	Datafiles for Thunder and Lightning

New package aasaver
	A screensaver for KDE which presents an ASCII aquarium

New package abyssinica-fonts
	SIL Abyssinica fonts

New package aldrin
	Modular music sequencer/tracker

New package cdcollect
	Simple CD/DVD catalog for GNOME

New package eclipse-demos
	Eclipse demonstration screencasts

New package fbreader
	E-book reader

New package higlayout
	Easy to use and powerful layout manager for Java

New package kbiof
	KDE port of the original BIOF XScreenSaver

New package ladspa-caps-plugins
	The C* Audio Plugin Suite

New package libHX
	General-purpose library

New package libpano13
	Library for manipulating panoramic images

New package londonlaw
	Online multiplayer version of a well known detective boardgame

New package lybniz
	A function graph plotter

New package php-channel-phing
	Adds phing channel to PEAR

New package php-channel-phpdb
	Adds phpdb channel to PEAR

New package quake3
	Quake 3 Arena tournament 3D shooter game

New package qwt-doc
	Documentation of qwt

New package rt61pci-firmware
	Firmware for Ralink?? RT2561/RT2661 A/B/G network adaptors

New package rt73usb-firmware
	Firmware for Ralink?? RT2571W/RT2671 A/B/G network adaptors

New package ruby-RMagick
	Graphics Processing for Ruby and Ruby on Rails

New package scim-python
	Python wrapper for Smart Common Input Method platform

New package straw
	Desktop news aggregator

New package taipeifonts
	Chinese Bitmap Fonts

New package vdr-ttxtsubs
	Teletext subtitles plugin for VDR

New package whowatch
	Display information about users currently logged on


Removed package eclipse-mylar

Updated Packages:

Coin2-2.5.0-2.fc8
-----------------
* Wed Oct 03 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.5.0-2
- Fix permissions on source files.
- Convert sources to utf-8.

* Tue Oct 02 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.5.0-1
- Upstream update.

FlightGear-0.9.11-0.4.pre1.fc8
------------------------------
* Tue Oct 02 2007 Fabrice Bellet <fabrice at bellet.info> 0.9.11-0.4.pre1
- use opengl-games-utils wrapper to show error dialog when DRI is missing

* Sun Sep 23 2007 Fabrice Bellet <fabrice at bellet.info> 0.9.11-0.3.pre1
- update icon cache handling to current guidelines/drafts
- update License tag

OpenSceneGraph-2.0-7.fc8
------------------------
* Thu Sep 27 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.0-7
- Let OpenSceneGraph-libs Obsoletes: Producer
- Let OpenSceneGraph-devel Obsoletes: Producer-devel.

* Wed Sep 26 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.0-6
- By public demand, add upstream's *.pcs.
- Add hacks to work around the worst bugs in *.pcs.
- Add OpenSceneGraph2-devel.
- Move ldconfig to *-libs.
- Abandon OpenThreads2.
- Remove obsolete applications.

Pixie-2.2.2-2.fc8
-----------------
* Mon Oct 01 2007 kwizart < kwizart at gmail.com > - 2.2.2-2
- Disable prefix in name

abcde-2.3.99.6-4.fc8
--------------------
* Sat Sep 29 2007 Ville Skytt?? <ville.skytta at iki.fi> - 2.3.99.6-4
- Requires: which

* Mon Aug 13 2007 Ville Skytt?? <ville.skytta at iki.fi> - 2.3.99.6-3
- License: GPLv2+
- Add (empty) %build section.

acpid-1.0.6-2.fc8
-----------------
* Wed Sep 26 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-2.fc8
- Fixed leak of a file descriptor
- Resolves: #304761

akode-2.0.1-9.fc8
-----------------
* Wed Sep 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 2.0.1-9
- BR: pulseaudio-libs-devel

alsa-plugins-1.0.14-4.fc8
-------------------------
* Mon Oct 01 2007 Lennart Poettering <lpoetter at redhat.com> - 1.0.14-4
- In the pulse plugin: reflect the XRUN state back to the application.
  Makes XMMS work on top of the alsa plugin. (#307341)

alsa-utils-1.0.15-0.4.rc1.fc8
-----------------------------
* Mon Oct 01 2007 Martin Stransky <stransky at redhat.com> 1.0.15-0.4.rc1
- moved saved volume settings back to /etc/alsa
  (per discussion at #293301)

amarok-1.4.7-5.fc8
------------------
* Fri Sep 28 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-5
- add patch 1 to fix Fedora bug 242862: Amarok doesn't support transfer
  of Unicode filenames to MTP devices

* Sun Sep 02 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-4
- add patch for kde bug 147126 : amarok freezes when trying to play
  mp3 files without mp3 support

* Fri Aug 24 2007 Todd Zullinger <tmz at pobox.com> 1.4.7-3
- rebuild with libgpod-0.5.2

audit-1.6.2-2.fc8
-----------------
* Mon Oct 01 2007 Steve Grubb <sgrubb at redhat.com> 1.6.2-2
- Don't retry if the rt queue is full.

bigboard-0.5.21-2.fc8
---------------------
* Tue Oct 02 2007 Colin Walters <walters at redhat.com> - 0.5.21-2
- require online-desktop

* Tue Oct 02 2007 Colin Walters <walters at redhat.com> - 0.5.21-1
- new upstream

* Thu Sep 27 2007 Colin Walters <walters at redhat.com> - 0.5.20-1
- new upstream

bug-buddy-1:2.20.0-2.fc8
------------------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-2
- Incorporate upstream fixes (#314861)

bzr-0.91-1.fc8
--------------
* Tue Aug 28 2007 Toshio Kuratomi <a.badger at gmail.com> - 0.91-1
- Update to 0.91.
  + Fixes some issues with using tag-enabled branches.

bzr-gtk-0.91.0-2.fc8
--------------------
* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-2
- Olive must be moved to an arch specific directory as well for now.
  If rpm could have noarch subpackages, this would be fine to leave in
  python_sitelib.

* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-1
- Update to 0.91.0.

* Thu Aug 30 2007 Toshio Kuratomi <a.badger at gmail.com> 0.90.0-2
- Move the plugins manually as distutils doesn't know that bzr is arch
  specific.

bzrtools-0.91.0-1.fc8
---------------------
* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-1
- Update to 0.91.0.

ccache-2.4-11.fc8
-----------------
* Tue Oct 02 2007 Ville Skytt?? <ville.skytta at iki.fi> - 2.4-11
- Apply upstream fix for problems when $HOME is not set (#315441).

* Wed Aug 22 2007 Ville Skytt?? <ville.skytta at iki.fi>
- Fix URL to upstream tarball.

chmlib-0.39-5.fc8
-----------------
* Sun Sep 30 2007 Peter Lemenkov <lemenkov at gmail.com> 0.39-5
- Changel license tag from LGPL to LGPLv2+

* Sun Aug 05 2007 Peter Lemenkov <lemenkov at gmail.com> 0.39-4
- Better fix for multi-arch issues

cinepaint-0.22.1-4.fc8
----------------------
* Tue Oct 02 2007 kwizart < kwizart at gmail.com > - 0.22.1-4
- Patch plug-ins/script-fu/interp_md5.* (remove RSA)
- Add Requires pygtk2

cobbler-0.6.2-2.fc8
-------------------
* Fri Sep 28 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.2-2
- Upstream changes (see CHANGELOG)
- removed syslinux as a requirement (cobbler check will detect absense)
- packaged /var/lib/cobbler/settings as a config file
- added BuildRequires of redhat-rpm-config to help src RPM rebuilds on other platforms
- permissions cleanup
- make license field conform to rpmlint
- relocate cgi-bin files to cobbler subdirectory 
- include the WUI!

codeina-0.10.1-2.fc8
--------------------
* Mon Oct 01 2007 - Bastien Nocera <bnocera at redhat.com> - 0.10.1-2
- Big patch from myself (fixes from Thomas) to:
- Show a title to the price column (#299251)
- Not redownload already downloaded packages, and check whether corrupted
  (#305421)
- Select free matching codecs by default (#305411)
- Clearly show an empty list and a warning when no codecs match the required
  ones, so users don't get confused

colordiff-1.0.6a-4.fc8
----------------------
* Sat Sep 29 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.0.6a-4
- Requires: which

* Mon Aug 13 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.0.6a-3
- License: GPLv2+

convmv-1.10-3.fc8
-----------------
* Thu Sep 27 2007 Nils Philippsen <nphilipp at redhat.com> - 1.10-3
- don't expect find output to be sorted, move "make test" to %check (#237687,
  patch by Giuseppe Bonacci)
- change license tag to "GPLv2"

cups-1:1.3.3-1.fc8
------------------
* Fri Sep 28 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.3-1
- 1.3.3.

* Tue Sep 25 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.2-3
- Don't strip foomatic recommended strings from make/model names.

* Fri Sep 21 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.2-2
- Write printcap when remote printers have timed out (bug #290831).

cupsddk-1.2.2-1.fc8
-------------------
* Tue Oct 02 2007 Tim Waugh <twaugh at redhat.com> 1.2.2-1
- 1.2.2 (with patch to fix build).

* Sat Sep 29 2007 Tim Waugh <twaugh at redhat.com> 1.2.1-1
- 1.2.1.

dbus-sharp-0.63-8.fc8
---------------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 0.63-8
- Add alpha to ExlusiveArch

* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 0.63-7
- Fix license field
- Add pkgconfig dependency to the -devel package

dhcp-12:3.0.6-7.fc8
-------------------
* Wed Sep 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-7
- In dhcp.conf.5, explain that if no next-server statement applies to the
  requesting client, the address 0.0.0.0 is used (#184484).

* Wed Sep 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-6
- Init script fixes for dhcpd and dhcrelay (#278601)

* Mon Sep 10 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-5
- Fix typos in ldap.c and correct LDAP macros (#283391)

docbook-dtds-1.0-32.fc8
-----------------------
* Mon Oct 01 2007 Ondrej Vasik <ovasik at redhat.com> - 1.0.32
- DocBook 4.4 SGML and XML.(#312941)
- added dist tag

e2fsprogs-1.40.2-8.fc8
----------------------
* Tue Oct 02 2007 Eric Sandeen <esandeen at redhat.com> 1.40.2-8
- Detect squashfs filesystems in libblkid (#305151)

echo-icon-theme-0.3-1.git.fc8
-----------------------------
* Tue Oct 02 2007 Luya Tshimbalanga <luya_tfz at thefinalzone.com> - 0.3-1.git
- Newest snapshot
- Included cc-by-sa 3.0 file
- Dropped patch contexts.patch

* Wed Sep 26 2007 Luya Tshimbalanga <luya_tfz at thefinalzone.com> - 0.2.5.20070427wiki
- Updated license to cc-by-sa 3.0

eclipse-1:3.3.0-22.fc8
----------------------
* Wed Sep 26 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-21
- Add patch to generate 1.6 bytecode on a 1.7 VM (kudos to Olivier
  Thomann)
- Resolves:  rhbz#288991.

* Tue Sep 18 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-20
- Move requirements on subclipse, cdt, mylyn, etc. to comps.xml.

* Mon Sep 10 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-19
- Don't require subclipse, cdt, or rpm-editor on ppc64.

empathy-0.14-2.fc8
------------------
* Tue Oct 02 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-2
- Disable VoIP support at this time, since it is deemed unstable by upstream
  for now. (Thanks to Brian Pepple for the notice.)

* Tue Oct 02 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-1
- Update to new upstream release (0.14).

* Sun Sep 30 2007 Peter Gordon <peter at thecodergeek.com> - 0.13-1
- Update to new upstream release (0.13), which adds a panel applet (Megaphone)
  and python bindings.
- Split shared libraries into a libs subpackage for easier handling
  in multi-lib environments.

eruby-1.0.5-10
--------------
* Tue Sep 25 2007 Akira TAGOH <tagoh at redhat.com> - 1.0.5-10
- clean up the spec file.

f-spot-0.4.0-3.fc8
------------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 0.4.0-3
- Add alpha to ExclusiveArch

firefox-2.0.0.6-11.fc8
----------------------
* Wed Sep 26 2007 Martin Stransky <stransky at redhat.com> 2.0.0.6-11
- Fixed #242657 - firefox -g doesn't work

fonts-chinese-3.03-12.fc8
-------------------------
* Thu Sep 27 2007 Caius Chance <cchance at redhat.com> - 3.03-12.fc8
- Resolves: rhbz#225761 (Convert fonts-chinese into meta-package.)
  <<<<< Taipei fonts was moved to a separate package taipeifonts.
  <<<<< Improved: % defattr(-,root,root,-)
  <<<<<-Put taipeifonts after cjkunifonts in the requires.

* Thu Sep 27 2007 Caius Chance <cchance at redhat.com> - 3.03-11.fc8
- Resolves: rhbz#225761 (Convert fonts-chinese into meta-package.)
  <<<<< Tidy up spec file.

fonts-japanese-0.20061016-12.fc8
--------------------------------
* Wed Sep 26 2007 Akira TAGOH <tagoh at redhat.com> - 0.20061016-12
- Remove jisksp16-1990 and knm_new fonts so that it has been packaged separately.
- clean up the spec file.

* Fri Aug 31 2007 Akira TAGOH <tagoh at redhat.com>
- Add jiskan24-2000-{1,2} and jiskan24-2003-1.

* Thu Aug 30 2007 Akira TAGOH <tagoh at redhat.com>
- drop BR gzip

fuse-2.7.0-8.fc8
----------------
* Mon Oct 01 2007 Peter Lemenkov <lemenkov at gmail.com> 2.7.0-8
- Added Require: which (BZ#312511)

* Fri Sep 21 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.7.0-7
- revert udev rules change

* Thu Sep 20 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.7.0-6
- change udev rules so that /dev/fuse is chmod 666 (bz 298651)

fvwm-2.5.23-3.fc8
-----------------
* Tue Oct 02 2007 Adam Goode <adam at spicenitz.org> - 2.5.23-3
- Change htmlview to xdg-open (thanks, Ville Skytt?? !)

fwfstab-0.01.1-7.fc8
--------------------
* Mon Oct 01 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.01.1-7
- Rebuild for redhat-artwork split

gcc-4.1.2-31
------------
* Wed Oct 03 2007 Jakub Jelinek <jakub at redhat.com> 4.1.2-31
- fix visibility of C++ guard variables (Jason Merrill)
- don't drop DECL_BUILT_IN_CLASS when defining a builtin function

* Mon Oct 01 2007 Jakub Jelinek <jakub at redhat.com> 4.1.2-30
- fix ICE on C++ gnu_inline function followed by prototype of the same
  fn (Alexandre Oliva)

* Fri Sep 28 2007 Jakub Jelinek <jakub at redhat.com> 4.1.2-29
- print virtual inline backtrace in some diagnostic messages to help
  locate bugs reported with -D_FORTIFY_SOURCE{,=2}

gdm-1:2.20.0-13.fc8
-------------------
* Tue Oct 02 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.0-13
- Actually add said escape == cancel behavior back

* Tue Oct 02 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.0-12
- Add escape == cancel behavior back

* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-11
- Fix a refcounting problem with user faces

gedit-1:2.20.1-1.fc8
--------------------
* Wed Sep 26 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.1-1
- Update to 2.20.1 at the request of upstream

ghc-6.8.0.20070928-2.fc8
------------------------
* Sat Sep 29 2007 Bryan O'Sullivan <bos at serpentine.com> - 6.8.0.20070928-2
- add happy to BuildRequires

* Sat Sep 29 2007 Bryan O'Sullivan <bos at serpentine.com> - 6.8.0.20070928-1
- prepare for GHC 6.8.1 by building a release candidate snapshot

ghostscript-8.60-3.fc8
----------------------
* Thu Sep 27 2007 Tim Waugh <twaugh at redhat.com> 8.60-3
- Back-ported mkstemp64 patch (bug #308211).

* Thu Aug 23 2007 Tim Waugh <twaugh at redhat.com> 8.60-2
- More specific license tag.

* Fri Aug 03 2007 Tim Waugh <twaugh at redhat.com> 8.60-1
- 8.60.

git-1.5.3.3-1.fc8
-----------------
* Sun Sep 30 2007 James Bowes <jbowes at redhat.com> 1.5.3.3-1
- git-1.5.3.3

* Wed Sep 26 2007 James Bowes <jbowes at redhat.com> 1.5.3.2-1
- git-1.5.3.2

glibc-2.6.90-16
---------------
* Sat Sep 29 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-16
- misc fixes (BZ#4963, BZ#4972, BZ#5028, BZ#5043, BZ#5058)
- improve -D_FORTIFY_SOURCE{,=2} diagnostic through warning/error
  attributes
- fix wcscpy, wcpcpy, fgetws, fgetws_unlocked, swprintf and vswprintf
  fortification inlines
- fix a scalability issue with lazy binding in heavily multithreaded
  programs

gnome-applets-1:2.20.0-6.fc8
----------------------------
* Thu Sep 27 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-6
- Fix a memory leak in the mixer preferences

gnome-desktop-2.20.0-3.fc8
--------------------------
* Thu Sep 27 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-3
- remove seemingly unneccessary dep on redhat-artwork

* Wed Sep 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Fix a memory leak

gnome-pilot-2.0.15-9.fc8
------------------------
* Wed Sep 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.0.15-9
- Fix the build with new intltool

* Tue Apr 24 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-8.fc7
- One more revision of the patch to close RH bug #198211.

* Mon Apr 23 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-7.fc7
- Revise patch for RH bug #198211 to match upstream's solution.

gnome-python2-extras-2.19.1-6.fc8
---------------------------------
* Fri Sep 28 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-6.fc8
- Add a gnome-python2-gdl subpackage (RH bug #303141).

gnome-session-2.20.0-2.fc8
--------------------------
* Thu Sep 27 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-2
- drop redhat-artwork dep.  We don't need it.

gnome-volume-manager-2.17.0-8.fc8
---------------------------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 2.17.0-8
- Drop the hard gthumb requirement (#228759)
- Fix license field

gpp-0.7.0-1.fc8
---------------
* Wed Sep 26 2007 Matt Domsch <matt at domsch.com> 0.7.0-1
- update to latest upstream, fixes #242195 and #198150
- fix .desktop file Version

gpredict-0.9.0-1.fc8
--------------------
* Sat Sep 29 2007 Denis Leroy <denis at poolshark.org> - 0.9.0-1
- Update to 0.9.0
- Removed tooltip patch, is now upstream

gpsim-0.22.0-5.fc8
------------------
* Thu Sep 27 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.22.0-5
- Add BR popt-devel

grace-5.1.21-4.fc8
------------------
* Fri Sep 28 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 5.1.21-4
- Correctly detect netcdf (signature has changed).
- Add libXmu-devel as BR.
- Add conditional dependency on chkfontpath for <= F8.

* Thu Sep 27 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 5.1.21-3
- Remove dependency on chkfontpath, thanks to ajax for the patch. (#252277)

gsoap-2.7.9-0.1.l
-----------------

gstreamer-0.10.14-4.fc8
-----------------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 0.10.14-4
- Add missing Requires (#312671)

* Tue Aug 14 2007 Matthias Clasen <mclasen at redhat.com> - 0.10.14-3
- Require check-devel (#251956)

* Sat Aug 04 2007 - Bastien Nocera <bnocera at redhat.com> - 0.10.14-1
- Update to 0.10.14

gtkwave-3.1.1-1.fc8
-------------------
* Fri Sep 28 2007 Paul Howarth <paul at city-fan.org> 3.1.1-1
- update to 3.1.1

hunspell-hu-1.2.1-1.fc8
-----------------------
* Tue Oct 02 2007 Caolan McNamara <caolanm at redhat.com> - 1.2.1-1
- latest version

* Fri Aug 03 2007 Caolan McNamara <caolanm at redhat.com> - 1.2-2
- clarify that this is tri-licenced

hunspell-pt-0.20071001-1.fc8
----------------------------
* Tue Oct 02 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071001-1
- next version

hwbrowser-0.37-1.fc8
--------------------
* Thu Sep 27 2007 Nils Philippsen <nphilipp at redhat.com> - 0.37-1
- hide notebook tabs (#308301)

icu-3.8-1.fc8
-------------
* Tue Oct 02 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-1
- latest version

* Mon Sep 03 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-0.2.d02
- next release candidate

* Wed Aug 29 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-0.2.d01
- rebuild

im-chooser-0.5.2-3.fc8
----------------------
* Tue Oct 02 2007 Akira TAGOH <tagoh at redhat.com> - 0.5.2-3
- Revert the previous change.

initscripts-8.57-1
------------------
* Tue Sep 25 2007 Bill Nottingham <notting at redhat.com> - 8.57-1
- work around upstream bash changes (#220887, modified from <nvigier at mandriva.com>)
- init.d/network: add Should-Start for firewall services
- ifup-eth: handle arp_ip_target separately (#288151, <agospoda at redhat.com>)
- rc.sysinit: remove rc.serial support - should be udev rules
- rc.sysinit: remove acpi module loading - now supported by the kernel automatically
- fix en_GB translation (#271201)
- translation updates: as, bn_IN, bg, ca, cs, de, el, es, fi, gu, hi, it, ja, ko, kn, ml,
  mr, nb, nl, pa, pl, pt, pt_BR, ro, sl, sr, sr at Latn, sv, ta, te, zh_CN

inn-2.4.3-7.fc8
---------------
* Tue Oct 02 2007 Ondrej Dvoracek <odvorace at redhat.com> 2.4.3-7
- initscript review (#246951)
- added buildrequires for perl-devel and python

iprutils-2.2.6-3.fc8
--------------------
* Mon Oct 01 2007 Jeremy Katz <katzj at redhat.com> - 2.2.6-3
- don't require redhat-lsb (#252343)

iptables-1.3.8-4.1.fc8
----------------------
* Wed Sep 26 2007 Thomas Woerner <twoerner at redhat.com> 1.3.8-4.1
- do not start ip6tables if ipv6 is blacklisted (rhbz#236888)
- use simpler fix for (rhbz#295611)
  Thanks to Linus Torvalds for the patch.

irqbalance-2:0.55-5.fc8
-----------------------
* Fri Sep 28 2007 Neil Horman <nhorman at redhat.com> - 2:0.55-5
- Install pie patch
- Grab Ulis cpuparse cleanup (bz 310821)

isdn4k-utils-3.2-55.fc8
-----------------------
* Thu Sep 27 2007 Than Ngo <than at redhat.com> -  3.2-55
- fix build issue with glibc

jd-1.9.6-0.6.rc070930.fc8
-------------------------
* Sun Sep 30 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-0.6.rc070930
- 1.9.6 rc 070930

* Tue Sep 18 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-0.5.beta070918
- 1.9.6 beta 070918

* Sun Aug 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-0.2.beta070804
- 1.9.6 beta 070804 release 2

jokosher-1.0-0.1.20070929svn.fc8
--------------------------------
* Sat Sep 29 2007 Christopher Brown <snecklifter at gmail.com> - 1.0-0.1.20070929svn
- change to python-setuptools-devel
- update to latest svn

* Tue Sep 04 2007 Christopher Brown <snecklifter at gmail.com> - 1.0-0.1.20070904svn
- change to python-setuptools-devel
- update to latest svn

* Fri Aug 24 2007 Christopher Brown <snecklifter at gmail.com> - 1.0-0.1.20070824svn
- update to latest svn

kazehakase-0.4.9-1.fc8
----------------------
* Sat Sep 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-1
- 0.4.9

kdebase-6:3.5.7-16.fc8
----------------------
* Tue Oct 02 2007 Than Ngo <than at redhat.com> - 6:3.5.7-16
- rh#299731, CVE-2007-4569

* Thu Sep 27 2007 Than Ngo <than at redhat.com> - 6:3.5.7-15
- rh#301841, "Root Shell" sessions will not close

kdeutils-6:3.5.7-6.fc8
----------------------
* Thu Sep 27 2007 Than Ngo <than at redhat.com> -  3.5.7-6
- fix build issue with new current glibc-2.6.90

kernel-2.6.23-0.217.rc9.git1.fc8
--------------------------------
* Tue Oct 02 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git1

* Tue Oct 02 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9

* Sun Sep 30 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc8-git4

kernel-xen-2.6-2.6.21-2947.fc8
------------------------------
* Thu Sep 27 2007 Eduardo Habkost <ehabkost at redhat.com>
- Fix 3w-9xxx to use PCI resources properly and work under Xen (bug #309611)

kexec-tools-1.102pre-2.fc8
--------------------------
* Mon Oct 01 2007 Neil Horman <nhorman at redhat.com> - 1.102pre-2
- Fix triggerpostun script (bz 308151)

kinput2-v3.1-36.fc8
-------------------
* Fri Sep 28 2007 Akira TAGOH <tagoh at redhat.com> - v3.1-36
- Add Requires: Canna to get it working just installing the package.
- clean up a bit the spec file.

koan-0.6.2-2.fc8
----------------
* Fri Sep 28 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.2-2
- Upstream changes (see CHANGELOG)

krb5-1.6.2-9.fc8
----------------
* Mon Oct 01 2007 Nalin Dahyabhai <nalin at redhat.com> 1.6.2-9
- apply the fix for CVE-2007-4000 instead of the experimental patch for
  setting ok-as-delegate flags

* Tue Sep 11 2007 Nalin Dahyabhai <nalin at redhat.com> 1.6.2-8
- move the db2 kdb plugin from -server to -libs, because a multilib libkdb
  might need it

* Tue Sep 11 2007 Nalin Dahyabhai <nalin at redhat.com> 1.6.2-7
- also perform PAM session and credential management when ftpd accepts a
  client using strong authentication, missed earlier
- also label kadmind log files and files created by the db2 plugin

lat-1.2.3-1.fc8
---------------
* Fri Sep 28 2007 Paul Howarth <paul at city-fan.org> 1.2.3-1
- Update to 1.2.3
- Clarify license as GPL version 2

* Sat Jun 09 2007 Paul Howarth <paul at city-fan.org> 1.2.2-3
- ExcludeArch ppc64 due to missing mono support on that arch (#241911)
- Require yelp (#243403)

* Fri Mar 16 2007 Paul Howarth <paul at city-fan.org> 1.2.2-2
- Upstream now installs correctly into %{_libdir} rather than %{_prefix}/lib
  so there's no need to override the destination directory in %install; this
  change gets the plugins installed into the correct directory too (#232278)

less-406-12.fc8
---------------
* Mon Oct 01 2007 Ivana Varekova <varekova at redhat.com> - 406-12
- change license tag
- fix 312591 - add which dependency

libICE-1.0.4-2.fc8
------------------
* Mon Oct 01 2007 Adam Jackson <ajax at redhat.com> 1.0.4-2
- Rebuild against xtrans 1.0.3-5 to pick up gethostname() avoidance.

libdockapp-0.6.1-4.fc8
----------------------
* Sun Sep 30 2007 Patrice Dumas <pertusus at free.fr> 0.6.1-4
- new fontpath.d configuraton mechanism, change by ajax, Adam Jackson
libselinux-2.0.35-2.fc8
-----------------------
* Thu Sep 27 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.35-2
- Fix segfault on missing file_context file

* Wed Sep 26 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.35-1
- Upgrade to upstream
	* Make netlink socket close-on-exec to avoid descriptor leakage from Dan Walsh.
	* Pass CFLAGS when using gcc for linking from Dennis Gilmore.

libsemanage-2.0.11-1.fc8
------------------------
* Fri Sep 28 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.11-1
- Upgrade to latest from NSA
	* Fix ordering of file_contexts.homedirs from Todd Miller and Dan Walsh.

* Fri Sep 28 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.10-2
- Fix sort order on generated homedir context

* Fri Sep 28 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.10-1
- Upgrade to latest from NSA
	* Fix error checking on getpw*_r functions from Todd Miller.
	* Make genhomedircon skip invalid homedir contexts from Todd Miller.
	* Set default user and prefix from seusers from Dan Walsh.
	* Add swigify Makefile target from Dan Walsh.

libsepol-2.0.11-1.fc8
---------------------
* Wed Sep 26 2007 Dan Walsh <dwalsh at redhat.com> 2.0.11-1
* Pass CFLAGS to CC even on link command, per Dennis Gilmore.

libvirt-0.3.3-1.fc8
-------------------
* Sun Sep 30 2007 Daniel Veillard <veillard at redhat.com> - 0.3.3-1
- Release of 0.3.3
- Avahi support
- NUMA support
- lots of assorted improvements, bugfixes and cleanups
- documentation and localization improvements

logrotate-3.7.6-1.3.fc8
-----------------------
* Thu Sep 27 2007 Tomas Smetana <tsmetana at redhat.com> 3.7.6-1.3
- popt-devel dependency was still missing

* Thu Sep 27 2007 Tomas Smetana <tsmetana at redhat.com> 3.7.6-1.2
- add missing dependencies to spec file

lsof-4.78-6.fc8
---------------
* Tue Oct 02 2007 Karel Zak <kzak at redhat.com> 4.78-6
- fix #280651 - lsof prints entries in multiple lines when SElinux is disabled
- fix #243976 - mmap'd files with large inode numbers confuse lsof

lynx-2.8.6-6.fc8
----------------
* Tue Oct 02 2007 Ivana Varekova <varekova at redhat.com> - 2.8.6-6
- fix 311031 - fix argument parsing

makebootfat-1.4-6.fc8
---------------------
* Thu Sep 27 2007 Dmitry Butskoy <Dmitry at Butskoy.name> - 1.4-6
- always distribute own ldlinux.sys as well as ldlinux.bss
- add conditional macro %{new_ldlinux} (default off) to build the package
  with ldlinux.bss and ldlinux.sys taken from some syslinux source directly.
- Update README.usbboot .

* Fri Aug 17 2007 Dmitry Butskoy <Dmitry at Butskoy.name>
- Change License tag to GPLv2+

man-pages-ja-20070915-1.fc8
---------------------------
* Thu Sep 27 2007 Akira TAGOH <tagoh at redhat.com> - 20070915-1
- updates to 20070915.
  - remove man-pages-ja-222495-swapon.2.patch so that it's no longer needed.
- clean up the spec file.
- fix some warnings in perl script.

mesa-7.0.1-6.fc8
----------------
* Fri Sep 28 2007 Dave Airlie <airlied at redhat.com> 7.0.1-6
- mesa-7.0.1-stable-branch.patch - Updated to close to 7.0.2-rc1
- This contains the fixes made to the upstream Mesa stable branch
  including fixes for 965 vblank interrupt issues along with a fix
  in the kernel - remove patches that already upstream.
- mesa-6.5.2-hush-synthetic-visual-warning.patch - dropped
- mesa-7.0-i-already-defined-glapi-you-twit.patch - dropped
- mesa-7.0.1-965-sampler-crash.patch - dropped

metacity-2.20.0-2.fc8
---------------------
* Thu Sep 27 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-2
- Drop dep on redhat-artwork, add one on nodoka

mlton-20070826-10.fc8
---------------------
* Thu Sep 27 2007 Adam Goode <adam at spicenitz.org> - 20070826-10
- Disable bootstrap

* Thu Sep 27 2007 Adam Goode <adam at spicenitz.org> - 20070826-9
- Re-bootstrap ppc

* Wed Sep 26 2007 Adam Goode <adam at spicenitz.org> - 20070826-8
- Really fix SRPM conditionals

mugshot-1.1.55-1.fc8
--------------------
* Thu Sep 27 2007 Colin Walters <walters at redhat.com> - 1.1.55-1
- new upstream

* Thu Sep 20 2007 Colin Walters <walters at redhat.com> - 1.1.54-1
- new upstream

nautilus-2.20.0-3.fc8
---------------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-3
- Fix a crash with small fonts (#242350)

* Tue Oct 02 2007 Alexander Larsson <alexl at redhat.com> - 2.20.0-1
- Backport fixes for async thumbnail loading from svn

* Fri Sep 28 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-2
- drop redhat-artwork dep. Alex says we don't need it anymore

neverball-1.4.0-10.fc8
----------------------
* Sat Sep 29 2007 Wart <wart at kobold.org> - 1.4.0-10
- Add wrapper for detecting DRI when launching game (BZ #304811)

nodoka-theme-gnome-0.3.2-2.fc8
------------------------------
* Thu Sep 27 2007 Martin Sourada <martin.sourada at seznam.cz> - 0.3.2-2
- Require fedora-icon-theme instead of redhat-artwork (rhbz #309631)

notification-daemon-0.3.7-6.fc8
-------------------------------
* Wed Sep 26 2007 Matthias Clasen <mclasen at redhat.com> - 0.3.7-6
- Make it build with the latest intltool

* Wed Aug 08 2007 Matthias Clasen <mclasen at redhat.com> - 0.3.7-5
- Update the license field

nsd-3.0.6-5.fc8
---------------
* Tue Oct 02 2007 Paul Wouters <paul at xelerance.com> - 3.0.6-5
- nsdc update and nsdc notify are no longer needed in initscript.

nspluginwrapper-0.9.91.5-4.fc8
------------------------------
* Mon Oct 01 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-4
- quit the plugin when browser crashes (#290901)

nss_compat_ossl-0.9.2-2.fc8
---------------------------
* Wed Sep 26 2007 Rob Crittenden <rcritten at redhat.com> 0.9.2-2
- Bugzilla #306711, need to define CERT_NewTempCertificate

ode-0.9-0.1.rc1.fc8
-------------------
* Fri Sep 28 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.9-0.1.rc1
- New upstream release 0.9-rc1

online-desktop-0.2.18-1.fc8
---------------------------
* Tue Oct 02 2007 Colin Walters <walters at redhat.com> - 0.2.18-1
- new upstream

* Thu Sep 27 2007 Colin Walters <walters at redhat.com> - 0.2.17-1
- new upstream

osgal-1:0.6.1-1.fc8
-------------------
* Sat Sep 29 2007 Christopher Stone <chris.stone at gmail.com> 1:0.6.1-1
- Upstream sync
- Move openalpp-devel Requires to this package
- Obsolete/Provides openalpp
- Fix up some rpmlint warnings

osgcal-0.1.46-2.fc8
-------------------
* Sat Sep 29 2007 Christopher Stone <chris.stone at gmail.com> 0.1.46-2
- Update License
- Fix encoding on Changelog

* Sat Sep 29 2007 Christopher Stone <chris.stone at gmail.com> 0.1.46-1
- Upstream sync
- Remove no longer needed 64-bit patch
- Update source URL

* Tue Sep 11 2007 Christopher Stone <chris.stone at gmail.com> 0.1.45-1
- Upstream sync
- Update 64-bit patch

perl-Jcode-2.06-5.fc8
---------------------
* Thu Sep 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 2.06-5
- fix license (thanks Tom)

perl-MP3-Info-1.23-1.fc8
------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 1.23-1
- Upstream sync

perl-Net-Netmask-1.9015-1.fc8
-----------------------------
* Thu Sep 27 2007 Warren Togami <wtogami at redhat.com> - 1.9015-1
- 1.9015, update license tag

perl-Net-SNPP-1.17-5.fc8
------------------------
* Thu Sep 27 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.17-5
- More BR fixes.
perl-Unicode-Map-0.112-11.fc8
-----------------------------
* Thu Sep 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.112-11
- fix license tag (thanks Tom)

perl-Unicode-Map8-0.12-14.fc8
-----------------------------
* Thu Sep 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.12-14
- fix license tag again (thanks Tom)

perl-Unicode-MapUTF8-1.11-6.fc8
-------------------------------
* Thu Sep 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.11-6
- fix license tag again (thanks Tom)

perl-Unicode-String-2.09-5.fc8
------------------------------
* Thu Sep 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 2.09-5
- fix license tag again (thanks Tom)

php-pear-Net-UserAgent-Detect-2.4.0-1.fc8
-----------------------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 2.4.0-1
- Upstream sync
php-pecl-radius-1.2.5-2.fc8
---------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 1.2.5-2
- Update to new standards
php-pecl-xdebug-2.0.0-2.fc8
---------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 2.0.0-2
- Update to latest standards
- Fix encoding on Changelog

pidgin-2.2.1-1.fc8
------------------
* Mon Oct 01 2007 Warren Togami <wtogami at redhat.com> - 2.2.1-1
- 2.2.1 with many bug fixes and CVE-2007-4996 DOS fix

* Sat Sep 29 2007 Michel Salim <michel.sylvan at gmail.com> - 2.2.0-3
- Build against avahi proper instead of its HOWL compatibility layer

pikloops-0.2.4-1.fc8
--------------------
* Fri Sep 28 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.4-1
- New upstream version

pingus-0.7.1-1.fc8
------------------
* Sun Sep 30 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.7.1-1
- New upstream release 0.7.1

pirut-1.3.21-1.fc8
------------------
* Mon Oct 01 2007 Jeremy Katz <katzj at redhat.com> - 1.3.21-1
- Avoid showing empty warnings output (#312051)
- Fix some cd repo tracebacks found by wwoods

policycoreutils-2.0.27-6.fc8
----------------------------
* Tue Oct 02 2007 Dan Walsh <dwalsh at redhat.com> 2.0.27-6
- Update translations

* Tue Oct 02 2007 Dan Walsh <dwalsh at redhat.com> 2.0.27-5
- Additional checkboxes for application policy

* Fri Sep 28 2007 Dan Walsh <dwalsh at redhat.com> 2.0.27-4
- Allow policy writer to select user types to transition to there users

ppl-0.9-16.fc8
--------------
* Sat Sep 29 2007 Roberto Bagnara <bagnara at cs.unipr.it> 0.9-16
- The value of the `License' tag is now `GPLv2+'.
- `ppl-swiprolog' dependency on `readline-devel' removed (again).

* Mon Sep 24 2007 Jesse Keating <jkeating at redhat.com> 0.9-15
- Rebuild for new libgmpxx.

* Tue Aug 28 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> 0.9-14
- Rebuild for selinux ppc32 issue.

pulseaudio-0.9.7-0.15.svn20071001.fc8
-------------------------------------
* Mon Oct 01 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.7-0.15.svn20071001
- Another SVN snapshot, fixing another round of bugs

pungi-1.1.4-1.fc8
-----------------
* Tue Oct 02 2007 Jesse Keating <jkeating at redhat.com> - 1.1.4-1
- Make sure we use strings in the config object

* Wed Sep 26 2007 Jesse Keating <jkeating at redhat.com> - 1.1.3-1
- Pull in all the optional Virt stuff
- Don't expire the metadata from Media repo.

pv-1.1.0-2.fc8
--------------
* Sat Sep 15 2007 Jakub Hrozek <jhrozek at redhat.com> - 1.1.0-2
- Fix the license tag

* Sat Sep 15 2007 Jakub Hrozek <jhrozek at redhat.com> - 1.1.0-1
- Bump to the latest upstream

* Mon Aug 13 2007 Jakub Hrozek <jhrozek at redhat.com> - 1.0.1-1
- Bump to latest upstream

pybliographer-1.2.11-1.fc8
--------------------------
* Wed Sep 26 2007 Zoltan Kota <z.kota at gmx.net> - 1.2.11-1
- update to 1.2.11

pykickstart-1.15-1.fc8
----------------------
* Tue Oct 02 2007 Chris Lumens <clumens at redhat.com> 1.15-1
- Update translations (#259121).
- The device command no longer takes a type argument.

* Fri Sep 28 2007 Chris Lumens <clumens at redhat.com> 1.14-1
- Fix output formatting for packages section header (#310211).
- Add a script to flatten kickstart files containing includes (katzj).

python-adns-1.2.1-1.fc8
-----------------------
* Mon Oct 01 2007 Radek Vok??l <rvokal at redhat.com> - 1.2.1-1
- upgrade to 1.2.1
- fixed URL and Source

python-docutils-0.4-7.fc8
-------------------------
* Thu Sep 27 2007 Toshio Kuratomi <a.badger at gmail.com> 0.4-7
- Build egg info.

python-fpconst-0.7.3-1.fc8
--------------------------
* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 0.7.3-1
- Upstream sync
- Update source URL
- Some spec file cleanups

pyxf86config-0.3.34-1.fc8
-------------------------
* Wed Sep 26 2007 Adam Jackson <ajax at redhat.com> 0.3.34-1
- pyxf86config 0.3.34
- License is GPLv2
- Bump libxf86config-devel buildreq to pick up symbol visibility tweak

qgis-0.9.0-1.fc8
----------------
* Wed Sep 26 2007 Douglas E. Warner <silfreed at silfreed.net> 0.9.0-1
- update to 0.9.0
- remove settings-include-workdir.patch
- updated man-install-share.patch to man-install-share-0.9.0.patch
- updated lib64-suffix.patch to lib64-suffix-0.9.0.patch
- enabled python to support msexport tool
- added Requires: grass to grass subpackage

qwt-5.0.2-5.fc8
---------------
* Sat Sep 29 2007 Frank B??ttner <frank-buettner at gmx.net> - 5.0.2-5
- add EPEL support

* Sat Sep 29 2007 Frank B??ttner <frank-buettner at gmx.net> - 5.0.2-4
- remove parallel build, because it will fail sometimes

* Fri Sep 28 2007 Frank B??ttner <frank-buettner at gmx.net> - 5.0.2-3
- fix some errors in the spec file

readahead-1:1.4.2-1.fc8
-----------------------
* Mon Oct 01 2007 Karel Zak <kzak at redhat.com> 1:1.4.2-1
- upgrade to 1.4.2 (includes bug fixes only)
   - auparse requires as a record separator (#253226)
   - fix e-mail setting in Makevars  (#308271)
   - remove debug message (#237302)
   - improve init scripts  (#247044, #243685)
   - add pl.po

redhat-artwork-7.0.0-13.fc8
---------------------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 7.0.0-13
- Add a forgotten Provides

* Thu Sep 27 2007 Ray Strode <rstrode at redhat.com> - 7.0.0-12
- Add Provides to help with artwork split up

redhat-menus-8.9.11-1.fc8
-------------------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 8.9.11-1
- Move patches upstream
- Fix license field
- Spec file fixes

rhgb-0.17.7-1.fc8
-----------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 0.17.7-1
- Move all patches upstream
- Pull in new translations

rhythmbox-0.11.2-7.fc8
----------------------
* Tue Oct 02 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-7
- Add upstream patch to make the Upnp media store work (GNOME #482548)

rss-glx-0.8.1.p-13.fc8
----------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-13
- prefix binaries with "rss-glx-" (#250180)

* Mon Oct 01 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-12
- don't ship README.xscreensaver (#200881)

samba-0:3.0.26a-1.fc8
---------------------
* Tue Oct 02 2007 Simo Sorce <ssorce at redhat.com> 3.0.26a-1.fc8
- rebuild with AD DNS Update support

sane-backends-1.0.18-17.fc8
---------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 1.0.18-17
- disable pint backend (which doesn't build without some BSD specific headers)

* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 1.0.18-16
- enable dell1600n_net (#314081) and pint backends

scribes-0.3.2.9-1.fc8
---------------------
* Sun Sep 30 2007 Peter Gordon <peter at thecodergeek.com> - 0.3.2.9-1
- Update to new upstream release (0.3.2.9).
- Update License tag (GPLv2+).

selinux-policy-3.0.8-16.fc8
---------------------------
* Mon Oct 01 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-16
- Fix exim policy

* Mon Sep 24 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-15
- Allow tmpreadper to read man_t
- Allow racoon to bind to all nodes
- Fixes for finger print reader

setroubleshoot-1.10.7-1.fc8
---------------------------
* Tue Oct 02 2007 John Dennis <jdennis at redhat.com> - 1.10.7-1
- Fix spec file requires for opening an HTML page
	  In configure.ac search for xdg-open and htmlview in priority order,
	  set variable html_browser_open to the one found, in spec file require
	  xdg-utils for fedora and htmlview for RHEL.

	- add "Host" column in browser
	  add "Toggle Column Visibility" menu to toggle display of any column on/off

	- Resolves bug #310261: setroubleshoot notifications aren't throttled

	- add support for AUDIT_EOE, end-of-event, if AUDIT_EOE immediately
	  emit cached event. Disable timeouts used to flush events if
	  AUDIT_EOE has been seen.

* Wed Sep 26 2007 John Dennis <jdennis at redhat.com> - 1.10.6-1
- make selinx-policy requires in spec file specific to dist tag

sip-4.6-3.fc8
-------------
* Mon Oct 01 2007 Than Ngo <than at redhat.com> - 4.6-3
- fix rh#289321, sipconfig.py includes wrong py_lib_dir, thanks to Rex Dieter

* Thu Aug 30 2007 Than Ngo <than at redhat.com> - 4.6-2.fc7
- typo in description

* Thu Apr 12 2007 Than Ngo <than at redhat.com> - 4.6-1.fc7
- 4.6

smb4k-0.8.5-1.fc8
-----------------
* Thu Sep 27 2007 Marcin Garski <mgarski[AT]post.pl> 0.8.5-1
- Update to 0.8.5

smbldap-tools-0.9.4-1.fc8
-------------------------
* Wed Sep 26 2007 Paul Howarth <paul at city-fan.org> 0.9.4-1
- update to 0.9.4
- new upstream, new URLs
- drop useradd_option-o enhancement patch, new included upstream
- update config patch
- new script smbldap-userlist included
- convert docs to UTF-8
- HTML docs no longer included with upstream source
- make and include manpages

sqlite-3.4.2-3.fc8
------------------
* Fri Sep 28 2007 Panu Matilainen <pmatilai at redhat.com> - 3.4.2-3
- Add another build conditional for enabling %check

* Fri Sep 28 2007 Panu Matilainen <pmatilai at redhat.com> - 3.4.2-2
- Use bconds for the spec build conditionals
- Enable -tcl subpackage again (#309041)

stellarium-0.9.0-5.fc8
----------------------
* Wed Sep 26 2007 Jochen Schmitt <Jochen herr-schmitt de> 0.9.0-5
- Add usage of opengl-game-wrapper (BZ #304851)

struts-0:1.2.9-4jpp.9.fc8
-------------------------
* Thu Sep 27 2007 Deepak Bhole <dbhole at redhat.com> 1.2.9-4jpp.9
- Re-enable compliation of webapp classes, and disable run of check-buildroot

sylpheed-2.4.6-2
----------------
* Tue Oct 02 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.6-2
- Require xdg-utils and use xdg-open instead of gnome-open in defs.h
  patch.

system-config-date-1.9.10-1.fc8
-------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.10
- pick up updated translations

system-config-display-1.0.51-4.fc8
----------------------------------
* Mon Oct 01 2007 Adam Jackson <ajax at redhat.com> 1.0.51-4
- Un-Require: redhat-artwork, we don't actually require it. (#314001)

* Tue Jul 24 2007 Adam Jackson <ajax at redhat.com> 1.0.51-3
- Remove ppc64 from ExcludeArch.

system-config-firewall-1.0.8-1.fc8
----------------------------------
* Mon Oct 01 2007 Thomas Woerner <twoerner at redhat.com> 1.0.8-1
- use extension match for protocols (rhbz#229879)
- use ipv6-icmp instead of icmpv6 (rhbz#291001)
- use ':' in tui as port/proto delimiter for other ports (rhbz#292171)
- some translation fixes

system-config-nfs-1.3.28-1.fc8
------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.28
- pick up updated translations

* Mon Sep 10 2007 Nils Philippsen <nphilipp at redhat.com>
- make use of force tagging (since mercurial 0.9.4)

system-config-printer-0.7.74.4-1.fc8
------------------------------------
* Tue Oct 02 2007 Tim Waugh <twaugh at redhat.com> 0.7.74.4-1
- Changed PreReq to Requires.
- Mark console.apps file as a config file.
- Mark pam file as a config file (not replaceable).
- No need to ship empty NEWS file.
- Give cupsd.py executable permissions to satisfy rpmlint.
- Provides system-config-printer-gui.
- Mark D-Bus configuration file as a config file.
- Fixed libs summary.
- Better buildroot tag.
- Better defattr.
- Preserve timestamps on explicitly install files.
- Make example pycups program non-executable.
- 0.7.74.4:
  - Updated translations.
  - Several small bugs fixed.

* Thu Sep 27 2007 Tim Waugh <twaugh at redhat.com> 0.7.74.3-1
- 0.7.74.3:
  - Updated translations.
  - Other small bug fixes.

system-config-samba-1.2.53-1.fc8
--------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.53
- pick up updated translations

system-config-services-0.9.11-1.fc8
-----------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.11
- pick up updated translations

* Mon Sep 10 2007 Nils Philippsen <nphilipp at redhat.com>
- make use of force tagging (since mercurial 0.9.4)

system-config-users-1.2.68-1.fc8
--------------------------------
* Fri Sep 28 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.68
- remove po/POTFILES.in to appease transifex (#299811)
- pick up updated translations

system-switch-java-1.1.2-1.fc8
------------------------------
* Tue Oct 02 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 1.1.2-1
- Import system-switch-java 1.1.2.
- Resolves: rhbz#312321

* Fri Sep 28 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 1.1.1-1
- Import system-switch-java 1.1.1.

* Sat Jul 21 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 1.1.0-4
- Tolerate trailing newlines in alternatives file.
- Bump release number.

t1lib-5.1.1-3.fc8
-----------------
* Thu Sep 27 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 5.1.1-3
- Apply patch to fix CVE-2007-4033

taglib-1.5-0.5.20070924svn.fc8
------------------------------
* Thu Sep 27 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5-0.5.20070924svn
- -BR: automake 
- +BR: zlib-devel

* Thu Sep 27 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5-0.4.20070924svn
- use cmake, fixes "taglib_export.h not included" (#272361#c7)

tcldebugger-1.4-5.20061030cvs.fc8
---------------------------------
* Mon Oct 01 2007 Wart <wart at kobold.org> 1.4-5.20061030cvs
- Switch from htmlview to xdg-utils

telepathy-gabble-0.6.0-1.fc8
----------------------------
* Mon Oct 01 2007 Matej Cepl <mcepl at redhat.com> - 0.6.0-1
- New upstream version.

tellico-1.2.14-2.fc8
--------------------
* Thu Sep 27 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.2.14-2
- Declare new file (due to the fix for Fedora 7).

* Thu Sep 27 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.2.14-1
- New upstream version (fixes problem with settings not being saved on Fedora).

thunderbird-2.0.0.6-6.fc8
-------------------------
* Wed Sep 26 2007 Martin Stransky <stransky at redhat.com> 2.0.0.6-6
- Fixed #242657 - firefox -g doesn't work

tig-0.9.1-1.fc8
---------------
* Sun Sep 30 2007 James Bowes <jbowes at redhat.com> - 0.9.1-1
- tig-0.9.1

tremulous-1.1.0-5.fc8
---------------------
* Wed Sep 26 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.1.0-5
- Update syslibs patch to make the system libjpeg use tremulous' Malloc and
  Free functions, instead of the libc ones

tsclient-0.150-4.fc8
--------------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 0.150.4
- Require vnc, too (#158658)
- Fix license field

tzdata-2007h-1.fc8
------------------
* Mon Oct 01 2007 Petr Machata <pmachata at redhat.com> - 2007h-1
- Upstream 2007h
  - Brazil will observe DST from 2007-10-14 to 2008-02-17
  - Egypt and Gaza switched earlier than we expected
  - Iran will resume DST next year
  - Venezuela is scheduled to change TZ to -4:30 on January 1

vim-2:7.1.122-1.fc8
-------------------
* Wed Sep 26 2007 Karsten Hopp <karsten at redhat.com> 7.1.122-1
- patchlevel 122

vino-2.20.0-2.fc8
-----------------
* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Fix a directory ownership issue

xdg-user-dirs-gtk-0.6-2.fc8
---------------------------
* Mon Oct 01 2007 Matthias Clasen <mclasen at redhat.com> - 0.6-2
- Fix the special case for en_US  (#307881)

xeuphoric-0.18.2-9.fc8
----------------------
* Fri Sep 28 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.18.2-9
- Changed to exclusivearch %{ix86}. (BZ #310391)

* Tue Aug 21 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.18.2-8
- Release bump for F8 mass rebuild
- License change due to new guidelines

* Fri Jun 29 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.18.2-7
- Various cleanups to the SPEC including conforming to new guidelines
- Fix BZ #245091
- Additional .desktop files for other emulator models
- Encoding fixes for documentation
- Fixed installation of broken man page

xfsprogs-2.9.4-3.fc8
--------------------
* Tue Oct 02 2007 Eric Sandeen <sandeen at redhat.com> 2.9.4-3
- mkfs.xfs: Fix wiping old AG headers and purge whack buffers

* Mon Oct 01 2007 Eric Sandeen <sandeen at redhat.com> 2.9.4-2
- Add alpha to the multilib wrapper (#310411)

xkeyboard-config-1.1-2.fc8
--------------------------
* Wed Sep 26 2007 Matthias Clasen <mclasen at redhat.com> - 1.1-2
- Pick up the respun 1.1 release

xml-commons-apis-0:1.3.04-0jpp.1.fc8
------------------------------------
* Tue Mar 06 2007 Matt Wringe <mwringe at redhat.com> - 0:1.3.04-0jpp.1
- Update to 1.3.04

xorg-x11-drv-ati-6.7.194-2.fc8
------------------------------
* Fri Sep 28 2007 Dave Airlie <airlied at redhat.com> 6.7.194-2
- radeon-6.7.194-disable-rc410-dri.patch - Disable DRI on
  RC410 by default as it seems to need some more work.

xorg-x11-server-1.3.0.0-27.fc8
------------------------------
* Mon Oct 01 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-27
- BuildReq: mesa-source >= 7.0.1-5.

* Wed Sep 26 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-26
- xserver-1.3.0-randr-updates.patch: Default ModeDebug to TRUE, better to
  have too much information than too little.
- xorg-x11-server-1.0.1-fpic-libxf86config.patch: Build the parser library
  with hidden symbols to shrink pyf86config a bit.
- xserver-1.3.0-intel-by-default.patch: Use intel, not i810, when starting
  without a config file.
- Enable maintainer mode when building so I swear at autotools less.

* Wed Sep 26 2007 Dave Airlie <airlied at redhat.com> 1.3.0.0-25
- xserver-1.3.0-randr-updates.patch: Backport randr from server git
  This contains a lot of fixes since 1.3.0 went out, and saves
  us backporting each fix individually
- xserver-1.3.0-less-randr-fakerama.patch - dropped
- xorg-x11-server-1.2.0-maxpixclock-option.patch - dropped
- xserver-1.3.0-edid-quirk-backports.patch - dropped
- xserver-1.2.0-honor-displaysize.patch - dropped
- xserver-1.3.0-honor-displaysize.patch - reapply to new code layout
- xserver-1.3.0-randr12-config-hack.patch - rebased

xorg-x11-xfs-1:1.0.5-1.fc8
--------------------------
* Tue Oct 02 2007 Adam Jackson <ajax at redhat.com> 1:1.0.5-1
- xfs 1.0.5

xorg-x11-xtrans-devel-1.0.3-5.fc8
---------------------------------
* Mon Oct 01 2007 Adam Jackson <ajax at redhat.com> 1.0.3-5
- xtrans-1.0.3-avoid-gethostname.patch: Don't trust gethostname() output
  when building networkIds for AF_UNIX sockets.  Fixes application launch
  delays and failures when dhclient changes your hostname from under you.

xsane-0.994-4.fc8
-----------------

xscreensaver-1:5.03-9.fc8
-------------------------
* Tue Oct 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-9
- Change the default browser to xdg-open
- Don't mark XScreenSaver.ad as %config. This file is overwritten
  automatically.

yum-cron-0.5-1.fc8
------------------
* Sat Sep 29 2007 Alec Habig <ahabig at umn.edu> - 0.5-1
- Added a lockfile to prevent multiple instances of the cron scripts
  from running and hanging, see bug 311661

yumex-2.0.2-1.fc8
-----------------
* Fri Sep 28 2007 Tim Lauridsen <tla at rasmil.dk> - 2.0.2-1
- Release 2.0.2

z88dk-1.6-11.fc8.1
------------------
* Thu Sep 27 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.6-11.1
- no ppc64

* Thu Sep 27 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.6-11
- fix license tag (Artistic clarified)

Broken deps for i386
----------------------------------------------------------
	TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc64 requires gnome-python2-gtkmozembed
	TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
	aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
	anaconda - 11.3.0.36-1.ppc64 requires gnome-python2-gtkhtml2
	blogtk - 1.1-8.fc7.noarch requires gnome-python2-gtkhtml2
	elisa - 0.3.1-2.fc8.noarch requires gnome-python2-extras
	exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkhtml2
	exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkmozembed
	gimmie - 0.2.7-2.fc8.ppc64 requires gnome-python2-libegg
	gnochm - 0.9.10-1.fc8.noarch requires gnome-python2-gtkhtml2
	gnome-applets - 1:2.20.0-6.fc8.ppc64 requires gnome-python2-libegg
	gnome-blog - 0.9.1-5.fc7.noarch requires gnome-python2-gtkspell
	gramps - 2.2.8-3.fc8.noarch requires gnome-python2-gtkspell
	istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-libegg
	istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-extras
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-gtkhtml2
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-libegg
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-gtkmozembed
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-extras
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	quodlibet - 1.0-2.fc8.ppc64 requires gnome-python2-libegg
	scribes - 0.3.2.9-1.fc8.noarch requires gnome-python2-gtkspell >= 0:2.12
	setroubleshoot - 1.10.7-1.fc8.noarch requires gnome-python2-gtkhtml2
	solfege - 3.8.0-1.fc8.ppc64 requires gnome-python2-gtkhtml2
	sonata - 1.2.3-1.fc8.ppc64 requires gnome-python2-libegg
	straw - 0.27-9.fc8.noarch requires gnome-python2-gtkhtml2
	straw - 0.27-9.fc8.noarch requires gnome-python2-libegg
	wuja - 0.0.8-2.fc8.noarch requires gnome-python2-libegg >= 0:2.14.3
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From j.w.r.degoede at hhs.nl  Wed Oct  3 13:20:30 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 03 Oct 2007 15:20:30 +0200
Subject: rawhide report: 20071003 changes
In-Reply-To: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
References: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
Message-ID: <4703971E.9030308@hhs.nl>

Build System wrote:
> 
> Broken deps for i386
> ----------------------------------------------------------
> 	TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
> 	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
> 	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
> 	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
> 	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
> 	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
> 	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
> 	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
> 	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
> 	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
> 	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
> 	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
> 	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
> 
> 

About the kmods, didn't we decide to not do kmods anymore, shouldn't these be 
removed from the repo then?

Regards,

hans




From sundaram at fedoraproject.org  Wed Oct  3 13:34:04 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 03 Oct 2007 19:04:04 +0530
Subject: rawhide report: 20071003 changes
In-Reply-To: <4703971E.9030308@hhs.nl>
References: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
	<4703971E.9030308@hhs.nl>
Message-ID: <47039A4C.5020501@fedoraproject.org>

Hans de Goede wrote:

> 
> About the kmods, didn't we decide to not do kmods anymore, shouldn't 
> these be removed from the repo then?

The existing kmods have a grace period till Fedora 9 release. No more 
new ones would be introduced.

Rahul



From j.w.r.degoede at hhs.nl  Wed Oct  3 13:24:30 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 03 Oct 2007 15:24:30 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <200710031013.28627.gunchev@gmail.com>
References: <46F8F5E8.3000801@hhs.nl>
	<47015AF3.307@amiga-hardware.com>	<47025E42.2030604@hhs.nl>
	<200710031013.28627.gunchev@gmail.com>
Message-ID: <4703980E.8070101@hhs.nl>

Doncho N. Gunchev wrote:
> On Tuesday 2007-10-02 18:05:38 Hans de Goede wrote:
>> Ian Chapman wrote:
>>> Doncho N. Gunchev wrote:
>>>
>>>>> for all games just by exporting the environment variable.  Since you
>>>>> are asking for the games packages to use this by default, there needs
>>>>> to be a per-user way to disable the script action on multi-user
>>>>> configurations.
>>>> Why not a checkbox - don't show this warning again? If checked - touch
>>>> a file (say ~/.no_video_warning) and don't bother the user again.
>>>>
>>>> I think the user should be able to abort the game start, to start anyway
>>>> and to start anyway and never be bothered again.
>>>>
>>> +1
>>>
>>> To be fair I haven't see the script (yet) but that sounds a like a 
>>> sensible suggestion to me. The user should have the option of continuing 
>>> regardless, if they so choose, and not to be bothered again. This should 
>>> be as simple as possible and done graphically, ideally at launch time.
>>>
>> There are 2 issues with these train of thoughts:
>> 1) There really is no reason to want to run fullscreen OpenGL programs without
>>     hardware acceleration, they will not be usable <period>. If you don't
>>     believe me, try it!
> 
> I know, from a long time. Users *should* be able to see it with their own eyes.
> 
>> 2) The current wrapper uses zenity, so it cannot do the advenced kind of
>>     dialogs with a checkbox people ask for.
>>
> 
> Well... improvise:
> 
> ans=$(zenity  --list  --text "Your video..." --radiolist  --column "Pick"  \
> --column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
>  FALSE "Always run regardless"); echo $ans
> 

I don't think we want the "Never run such programs" option, as from then on 
such programs would silently fail. But other then that it might be ok. I would 
need to see it. If someone wants to spend some time on implementing this and it 
doesn't look horrible I would be more then happy to take a patch for this.

Please submit any patches through bugzilla.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Wed Oct  3 13:26:55 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 03 Oct 2007 15:26:55 +0200
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <1190996776.18404.4.camel@gibraltar.stuttgart.redhat.com>
References: <46F8F5E8.3000801@hhs.nl>	<1190722516.8399.1.camel@localhost.localdomain>
	<46F8FC8E.70906@hhs.nl>
	<1190996776.18404.4.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <4703989F.1040906@hhs.nl>

Nils Philippsen wrote:
> On Tue, 2007-09-25 at 14:18 +0200, Hans de Goede wrote:
>> G?rard Milmeister wrote:
>>> On Tue, 2007-09-25 at 13:50 +0200, Hans de Goede wrote:
>>>> This is esp. important for the Games Live DVD, as there people will
>>>> not have 
>>>> those other <beep> drivers available.
>>> I wonder if it makes any sense to include OpenGL games in such a Games
>>> Live DVD, that does not provide <beep> drivers.
>> Yes it does, as OpenGL games will work fine on all integrated intel graphics 
>> (lots of systems) and on all pre r5xx radeons (quite a few systems).
> 
> Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414
> 

Excellent example of both why we need the wrapper, and why we want to have 3D 
games on the games spin so people can check to see if things work in the store :)

>> And who knows, with Fedora 9 we might have radeon 3d support over the whole 
>> line, and nouveau 3d support for nvidea cards, and yes then we still want to 
>> have this check, as there will always be some unsupported cards.
> 
> BTW: I've looked at the (F7) version of the script. Does it work with
> AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
> indirect rendering and glxinfo should give "direct rendering: No". Then
> there's the issue of proprietary 3D drivers completely bypassing the
> DRI/DRM infrastructure.
> 

I currently can't get 3D desktop effects to work on either my i386 i810, or my 
x86_64 r300 machine. Is this a known problem? Could someone with working 3D 
desktop effects please check to see if opengl-games-utils works properly or 
not, and possibly come up with a patch to make it work in this scenario if 
necessary?

Thanks & Regards,

Hans




From katzj at redhat.com  Wed Oct  3 13:57:46 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 03 Oct 2007 09:57:46 -0400
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <20071003125713.31ba8619@htpc>
References: <4702D28F.1050705@fedoraproject.org> <20071003125713.31ba8619@htpc>
Message-ID: <1191419866.25097.58.camel@localhost.localdomain>

On Wed, 2007-10-03 at 12:57 +0200, Sebastian Vahl wrote:
> For KDE: knetworkmanager is probably gone for test3 because it isn't
> working with the newest networkmanager. We use nm-applet from
> Gnome as a replacement.
> See: https://bugzilla.redhat.com/show_bug.cgi?id=298991
> 
> Jeremy should confirm this before it gets into the release notes
> because he's the one implementing the needed changes for the livecd.

Yep, this is done.

Jeremy



From dakingun at gmail.com  Wed Oct  3 14:00:12 2007
From: dakingun at gmail.com (Deji Akingunola)
Date: Wed, 3 Oct 2007 10:00:12 -0400
Subject: rawhide report: 20071003 changes
In-Reply-To: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
References: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
Message-ID: <b80014de0710030700m399fb71fte8cd962d14b2a3fa@mail.gmail.com>

On 10/3/07, Build System <buildsys at redhat.com> wrote:

>
> gnome-python2-extras-2.19.1-6.fc8
> ---------------------------------
> * Fri Sep 28 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-6.fc8
> - Add a gnome-python2-gdl subpackage (RH bug #303141).
>
...
>
> Broken deps for ppc64
> ----------------------------------------------------------
>         Miro - 0.9.8.1-6.fc8.ppc64 requires gnome-python2-gtkmozembed
>         TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
>         aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
>         anaconda - 11.3.0.36-1.ppc64 requires gnome-python2-gtkhtml2
>         blogtk - 1.1-8.fc7.noarch requires gnome-python2-gtkhtml2
>         elisa - 0.3.1-2.fc8.noarch requires gnome-python2-extras
>         exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkhtml2
>         exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkmozembed
>         gimmie - 0.2.7-2.fc8.ppc64 requires gnome-python2-libegg
>         gnochm - 0.9.10-1.fc8.noarch requires gnome-python2-gtkhtml2
>         gnome-applets - 1:2.20.0-6.fc8.ppc64 requires gnome-python2-libegg
>         gnome-blog - 0.9.1-5.fc7.noarch requires gnome-python2-gtkspell
>         gramps - 2.2.8-3.fc8.noarch requires gnome-python2-gtkspell
>         istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-libegg
>         istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-extras

There is an issue with ppc64 builds missing for
gnome-python2-extras-2.19.1-6.fc8 sub-packages. A quick look at the
spec file in CVS reveals there is a 'ExcludeArch: ppc64' line for just
one of its sub-packages (gnome-python2-gdl), but that (seemingly)
caused ppc64 to be excluded for all them.

Deji



From dcbw at redhat.com  Wed Oct  3 13:59:57 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 03 Oct 2007 09:59:57 -0400
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <4702D28F.1050705@fedoraproject.org>
References: <4702D28F.1050705@fedoraproject.org>
Message-ID: <1191419997.15982.23.camel@localhost.localdomain>

On Wed, 2007-10-03 at 04:51 +0530, Rahul Sundaram wrote:
> Hi
> 
> Fedora 8 Test 3 has been pushed to mirrors and will be available as per 
> the release schedule. In the official announcement, we intend to list 
> any import changes as well as bugs and since I haven't been paying close 
> attention as before in between the last test release and this one, I 
> would love to get some help with that.
> 
> If you are a rawhide user and noticed any major changes after test 3 
> (new features, new packages, user visible things) and if there are major 
> issues that we need to highlight, do let me know either here or offlist. 
> Thanks.

NetworkManager has been bumped to a 0.7 SVN snapshot.

What's Awesome
----------------------------

* Faster connections
* Kill kill kill dhcdbdbddbbdbdbbdbd
* More reliable wireless connections
* Doesn't mash together wireless networks with the same SSID (but
different security, bands, or modes)
* Richer, saner D-Bus API (including introspection)


What Will Be Awesome in F8 (or soon thereafter)
-----------------------------------------------

* Static IPs (more than one if you like!)
* Custom DNS servers and search domains
* Better support for all the wireless security modes
* Multiple active device support (Internet connection sharing, woohoo!)
* A solid API and infrastructure to add stuff like Bluetooth DUN,
Bluetooth PAN, cellular broadband cards, etc
* Get connected when the system boots and don't have to wait for login


What's Busted Right Now (but will be fixed ASAP)
------------------------------------------------

* Does not support WEP passphrases
* Does not support WPA[2] Enterprise, IEEE801.X (Dynamic WEP), or LEAP
* Does not support hidden networks
* Does not autoconnect to last wireless network
* OpenVPN VPN plugin busted
* SELinux Enforcing mode is rocky




From ssorce at redhat.com  Wed Oct  3 14:07:39 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 03 Oct 2007 10:07:39 -0400
Subject: samba license change
Message-ID: <1191420459.8632.60.camel@localhost.localdomain>

Samba has changed it's license from GPLv2+ to GPLv3+
The license change affects version 3.2.0 (still a pre-release now).
In F-8 we will still have 3.0.X so the change affects F-9

Simo.




From j.w.r.degoede at hhs.nl  Wed Oct  3 13:53:46 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 03 Oct 2007 15:53:46 +0200
Subject: rawhide report: 20071003 changes
In-Reply-To: <b80014de0710030700m399fb71fte8cd962d14b2a3fa@mail.gmail.com>
References: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
	<b80014de0710030700m399fb71fte8cd962d14b2a3fa@mail.gmail.com>
Message-ID: <47039EEA.3000806@hhs.nl>

Deji Akingunola wrote:
> On 10/3/07, Build System <buildsys at redhat.com> wrote:
> 
>> gnome-python2-extras-2.19.1-6.fc8
>> ---------------------------------
>> * Fri Sep 28 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-6.fc8
>> - Add a gnome-python2-gdl subpackage (RH bug #303141).
>>
> ...
>> Broken deps for ppc64
>> ----------------------------------------------------------
>>         Miro - 0.9.8.1-6.fc8.ppc64 requires gnome-python2-gtkmozembed
>>         TnL-data - 070909-1.fc8.noarch requires TnL >= 0:070909
>>         aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
>>         anaconda - 11.3.0.36-1.ppc64 requires gnome-python2-gtkhtml2
>>         blogtk - 1.1-8.fc7.noarch requires gnome-python2-gtkhtml2
>>         elisa - 0.3.1-2.fc8.noarch requires gnome-python2-extras
>>         exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkhtml2
>>         exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkmozembed
>>         gimmie - 0.2.7-2.fc8.ppc64 requires gnome-python2-libegg
>>         gnochm - 0.9.10-1.fc8.noarch requires gnome-python2-gtkhtml2
>>         gnome-applets - 1:2.20.0-6.fc8.ppc64 requires gnome-python2-libegg
>>         gnome-blog - 0.9.1-5.fc7.noarch requires gnome-python2-gtkspell
>>         gramps - 2.2.8-3.fc8.noarch requires gnome-python2-gtkspell
>>         istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-libegg
>>         istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-extras
> 
> There is an issue with ppc64 builds missing for
> gnome-python2-extras-2.19.1-6.fc8 sub-packages. A quick look at the
> spec file in CVS reveals there is a 'ExcludeArch: ppc64' line for just
> one of its sub-packages (gnome-python2-gdl), but that (seemingly)
> caused ppc64 to be excluded for all them.
> 

AFAIK ExcludeArch is not per package, but global. The correct way would be to 
use %ifnarch surrounding the sub-package and %files list.

Regards,

Hans





From rc040203 at freenet.de  Wed Oct  3 14:25:24 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 03 Oct 2007 16:25:24 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1191421524.3395.172.camel@mccallum.corsepiu.local>

On Wed, 2007-10-03 at 14:09 +0200, Michael Schwendt wrote:
> On Wed, 3 Oct 2007 14:12:15 +0300 (EEST), Panu Matilainen wrote:
> 
> > >> ./configure: line 37448: cmp: command not found
> > >> ...
> > >> error: Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> > >> ...
> > >> RPM build errors:
> > >>     Bad exit status from /var/tmp/rpm-tmp.62964 (%build)
> > >> ...
> > >>
> > >>
> > >> Seemingly, "cmp" is in FC-7's default packages in koji, but not in
> > >> FC-7's mock.
> > >
> > > It's the same old "diffutils is missing" problem that has been found
> > > recently. Normally, "rpm-build" used to require "diffutils", because
> > > it uses diff in scripts like check-files. But the RPM update for
> > > F7 and FC6 has dropped the diffutils "Requires" (the %changelog does
> > > not mention that). The mock buildsys build-group pkg needs an
> > > update.
> > 
> > No it wasn't dropped from rpm-build, it never was there to begin with.
If rpm doesn't use these tools itself, then this would be, OK, otherwise
this would qualify as a bug.

> > diffutils has always been one of the implicit requirements (for no good 
> > reason IMO but that's another story) and has only been added recently to 
> > rawhide rpm.
Does rpm use it?

> Then we're back at the questions "who dropped diffutils from the
> buildsys build-groups for stable dists?" or "why is diffutils missing
> suddenly"?
IMO, without any doubt a buildsys. Why changes like these could have
made to hit the users, would be interesting to know.

Ralf




From jonathan.underwood at gmail.com  Wed Oct  3 14:38:53 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 3 Oct 2007 15:38:53 +0100
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <20071003131326.GD2557@free.fr>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
	<645d17210710030531s266e7047re9a375d6df40300e@mail.gmail.com>
	<20071003131326.GD2557@free.fr>
Message-ID: <645d17210710030738s12a9727hbe37410e8d7d5e3d@mail.gmail.com>

On 03/10/2007, Patrice Dumas <pertusus at free.fr> wrote:
> On Wed, Oct 03, 2007 at 01:31:48PM +0100, Jonathan Underwood wrote:
> > On 02 Oct 2007 13:12:31 -0500, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
> > > Issues pending FESCO ratification:
> > >  * Naming of TeX-related packages:
> > >   * http://www.redhat.com/archives/fedora-packaging/2007-September/msg00066.html
> > >   * Accepted (5 - 0)
> >
> > Presumably package names should be changed for F8?
>
> Certainly not. We are past test3, texlive is still not in, and it is not
> a big deal. Additionally, it would be nice to have the virtual provides
> also in, jindrich was inclined to add them, before we adjust the
> packages. F9 would be a more realistic target, in my opinion, without
> pressure on the maintainers to change names in case they have more
> important business to do.

OK, good - thanks for clarification.



From pertusus at free.fr  Wed Oct  3 14:42:33 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Oct 2007 16:42:33 +0200
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <645d17210710030738s12a9727hbe37410e8d7d5e3d@mail.gmail.com>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
	<645d17210710030531s266e7047re9a375d6df40300e@mail.gmail.com>
	<20071003131326.GD2557@free.fr>
	<645d17210710030738s12a9727hbe37410e8d7d5e3d@mail.gmail.com>
Message-ID: <20071003144233.GF2557@free.fr>

On Wed, Oct 03, 2007 at 03:38:53PM +0100, Jonathan Underwood wrote:
> On 03/10/2007, Patrice Dumas <pertusus at free.fr> wrote:
> 
> OK, good - thanks for clarification.

It is just my point of view, though... Maybe FESCo could have another
advice.

--
Pat



From tmz at pobox.com  Wed Oct  3 14:47:01 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 3 Oct 2007 10:47:01 -0400
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <1191421524.3395.172.camel@mccallum.corsepiu.local>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
	<1191421524.3395.172.camel@mccallum.corsepiu.local>
Message-ID: <20071003144701.GA26922@psilocybe.teonanacatl.org>

Ralf Corsepius wrote:
> On Wed, 2007-10-03 at 14:09 +0200, Michael Schwendt wrote:
>>>> It's the same old "diffutils is missing" problem that has been
>>>> found recently. Normally, "rpm-build" used to require
>>>> "diffutils", because it uses diff in scripts like check-files.
>>>> But the RPM update for F7 and FC6 has dropped the diffutils
>>>> "Requires" (the %changelog does not mention that). The mock
>>>> buildsys build-group pkg needs an update.
>>> 
>>> No it wasn't dropped from rpm-build, it never was there to begin
>>> with.
> If rpm doesn't use these tools itself, then this would be, OK,
> otherwise this would qualify as a bug.
> 
>>> diffutils has always been one of the implicit requirements (for no
>>> good reason IMO but that's another story) and has only been added
>>> recently to rawhide rpm.
> Does rpm use it?

Yes.  As Michael said above, diff is used in the check-files script
for one.  So it needs to require diffutils.

The problem is that this could have been coordinated better.  The
buildsys package for F-7 shouldn't have been updated until after an
updated rpm package with fixed BRs was pushed.

Should a ticket get filed with infrastructure regarding this?  Or has
one already been filed?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ah!  Useless!  Every one of you!  Fine.  I will defend myself and to
hell with all of you!
    -- Stewie Griffin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/3959e7df/attachment.sig>

From alexl at redhat.com  Wed Oct  3 14:54:33 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Wed, 03 Oct 2007 16:54:33 +0200
Subject: gnome-keyring issue, workaround
Message-ID: <1191423273.22332.50.camel@localhost.localdomain>

I fixed a gnome-keyring issue today where it would unset the default
keyring on logout. However, people running test versions could already
have had this happen to them.

If you have gnome-keyring problems, check the file
~/.gnome2/keyrings/default. It should contain the name of the default
keyring, which is typically "default". If it has size 0 you problably
ran into this bug. You can fix it by doing:

 echo -n default > ~/.gnome2/keyrings/default



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct  3 15:14:04 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 3 Oct 2007 17:14:04 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003144701.GA26922@psilocybe.teonanacatl.org>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
	<1191421524.3395.172.camel@mccallum.corsepiu.local>
	<20071003144701.GA26922@psilocybe.teonanacatl.org>
Message-ID: <20071003171404.527fb5de.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 3 Oct 2007 10:47:01 -0400, Todd Zullinger wrote:

> Ralf Corsepius wrote:
> > On Wed, 2007-10-03 at 14:09 +0200, Michael Schwendt wrote:
> >>>> It's the same old "diffutils is missing" problem that has been
> >>>> found recently. Normally, "rpm-build" used to require
> >>>> "diffutils", because it uses diff in scripts like check-files.
> >>>> But the RPM update for F7 and FC6 has dropped the diffutils
> >>>> "Requires" (the %changelog does not mention that). The mock
> >>>> buildsys build-group pkg needs an update.
> >>> 
> >>> No it wasn't dropped from rpm-build, it never was there to begin
> >>> with.
> > If rpm doesn't use these tools itself, then this would be, OK,
> > otherwise this would qualify as a bug.
> > 
> >>> diffutils has always been one of the implicit requirements (for no
> >>> good reason IMO but that's another story) and has only been added
> >>> recently to rawhide rpm.
> > Does rpm use it?
> 
> Yes.  As Michael said above, diff is used in the check-files script
> for one.  So it needs to require diffutils.
> 
> The problem is that this could have been coordinated better.  The
> buildsys package for F-7 shouldn't have been updated until after an
> updated rpm package with fixed BRs was pushed.
> 
> Should a ticket get filed with infrastructure regarding this?  Or has
> one already been filed?
> 

What coordination do you refer to? Look at this:

The "diffutils" pkg has been on the "Exceptions" list for a very long
time. Wiki tracks it back to 2005, which is even before FESCo carved
those guidelines into stone:

  Revision 22 as of 2005-04-23 22:25:17
  http://fedoraproject.org/wiki/Packaging/Guidelines?action=recall&rev=22#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30

It *still* is on that list. Why is it missing in buildroot configs
nowadays?

I do understand that some people have killed the very important
_expanded_ list of BR exceptions without much thought. But diffutils is
on the short (!) list of exceptions _explicitly_.



From wart at kobold.org  Wed Oct  3 15:19:43 2007
From: wart at kobold.org (Wart)
Date: Wed, 03 Oct 2007 08:19:43 -0700
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <4703989F.1040906@hhs.nl>
References: <46F8F5E8.3000801@hhs.nl>	<1190722516.8399.1.camel@localhost.localdomain>	<46F8FC8E.70906@hhs.nl>	<1190996776.18404.4.camel@gibraltar.stuttgart.redhat.com>
	<4703989F.1040906@hhs.nl>
Message-ID: <4703B30F.8030307@kobold.org>

Hans de Goede wrote:
> Nils Philippsen wrote:
>> On Tue, 2007-09-25 at 14:18 +0200, Hans de Goede wrote:
>>> And who knows, with Fedora 9 we might have radeon 3d support over the 
>>> whole line, and nouveau 3d support for nvidea cards, and yes then we 
>>> still want to have this check, as there will always be some 
>>> unsupported cards.
>>
>> BTW: I've looked at the (F7) version of the script. Does it work with
>> AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
>> indirect rendering and glxinfo should give "direct rendering: No". Then
>> there's the issue of proprietary 3D drivers completely bypassing the
>> DRI/DRM infrastructure.
>>
> 
> I currently can't get 3D desktop effects to work on either my i386 i810, 
> or my x86_64 r300 machine. Is this a known problem? Could someone with 
> working 3D desktop effects please check to see if opengl-games-utils 
> works properly or not, and possibly come up with a patch to make it work 
> in this scenario if necessary?

On my F-7 x86_64 desktop with binary nvidia drivers and Desktop Effects 
enabled (AIGLX), glxinfo still returns 'direct rendering: Yes'.

--Wart



From rhlists at bellsouth.net  Wed Oct  3 15:23:00 2007
From: rhlists at bellsouth.net (Bob)
Date: Wed, 03 Oct 2007 15:23:00 +0000
Subject: Alpine
Message-ID: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>

What is the status of Alpine?  Everyone know and then I hear a word or two about it but is there any chance it will ever make it out of development?  

Thanks

Bob



From wwoods at redhat.com  Wed Oct  3 15:26:29 2007
From: wwoods at redhat.com (Will Woods)
Date: Wed, 03 Oct 2007 11:26:29 -0400
Subject: Problems with clock in f8t2
In-Reply-To: <18179.30774.903928.719824@zebedee.pink>
References: <18179.30774.903928.719824@zebedee.pink>
Message-ID: <1191425189.3020.5.camel@metroid.rdu.redhat.com>

On Wed, 2007-10-03 at 12:08 +0100, Andrew Haley wrote:
> There seems to be some problem with the system clock with f8t2.  In
> particular, setting the clock via ntp no longer works.
> 
> Like this:
> 
> zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
>  3 Oct 12:03:52 ntpdate[17063]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
>  3 Oct 12:03:56 ntpdate[17063]: step time server 134.34.3.18 offset -372.433774 sec
> zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
>  3 Oct 12:04:01 ntpdate[17064]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
>  3 Oct 12:04:05 ntpdate[17064]: step time server 134.34.3.18 offset -372.458162 sec
> 
> The kernel:
> 
> 2.6.23-0.164.rc5.fc8 #1 SMP Tue Sep 4 18:24:12 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> 
> Is anyone else seeing this?

That kernel is old - we had some rtc / clock problems up until .211 or
so. You should probably upgrade and try again.

-w
-------------- 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/20071003/05605219/attachment.sig>

From jima at beer.tclug.org  Wed Oct  3 15:35:25 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 3 Oct 2007 10:35:25 -0500 (CDT)
Subject: Alpine
In-Reply-To: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
References: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
Message-ID: <Pine.LNX.4.64.0710031033160.4486@beer.tclug.org>

On Wed, 3 Oct 2007, Bob wrote:
> What is the status of Alpine?  Everyone know and then I hear a word or 
> two about it but is there any chance it will ever make it out of 
> development?

  *blink*  Huh.  I thought Joshua had branched it for at least F-7.  I 
guess I'll have to see if there's any reason not to.

      Jima
(Alpine comaintainer)



From tmz at pobox.com  Wed Oct  3 15:38:51 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 3 Oct 2007 11:38:51 -0400
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003171404.527fb5de.mschwendt.tmp0701.nospam@arcor.de>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
	<1191421524.3395.172.camel@mccallum.corsepiu.local>
	<20071003144701.GA26922@psilocybe.teonanacatl.org>
	<20071003171404.527fb5de.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071003153850.GB26922@psilocybe.teonanacatl.org>

Michael Schwendt wrote:
> What coordination do you refer to? Look at this:
> 
> The "diffutils" pkg has been on the "Exceptions" list for a very long
> time. Wiki tracks it back to 2005, which is even before FESCo carved
> those guidelines into stone:
> 
>  Revision 22 as of 2005-04-23 22:25:17
>  http://fedoraproject.org/wiki/Packaging/Guidelines?action=recall&rev=22#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30
> 
> It *still* is on that list. Why is it missing in buildroot configs
> nowadays?

Bah, my mistake.  I had thought (for some unknown reason) that
diffutils had been removed from the short list and that's why it
disappeared from the buildsys-build package.

So it's just a plain old bug in the buildsys-build package that
diffutils isn't required anymore.  I asked this last week sometime
and never got any replies... Where is the srpm or cvs for the
buildsys-build package?  And should bugs in this package be reported
to the infrastructure ticketing system or somewhere else?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If barbie is so popular, why do you have to buy her friends?
    -- Jack Handy

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

From mjs at CLEMSON.EDU  Wed Oct  3 15:48:18 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Wed, 03 Oct 2007 11:48:18 -0400
Subject: Notes for Fedora 8 Test 3
In-Reply-To: <1191419866.25097.58.camel@localhost.localdomain>
References: <4702D28F.1050705@fedoraproject.org> <20071003125713.31ba8619@htpc>
	<1191419866.25097.58.camel@localhost.localdomain>
Message-ID: <1191426498.14519.2.camel@vincent52.localdomain>

On Wed, 2007-10-03 at 09:57 -0400, Jeremy Katz wrote:
> On Wed, 2007-10-03 at 12:57 +0200, Sebastian Vahl wrote:
> > For KDE: knetworkmanager is probably gone for test3 because it isn't
> > working with the newest networkmanager. We use nm-applet from
> > Gnome as a replacement.
> > See: https://bugzilla.redhat.com/show_bug.cgi?id=298991
> > 
> > Jeremy should confirm this before it gets into the release notes
> > because he's the one implementing the needed changes for the livecd.
> 
> Yep, this is done.

The general state of NetworkManager--the move from 0.6.5 to 0.7 and the
unfinished state of 0.7 (can't "connect to other" or "create new", can't
configure VPN connections, etc.) are worth warning people about.

> 
> Jeremy
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From aph at redhat.com  Wed Oct  3 15:53:54 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 3 Oct 2007 16:53:54 +0100
Subject: Problems with clock in f8t2
In-Reply-To: <1191425189.3020.5.camel@metroid.rdu.redhat.com>
References: <18179.30774.903928.719824@zebedee.pink>
	<1191425189.3020.5.camel@metroid.rdu.redhat.com>
Message-ID: <18179.47890.620147.415475@zebedee.pink>

Will Woods writes:
 > On Wed, 2007-10-03 at 12:08 +0100, Andrew Haley wrote:
 > > There seems to be some problem with the system clock with f8t2.  In
 > > particular, setting the clock via ntp no longer works.
 > > 
 > > Like this:
 > > 
 > > zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
 > >  3 Oct 12:03:52 ntpdate[17063]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
 > >  3 Oct 12:03:56 ntpdate[17063]: step time server 134.34.3.18 offset -372.433774 sec
 > > zorro:gcc $ sudo ntpdate -v -b 1.fedora.pool.ntp.org
 > >  3 Oct 12:04:01 ntpdate[17064]: ntpdate 4.2.4p2 at 1.1495-o Tue Aug 21 13:51:59 UTC 2007 (1)
 > >  3 Oct 12:04:05 ntpdate[17064]: step time server 134.34.3.18 offset -372.458162 sec
 > > 
 > > The kernel:
 > > 
 > > 2.6.23-0.164.rc5.fc8 #1 SMP Tue Sep 4 18:24:12 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
 > > 
 > > Is anyone else seeing this?
 > 
 > That kernel is old - we had some rtc / clock problems up until .211 or
 > so. You should probably upgrade and try again.
 
Yea, fixed.  Here was me trying to test f8t2.  Silly me.  :-)

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From pemboa at gmail.com  Wed Oct  3 15:54:20 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 3 Oct 2007 10:54:20 -0500
Subject: Default Firefox settings
Message-ID: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>

Hello,

I recently asked about ways to benchmark Firefox[1] because of how
slow I found Firefox to be  on Fedora 7. It was almost unusably slow,
prompting me to switch to Konqueror as much as possible.

However I have found a short tutorial which after following the speed
seems to at least be on par which my laptop (which has half the
processing speed, and a slower, IDE hard drive, and slower memory)

Assuming I haven't encountered some freak situation, it may be
necessary to consider changing the default Firefox settings, one of
which is IPV6 DNS. I have zero issues against IPV6 myself, but if it
helps make Firefox useful, by all means.

Again, if I can provide any objective metrics, please let me know.

[1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html
[2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From ville.skytta at iki.fi  Wed Oct  3 16:15:17 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 3 Oct 2007 19:15:17 +0300
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <20071003144233.GF2557@free.fr>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
	<645d17210710030738s12a9727hbe37410e8d7d5e3d@mail.gmail.com>
	<20071003144233.GF2557@free.fr>
Message-ID: <200710031915.18279.ville.skytta@iki.fi>

On Wednesday 03 October 2007, Patrice Dumas wrote:
> On Wed, Oct 03, 2007 at 03:38:53PM +0100, Jonathan Underwood wrote:
> > On 03/10/2007, Patrice Dumas <pertusus at free.fr> wrote:
> >
> > OK, good - thanks for clarification.
>
> It is just my point of view, though... Maybe FESCo could have another
> advice.

I think targeting F9 for renaming existing packages but starting to apply the 
new guidelines already now for new to-be-introduced packages makes sense.  
(Clarification: I'm not in FESCo, am in FPC, but speaking for myself only.)



From ajackson at redhat.com  Wed Oct  3 16:01:12 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 03 Oct 2007 12:01:12 -0400
Subject: rawhide report: 20071003 changes
In-Reply-To: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
References: <200710031325.l93DPJqt009149@porkchop.devel.redhat.com>
Message-ID: <1191427272.31421.138.camel@localhost.localdomain>

On Wed, 2007-10-03 at 09:25 -0400, Build System wrote:

> xorg-x11-server-1.3.0.0-27.fc8
> ------------------------------
> * Mon Oct 01 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-27
> - BuildReq: mesa-source >= 7.0.1-5.

This is broken on at least some intel(4) configurations, as in, X won't
start at all.

Fix available:

http://koji.fedoraproject.org/koji/buildinfo?buildID=20093

- ajax



From pertusus at free.fr  Wed Oct  3 16:18:46 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 3 Oct 2007 18:18:46 +0200
Subject: Summary of the 2007-10-02 Packaging Committee meeting
In-Reply-To: <200710031915.18279.ville.skytta@iki.fi>
References: <ufa1wcde67k.fsf@epithumia.math.uh.edu>
	<645d17210710030738s12a9727hbe37410e8d7d5e3d@mail.gmail.com>
	<20071003144233.GF2557@free.fr>
	<200710031915.18279.ville.skytta@iki.fi>
Message-ID: <20071003161846.GH2557@free.fr>

On Wed, Oct 03, 2007 at 07:15:17PM +0300, Ville Skytt? wrote:
> 
> I think targeting F9 for renaming existing packages but starting to apply the 
> new guidelines already now for new to-be-introduced packages makes sense.  
> (Clarification: I'm not in FESCo, am in FPC, but speaking for myself only.)

Also speaking for myself, but I agree. New packages should follow
new guidelines, indeed.

--
Pat



From ivazqueznet at gmail.com  Wed Oct  3 16:31:45 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 03 Oct 2007 12:31:45 -0400
Subject: fedora-release fedora-release.spec,1.54,1.55
In-Reply-To: <200710031604.l93G46eT015031@cvs-int.fedora.redhat.com>
References: <200710031604.l93G46eT015031@cvs-int.fedora.redhat.com>
Message-ID: <1191429105.13400.32.camel@ignacio.lan>

On Wed, 2007-10-03 at 12:04 -0400, Jesse Keating wrote:
> Author: jkeating
> 
> Update of /cvs/fedora/fedora-release
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14970
> 
> Modified Files:
> 	fedora-release.spec 
> Log Message:
> First release for 9

> -Version:	7.92
> +Version:	8.90

Isn't this supposed to be 8.89?

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071003/91362c5d/attachment.sig>

From bpepple at fedoraproject.org  Wed Oct  3 16:40:37 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 03 Oct 2007 12:40:37 -0400
Subject: Plan for tomorrows (20071004) FESCO meeting
Message-ID: <1191429637.14575.4.camel@kennedy>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic FESCo meeting -- Any objection to this week's report from FPC at
https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00081.html

/topic Status Update: Compat Policy
http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy

/topic Status Update: FESCo Proposal Template - f13

/topic FESCo meeting -- Free discussion around Fedora

There's not much on the schedule for tomorrow so if you want something
to be discussed, send a note to the list in reply to this mail and I'll
add it to the schedule.  You can also propose topics in the meeting
while it is in the "Free discussion around Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071003/2185dc34/attachment.sig>

From orion at cora.nwra.com  Wed Oct  3 16:43:50 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 03 Oct 2007 10:43:50 -0600
Subject: Alpine
In-Reply-To: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
References: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
Message-ID: <4703C6C6.3040409@cora.nwra.com>

Bob wrote:
> What is the status of Alpine?  Everyone know and then I hear a word or two about it but is there any chance it will ever make it out of development?  
> 
> Thanks
> 
> Bob
> 

I've compiled the src.rpm on EL-5 and have been using it there without 
issue.  Would be nice to see an epel release.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct  3 16:52:33 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 3 Oct 2007 18:52:33 +0200
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003153850.GB26922@psilocybe.teonanacatl.org>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
	<1191421524.3395.172.camel@mccallum.corsepiu.local>
	<20071003144701.GA26922@psilocybe.teonanacatl.org>
	<20071003171404.527fb5de.mschwendt.tmp0701.nospam@arcor.de>
	<20071003153850.GB26922@psilocybe.teonanacatl.org>
Message-ID: <20071003185233.5b535043.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 3 Oct 2007 11:38:51 -0400, Todd Zullinger wrote:

> Michael Schwendt wrote:
> > What coordination do you refer to? Look at this:
> > 
> > The "diffutils" pkg has been on the "Exceptions" list for a very long
> > time. Wiki tracks it back to 2005, which is even before FESCo carved
> > those guidelines into stone:
> > 
> >  Revision 22 as of 2005-04-23 22:25:17
> >  http://fedoraproject.org/wiki/Packaging/Guidelines?action=recall&rev=22#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30
> > 
> > It *still* is on that list. Why is it missing in buildroot configs
> > nowadays?
> 
> Bah, my mistake.  I had thought (for some unknown reason) that
> diffutils had been removed from the short list and that's why it
> disappeared from the buildsys-build package.
> 
> So it's just a plain old bug in the buildsys-build package that
> diffutils isn't required anymore.

http://buildsys.fedoraproject.org/buildgroups/6/i386/

buildsys-build-0.5-1.noarch.rpm from June 2006 "Requires: diffutils",
because it requires the list of Exceptions from the guidelines.

> I asked this last week sometime
> and never got any replies... Where is the srpm or cvs for the
> buildsys-build package?  And should bugs in this package be reported
> to the infrastructure ticketing system or somewhere else?

The buildsys-build spec is included in mock as %doc file.
diffutils is an R there, too, since at least June 2006.



From kanarip at kanarip.com  Wed Oct  3 17:04:56 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 03 Oct 2007 19:04:56 +0200
Subject: Default Firefox settings
In-Reply-To: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
Message-ID: <4703CBB8.5060109@kanarip.com>

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

Arthur Pemberton wrote:
> Hello,
> 
> I recently asked about ways to benchmark Firefox[1] because of how
> slow I found Firefox to be  on Fedora 7. It was almost unusably slow,
> prompting me to switch to Konqueror as much as possible.
> 
> However I have found a short tutorial which after following the speed
> seems to at least be on par which my laptop (which has half the
> processing speed, and a slower, IDE hard drive, and slower memory)
> 
> Assuming I haven't encountered some freak situation, it may be
> necessary to consider changing the default Firefox settings, one of
> which is IPV6 DNS. I have zero issues against IPV6 myself, but if it
> helps make Firefox useful, by all means.
> 

Does upstream think the default settings as provided in the vanilla
distribution should be adjusted as set forth in [2] ? If they don't, I
think we shouldn't either.

> Again, if I can provide any objective metrics, please let me know.
> 
> [1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html
> [2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu
> 

Kind regards,

Jeroen van Meeuwen
- -kanarip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHA8u4KN6f2pNCvwgRAgYiAJ929YYrJhgeTrjaatAvNdJdsQISZwCg0cmW
5ZomvUCCswashuY/N66qEuI=
=Bxa1
-----END PGP SIGNATURE-----



From davej at redhat.com  Wed Oct  3 17:06:02 2007
From: davej at redhat.com (Dave Jones)
Date: Wed, 3 Oct 2007 13:06:02 -0400
Subject: Latest kernel still has Bonding bug report on startup!
In-Reply-To: <47021F17.7060806@cohtech.com>
References: <47021F17.7060806@cohtech.com>
Message-ID: <20071003170602.GB32239@redhat.com>

On Tue, Oct 02, 2007 at 11:36:07AM +0100, Howard Wilkinson wrote:
 > I reported a bug against a previous version of the kernel with the 
 > bonding network interface - somebody else raised the bug. I have just 
 > installed the latest development kernel and it still reports a problem. 
 > Dmesg trace attached.

Thanks. Forwarded to relevant upstream developers.

	Dave

-- 
http://www.codemonkey.org.uk



From tmz at pobox.com  Wed Oct  3 17:06:40 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 3 Oct 2007 13:06:40 -0400
Subject: FC-7 mockbuild fails/koji build succeeds
In-Reply-To: <20071003185233.5b535043.mschwendt.tmp0701.nospam@arcor.de>
References: <1191386564.3395.146.camel@mccallum.corsepiu.local>
	<20071003110022.c6092737.mschwendt.tmp0701.nospam@arcor.de>
	<alpine.DEB.0.9999.0710031358540.31518@gotcha.dreamhost.com>
	<20071003140900.f8fe6cb0.mschwendt.tmp0701.nospam@arcor.de>
	<1191421524.3395.172.camel@mccallum.corsepiu.local>
	<20071003144701.GA26922@psilocybe.teonanacatl.org>
	<20071003171404.527fb5de.mschwendt.tmp0701.nospam@arcor.de>
	<20071003153850.GB26922@psilocybe.teonanacatl.org>
	<20071003185233.5b535043.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071003170640.GE26922@psilocybe.teonanacatl.org>

Michael Schwendt wrote:
>> I asked this last week sometime and never got any replies... Where
>> is the srpm or cvs for the buildsys-build package?  And should bugs
>> in this package be reported to the infrastructure ticketing system
>> or somewhere else?
> 
> The buildsys-build spec is included in mock as %doc file.  diffutils
> is an R there, too, since at least June 2006.

Yeah, but that spec is for 0.7.6-1, which is not what's currently at
http://buildsys.fedoraproject.org/buildgroups/7/i386/.  There,
0.8-1.fc7 is the latest, and there's no spec or srpm.  I was curious
to find out where the package is maintained to check the commit logs
for a hint as to why diffutils went away.  Hopefully Dennis will
notice this thread and comment (I copied him on one of my previous
messages).

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I figure that if God actually does exist, He's big enough to
understand an honest difference of opinion.
    -- Isaac Asimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/2a29e61e/attachment.sig>

From jkeating at redhat.com  Wed Oct  3 17:23:00 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 3 Oct 2007 13:23:00 -0400
Subject: fedora-release fedora-release.spec,1.54,1.55
In-Reply-To: <1191429105.13400.32.camel@ignacio.lan>
References: <200710031604.l93G46eT015031@cvs-int.fedora.redhat.com>
	<1191429105.13400.32.camel@ignacio.lan>
Message-ID: <20071003132300.32c56a68@redhat.com>

On Wed, 03 Oct 2007 12:31:45 -0400
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:

> Isn't this supposed to be 8.89?

Nah, we decided to stop counting like computers as it was confusing.
8.90 is pre-test1, 8.91 is test1 (see how the 1s match up?) 8.92 is
test2, etc....

Just part of an overall effort to be a bit less confusing.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/91466d55/attachment.sig>

From caillon at redhat.com  Wed Oct  3 17:19:35 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 03 Oct 2007 13:19:35 -0400
Subject: Default Firefox settings
In-Reply-To: <4703CBB8.5060109@kanarip.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
Message-ID: <4703CF27.4000002@redhat.com>

Jeroen van Meeuwen wrote:
> Does upstream think the default settings as provided in the vanilla
> distribution should be adjusted as set forth in [2] ? If they don't, I
> think we shouldn't either.

Several of the preference tweaks will indeed enhance performance for a 
reasonably large percentage of websites but will cause a not 
insignificant number to break.  (By refusing to load, hanging the 
browser, etc.)  The prefs are generally that way for a good reason.



From rdieter at math.unl.edu  Wed Oct  3 17:39:22 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 03 Oct 2007 12:39:22 -0500
Subject: Alpine
References: <100320071523.19045.4703B3D40001993B00004A6522216125569B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
	<Pine.LNX.4.64.0710031033160.4486@beer.tclug.org>
Message-ID: <fe0k4a$mq4$1@sea.gmane.org>

Jima wrote:

> On Wed, 3 Oct 2007, Bob wrote:
>> What is the status of Alpine?  Everyone know and then I hear a word or
>> two about it but is there any chance it will ever make it out of
>> development?
> 
>   *blink*  Huh.  I thought Joshua had branched it for at least F-7.  I
> guess I'll have to see if there's any reason not to.

I think the rationale was to wait for 1.0 before releasing for anything !=
devel/

(not that I agree with that, I'm just the messenger).

-- Rex



From rhlists at bellsouth.net  Wed Oct  3 18:08:40 2007
From: rhlists at bellsouth.net (Bob)
Date: Wed, 03 Oct 2007 18:08:40 +0000
Subject: Alpine
Message-ID: <100320071808.27075.4703DAA8000CEC55000069C322230680329B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>

>From: Joshua Daniel Franklin <joshuadfranklin at yahoo.com>
>
> --- Jima wrote:
> 
> > On Wed, 3 Oct 2007, Bob wrote:
> > > What is the status of Alpine?  Everyone know and then I hear a word or 
> > > two about it but is there any chance it will ever make it out of 
> > > development?
> > 
> >   *blink*  Huh.  I thought Joshua had branched it for at least F-7.  I 
> > guess I'll have to see if there's any reason not to.
> 
> I only branched for dev (in time for F-8 too) until the 
> Alpine 1.0 release. I think there are still a number of 
> significant bugs being worked out. However, if you'd like 
> to branch feel free as you're the co-maintainer. :)
> 
> That said, the built RPM works fine for me (well, occasional
> crash when scrolling through large folders):
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=18087
> 

No problem, I can wait.  I was just looking to get an idea where it was.

Thanks for the update!

I second the suggestion of including it in EPEL...

BOb



From pemboa at gmail.com  Wed Oct  3 18:15:53 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 3 Oct 2007 13:15:53 -0500
Subject: Default Firefox settings
In-Reply-To: <4703CBB8.5060109@kanarip.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
Message-ID: <16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>

On 10/3/07, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Arthur Pemberton wrote:
> > Hello,
> >
> > I recently asked about ways to benchmark Firefox[1] because of how
> > slow I found Firefox to be  on Fedora 7. It was almost unusably slow,
> > prompting me to switch to Konqueror as much as possible.
> >
> > However I have found a short tutorial which after following the speed
> > seems to at least be on par which my laptop (which has half the
> > processing speed, and a slower, IDE hard drive, and slower memory)
> >
> > Assuming I haven't encountered some freak situation, it may be
> > necessary to consider changing the default Firefox settings, one of
> > which is IPV6 DNS. I have zero issues against IPV6 myself, but if it
> > helps make Firefox useful, by all means.
> >
>
> Does upstream think the default settings as provided in the vanilla
> distribution should be adjusted as set forth in [2] ? If they don't, I
> think we shouldn't either.
>
> > Again, if I can provide any objective metrics, please let me know.
> >
> > [1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html
> > [2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu
> >
>
> Kind regards,
>
> Jeroen van Meeuwen
> - -kanarip


Fair enough, but the speed differences cannot be ignored. Nor is the
fact that it makes Firefox (at least on Fedora) to seem very slow.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From oliver at linux-kernel.at  Wed Oct  3 18:36:36 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 03 Oct 2007 20:36:36 +0200
Subject: pungi, python and the question: where are the python gurus?
In-Reply-To: <20071003073244.538e9091@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>	<4703669C.2060600@linux-kernel.at>
	<20071003073244.538e9091@redhat.com>
Message-ID: <4703E134.5090601@linux-kernel.at>

Jesse Keating schrieb:
> On Wed, 03 Oct 2007 11:53:32 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
> 
>> pykickstart-1.2-2.fc8
> 
> This is likely your problem.  pykickstart-1.13-1.fc8 was current when I
> did my test.

OK. Will try newer version.

Thx,
 Oliver



From cra at WPI.EDU  Wed Oct  3 18:52:56 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 3 Oct 2007 14:52:56 -0400
Subject: Default Firefox settings
In-Reply-To: <16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
Message-ID: <20071003185256.GM6066@angus.ind.WPI.EDU>

On Wed, Oct 03, 2007 at 01:15:53PM -0500, Arthur Pemberton wrote:
> > Does upstream think the default settings as provided in the vanilla
> > distribution should be adjusted as set forth in [2] ? If they don't, I
> > think we shouldn't either.
> >
> > > Again, if I can provide any objective metrics, please let me know.
> > >
> > > [1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html
> > > [2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu
> 
> Fair enough, but the speed differences cannot be ignored. Nor is the
> fact that it makes Firefox (at least on Fedora) to seem very slow.

Actually, I use IPv6 here and it isn't the cause of Firefox slowness.  
My biggest problem is simply rendering speed.  It is excruciatingly 
slow in scrolling an already loaded web page.

On the bright side, for whatever reason the F8 version of Firefox 
seems much faster.  Can anyone explain what might have changed?



From oliver at linux-kernel.at  Wed Oct  3 20:36:20 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 03 Oct 2007 22:36:20 +0200
Subject: short koji repo question
In-Reply-To: <20071003073244.538e9091@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>	<4703669C.2060600@linux-kernel.at>
	<20071003073244.538e9091@redhat.com>
Message-ID: <4703FD44.4060708@linux-kernel.at>

Hi!

Is there any good reason, why koji doesn't also create the sqlite
database with createrepo (passing -d option)?

For slow arches, it would speed up the init phase of the build-root...
For the fast arches, well it would also be faster I think...

If someone is going to change/try that. Let me know the progress. I
tried that on our Alpha Koji, but encountered a problem...

Just 2 cent,
 -of



From mattdm at mattdm.org  Wed Oct  3 21:09:36 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 3 Oct 2007 17:09:36 -0400
Subject: orinoco_pci is all broken [was Re: NetworkManager-0.7 can't make
	new wireless connection]
In-Reply-To: <1191338779.31874.5.camel@xo-3E-67-34.localdomain>
References: <1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
	<1191326350.21429.24.camel@xo-3E-67-34.localdomain>
	<20071002150016.GA26688@jadzia.bu.edu>
	<1191338779.31874.5.camel@xo-3E-67-34.localdomain>
Message-ID: <20071003210936.GA22885@jadzia.bu.edu>

On Tue, Oct 02, 2007 at 11:26:19AM -0400, Dan Williams wrote:
> Does rmmoding orinoco_pci reset it sufficiently?

So, having done this, it can scan again, but won't connect, and after that,
I think get ""Faild to read scan data : No data available".

[...]
> I think this requires a driver update; maybe wpa_supplicant needs to be
> more lenient in its timeouts for getting scan data out of the card, but
> I'm pretty sure it's waiting ~ 10s max before asking the card for
> results explicitly.

So, what should I do now? Would a bug in bugzilla be helpful? (For you, or
for me?)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jkeating at redhat.com  Wed Oct  3 21:18:03 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 3 Oct 2007 17:18:03 -0400
Subject: Freeze over for Fedora 8 Test 3 - Still in continual development
 freeze
Message-ID: <20071003171803.324a63a9@redhat.com>

We have lifted the Fedora 8 Test 3 freeze from rawhide.  Builds from
devel/ now continue to go into rawhide each night.  However we are
still under continual development freeze so we ask you to please keep
your changes to bugfix in nature.  This is somewhat self policing, as
an attempt to lower the bar for getting fixes into the release.

The other side of this is an attempt at freeing up developers to work
on F9 stuff.  To that end we are now processing F-8 branch requests.
If you request your package be branched for F-8, a branch will be made
based on content currently in devel/.  Builds from F-8/ will obviously
go to the dist-f8 collection and thus rawhide/release.  For packages
that are branched, builds from devel/ will go to dist-f9 and be held
there for the start of Fedora 9 development.  If a package isn't
branched yet, builds from devel/ continue to go to dist-f8.

Happy building!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071003/bac1feff/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From joshuadfranklin at yahoo.com  Wed Oct  3 21:27:53 2007
From: joshuadfranklin at yahoo.com (Joshua Daniel Franklin)
Date: Wed, 3 Oct 2007 14:27:53 -0700 (PDT)
Subject: Alpine
In-Reply-To: <100320071808.27075.4703DAA8000CEC55000069C322230680329B0A02D2089B9A019C04040A0DBF000E0E9B9C9D@bellsouth.net>
Message-ID: <613309.251.qm@web37907.mail.mud.yahoo.com>

--- Bob wrote:
> I second the suggestion of including it in EPEL...

Yes, I plan on branching alpine-1.0 for RHEL4 and 5 too.


      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 




From dcbw at redhat.com  Wed Oct  3 21:47:55 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 03 Oct 2007 17:47:55 -0400
Subject: orinoco_pci is all broken [was Re: NetworkManager-0.7 can't
	make new wireless connection]
In-Reply-To: <20071003210936.GA22885@jadzia.bu.edu>
References: <1191026134.6487.8.camel@localhost.localdomain>
	<1191087158.12995.41.camel@vincent52.localdomain>
	<20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
	<1191326350.21429.24.camel@xo-3E-67-34.localdomain>
	<20071002150016.GA26688@jadzia.bu.edu>
	<1191338779.31874.5.camel@xo-3E-67-34.localdomain>
	<20071003210936.GA22885@jadzia.bu.edu>
Message-ID: <1191448075.23792.5.camel@localhost.localdomain>

On Wed, 2007-10-03 at 17:09 -0400, Matthew Miller wrote:
> On Tue, Oct 02, 2007 at 11:26:19AM -0400, Dan Williams wrote:
> > Does rmmoding orinoco_pci reset it sufficiently?
> 
> So, having done this, it can scan again, but won't connect, and after that,
> I think get ""Faild to read scan data : No data available".

Same problem again.

> [...]
> > I think this requires a driver update; maybe wpa_supplicant needs to be
> > more lenient in its timeouts for getting scan data out of the card, but
> > I'm pretty sure it's waiting ~ 10s max before asking the card for
> > results explicitly.
> 
> So, what should I do now? Would a bug in bugzilla be helpful? (For you, or
> for me?)

Hmm, not sure.  Basically need to patch the driver to be more
intelligent about scanning.  There's nothing rocket-science about this,
just would take a day or two to port over what's in the airo driver.
Not sure if a bug report would help, but feel free to file one anyway
and assign it to me (also cc linville at redhat dot com)

Dan




From poelstra at redhat.com  Wed Oct  3 21:38:58 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 03 Oct 2007 14:38:58 -0700
Subject: Freeze over for Fedora 8 Test 3 - Still in continual development
 freeze
In-Reply-To: <20071003171803.324a63a9@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
Message-ID: <47040BF2.4050805@redhat.com>

Jesse Keating said the following on 10/03/2007 02:18 PM Pacific Time:
> We have lifted the Fedora 8 Test 3 freeze from rawhide.  Builds from
> devel/ now continue to go into rawhide each night.  However we are
> still under continual development freeze so we ask you to please keep
> your changes to bugfix in nature.  This is somewhat self policing, as
> an attempt to lower the bar for getting fixes into the release.
> 

http://fedoraproject.org/wiki/Releases/8/FeatureList

In addition, if you are a feature owner please update the status of your feature page if it is not at 100% complete.  If there is functionality that is not completed, please rework the feature page to reflect what is finished for Fedora 8 so that the feature can be considered "complete" as described.  Please create a new feature page for Fedora 9 functionality you plan to create later.

This will help testers of F8T3 and users of GA to have a clear understanding what new functionality is present and expected to work.

Thank you,
John Feature Wrangler

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From cra at WPI.EDU  Wed Oct  3 22:26:58 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 3 Oct 2007 18:26:58 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <1191041189.9155.7.camel@xo-3E-67-34.localdomain>
References: <1190823905.15397.16.camel@vincent52.localdomain>
	<loom.20070926T224337-568@post.gmane.org>
	<f6e5806f0709271028v48022df3t54275de33a25144d@mail.gmail.com>
	<20070927201036.GA21031@jadzia.bu.edu>
	<20070927202009.GR6066@angus.ind.WPI.EDU>
	<1191041189.9155.7.camel@xo-3E-67-34.localdomain>
Message-ID: <20071003222658.GO6066@angus.ind.WPI.EDU>

On Sat, Sep 29, 2007 at 12:46:29AM -0400, Dan Williams wrote:
> On Thu, 2007-09-27 at 16:20 -0400, Chuck Anderson wrote:
> > On Thu, Sep 27, 2007 at 04:10:36PM -0400, Matthew Miller wrote:
> > > On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote:
> > > > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has
> > > > gone away.  I can use it to connect to wireless networks again without
> > > > a lot of service restarting.
> > > 
> > > Yeah, works for me too.
> > 
> > Not working here.  I use the ath5k driver and it scans and find 
> > wireless networks, but when I click on them (WPA/WPA2 Enterprise 
> > required) nothing happens--no pop up, no dialog asking for certificate 
> > files, nothing.
> 
> ath5k is still pretty immature; it hasn't worked for me with
> wpa_supplicant/NM and only recently stopped hanging the machine on even
> a plain 'ifup' at boot time.  I'll have a go at seeing whether or not
> this is an NM, wpa_supplicant, or driver problem.  But just know that it
> may be rocky with ath5k for a while since it's still under really heavy
> development, about where mac80211 itself was this spring.

Newer stuff is now working great on the open wireless network I tried.  
NM scans and finds the network.  I have to manually select it, and it 
DHCPs and works fine from there on.  This is all with the ath5k 
driver.

Unfortunately, WPA/WPA2 Enterprise (e.g. certificate-based, not PSK) 
is still doing absolutely nothing, no dialog box at all, no chance to 
configure it with certs...  How is this supposed to work?

I built madwifi ath_pci driver from Livna for the 214.rc8.git2.fc8 
kernel, and it behaves the same way w.r.t. WPA.  I'll retry the open 
network with that driver later tonight.

But basically, this seems like a regression.  Wireless networks that 
worked before should ideally continue to work with the new NM.



From darrellpf at gmail.com  Wed Oct  3 22:48:40 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 3 Oct 2007 15:48:40 -0700
Subject: Default Firefox settings
In-Reply-To: <20071003185256.GM6066@angus.ind.WPI.EDU>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
Message-ID: <f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>

I'm using firefox granparadisio.

I was having a terrible time with unbearably slow firefox on some
hotel networks. All my other network apps were working fine.

It looked like firefox was timing out on dns lookups. Eventually when
addresses got cached locally on the machine firefox speeded up
considerably.

In preferences/network/setting, "auto detect proxy settings" was set.
I changed to "direct connection to internet" and firefox works at a
decent speed.

darrell



From gunchev at gmail.com  Wed Oct  3 22:49:03 2007
From: gunchev at gmail.com (Doncho N. Gunchev)
Date: Thu, 4 Oct 2007 01:49:03 +0300
Subject: Please modify your OpenGL using games to use opengl-games-utils
In-Reply-To: <4703980E.8070101@hhs.nl>
References: <46F8F5E8.3000801@hhs.nl> <200710031013.28627.gunchev@gmail.com>
	<4703980E.8070101@hhs.nl>
Message-ID: <200710040149.03661.gunchev@gmail.com>

On Wednesday 2007-10-03 16:24:30 Hans de Goede wrote:
> Doncho N. Gunchev wrote:
> > On Tuesday 2007-10-02 18:05:38 Hans de Goede wrote:
> >> Ian Chapman wrote:
> >>> Doncho N. Gunchev wrote:
> >>>
> >>>>> for all games just by exporting the environment variable.  Since you
...
> > Well... improvise:
> > 
> > ans=$(zenity  --list  --text "Your video..." --radiolist  --column "Pick"  \
> > --column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
> >  FALSE "Always run regardless"); echo $ans
> > 
> 
> I don't think we want the "Never run such programs" option, as from then on 
> such programs would silently fail. But other then that it might be ok. I would 
> need to see it. If someone wants to spend some time on implementing this and it 
> doesn't look horrible I would be more then happy to take a patch for this.
> 
> Please submit any patches through bugzilla.
> 

Hm, this means against opengl-games-utils, which I just discovered I have
installed. The "Never run such programs" was just an example. I'll see
what I can do :-)

-- 
Regards,
  Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu



From pemboa at gmail.com  Wed Oct  3 23:03:21 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 3 Oct 2007 18:03:21 -0500
Subject: Default Firefox settings
In-Reply-To: <f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
Message-ID: <16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>

On 10/3/07, darrell pfeifer <darrellpf at gmail.com> wrote:
> I'm using firefox granparadisio.
>
> I was having a terrible time with unbearably slow firefox on some
> hotel networks. All my other network apps were working fine.
>
> It looked like firefox was timing out on dns lookups. Eventually when
> addresses got cached locally on the machine firefox speeded up
> considerably.
>
> In preferences/network/setting, "auto detect proxy settings" was set.
> I changed to "direct connection to internet" and firefox works at a
> decent speed.
>
> darrell


When firefox is slow, it is _really_ slow. Is this acceptable by default?


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From alexl at users.sourceforge.net  Wed Oct  3 23:22:21 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 03 Oct 2007 16:22:21 -0700
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <46CCFAF3.2070506@redhat.com> (Mike McGrath's message of "Wed\,
	22 Aug 2007 22\:11\:47 -0500")
References: <46CCFAF3.2070506@redhat.com>
Message-ID: <641wcbiy1e.fsf@allele2.eebweb.arizona.edu>

>>>>> "MM" == Mike McGrath  writes:

MM> Doing a little house cleaning.  In particular OTRS and BackupPC
MM> upstream have been doing some very cool things but I don't use
MM> those packages anymore and have been neglecting them.

MM> Orphaning: OTRS BackupPC sqlite2

I'll take sqlite2, looks like it's a currently a requirement for
moomps.

moomps looks like it is rawhide/F-8 but sqlite2 isn't which would
presumably mean that moomps would currently be uninstallable because
it would be missing its dependencies.

Alex



From poelstra at redhat.com  Wed Oct  3 23:51:45 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 03 Oct 2007 16:51:45 -0700
Subject: Fedora Rel-Eng Meeting Recap 2007-OCT-10
Message-ID: <47042B11.6040401@redhat.com>


Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-oct-01


Please make corrections and clarifications to the wiki page.

== Fedora 8 Test 3 ==
 * release candidate tree done (minus live images) which is synced to RDU
 * working through some problematic issues with live images right now 
 * adding "new" packages now that need to be on the DVD would slip the release

== Regular Fedora Releases on CD ==
 * we don't explain clearly anywhere why we don't do CD release anymore (regular ISOs not live image)
 * doing regular CD releases increases disk space on mirrors, compose time, and QA paths considerably
 * the i386 Live CD is usable in CD form, or the network based install options from rescue or boot.iso
 * creating CD sets can be created with existing free tools--LUGs can produce such things for their members, or whatever.
 * if CD releases were to be re-instituted the Fedora board would have to make decision that it is really important
    * QA would need to sign off
    * face possible wrath of the mirrors 

== IRC Transcript ==



From mattdm at mattdm.org  Thu Oct  4 01:34:08 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 3 Oct 2007 21:34:08 -0400
Subject: orinoco_pci is all broken [was Re: NetworkManager-0.7 can't
	make new wireless connection]
In-Reply-To: <1191448075.23792.5.camel@localhost.localdomain>
References: <20070930002552.GA8910@jadzia.bu.edu>
	<1191250903.5368.4.camel@xo-3E-67-34.localdomain>
	<20071001153850.GA804@jadzia.bu.edu>
	<1191263109.19127.0.camel@xo-3E-67-34.localdomain>
	<20071001185652.GA24204@jadzia.bu.edu>
	<1191326350.21429.24.camel@xo-3E-67-34.localdomain>
	<20071002150016.GA26688@jadzia.bu.edu>
	<1191338779.31874.5.camel@xo-3E-67-34.localdomain>
	<20071003210936.GA22885@jadzia.bu.edu>
	<1191448075.23792.5.camel@localhost.localdomain>
Message-ID: <20071004013408.GA15217@jadzia.bu.edu>

On Wed, Oct 03, 2007 at 05:47:55PM -0400, Dan Williams wrote:
> just would take a day or two to port over what's in the airo driver.
> Not sure if a bug report would help, but feel free to file one anyway
> and assign it to me (also cc linville at redhat dot com)

Ta-da: <https://bugzilla.redhat.com/show_bug.cgi?id=317691>

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mike at miketc.com  Thu Oct  4 02:22:24 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 03 Oct 2007 21:22:24 -0500
Subject: Icons enlarged
Message-ID: <1191464544.2247.2.camel@scrappy.miketc.com>

I may have missed this topic/bug if it was discussed due to some other
reasons, but wanted to point it out anyway just in case.  I have noticed
that after today's rawhide updates that lot of my icons and buttons are
enlarged?  Like some of my evo buttons are really big,and the volume
control icon on my panel is big.  But nothing else on the panel is.  I
am also running the echo-icon-them just in case that is relevant.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From d.jacobfeuerborn at conversis.de  Thu Oct  4 03:46:54 2007
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Thu, 04 Oct 2007 05:46:54 +0200
Subject: Default Firefox settings
In-Reply-To: <4703CF27.4000002@redhat.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>	<4703CBB8.5060109@kanarip.com>
	<4703CF27.4000002@redhat.com>
Message-ID: <4704622E.4020602@conversis.de>

Christopher Aillon wrote:
> Jeroen van Meeuwen wrote:
>> Does upstream think the default settings as provided in the vanilla
>> distribution should be adjusted as set forth in [2] ? If they don't, I
>> think we shouldn't either.
> 
> Several of the preference tweaks will indeed enhance performance for a 
> reasonably large percentage of websites but will cause a not 
> insignificant number to break.  (By refusing to load, hanging the 
> browser, etc.)  The prefs are generally that way for a good reason.
> 

Does there exist any useful statistical data out there to verify the "not 
insignificant number" claim? I've been browsing the web with pipelining 
enabled for ages and have yet to come across a page that doesn't work. Is 
the problem real or one of these myths that stay around because people read 
on the internet that pipelining has problems so it must be true?

Regards,
   Dennis



From sesanach at gmail.com  Thu Oct  4 05:38:58 2007
From: sesanach at gmail.com (Sam Gordon)
Date: Thu, 4 Oct 2007 00:38:58 -0500
Subject: technical question
Message-ID: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>

hi i got a question..my friend installed fedora on my pc and put in the
username password and now he doesnt remember it lol..and i have no idea what
it is because he installed it...is there a way to override the login or
somehow bypass it and change the information? plz just tell me what my
options r in the matter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/3d3d2a65/attachment.htm>

From peter at thecodergeek.com  Thu Oct  4 05:44:45 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 03 Oct 2007 22:44:45 -0700
Subject: technical question
In-Reply-To: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
Message-ID: <1191476685.27987.9.camel@localhost.localdomain>

On Thu, 2007-10-04 at 00:38 -0500, Sam Gordon wrote:
> hi i got a question..my friend installed fedora on my pc and put in
> the username password and now he doesnt remember it lol..and i have no
> idea what it is because he installed it...is there a way to override
> the login or somehow bypass it and change the information? plz just
> tell me what my options r in the matter 

Yes, you should be able to login as the root user (the so-called
"superuser" in Unix/Linux systems). As the root user you can then run
"passwd <username>" to replace your lost password for that acccount. 

Hope that helps.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071003/2366e42f/attachment.sig>

From cjdahlin at ncsu.edu  Thu Oct  4 05:46:41 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Thu, 04 Oct 2007 01:46:41 -0400
Subject: technical question
In-Reply-To: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
Message-ID: <47047E41.4050303@ncsu.edu>

Sam Gordon wrote:
> hi i got a question..my friend installed fedora on my pc and put in 
> the username password and now he doesnt remember it lol..and i have no 
> idea what it is because he installed it...is there a way to override 
> the login or somehow bypass it and change the information? plz just 
> tell me what my options r in the matter

This list is for development discussion. For help and support you should 
try fedoraforum.org or #fedora on irc.freenode.net . That being said, 
from the grub screen, edit your default boot settings and add the word 
'single' (without quotes) to the end of the line mentioning 'vmlinuz' . 
When you boot, you will get a text-only shell with root privileges.



From sesanach at gmail.com  Thu Oct  4 05:55:08 2007
From: sesanach at gmail.com (Sam Gordon)
Date: Thu, 4 Oct 2007 00:55:08 -0500
Subject: technical question
In-Reply-To: <47047E41.4050303@ncsu.edu>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
	<47047E41.4050303@ncsu.edu>
Message-ID: <1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>

hey wow that was fast cool...ok im in some screen and its says GNU GRUB vr.
0.97
Fedora Core(2.6.15-1.2054_FC5)
i guess its like a boot window...i cant like edit commands before booting,
modify kernel arguments before booting, or go to command line...
is this where i type what u said or the main login window after the system
starts up?
cuz i tried /etc/passwd and that didnt work at all...and u attached
something do i input that sumwhere?

On 10/4/07, Casey Dahlin <cjdahlin at ncsu.edu> wrote:
>
> Sam Gordon wrote:
> > hi i got a question..my friend installed fedora on my pc and put in
> > the username password and now he doesnt remember it lol..and i have no
> > idea what it is because he installed it...is there a way to override
> > the login or somehow bypass it and change the information? plz just
> > tell me what my options r in the matter
>
> This list is for development discussion. For help and support you should
> try fedoraforum.org or #fedora on irc.freenode.net . That being said,
> from the grub screen, edit your default boot settings and add the word
> 'single' (without quotes) to the end of the line mentioning 'vmlinuz' .
> When you boot, you will get a text-only shell with root privileges.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/f54d3d8c/attachment.htm>

From cjdahlin at ncsu.edu  Thu Oct  4 06:05:01 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Thu, 04 Oct 2007 02:05:01 -0400
Subject: technical question
In-Reply-To: <1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>	<47047E41.4050303@ncsu.edu>
	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>
Message-ID: <4704828D.3070907@ncsu.edu>

Modify kernel arguments. You want to add 'single' to the end of the 
arguments list.

Sam Gordon wrote:
> hey wow that was fast cool...ok im in some screen and its says GNU 
> GRUB vr. 0.97
> Fedora Core(2.6.15-1.2054_FC5)
> i guess its like a boot window...i cant like edit commands before 
> booting, modify kernel arguments before booting, or go to command line...
> is this where i type what u said or the main login window after the 
> system starts up?
> cuz i tried /etc/passwd and that didnt work at all...and u attached 
> something do i input that sumwhere?
>
> On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu 
> <mailto:cjdahlin at ncsu.edu>> wrote:
>
>     Sam Gordon wrote:
>     > hi i got a question..my friend installed fedora on my pc and put in
>     > the username password and now he doesnt remember it lol..and i
>     have no
>     > idea what it is because he installed it...is there a way to
>     override
>     > the login or somehow bypass it and change the information? plz just
>     > tell me what my options r in the matter
>
>     This list is for development discussion. For help and support you
>     should
>     try fedoraforum.org <http://fedoraforum.org> or #fedora on
>     irc.freenode.net <http://irc.freenode.net> . That being said,
>     from the grub screen, edit your default boot settings and add the word
>     'single' (without quotes) to the end of the line mentioning
>     'vmlinuz' .
>     When you boot, you will get a text-only shell with root privileges.
>
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From sesanach at gmail.com  Thu Oct  4 06:13:30 2007
From: sesanach at gmail.com (Sam Gordon)
Date: Thu, 4 Oct 2007 01:13:30 -0500
Subject: technical question
In-Reply-To: <4704828D.3070907@ncsu.edu>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
	<47047E41.4050303@ncsu.edu>
	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>
	<4704828D.3070907@ncsu.edu>
Message-ID: <1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>

im probably buggin the hell out of u and im sorry....it rebooted it after i
wrote single in the line for the kernels but now its stuck at
sh-3.1#
and doesnt load anything

On 10/4/07, Casey Dahlin <cjdahlin at ncsu.edu> wrote:
>
> Modify kernel arguments. You want to add 'single' to the end of the
> arguments list.
>
> Sam Gordon wrote:
> > hey wow that was fast cool...ok im in some screen and its says GNU
> > GRUB vr. 0.97
> > Fedora Core(2.6.15-1.2054_FC5)
> > i guess its like a boot window...i cant like edit commands before
> > booting, modify kernel arguments before booting, or go to command
> line...
> > is this where i type what u said or the main login window after the
> > system starts up?
> > cuz i tried /etc/passwd and that didnt work at all...and u attached
> > something do i input that sumwhere?
> >
> > On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu
> > <mailto:cjdahlin at ncsu.edu>> wrote:
> >
> >     Sam Gordon wrote:
> >     > hi i got a question..my friend installed fedora on my pc and put
> in
> >     > the username password and now he doesnt remember it lol..and i
> >     have no
> >     > idea what it is because he installed it...is there a way to
> >     override
> >     > the login or somehow bypass it and change the information? plz
> just
> >     > tell me what my options r in the matter
> >
> >     This list is for development discussion. For help and support you
> >     should
> >     try fedoraforum.org <http://fedoraforum.org> or #fedora on
> >     irc.freenode.net <http://irc.freenode.net> . That being said,
> >     from the grub screen, edit your default boot settings and add the
> word
> >     'single' (without quotes) to the end of the line mentioning
> >     'vmlinuz' .
> >     When you boot, you will get a text-only shell with root privileges.
> >
> >     --
> >     fedora-devel-list mailing list
> >     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
> >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/ea5ba60c/attachment.htm>

From cjdahlin at ncsu.edu  Thu Oct  4 06:16:36 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Thu, 04 Oct 2007 02:16:36 -0400
Subject: technical question
In-Reply-To: <1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>	<47047E41.4050303@ncsu.edu>	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>	<4704828D.3070907@ncsu.edu>
	<1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>
Message-ID: <47048544.5030109@ncsu.edu>

That would be the command prompt :)

Linux users who haven't seen a shell before. Fancy this wondrous modern 
age we live in. Type the following:

passwd root

and you can change the root password. Then type

passwd <your friend's username here>

and you can change his password.

Sam Gordon wrote:
> im probably buggin the hell out of u and im sorry....it rebooted it 
> after i wrote single in the line for the kernels but now its stuck at
> sh-3.1#
> and doesnt load anything
>
> On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu 
> <mailto:cjdahlin at ncsu.edu>> wrote:
>
>     Modify kernel arguments. You want to add 'single' to the end of the
>     arguments list.
>
>     Sam Gordon wrote:
>     > hey wow that was fast cool...ok im in some screen and its says GNU
>     > GRUB vr. 0.97
>     > Fedora Core( 2.6.15-1.2054_FC5)
>     > i guess its like a boot window...i cant like edit commands before
>     > booting, modify kernel arguments before booting, or go to
>     command line...
>     > is this where i type what u said or the main login window after the
>     > system starts up?
>     > cuz i tried /etc/passwd and that didnt work at all...and u attached
>     > something do i input that sumwhere?
>     >
>     > On 10/4/07, *Casey Dahlin* < cjdahlin at ncsu.edu
>     <mailto:cjdahlin at ncsu.edu>
>     > <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>> wrote:
>     >
>     >     Sam Gordon wrote:
>     >     > hi i got a question..my friend installed fedora on my pc
>     and put in
>     >     > the username password and now he doesnt remember it lol..and i
>     >     have no
>     >     > idea what it is because he installed it...is there a way to
>     >     override
>     >     > the login or somehow bypass it and change the information?
>     plz just
>     >     > tell me what my options r in the matter
>     >
>     >     This list is for development discussion. For help and
>     support you
>     >     should
>     >     try fedoraforum.org <http://fedoraforum.org>
>     <http://fedoraforum.org> or #fedora on
>     >     irc.freenode.net <http://irc.freenode.net>
>     <http://irc.freenode.net> . That being said,
>     >     from the grub screen, edit your default boot settings and
>     add the word
>     >     'single' (without quotes) to the end of the line mentioning
>     >     'vmlinuz' .
>     >     When you boot, you will get a text-only shell with root
>     privileges.
>     >
>     >     --
>     >     fedora-devel-list mailing list
>     >     fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>
>     <mailto:fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>>
>     >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>     >
>     >
>
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From cjdahlin at ncsu.edu  Thu Oct  4 06:18:55 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Thu, 04 Oct 2007 02:18:55 -0400
Subject: technical question
In-Reply-To: <1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>	<47047E41.4050303@ncsu.edu>	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>	<4704828D.3070907@ncsu.edu>
	<1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>
Message-ID: <470485CF.1040302@ncsu.edu>

That would be the command prompt :)

Linux users who haven't seen a shell before. Fancy this wondrous modern 
age we live in. Type the following:

passwd root

and you can change the root password. Then type

passwd <your friend's username here>

and you can change his password.

Sam Gordon wrote:
> im probably buggin the hell out of u and im sorry....it rebooted it 
> after i wrote single in the line for the kernels but now its stuck at
> sh-3.1#
> and doesnt load anything
>
> On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu 
> <mailto:cjdahlin at ncsu.edu>> wrote:
>
>     Modify kernel arguments. You want to add 'single' to the end of the
>     arguments list.
>
>     Sam Gordon wrote:
>     > hey wow that was fast cool...ok im in some screen and its says GNU
>     > GRUB vr. 0.97
>     > Fedora Core( 2.6.15-1.2054_FC5)
>     > i guess its like a boot window...i cant like edit commands before
>     > booting, modify kernel arguments before booting, or go to
>     command line...
>     > is this where i type what u said or the main login window after the
>     > system starts up?
>     > cuz i tried /etc/passwd and that didnt work at all...and u attached
>     > something do i input that sumwhere?
>     >
>     > On 10/4/07, *Casey Dahlin* < cjdahlin at ncsu.edu
>     <mailto:cjdahlin at ncsu.edu>
>     > <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>> wrote:
>     >
>     >     Sam Gordon wrote:
>     >     > hi i got a question..my friend installed fedora on my pc
>     and put in
>     >     > the username password and now he doesnt remember it lol..and i
>     >     have no
>     >     > idea what it is because he installed it...is there a way to
>     >     override
>     >     > the login or somehow bypass it and change the information?
>     plz just
>     >     > tell me what my options r in the matter
>     >
>     >     This list is for development discussion. For help and
>     support you
>     >     should
>     >     try fedoraforum.org <http://fedoraforum.org>
>     <http://fedoraforum.org> or #fedora on
>     >     irc.freenode.net <http://irc.freenode.net>
>     <http://irc.freenode.net> . That being said,
>     >     from the grub screen, edit your default boot settings and
>     add the word
>     >     'single' (without quotes) to the end of the line mentioning
>     >     'vmlinuz' .
>     >     When you boot, you will get a text-only shell with root
>     privileges.
>     >
>     >     --
>     >     fedora-devel-list mailing list
>     >     fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>
>     <mailto:fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>>
>     >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>     >
>     >
>
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From sesanach at gmail.com  Thu Oct  4 06:25:21 2007
From: sesanach at gmail.com (Sam Gordon)
Date: Thu, 4 Oct 2007 01:25:21 -0500
Subject: technical question
In-Reply-To: <470485CF.1040302@ncsu.edu>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>
	<47047E41.4050303@ncsu.edu>
	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>
	<4704828D.3070907@ncsu.edu>
	<1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>
	<470485CF.1040302@ncsu.edu>
Message-ID: <1dfb71690710032325x74cbb888h82d9f05f2b736a12@mail.gmail.com>

working with linux is harder then flying a plane for me lol....ive never
used it before im a windows person and my friend is trying to successfully
pull me away from it

On 10/4/07, Casey Dahlin <cjdahlin at ncsu.edu> wrote:
>
> That would be the command prompt :)
>
> Linux users who haven't seen a shell before. Fancy this wondrous modern
> age we live in. Type the following:
>
> passwd root
>
> and you can change the root password. Then type
>
> passwd <your friend's username here>
>
> and you can change his password.
>
> Sam Gordon wrote:
> > im probably buggin the hell out of u and im sorry....it rebooted it
> > after i wrote single in the line for the kernels but now its stuck at
> > sh-3.1#
> > and doesnt load anything
> >
> > On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu
> > <mailto:cjdahlin at ncsu.edu>> wrote:
> >
> >     Modify kernel arguments. You want to add 'single' to the end of the
> >     arguments list.
> >
> >     Sam Gordon wrote:
> >     > hey wow that was fast cool...ok im in some screen and its says GNU
> >     > GRUB vr. 0.97
> >     > Fedora Core( 2.6.15-1.2054_FC5)
> >     > i guess its like a boot window...i cant like edit commands before
> >     > booting, modify kernel arguments before booting, or go to
> >     command line...
> >     > is this where i type what u said or the main login window after
> the
> >     > system starts up?
> >     > cuz i tried /etc/passwd and that didnt work at all...and u
> attached
> >     > something do i input that sumwhere?
> >     >
> >     > On 10/4/07, *Casey Dahlin* < cjdahlin at ncsu.edu
> >     <mailto:cjdahlin at ncsu.edu>
> >     > <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>> wrote:
> >     >
> >     >     Sam Gordon wrote:
> >     >     > hi i got a question..my friend installed fedora on my pc
> >     and put in
> >     >     > the username password and now he doesnt remember it lol..and
> i
> >     >     have no
> >     >     > idea what it is because he installed it...is there a way to
> >     >     override
> >     >     > the login or somehow bypass it and change the information?
> >     plz just
> >     >     > tell me what my options r in the matter
> >     >
> >     >     This list is for development discussion. For help and
> >     support you
> >     >     should
> >     >     try fedoraforum.org <http://fedoraforum.org>
> >     <http://fedoraforum.org> or #fedora on
> >     >     irc.freenode.net <http://irc.freenode.net>
> >     <http://irc.freenode.net> . That being said,
> >     >     from the grub screen, edit your default boot settings and
> >     add the word
> >     >     'single' (without quotes) to the end of the line mentioning
> >     >     'vmlinuz' .
> >     >     When you boot, you will get a text-only shell with root
> >     privileges.
> >     >
> >     >     --
> >     >     fedora-devel-list mailing list
> >     >     fedora-devel-list at redhat.com
> >     <mailto:fedora-devel-list at redhat.com>
> >     <mailto:fedora-devel-list at redhat.com
> >     <mailto:fedora-devel-list at redhat.com>>
> >     >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >     >
> >     >
> >
> >     --
> >     fedora-devel-list mailing list
> >     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
> >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/3e3e17e1/attachment.htm>

From cjdahlin at ncsu.edu  Thu Oct  4 06:37:50 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Thu, 04 Oct 2007 02:37:50 -0400
Subject: technical question
In-Reply-To: <1dfb71690710032325x74cbb888h82d9f05f2b736a12@mail.gmail.com>
References: <1dfb71690710032238m4cb45ad2o473ed435248c5e1f@mail.gmail.com>	<47047E41.4050303@ncsu.edu>	<1dfb71690710032255l8415f59r838802cd08ca3db@mail.gmail.com>	<4704828D.3070907@ncsu.edu>	<1dfb71690710032313pe423468qd632529d38425d14@mail.gmail.com>	<470485CF.1040302@ncsu.edu>
	<1dfb71690710032325x74cbb888h82d9f05f2b736a12@mail.gmail.com>
Message-ID: <47048A3E.7070801@ncsu.edu>

Well welcome aboard.

This might have been the harder way to do things. I assumed that you 
didn't know the root (administrator) password either.

Well, with luck you'll never have to do this again :)

I will mention again that fedora-devel-list is where the engineers do 
the grunt work on fedora, and they really can't do tech support. The 
users list is for these kinds of questions:

http://www.redhat.com/mailman/listinfo/fedora-list

Hope I helped. Now to bed. :)

--CJD

Sam Gordon wrote:
> working with linux is harder then flying a plane for me lol....ive 
> never used it before im a windows person and my friend is trying to 
> successfully pull me away from it
>
> On 10/4/07, * Casey Dahlin* <cjdahlin at ncsu.edu 
> <mailto:cjdahlin at ncsu.edu>> wrote:
>
>     That would be the command prompt :)
>
>     Linux users who haven't seen a shell before. Fancy this wondrous
>     modern
>     age we live in. Type the following:
>
>     passwd root
>
>     and you can change the root password. Then type
>
>     passwd <your friend's username here>
>
>     and you can change his password.
>
>     Sam Gordon wrote:
>     > im probably buggin the hell out of u and im sorry....it rebooted it
>     > after i wrote single in the line for the kernels but now its
>     stuck at
>     > sh-3.1#
>     > and doesnt load anything
>     >
>     > On 10/4/07, *Casey Dahlin* <cjdahlin at ncsu.edu
>     <mailto:cjdahlin at ncsu.edu>
>     > <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>> wrote:
>     >
>     >     Modify kernel arguments. You want to add 'single' to the end
>     of the
>     >     arguments list.
>     >
>     >     Sam Gordon wrote:
>     >     > hey wow that was fast cool...ok im in some screen and its
>     says GNU
>     >     > GRUB vr. 0.97
>     >     > Fedora Core( 2.6.15-1.2054_FC5)
>     >     > i guess its like a boot window...i cant like edit commands
>     before
>     >     > booting, modify kernel arguments before booting, or go to
>     >     command line...
>     >     > is this where i type what u said or the main login window
>     after the
>     >     > system starts up?
>     >     > cuz i tried /etc/passwd and that didnt work at all...and u
>     attached
>     >     > something do i input that sumwhere?
>     >     >
>     >     > On 10/4/07, *Casey Dahlin* < cjdahlin at ncsu.edu
>     <mailto:cjdahlin at ncsu.edu>
>     >     <mailto: cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>
>     >     > <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>
>     <mailto:cjdahlin at ncsu.edu <mailto:cjdahlin at ncsu.edu>>>> wrote:
>     >     >
>     >     >     Sam Gordon wrote:
>     >     >     > hi i got a question..my friend installed fedora on my pc
>     >     and put in
>     >     >     > the username password and now he doesnt remember it
>     lol..and i
>     >     >     have no
>     >     >     > idea what it is because he installed it...is there a
>     way to
>     >     >     override
>     >     >     > the login or somehow bypass it and change the
>     information?
>     >     plz just
>     >     >     > tell me what my options r in the matter
>     >     >
>     >     >     This list is for development discussion. For help and
>     >     support you
>     >     >     should
>     >     >     try fedoraforum.org <http://fedoraforum.org>
>     <http://fedoraforum.org>
>     >     <http://fedoraforum.org> or #fedora on
>     >     >     irc.freenode.net <http://irc.freenode.net>
>     <http://irc.freenode.net>
>     >     <http://irc.freenode.net> . That being said,
>     >     >     from the grub screen, edit your default boot settings and
>     >     add the word
>     >     >     'single' (without quotes) to the end of the line
>     mentioning
>     >     >     'vmlinuz' .
>     >     >     When you boot, you will get a text-only shell with root
>     >     privileges.
>     >     >
>     >     >     --
>     >     >     fedora-devel-list mailing list
>     >     >     fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>
>     >     <mailto:fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>>
>     >     <mailto:fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>
>     >     <mailto:fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com>>>
>     >     >    
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>     <https://www.redhat.com/mailman/listinfo/fedora-devel-list>
>     >     >
>     >     >
>     >
>     >     --
>     >     fedora-devel-list mailing list
>     >     fedora-devel-list at redhat.com
>     <mailto:fedora-devel-list at redhat.com> <mailto:
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>>
>     >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>     >
>     >
>
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From Christian.Iseli at licr.org  Thu Oct  4 07:08:46 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Thu, 4 Oct 2007 09:08:46 +0200
Subject: Fedora Package Status of Oct  3, 2007
Message-ID: <20071004090846.00c616ad@ludwig-alpha.unil.ch>

Hi folks,

We passed the 5000 SRPMS mark...  Champagne :-)

NEW review requests down and OPEN bugs also down... looking good.
I suppose the high number of unavailable packages is due (in part)
to the freeze...

Cheers,
					Christian

====

Fedora Package Status of Oct  3, 2007

The full report can be found here:
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus


Owners stats:
 - 5032 packages
 - 8329 binary rpms in devel
 - 99 orphans
 - 36 packages not available in devel or release
    andreas at bawue dot net                   perl-HTML-CalendarMonthSimple
    ansilva at redhat dot com                  rpmrebuild
    bdpepple at gmail dot com                  galago-filesystem
    bdpepple at gmail dot com                  gaim-galago
    cweyl at alumni dot drew dot edu           gaim-gaym
    dakingun at gmail dot com                  flagpoll
    dbhole at redhat dot com                   dom2-core-tests
    debarshi dot ray at gmail dot com          opyum
    devrim at commandprompt dot com            postgresql-pgpool-ha
    fangqq at gmail dot com                    wqy-unibit-fonts
    foolish at guezz dot net                   perl-SQLite-Simple
    jafo at tummy dot com                      python-mechanoid
    jmp at safe dot ca                         clement
    jorton at redhat dot com                   libc-client
    lxtnow at gmail dot com                    guile-gnome-platform
    matthias at rpmforge dot net               gnome-themes-extras
    mchristi at redhat dot com                 scsi-target-utils
    noah at coderanger dot net                 rainbow
    noah at coderanger dot net                 python-olpcgames
    odvorace at redhat dot com                 odvorace
    odvorace at redhat dot com                 jbrassow
    oliver at linux-kernel dot at              aboot
    orion at cora dot nwra dot com             R-multcomp
    paul at all-the-johnsons dot co dot uk     mysql-connector-net
    pertusus at free dot fr                    ivman
    pingoufc4 at yahoo dot fr                  R-DynDoc
    rdieter at math dot unl dot edu            pykdeextensions
    richard at hughsie dot com                 ohm
    rvokal at redhat dot com                   gaim-guifications
    splinux25 at gmail dot com                 drapes
    than at redhat dot com                     kdelibs3
    trond dot danielsen at gmail dot com       uisp
    trond dot danielsen at gmail dot com       avarice
    vivekl at redhat dot com                   saxon8
    vivekl at redhat dot com                   classpathx-jaxp
    yufanyufan at gmail dot com                audacious-plugins-docklet
 - 10 packages not available in devel but present in release
    andreas dot bierfert at lowlatency dot de  syncekonnector
    caolanm at redhat dot com                  hunspell-he
    jkeating at redhat dot com                 tux
    jorton at redhat dot com                   newt-perl
    overholt at redhat dot com                 eclipse-nlspackager
    overholt at redhat dot com                 eclipse-sdk-nls
    ruben at rubenkerkhof dot com              csync2
    tmraz at redhat dot com                    openssl097a
    twaugh at redhat dot com                   desktop-printing
    wtogami at redhat dot com                  firefox-32
 - 10 packages which have not yet been FE-ACCEPT'd...
   https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861,280541,287801
     eclipse                                  bkonrath at redhat.com
     cyrus-imapd                              tjanouse at redhat.com
     setools                                  cpebenito at tresys.com
     Sirius                                   makghosh at gmail.com
   https://bugzilla.redhat.com/buglist.cgi?bug_id=190045,221717,224458,250040,252049,269441
     ladspa-caps-plugins                      green at redhat.com
     agg                                      caolanm at redhat.com
     libsilc                                  wtogami at redhat.com
     new                                      mike at flyn.org
     asm2                                     vivekl at redhat.com
     dvgrab                                   rpm at greysector.net
 - 3 packages present in the development repo which have no owners entry
    audacious-docklet s390utils stardict-dic
 - 4 orphaned packages, yet available in devel
    cgi-util redet redet-doc windowlab

FE-ACCEPT packages stats:
 - 3264 accepted, closed package reviews
 - 48 accepted, closed package reviews not in repo
 - 10 accepted, closed package reviews not in owners
 - 78 accepted, open package reviews older than 4 weeks;
 - 52 accepted, open package reviews with a package already in the repo

FE-REVIEW packages stats:
 - 279 open tickets
 - 122 tickets with no activity in eight weeks
 - 43 tickets with no activity in four weeks
 - 29 closed tickets

FE-NEW packages stats:
 - 864 open tickets
 - 627 tickets with no activity in eight weeks
 - 101 tickets with no activity in four weeks

FE-NEEDSPONSOR packages stats:
 - 27 open tickets
 - 6 tickets with no activity in eight weeks
 - 3 tickets with no activity in four weeks

FE-Legal packages stats:
 - 5 open tickets
 - 3 tickets with no activity in eight weeks

OPEN-BUGS packages stats:
 - 8446 open tickets
 - 5555 tickets with no activity in eight weeks
 - 950 tickets with no activity in four weeks

CVS stats:
 - 5039 packages with a devel directory
 - 3 packages with no owners entry
    glibc32 glibc64 tdma
 - 243 packages were dropped from Fedora

Maintainers stats:
 - 425 maintainers
 - 25 inactive maintainers with open bugs
 - 23 inactive maintainers

Dropped Fedora packages:
 - 58 packages were dropped since Fedora 7

Comps.xml files stats:
 -  2557 packages in comps-f8 file
 -  1138 packages missing from comps-f8 file
 -  22 packages in comps-f8 but not in repo
 -  2418 packages in comps-f7 file
 -  1090 packages missing from comps-f7 file
 -  25 packages in comps-f7 but not in repo



From debarshi.ray at gmail.com  Thu Oct  4 07:26:45 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 4 Oct 2007 12:56:45 +0530
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
	development freeze
In-Reply-To: <20071003171803.324a63a9@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
Message-ID: <3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>

> However we are still under continual development freeze so we ask
> you to please keep your changes to bugfix in nature.

New upstream releases which fix known bugs (non-FEVer bugs) are allowed?

> To that end we are now processing F-8 branch requests.
> If you request your package be branched for F-8, a branch will be made
> based on content currently in devel/.

What is the procedure for requesting a F-8 branch?

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From debarshi.ray at gmail.com  Thu Oct  4 07:53:39 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 4 Oct 2007 13:23:39 +0530
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>

I was looking for a laptop backup solution, and would like to take BackupPC.

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From nicolas.mailhot at laposte.net  Thu Oct  4 08:05:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 4 Oct 2007 10:05:07 +0200 (CEST)
Subject: Default Firefox settings
In-Reply-To: <16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
	<16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
Message-ID: <19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>


Le Jeu 4 octobre 2007 01:03, Arthur Pemberton a ?crit :
> On 10/3/07, darrell pfeifer <darrellpf at gmail.com> wrote:

>> In preferences/network/setting, "auto detect proxy settings" was
>> set.
>> I changed to "direct connection to internet" and firefox works at a
>> decent speed.

> When firefox is slow, it is _really_ slow. Is this acceptable by
> default?

You do need to auto detect proxy settings - when a proxy is available
most of the times you won't be allowed direct internet connection.

The problem is firefox sucks big time when you're behind a proxy - as
soon as the proxy is slow to answer for one tab all the others start
being sluggish/frozen (I suppose firefox has internal locking where
the cost of some locks is only evident in a proxy context)

The problem is not the setting, the problem is firefox is buggy.
That's something to report upstream.

-- 
Nicolas Mailhot




From bernie at codewiz.org  Thu Oct  4 09:10:01 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Thu, 04 Oct 2007 05:10:01 -0400
Subject: Default Firefox settings
In-Reply-To: <19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>	<4703CBB8.5060109@kanarip.com>	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>	<20071003185256.GM6066@angus.ind.WPI.EDU>	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>	<16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
	<19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
Message-ID: <4704ADE9.8020108@codewiz.org>

Nicolas Mailhot wrote:

> You do need to auto detect proxy settings - when a proxy is available
> most of the times you won't be allowed direct internet connection.
> 
> The problem is firefox sucks big time when you're behind a proxy - as
> soon as the proxy is slow to answer for one tab all the others start
> being sluggish/frozen (I suppose firefox has internal locking where
> the cost of some locks is only evident in a proxy context)
> 
> The problem is not the setting, the problem is firefox is buggy.
> That's something to report upstream.

I experienced this problem to.  My guess was that Firefox blocked while
resolving hostnames in proxy.pac JavaScript snippets like this one:

 function FindProxyForURL(url, host)
 {
  ip = dnsResolve(host);
  if (isInNet(myIpAddress(), "10.0.0.0", "255.0.0.0")
    && !shExpMatch(url, "ftp://*")
    && !isInNet(ip, "127.0.0.0", "255.0.0.0")
    && !isInNet(ip, "10.0.0.0", "255.0.0.0")
    && !isInNet(ip, "81.174.33.43", "255.255.255.248"))
   return "PROXY 10.3.3.1:3128";
  else
   return "DIRECT";
 }

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/



From jkeating at redhat.com  Thu Oct  4 10:19:44 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 4 Oct 2007 06:19:44 -0400
Subject: short koji repo question
In-Reply-To: <4703FD44.4060708@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>
	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>
	<47026129.2080001@linux-kernel.at> <470270C6.60309@linux-kernel.at>
	<20071002142722.1857e919@redhat.com>
	<4703669C.2060600@linux-kernel.at>
	<20071003073244.538e9091@redhat.com>
	<4703FD44.4060708@linux-kernel.at>
Message-ID: <20071004061944.2fe6427a@redhat.com>

On Wed, 03 Oct 2007 22:36:20 +0200
Oliver Falk <oliver at linux-kernel.at> wrote:

> Is there any good reason, why koji doesn't also create the sqlite
> database with createrepo (passing -d option)?
> 
> For slow arches, it would speed up the init phase of the build-root...
> For the fast arches, well it would also be faster I think...
> 
> If someone is going to change/try that. Let me know the progress. I
> tried that on our Alpha Koji, but encountered a problem...

Mostly because the development of koji happened mostly on RHEL4/5
machines which lack a createrepo that can do -d.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/a8236cb0/attachment.sig>

From jkeating at redhat.com  Thu Oct  4 10:29:16 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 4 Oct 2007 06:29:16 -0400
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
 development freeze
In-Reply-To: <3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
Message-ID: <20071004062916.75dbec15@redhat.com>

On Thu, 4 Oct 2007 12:56:45 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> New upstream releases which fix known bugs (non-FEVer bugs) are
> allowed?

Yes.  There is no way to have a hard/fast rule that says no new
versions.  If the new version is fixing bugs and not introducing new
features, it's a pretty easy call to make to say that this is OK.
We're letting maintainers who are more familiar with the software make
the decision of what to bring in or not.

> 
> > To that end we are now processing F-8 branch requests.
> > If you request your package be branched for F-8, a branch will be
> > made based on content currently in devel/.  
> 
> What is the procedure for requesting a F-8 branch?

The same way you request any other branch

http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/2c6e1b8d/attachment.sig>

From jkeating at redhat.com  Thu Oct  4 10:30:09 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 4 Oct 2007 06:30:09 -0400
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
Message-ID: <20071004063009.2ec0392a@redhat.com>

On Wed, 03 Oct 2007 16:22:21 -0700
Alex Lancaster <alexl at users.sourceforge.net> wrote:

> I'll take sqlite2, looks like it's a currently a requirement for
> moomps.
> 
> moomps looks like it is rawhide/F-8 but sqlite2 isn't which would
> presumably mean that moomps would currently be uninstallable because
> it would be missing its dependencies.


Actually moomps just needs to be rebuilt against the latest sqlite
builds which have sqlite-tcl now.  That should be the last sqlite2 need.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/6ac6e8c0/attachment.sig>

From buildsys at fedoraproject.org  Thu Oct  4 10:39:34 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu,  4 Oct 2007 06:39:34 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-04
Message-ID: <20071004103934.884BF15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 10

NEW aasaver-0.3.2-1.fc6 : A screensaver for KDE which presents an ASCII aquarium
    catfish-0.3-0.2.c.fc6
    Coin2-2.5.0-2.fc6
    flashrom-0-0.2.20071003svn2817.fc6
NEW kbiof-0.3-1.fc6 : KDE port of the original BIOF XScreenSaver
    poker-network-1.2.0-2.fc6
    poker2d-1.2.0-1.fc6
NEW R-DynDoc-1.14.0-5.fc6 : Functions for dynamic documents
NEW superiotool-0-0.3.20071004svn2819.fc6 : Simple program for detecting Super I/O on your mainboard
NEW wqy-unibit-fonts-1.1.0-4.fc6 : WenQuanYi Unibit Bitmap Font


Changes in Fedora Extras 6: 


aasaver-0.3.2-1.fc6
-------------------
* Sun Sep 30 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.3.2-1
- Initial release

catfish-0.3-0.2.c.fc6
---------------------
* Wed Oct 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-0.2.c
- License update
- Create sub-metapackage to install all supported search engines
- Remove redhat-artwork dependency

* Fri Aug 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-0.1.c
- 0.3c

Coin2-2.5.0-2.fc6
-----------------
* Wed Oct 03 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.5.0-2
- Fix permissions on source files.
- Convert sources to utf-8.

* Tue Oct 02 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.5.0-1
- Upstream update.

* Fri Aug 17 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.4.6-2
- Update license tag.

* Sun Apr 15 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.4.6-1
- Upstream update.
- Re-base the patches to 2.4.6.
- Spec file massage.

flashrom-0-0.2.20071003svn2817.fc6
----------------------------------
* Wed Oct 03 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.2.20071003svn2817
- Added correct BZ# for ExludeArch issue
- Preserved timestamp then installing flashrom
- svn ver. 2817 (support for IT8716F added, added COPYING)

kbiof-0.3-1.fc6
---------------
* Sat Sep 29 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.3-1
- Initial release

poker-network-1.2.0-2.fc6
-------------------------
* Wed Oct 03 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-2
- Add patch to fix poker-bot

* Wed Oct 03 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-1
- Upstream sync

poker2d-1.2.0-1.fc6
-------------------
* Wed Oct 03 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-1
- Upstream sync

R-DynDoc-1.14.0-5.fc6
---------------------
* Wed Aug 29 2007 Pingou <pingoufc4 at yahoo.fr> 1.14.0-5
-Change the license tag

superiotool-0-0.3.20071004svn2819.fc6
-------------------------------------
* Thu Oct 04 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.3.20071004svn2819
- svn ver. 2819 (added COPYING)

* Wed Oct 03 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.2.20071003svn2818
- Preserved timestamp then installing superiotool
- Native commands instead of macros (rm, install, mkdir, make)
- svn ver. 2818 (slightly changed output of version banner).

* Tue Oct 02 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.1.20071002svn2816
- Initial build for Fedora

wqy-unibit-fonts-1.1.0-4.fc6
----------------------------
* Sun Sep 30 2007 Qianqian Fang <fangqq at gmail.com> 1.1.0-4
- more spec file clean up

* Thu Sep 27 2007 Qianqian Fang <fangqq at gmail.com> 1.1.0-3
- change install directory to /usr/share/fonts/wenquanyi-unibit/

* Tue Sep 25 2007 Qianqian Fang <fangqq at gmail.com> 1.1.0-2
- change install directory to /usr/share/fonts/wqy-unibit/

* Fri Sep 14 2007 Qianqian Fang <fangqq at gmail.com> 1.1.0-1
- add more than 80 new glyphs between 0xFF00-0xFFFD, totaling 46443 glyphs

* Tue Sep 11 2007 Qianqian Fang <fangqq at gmail.com> 1.0.0-3
- remove non-ascii character from README, update upstream tarball

* Tue Sep 11 2007 Qianqian Fang <fangqq at gmail.com> 1.0.0-2
- change package name from wqy-unibit to wqy-unibit-fonts
- follow the new guideline for F8, use font catalogue symlink (#252279)

* Sun Sep 09 2007 Qianqian Fang <fangqq at gmail.com> 1.0.0-1
- initial release of the font
- initial packaging for Fedora (#285561)



From alexl at users.sourceforge.net  Thu Oct  4 11:07:10 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Thu, 04 Oct 2007 04:07:10 -0700
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <20071004063009.2ec0392a@redhat.com> (Jesse Keating's message of
	"Thu\, 4 Oct 2007 06\:30\:09 -0400")
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
	<20071004063009.2ec0392a@redhat.com>
Message-ID: <bpwsu3uoip.fsf@allele2.eebweb.arizona.edu>


Alex Lancaster wrote:

>> I'll take sqlite2, looks like it's a currently a requirement for
>> moomps.

>> moomps looks like it is rawhide/F-8 but sqlite2 isn't which would
>> presumably mean that moomps would currently be uninstallable
>> because it would be missing its dependencies.

>>>>> "JK" == Jesse Keating  writes:

JK> Actually moomps just needs to be rebuilt against the latest sqlite
JK> builds which have sqlite-tcl now.  That should be the last sqlite2
JK> need.

OK, that's good to know, so sqlite2 will then not be necessary (unless
there is some other package that hasn't yet been ported to sqlite 3).
I take it that would include moodss as well, since repoquery also
reports that as a dependent package:

# repoquery --recursive --whatrequires sqlite2
sqlite2-devel-0:2.8.17-1.fc6.i386
moomps-0:5.8-2.fc7.i386
sqlite2-tcl-0:2.8.17-1.fc6.i386
moodss-0:21.5-1.fc7.i386

Alex



From alexl at users.sourceforge.net  Thu Oct  4 11:12:24 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Thu, 04 Oct 2007 04:12:24 -0700
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>
	(Debarshi Ray's message of "Thu\, 4 Oct 2007 13\:23\:39 +0530")
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>
Message-ID: <6lodffuo9z.fsf@allele2.eebweb.arizona.edu>

>>>>> Debarshi 'Rishi' Ray  writes:

> I was looking for a laptop backup solution, and would like to take
> BackupPC.  Happy hacking, Debarshi

I think it's already been taken (the announcement was made a while
back on the old fedora-maintainers list).  According to pkgdb it's now
owned by Johan Cwiklinski.  See:

https://admin.fedoraproject.org/pkgdb/packages/name/BackupPC

Alex



From buildsys at fedoraproject.org  Thu Oct  4 11:23:54 2007
From: buildsys at fedoraproject.org (Fedora Extras repoclosure)
Date: Thu, 04 Oct 2007 11:23:54 -0000
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-04
Message-ID: <20071004112354.10872.71643@extras64.linux.duke.edu>

======================================================================
The results in this summary consider Test Updates!
======================================================================
Summary of broken packages (by owner):

    andreas.bierfert AT lowlatency.de
        koffice-karbon - 1.6.2-3.fc7.i386    (49 days)
        koffice-kivio - 1.6.2-3.fc7.i386    (49 days)
        koffice-kspread - 1.6.2-3.fc7.i386    (49 days)

    bjohnson AT symetrix.com
        dbmail - 2.2.4-4.fc7.i386    (91 days)

    gauret AT free.fr
        glest-data - 2.0.0-2.fc7.noarch    (45 days)

    lxtnow AT gmail.com
        python-gammu - 0.20-1.fc7.i386    (62 days)
        python-gammu - 0.20-1.fc7.ppc    (62 days)
        python-gammu - 0.20-1.fc7.x86_64    (62 days)

    tcallawa AT redhat.com
        compat-wxGTK-devel - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.ppc    (80 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.x86_64    (80 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.ppc    (80 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.x86_64    (80 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.ppc    (80 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.x86_64    (80 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.i386    (80 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.ppc    (80 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64    (80 days)

    twoerner AT redhat.com
        postfix-pflogsumm - 2:2.4.3-2.fc7.i386    (111 days)
        postfix-pflogsumm - 2:2.4.3-2.fc7.ppc    (111 days)
        postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64    (111 days)


======================================================================
Broken packages in fedora-7-i386:

    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-gl-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6


======================================================================
Broken packages in fedora-7-ppc:

    compat-wxGTK-devel-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.ppc  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-gl-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    glest-data-2.0.0-2.fc7.noarch  requires  glest = 0:2.0.0


======================================================================
Broken packages in fedora-7-x86_64:

    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-devel-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.x86_64  requires  libwx_gtk-2.4.so.0()(64bit)
    compat-wxGTK-gl-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-gl-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    dbmail-2.2.4-4.fc7.i386  requires  dbmail-database-driver = 0:2.2.4-4.fc7
    koffice-karbon-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7
    koffice-kivio-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7
    koffice-kspread-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7


======================================================================
Broken packages in fedora-updates-7-i386:

    postfix-pflogsumm-2:2.4.3-2.fc7.i386  requires  postfix = 0:2.4.3-2.fc7
    python-gammu-0.20-1.fc7.i386  requires  libGammu.so.1


======================================================================
Broken packages in fedora-updates-7-ppc:

    postfix-pflogsumm-2:2.4.3-2.fc7.ppc  requires  postfix = 0:2.4.3-2.fc7
    python-gammu-0.20-1.fc7.ppc  requires  libGammu.so.1


======================================================================
Broken packages in fedora-updates-7-x86_64:

    postfix-pflogsumm-2:2.4.3-2.fc7.x86_64  requires  postfix = 0:2.4.3-2.fc7
    python-gammu-0.20-1.fc7.x86_64  requires  libGammu.so.1()(64bit)



From oliver at linux-kernel.at  Thu Oct  4 11:40:05 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 04 Oct 2007 13:40:05 +0200
Subject: short koji repo question
In-Reply-To: <20071004061944.2fe6427a@redhat.com>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>	<4703669C.2060600@linux-kernel.at>	<20071003073244.538e9091@redhat.com>	<4703FD44.4060708@linux-kernel.at>
	<20071004061944.2fe6427a@redhat.com>
Message-ID: <4704D115.8050500@linux-kernel.at>

On 10/04/2007 12:19 PM, Jesse Keating wrote:
> On Wed, 03 Oct 2007 22:36:20 +0200
> Oliver Falk <oliver at linux-kernel.at> wrote:
> 
>> Is there any good reason, why koji doesn't also create the sqlite
>> database with createrepo (passing -d option)?
>>
>> For slow arches, it would speed up the init phase of the build-root...
>> For the fast arches, well it would also be faster I think...
>>
>> If someone is going to change/try that. Let me know the progress. I
>> tried that on our Alpha Koji, but encountered a problem...
> 
> Mostly because the development of koji happened mostly on RHEL4/5
> machines which lack a createrepo that can do -d.
> 
> 

Well. Sooner or later you'll have sqlite support for createrepo on your
machines and then:

--- /usr/sbin/kojid     2007-10-04 13:36:32.000000000 +0200
+++ /tmp/kojid  2007-10-04 13:36:15.000000000 +0200
@@ -2244,7 +2244,7 @@
         outdir = "%s/repo" % self.workdir
         datadir = "%s/repodata" % outdir
         koji.ensuredir(outdir)
-        cmd = ['/usr/bin/createrepo', '-vpd', '--outputdir', outdir]
+        cmd = ['/usr/bin/createrepo', '-vp', '--outputdir', outdir]
         if os.path.exists("%s/comps.xml" % repodir):
             cmd.extend(['-g', 'comps.xml'])
         #attempt to recycle repodata from last repo
@@ -2272,7 +2272,7 @@

         files = []
         for f in os.listdir(datadir):
-            if f.endswith('.xml') or f.endswith('.xml.gz') or
f.endswith('.bz2'):
+            if f.endswith('.xml') or f.endswith('.xml.gz'):
                 files.append(f)
                 session.uploadWrapper("%s/%s" % (datadir, f),
uploadpath, f)


I can do more digging and check if I can add some config key and >if<
that two lines of code... Or we simply check which version of createrepo
introduced -d and BR it in koji spec...

I can also open a ticket on hosted, if you prefer!?

Best,
 Oliver



From debarshi.ray at gmail.com  Thu Oct  4 11:54:13 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 4 Oct 2007 17:24:13 +0530
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <6lodffuo9z.fsf@allele2.eebweb.arizona.edu>
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>
	<6lodffuo9z.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>

> I think it's already been taken (the announcement was made a while
> back on the old fedora-maintainers list).  According to pkgdb it's now
> owned by Johan Cwiklinski.  See:
>
> https://admin.fedoraproject.org/pkgdb/packages/name/BackupPC

Ah! Ok, no problem. :-)

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jdieter at gmail.com  Thu Oct  4 12:02:57 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 04 Oct 2007 15:02:57 +0300
Subject: short koji repo question
In-Reply-To: <4704D115.8050500@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>
	<4703669C.2060600@linux-kernel.at>	<20071003073244.538e9091@redhat.com>
	<4703FD44.4060708@linux-kernel.at> <20071004061944.2fe6427a@redhat.com>
	<4704D115.8050500@linux-kernel.at>
Message-ID: <1191499377.20293.13.camel@jndwidescreen.lesbg.loc>

On Thu, 2007-10-04 at 13:40 +0200, Oliver Falk wrote:
> Well. Sooner or later you'll have sqlite support for createrepo on your
> machines and then:
> 
> --- /usr/sbin/kojid     2007-10-04 13:36:32.000000000 +0200
> +++ /tmp/kojid  2007-10-04 13:36:15.000000000 +0200
> @@ -2244,7 +2244,7 @@
>          outdir = "%s/repo" % self.workdir
>          datadir = "%s/repodata" % outdir
>          koji.ensuredir(outdir)
> -        cmd = ['/usr/bin/createrepo', '-vpd', '--outputdir', outdir]
> +        cmd = ['/usr/bin/createrepo', '-vp', '--outputdir', outdir]
>          if os.path.exists("%s/comps.xml" % repodir):
>              cmd.extend(['-g', 'comps.xml'])
>          #attempt to recycle repodata from last repo
> @@ -2272,7 +2272,7 @@
> 
>          files = []
>          for f in os.listdir(datadir):
> -            if f.endswith('.xml') or f.endswith('.xml.gz') or
> f.endswith('.bz2'):
> +            if f.endswith('.xml') or f.endswith('.xml.gz'):
>                  files.append(f)
>                  session.uploadWrapper("%s/%s" % (datadir, f),
> uploadpath, f)
> 
> 
> I can do more digging and check if I can add some config key and >if<
> that two lines of code... Or we simply check which version of createrepo
> introduced -d and BR it in koji spec...
> 
> I can also open a ticket on hosted, if you prefer!?
> 
> Best,
>  Oliver
> 

I think your patch is backward.  Shouldn't the -'s be +'s and visa
versa?

Jonathan
-------------- 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/20071004/e045882b/attachment.sig>

From mike at miketc.com  Thu Oct  4 12:20:45 2007
From: mike at miketc.com (Mike Chambers)
Date: Thu, 04 Oct 2007 07:20:45 -0500
Subject: Echo Icons changed (WAS: Re: Icons enlarged)
In-Reply-To: <1191464544.2247.2.camel@scrappy.miketc.com>
References: <1191464544.2247.2.camel@scrappy.miketc.com>
Message-ID: <1191500445.9540.1.camel@scrappy.miketc.com>

On Wed, 2007-10-03 at 21:22 -0500, Mike Chambers wrote:
> I may have missed this topic/bug if it was discussed due to some other
> reasons, but wanted to point it out anyway just in case.  I have noticed
> that after today's rawhide updates that lot of my icons and buttons are
> enlarged?  Like some of my evo buttons are really big,and the volume
> control icon on my panel is big.  But nothing else on the panel is.  I
> am also running the echo-icon-them just in case that is relevant.

Have narrowed down to the echo icons being the ones that seem to be
affected by the enlargements.  Any chance someone knows what is going on
with this package?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From oliver at linux-kernel.at  Thu Oct  4 12:23:41 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 04 Oct 2007 14:23:41 +0200
Subject: short koji repo question
In-Reply-To: <1191499377.20293.13.camel@jndwidescreen.lesbg.loc>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>	<4703669C.2060600@linux-kernel.at>	<20071003073244.538e9091@redhat.com>	<4703FD44.4060708@linux-kernel.at>
	<20071004061944.2fe6427a@redhat.com>	<4704D115.8050500@linux-kernel.at>
	<1191499377.20293.13.camel@jndwidescreen.lesbg.loc>
Message-ID: <4704DB4D.90103@linux-kernel.at>

On 10/04/2007 02:02 PM, Jonathan Dieter wrote:
> On Thu, 2007-10-04 at 13:40 +0200, Oliver Falk wrote:
>> Well. Sooner or later you'll have sqlite support for createrepo on your
>> machines and then:
>>
>> --- /usr/sbin/kojid     2007-10-04 13:36:32.000000000 +0200
>> +++ /tmp/kojid  2007-10-04 13:36:15.000000000 +0200
>> @@ -2244,7 +2244,7 @@
>>          outdir = "%s/repo" % self.workdir
>>          datadir = "%s/repodata" % outdir
>>          koji.ensuredir(outdir)
>> -        cmd = ['/usr/bin/createrepo', '-vpd', '--outputdir', outdir]
>> +        cmd = ['/usr/bin/createrepo', '-vp', '--outputdir', outdir]
>>          if os.path.exists("%s/comps.xml" % repodir):
>>              cmd.extend(['-g', 'comps.xml'])
>>          #attempt to recycle repodata from last repo
>> @@ -2272,7 +2272,7 @@
>>
>>          files = []
>>          for f in os.listdir(datadir):
>> -            if f.endswith('.xml') or f.endswith('.xml.gz') or
>> f.endswith('.bz2'):
>> +            if f.endswith('.xml') or f.endswith('.xml.gz'):
>>                  files.append(f)
>>                  session.uploadWrapper("%s/%s" % (datadir, f),
>> uploadpath, f)
>>
>>
>> I can do more digging and check if I can add some config key and >if<
>> that two lines of code... Or we simply check which version of createrepo
>> introduced -d and BR it in koji spec...
>>
>> I can also open a ticket on hosted, if you prefer!?
>>
>> Best,
>>  Oliver
>>
> 
> I think your patch is backward.  Shouldn't the -'s be +'s and visa
> versa?

Oh yes. Sorry:
--- /tmp/kojid  2007-10-04 13:36:15.000000000 +0200
+++ /usr/sbin/kojid     2007-10-04 13:36:32.000000000 +0200
@@ -2244,7 +2244,7 @@
         outdir = "%s/repo" % self.workdir
         datadir = "%s/repodata" % outdir
         koji.ensuredir(outdir)
-        cmd = ['/usr/bin/createrepo', '-vp', '--outputdir', outdir]
+        cmd = ['/usr/bin/createrepo', '-vpd', '--outputdir', outdir]
         if os.path.exists("%s/comps.xml" % repodir):
             cmd.extend(['-g', 'comps.xml'])
         #attempt to recycle repodata from last repo
@@ -2272,7 +2272,7 @@

         files = []
         for f in os.listdir(datadir):
-            if f.endswith('.xml') or f.endswith('.xml.gz'):
+            if f.endswith('.xml') or f.endswith('.xml.gz') or
f.endswith('.bz2'):
                 files.append(f)
                 session.uploadWrapper("%s/%s" % (datadir, f),
uploadpath, f)


-of



From caillon at redhat.com  Thu Oct  4 12:38:24 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 04 Oct 2007 08:38:24 -0400
Subject: Default Firefox settings
In-Reply-To: <4704622E.4020602@conversis.de>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>	<4703CBB8.5060109@kanarip.com>	<4703CF27.4000002@redhat.com>
	<4704622E.4020602@conversis.de>
Message-ID: <4704DEC0.6070609@redhat.com>

Dennis Jacobfeuerborn wrote:
> Does there exist any useful statistical data out there to verify the 
> "not insignificant number" claim? I've been browsing the web with 
> pipelining enabled for ages and have yet to come across a page that 
> doesn't work. Is the problem real or one of these myths that stay around 
> because people read on the internet that pipelining has problems so it 
> must be true?

You could look to see how many Apache 1.3.x webservers are out there 
still via Netcraft, etc.  Unless it's had a patch to it (I've not kept 
up on Apache 1.3).  My blog post [1] should help you figure out what 
data to look for if you want to figure this out.

[1] http://christopher.aillon.org/blog/dev/mozilla/20050105-pipelining.html



From mattdm at mattdm.org  Thu Oct  4 12:43:07 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 4 Oct 2007 08:43:07 -0400
Subject: Default Firefox settings
In-Reply-To: <19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
	<16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
	<19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
Message-ID: <20071004124307.GA735@jadzia.bu.edu>

On Thu, Oct 04, 2007 at 10:05:07AM +0200, Nicolas Mailhot wrote:
> The problem is firefox sucks big time when you're behind a proxy - as
> soon as the proxy is slow to answer for one tab all the others start
> being sluggish/frozen (I suppose firefox has internal locking where
> the cost of some locks is only evident in a proxy context)

I think this is because network.http.max-connections-per-server, which
defaults to 8, applies to the *proxy server* when using a proxy. Crank that
number way up (as much as whoever is running your proxy will allow) and
watch that problem go away).




-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From caillon at redhat.com  Thu Oct  4 12:43:26 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 04 Oct 2007 08:43:26 -0400
Subject: Default Firefox settings
In-Reply-To: <4704DEC0.6070609@redhat.com>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>	<4703CBB8.5060109@kanarip.com>	<4703CF27.4000002@redhat.com>	<4704622E.4020602@conversis.de>
	<4704DEC0.6070609@redhat.com>
Message-ID: <4704DFEE.3030900@redhat.com>

I wrote:
> You could look to see how many Apache 1.3.x webservers are out there 
> still via Netcraft, etc.  Unless it's had a patch to it (I've not kept 
> up on Apache 1.3).  My blog post [1] should help you figure out what 
> data to look for if you want to figure this out.

Also, see
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A%5Bpipelining%5D 
which has a bug list of things that need fixing before enabling 
pipelining by default, including some sites which break.



From nicolas.mailhot at laposte.net  Thu Oct  4 13:17:44 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 4 Oct 2007 15:17:44 +0200 (CEST)
Subject: Default Firefox settings
In-Reply-To: <20071004124307.GA735@jadzia.bu.edu>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
	<16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
	<19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
	<20071004124307.GA735@jadzia.bu.edu>
Message-ID: <38158.192.54.193.51.1191503864.squirrel@rousalka.dyndns.org>


Le Jeu 4 octobre 2007 14:43, Matthew Miller a ?crit :
> On Thu, Oct 04, 2007 at 10:05:07AM +0200, Nicolas Mailhot wrote:
>> The problem is firefox sucks big time when you're behind a proxy -
>> as
>> soon as the proxy is slow to answer for one tab all the others start
>> being sluggish/frozen (I suppose firefox has internal locking where
>> the cost of some locks is only evident in a proxy context)
>
> I think this is because network.http.max-connections-per-server, which
> defaults to 8, applies to the *proxy server* when using a proxy. Crank
> that
> number way up (as much as whoever is running your proxy will allow)
> and watch that problem go away).

Unfortunately this does not seem to work. For some obscure reason as
soon as a page contains stuff hosted at a site the proxy does not
like, all the firefox UI freezes waiting for the proxy to relay it (it
won't), instead of  recovering gracefully and processing the other
stuff (like it does on direct connexion when a website is dead)

-- 
Nicolas Mailhot




From katzj at redhat.com  Thu Oct  4 14:28:38 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 04 Oct 2007 10:28:38 -0400
Subject: Announcing Fedora 8 Test 3 (7.92)!
Message-ID: <1191508118.5234.11.camel@localhost.localdomain>

Fedora 8 Test 3 is here! This is the last test release before the
development freeze and a great time to test all those packages that you
know and love. Test 3 is for beta users. This is the time when we must
have full community participation. Without this participation both
hardware and software functionality suffers.

Fedora is a Linux-based operating system that showcases the latest in
free and open source software. Fedora is always free for anyone to use,
modify, and distribute. It is built by people across the globe who work
together as a community: the Fedora Project. The Fedora Project is open
and anyone is welcome to join.

Up-to-date release notes for Fedora 8 Test 3 can be found at
http://docs.fedoraproject.org/release-notes.

== Changes from Fedora 8 Test 2 ==

 * Online Desktop provides a desktop experience designed around online
services. A preview of Online Desktop is provided via BigBoard, which is
a optional sidebar in GNOME.

 * KDE 3.5.7 is available in the KDE Live image as well as the regular
DVD. The KDE 4 (Beta) Development Environment is available in the
repository.

 * Live installations are faster and require a smaller root filesystem.
The file system layout has also changed somewhat.  System files for the
Live images are now under `LiveOS/`, and a new `README` file has been
provided as a short introduction to the live image.

 * Package management now features much better performance via `yum` and
friends.

 * The completely free and open source Java environment called Iced Tea
is installed by default.  Iced Tea is derived from OpenJDK, includes a
browser plugin based on GCJ, and is available for both x86 and x86_64
architectures. GCJ is still the default on PPC architecture. 

 * CodecBuddy is now included, and promotes free, superior quality, open
formats to end users trying to play multimedia content under patent
encumbered or proprietary formats.

 * Bluetooth devices and tools now have better graphical and system
integration.

 * Laptop users benefit from the "quirks" features in HAL, including
better suspend/resume and multimedia keyboard support.

 * There is now improved power management thanks to both a tickless
kernel in `x86` and `x86_64` architectures, and a reduction in
unnecessary processor wakeups via `powertop`.

 * Eclipse 3.3 (Europa), a new release of the great IDE and development
platform, is available as part of this release. 

 * The `pam_console` module has been removed in favor of access control
via HAL, which modernizes the desktop.

 * NetworkManager 0.7 provides improved wireless network management
support. It includes support for multiple devices and provides the
capability of system-wide configuration, among many other enhancements.
This transition may induce some regressions temporarily, and more
testing and feedback is appreciated. 

 * Secure remote management capability is now provided for Xen, KVM, and
QEMU virtualization.

 * Transifex provides a web-based translation interface to allow users
to contribute translation work for Fedora hosted projects as well as
being able to provide translations to upstream directly to any upstream
project.

 * Integration of unique build IDs into Fedora's software building
infrastructure now provide enhanced debugging capabilities and core
dumps.

 * Fedora now offers easier rebranding of Fedora derivatives via a
`generic-logos` software package. Changes in Fedora's mirror structure
also make creation of derivatives easier. 
 
 * Fedora now includes support for Nepali Language, extending its reach
to many more users. 

=== What's New in Fedora 8 ===

 * A major list of features is available at
http://fedoraproject.org/wiki/Releases/8/FeatureList.

=== Release Schedule for Fedora 8 ===

 * The Fedora 8 release schedule can be found at
http://fedoraproject.org/wiki/Releases/8/Schedule. Fedora 8 is scheduled
for general release on 8 November 2007.

=== How to Get Fedora 8 Test 3 ===

 * Fedora 8 Test 3 can be installed via Live image, regular DVD, or via
network installation.  You can find the DVD images as well as the
primary live images at:

http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/

 * You can also download the DVD and Live images via bittorrent at:

http://torrent.fedoraproject.org

 * More information on the various spins available with the release of
Fedora 8 Test 3 is available at:

http://fedoraproject.org/wiki/F8Test3/Spins

People who are already running the rawhide (development) branch of
Fedora or any of the previous test releases can simply run `yum update`.
(Some current Rawhide packages might be newer than Fedora 8 Test 3
packages.)  We also appreciate new installation testing for feedback on
changes to the Anaconda installer. 

== Known Issues ==

 * [https://bugzilla.redhat.com/show_bug.cgi?id=302381 Bug 302381] If
you are installing via DVD or also possibly NFS-mounted ISO images, the
Add/Remove Programs application (`pirut`) may crash when run, with a
traceback about HAL. Running `yum update` or using `yum` to update at
least `pirut` should resolve the issue. 

 * [https://bugzilla.redhat.com/show_bug.cgi?id=298991 Bug 298991] The
KDE NetworkManager frontend `knetworkmanager`, a graphical interface for
switching between networks easily, is currently broken. This is intended
be fixed before Fedora 8 release. The KDE Live images have `nm-applet`,
which works with KDE, enabled by default as a workaround.

 * Other Common issues can be found at
http://fedoraproject.org/wiki/Bugs/F8Common.

=== Bug Reporting and tracking ===

You can follow the procedure outlined in
http://fedoraproject.org/wiki/BugsandFeatureRequests to report any bugs
found in your testing. 

The Release Engineering and QA teams keep track of bugs that are
considered release blockers. To see that list, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Blocker 

To see a list of additional non-blocker bugs that should hopefully be
fixed for Fedora 8, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Target 

Please check these lists before reporting new bugs!


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From jonathan.underwood at gmail.com  Thu Oct  4 14:44:38 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 4 Oct 2007 15:44:38 +0100
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>
	<6lodffuo9z.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>
Message-ID: <645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>

On 04/10/2007, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
> > I think it's already been taken (the announcement was made a while
> > back on the old fedora-maintainers list).  According to pkgdb it's now
> > owned by Johan Cwiklinski.  See:
> >
> > https://admin.fedoraproject.org/pkgdb/packages/name/BackupPC
>
> Ah! Ok, no problem. :-)

You could approach Johan and see if he would like a co-maintainer -
BackupPC is quite a complex package.

J.



From sundaram at fedoraproject.org  Thu Oct  4 14:41:53 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 04 Oct 2007 20:11:53 +0530
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>
References: <46CCFAF3.2070506@redhat.com>	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>	<6lodffuo9z.fsf@allele2.eebweb.arizona.edu>	<3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>
	<645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>
Message-ID: <4704FBB1.4000501@fedoraproject.org>

Jonathan Underwood wrote:
> On 04/10/2007, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
>>> I think it's already been taken (the announcement was made a while
>>> back on the old fedora-maintainers list).  According to pkgdb it's now
>>> owned by Johan Cwiklinski.  See:
>>>
>>> https://admin.fedoraproject.org/pkgdb/packages/name/BackupPC
>> Ah! Ok, no problem. :-)
> 
> You could approach Johan and see if he would like a co-maintainer -
> BackupPC is quite a complex package.

Right. There were a discussion recently in fedora-list where folks were 
asking for better documentation like a README.Fedora file for this package.

Rahul



From buc at odusz.so-cdu.ru  Thu Oct  4 14:48:40 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 04 Oct 2007 18:48:40 +0400
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <1191508118.5234.11.camel@localhost.localdomain>
References: <1191508118.5234.11.camel@localhost.localdomain>
Message-ID: <4704FD48.10502@odu.neva.ru>

Jeremy Katz wrote:
>  * The `pam_console` module has been removed in favor of access control
> via HAL, which modernizes the desktop.
>   

Oops...

I use pam_console for the "login once" feature, i.e. after the first 
login from one of the console ttys or gdm the next logins (gdm or 
console) are without password.

What I have to do now? :(

Provide some patch for hal for the same feature? (As well as I had 
created the applied patch for pam_console auth some years ago)...


Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From tmraz at redhat.com  Thu Oct  4 14:53:16 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 04 Oct 2007 16:53:16 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <4704FD48.10502@odu.neva.ru>
References: <1191508118.5234.11.camel@localhost.localdomain>
	<4704FD48.10502@odu.neva.ru>
Message-ID: <1191509596.5795.2.camel@vespa.kabelta.loc>


On Thu, 2007-10-04 at 18:48 +0400, Dmitry Butskoy wrote:
> Jeremy Katz wrote:
> >  * The `pam_console` module has been removed in favor of access control
> > via HAL, which modernizes the desktop.
> >   
> 
> Oops...
> 
> I use pam_console for the "login once" feature, i.e. after the first 
> login from one of the console ttys or gdm the next logins (gdm or 
> console) are without password.
> 
> What I have to do now? :(
pam_console as a module will still be there for some time I think. Only
the management of device permissions and ownership for most devices was
taken out from its configuration.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From paul at all-the-johnsons.co.uk  Thu Oct  4 15:02:15 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 04 Oct 2007 16:02:15 +0100
Subject: Getting my broadcom wireless card to work with rawhide
Message-ID: <1191510135.4157.22.camel@localhost.localdomain>

Hi,

I have a broadcom wireless card in my box. lspci is showing it haapily
as

02:06.0 Network controller: Broadcom Corporation BCM4318 [AirForce One
54g] 802.11g Wireless LAN Controller (rev 02)

and b43 is showing up in lsmod.

I've used b43-fcutter to install the firmware into /lib/firmware/b43 and
have an alias in /etc/modprobe.conf for wlan0

So far so good - the activity light comes on on the card and I'm happy.

My problem comes activating it. /sbin/ifup wlan0 comes up with

Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Device or resource busy

It can then not get an IP address. dmesg gives me

b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:1b:2f:44:23:32
wlan0: authenticate with AP 00:1b:2f:44:23:32
wlan0: authenticate with AP 00:1b:2f:44:23:32
wlan0: authentication with AP 00:1b:2f:44:23:32 timed out

How do I get it to work? I'm using the v4 driver

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071004/114383fe/attachment.sig>

From mikeb at redhat.com  Thu Oct  4 15:27:52 2007
From: mikeb at redhat.com (Mike Bonnet)
Date: Thu, 04 Oct 2007 11:27:52 -0400
Subject: short koji repo question
In-Reply-To: <4703FD44.4060708@linux-kernel.at>
References: <47021F9D.7060103@linux-kernel.at>
	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>
	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>
	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>
	<4703669C.2060600@linux-kernel.at> <20071003073244.538e9091@redhat.com>
	<4703FD44.4060708@linux-kernel.at>
Message-ID: <1191511672.9485.10.camel@localhost.localdomain>

On Wed, 2007-10-03 at 22:36 +0200, Oliver Falk wrote:
> Hi!
> 
> Is there any good reason, why koji doesn't also create the sqlite
> database with createrepo (passing -d option)?

createrepo in koji also uses the --update flag if a previous repo
exists.  This causes it to parse the existing repodata and reuse it for
all packages that haven't changed.  This is a *huge* increase in speed,
since only 1 or 2 packages have changed between repo regens in the
normal case.

I'm not sure if --update will work with sqlite database, but if not, I'd
like to see that support added before changing the createrepo call.

> For slow arches, it would speed up the init phase of the build-root...
> For the fast arches, well it would also be faster I think...
> 
> If someone is going to change/try that. Let me know the progress. I
> tried that on our Alpha Koji, but encountered a problem...




From johan at x-tnd.be  Thu Oct  4 15:31:35 2007
From: johan at x-tnd.be (Johan Cwiklinski)
Date: Thu, 04 Oct 2007 17:31:35 +0200
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <4704FBB1.4000501@fedoraproject.org>
References: <46CCFAF3.2070506@redhat.com>	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>	<6lodffuo9z.fsf@allele2.eebweb.arizona.edu>	<3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>	<645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>
	<4704FBB1.4000501@fedoraproject.org>
Message-ID: <47050757.1000606@x-tnd.be>

Rahul Sundaram a ?crit :
> Jonathan Underwood wrote:
>> On 04/10/2007, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
>>>> I think it's already been taken (the announcement was made a while
>>>> back on the old fedora-maintainers list).  According to pkgdb it's now
>>>> owned by Johan Cwiklinski.  See:
>>>>
>>>> https://admin.fedoraproject.org/pkgdb/packages/name/BackupPC
>>> Ah! Ok, no problem. :-)
>>
>> You could approach Johan and see if he would like a co-maintainer -
>> BackupPC is quite a complex package.
>
> Right. There were a discussion recently in fedora-list where folks
> were asking for better documentation like a README.Fedora file for
> this package.
>
> Rahul
>
Hello,

I'll take a look at fedora-list to know what was asked.

Actually, if someone want to co-maintain this package, he'll be welcome...
Feel free to contact me about it :)

Regards,
Johan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/8a6db875/attachment.sig>

From martin.sourada at seznam.cz  Thu Oct  4 15:34:13 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Thu, 04 Oct 2007 17:34:13 +0200
Subject: Echo Icons changed (WAS: Re: Icons enlarged)
In-Reply-To: <1191500445.9540.1.camel@scrappy.miketc.com>
References: <1191464544.2247.2.camel@scrappy.miketc.com>
	<1191500445.9540.1.camel@scrappy.miketc.com>
Message-ID: <1191512053.1374.22.camel@pc-notebook.kolej.mff.cuni.cz>


On Thu, 2007-10-04 at 14:20 +0200, Mike Chambers wrote:
> On Wed, 2007-10-03 at 21:22 -0500, Mike Chambers wrote:
> > I may have missed this topic/bug if it was discussed due to some other
> > reasons, but wanted to point it out anyway just in case.  I have noticed
> > that after today's rawhide updates that lot of my icons and buttons are
> > enlarged?  Like some of my evo buttons are really big,and the volume
> > control icon on my panel is big.  But nothing else on the panel is.  I
> > am also running the echo-icon-them just in case that is relevant.
> 
> Have narrowed down to the echo icons being the ones that seem to be
> affected by the enlargements.  Any chance someone knows what is going on
> with this package?
> 
> -- 
> Mike Chambers
> Madisonville, KY
> 
> "Best lil town on Earth!"
> 

Oh, yeah, wrong index.theme file (optimised for enabled SVGs, but we
didn't include them). We'll try to fix it soonish.

cc-ing art-list and Luya.

Martin



From debarshi.ray at gmail.com  Thu Oct  4 15:36:17 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 4 Oct 2007 21:06:17 +0530
Subject: [sqlite2] Re: Orphaning packages
In-Reply-To: <645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>
References: <46CCFAF3.2070506@redhat.com>
	<641wcbiy1e.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040053y1fbbe235rebfe40e8ca0288cb@mail.gmail.com>
	<6lodffuo9z.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0710040454j6d01a2a7o41d07c33f717bd05@mail.gmail.com>
	<645d17210710040744j676934adq70cb92009202bb69@mail.gmail.com>
Message-ID: <3170f42f0710040836q43c08cb0p6a6329085c81a1d2@mail.gmail.com>

> You could approach Johan and see if he would like a co-maintainer -
> BackupPC is quite a complex package.

I guess I would leave him to do it for the moment. :-)

Good luck,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From katzj at redhat.com  Thu Oct  4 14:45:47 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 4 Oct 2007 16:45:47 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
Message-ID: <000001c80695$3ff8e8b0$ba00000a@grecom.local>

Fedora 8 Test 3 is here! This is the last test release before the
development freeze and a great time to test all those packages that you
know and love. Test 3 is for beta users. This is the time when we must
have full community participation. Without this participation both
hardware and software functionality suffers.

Fedora is a Linux-based operating system that showcases the latest in
free and open source software. Fedora is always free for anyone to use,
modify, and distribute. It is built by people across the globe who work
together as a community: the Fedora Project. The Fedora Project is open
and anyone is welcome to join.

Up-to-date release notes for Fedora 8 Test 3 can be found at
http://docs.fedoraproject.org/release-notes.

== Changes from Fedora 8 Test 2 ==

 * Online Desktop provides a desktop experience designed around online
services. A preview of Online Desktop is provided via BigBoard, which is
a optional sidebar in GNOME.

 * KDE 3.5.7 is available in the KDE Live image as well as the regular
DVD. The KDE 4 (Beta) Development Environment is available in the
repository.

 * Live installations are faster and require a smaller root filesystem.
The file system layout has also changed somewhat.  System files for the
Live images are now under `LiveOS/`, and a new `README` file has been
provided as a short introduction to the live image.

 * Package management now features much better performance via `yum` and
friends.

 * The completely free and open source Java environment called Iced Tea
is installed by default.  Iced Tea is derived from OpenJDK, includes a
browser plugin based on GCJ, and is available for both x86 and x86_64
architectures. GCJ is still the default on PPC architecture. 

 * CodecBuddy is now included, and promotes free, superior quality, open
formats to end users trying to play multimedia content under patent
encumbered or proprietary formats.

 * Bluetooth devices and tools now have better graphical and system
integration.

 * Laptop users benefit from the "quirks" features in HAL, including
better suspend/resume and multimedia keyboard support.

 * There is now improved power management thanks to both a tickless
kernel in `x86` and `x86_64` architectures, and a reduction in
unnecessary processor wakeups via `powertop`.

 * Eclipse 3.3 (Europa), a new release of the great IDE and development
platform, is available as part of this release. 

 * The `pam_console` module has been removed in favor of access control
via HAL, which modernizes the desktop.

 * NetworkManager 0.7 provides improved wireless network management
support. It includes support for multiple devices and provides the
capability of system-wide configuration, among many other enhancements.
This transition may induce some regressions temporarily, and more
testing and feedback is appreciated. 

 * Secure remote management capability is now provided for Xen, KVM, and
QEMU virtualization.

 * Transifex provides a web-based translation interface to allow users
to contribute translation work for Fedora hosted projects as well as
being able to provide translations to upstream directly to any upstream
project.

 * Integration of unique build IDs into Fedora's software building
infrastructure now provide enhanced debugging capabilities and core
dumps.

 * Fedora now offers easier rebranding of Fedora derivatives via a
`generic-logos` software package. Changes in Fedora's mirror structure
also make creation of derivatives easier. 
 
 * Fedora now includes support for Nepali Language, extending its reach
to many more users. 

=== What's New in Fedora 8 ===

 * A major list of features is available at
http://fedoraproject.org/wiki/Releases/8/FeatureList.

=== Release Schedule for Fedora 8 ===

 * The Fedora 8 release schedule can be found at
http://fedoraproject.org/wiki/Releases/8/Schedule. Fedora 8 is scheduled
for general release on 8 November 2007.

=== How to Get Fedora 8 Test 3 ===

 * Fedora 8 Test 3 can be installed via Live image, regular DVD, or via
network installation.  You can find the DVD images as well as the
primary live images at:

http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/

 * You can also download the DVD and Live images via bittorrent at:

http://torrent.fedoraproject.org

 * More information on the various spins available with the release of
Fedora 8 Test 3 is available at:

http://fedoraproject.org/wiki/F8Test3/Spins

People who are already running the rawhide (development) branch of
Fedora or any of the previous test releases can simply run `yum update`.
(Some current Rawhide packages might be newer than Fedora 8 Test 3
packages.)  We also appreciate new installation testing for feedback on
changes to the Anaconda installer. 

== Known Issues ==

 * [https://bugzilla.redhat.com/show_bug.cgi?id=302381 Bug 302381] If
you are installing via DVD or also possibly NFS-mounted ISO images, the
Add/Remove Programs application (`pirut`) may crash when run, with a
traceback about HAL. Running `yum update` or using `yum` to update at
least `pirut` should resolve the issue. 

 * [https://bugzilla.redhat.com/show_bug.cgi?id=298991 Bug 298991] The
KDE NetworkManager frontend `knetworkmanager`, a graphical interface for
switching between networks easily, is currently broken. This is intended
be fixed before Fedora 8 release. The KDE Live images have `nm-applet`,
which works with KDE, enabled by default as a workaround.

 * Other Common issues can be found at
http://fedoraproject.org/wiki/Bugs/F8Common.

=== Bug Reporting and tracking ===

You can follow the procedure outlined in
http://fedoraproject.org/wiki/BugsandFeatureRequests to report any bugs
found in your testing. 

The Release Engineering and QA teams keep track of bugs that are
considered release blockers. To see that list, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Blocker 

To see a list of additional non-blocker bugs that should hopefully be
fixed for Fedora 8, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Target 

Please check these lists before reporting new bugs!


-- 
fedora-announce-list mailing list
fedora-announce-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-announce-list


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From katzj at redhat.com  Thu Oct  4 14:45:47 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 4 Oct 2007 16:45:47 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
Message-ID: <001301c80695$4023c940$ba00000a@grecom.local>

Fedora 8 Test 3 is here! This is the last test release before the
development freeze and a great time to test all those packages that you
know and love. Test 3 is for beta users. This is the time when we must
have full community participation. Without this participation both
hardware and software functionality suffers.

Fedora is a Linux-based operating system that showcases the latest in
free and open source software. Fedora is always free for anyone to use,
modify, and distribute. It is built by people across the globe who work
together as a community: the Fedora Project. The Fedora Project is open
and anyone is welcome to join.

Up-to-date release notes for Fedora 8 Test 3 can be found at
http://docs.fedoraproject.org/release-notes.

== Changes from Fedora 8 Test 2 ==

 * Online Desktop provides a desktop experience designed around online
services. A preview of Online Desktop is provided via BigBoard, which is
a optional sidebar in GNOME.

 * KDE 3.5.7 is available in the KDE Live image as well as the regular
DVD. The KDE 4 (Beta) Development Environment is available in the
repository.

 * Live installations are faster and require a smaller root filesystem.
The file system layout has also changed somewhat.  System files for the
Live images are now under `LiveOS/`, and a new `README` file has been
provided as a short introduction to the live image.

 * Package management now features much better performance via `yum` and
friends.

 * The completely free and open source Java environment called Iced Tea
is installed by default.  Iced Tea is derived from OpenJDK, includes a
browser plugin based on GCJ, and is available for both x86 and x86_64
architectures. GCJ is still the default on PPC architecture. 

 * CodecBuddy is now included, and promotes free, superior quality, open
formats to end users trying to play multimedia content under patent
encumbered or proprietary formats.

 * Bluetooth devices and tools now have better graphical and system
integration.

 * Laptop users benefit from the "quirks" features in HAL, including
better suspend/resume and multimedia keyboard support.

 * There is now improved power management thanks to both a tickless
kernel in `x86` and `x86_64` architectures, and a reduction in
unnecessary processor wakeups via `powertop`.

 * Eclipse 3.3 (Europa), a new release of the great IDE and development
platform, is available as part of this release. 

 * The `pam_console` module has been removed in favor of access control
via HAL, which modernizes the desktop.

 * NetworkManager 0.7 provides improved wireless network management
support. It includes support for multiple devices and provides the
capability of system-wide configuration, among many other enhancements.
This transition may induce some regressions temporarily, and more
testing and feedback is appreciated. 

 * Secure remote management capability is now provided for Xen, KVM, and
QEMU virtualization.

 * Transifex provides a web-based translation interface to allow users
to contribute translation work for Fedora hosted projects as well as
being able to provide translations to upstream directly to any upstream
project.

 * Integration of unique build IDs into Fedora's software building
infrastructure now provide enhanced debugging capabilities and core
dumps.

 * Fedora now offers easier rebranding of Fedora derivatives via a
`generic-logos` software package. Changes in Fedora's mirror structure
also make creation of derivatives easier. 
 
 * Fedora now includes support for Nepali Language, extending its reach
to many more users. 

=== What's New in Fedora 8 ===

 * A major list of features is available at
http://fedoraproject.org/wiki/Releases/8/FeatureList.

=== Release Schedule for Fedora 8 ===

 * The Fedora 8 release schedule can be found at
http://fedoraproject.org/wiki/Releases/8/Schedule. Fedora 8 is scheduled
for general release on 8 November 2007.

=== How to Get Fedora 8 Test 3 ===

 * Fedora 8 Test 3 can be installed via Live image, regular DVD, or via
network installation.  You can find the DVD images as well as the
primary live images at:

http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/

 * You can also download the DVD and Live images via bittorrent at:

http://torrent.fedoraproject.org

 * More information on the various spins available with the release of
Fedora 8 Test 3 is available at:

http://fedoraproject.org/wiki/F8Test3/Spins

People who are already running the rawhide (development) branch of
Fedora or any of the previous test releases can simply run `yum update`.
(Some current Rawhide packages might be newer than Fedora 8 Test 3
packages.)  We also appreciate new installation testing for feedback on
changes to the Anaconda installer. 

== Known Issues ==

 * [https://bugzilla.redhat.com/show_bug.cgi?id=302381 Bug 302381] If
you are installing via DVD or also possibly NFS-mounted ISO images, the
Add/Remove Programs application (`pirut`) may crash when run, with a
traceback about HAL. Running `yum update` or using `yum` to update at
least `pirut` should resolve the issue. 

 * [https://bugzilla.redhat.com/show_bug.cgi?id=298991 Bug 298991] The
KDE NetworkManager frontend `knetworkmanager`, a graphical interface for
switching between networks easily, is currently broken. This is intended
be fixed before Fedora 8 release. The KDE Live images have `nm-applet`,
which works with KDE, enabled by default as a workaround.

 * Other Common issues can be found at
http://fedoraproject.org/wiki/Bugs/F8Common.

=== Bug Reporting and tracking ===

You can follow the procedure outlined in
http://fedoraproject.org/wiki/BugsandFeatureRequests to report any bugs
found in your testing. 

The Release Engineering and QA teams keep track of bugs that are
considered release blockers. To see that list, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Blocker 

To see a list of additional non-blocker bugs that should hopefully be
fixed for Fedora 8, visit:

 *
http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Target 

Please check these lists before reporting new bugs!


-- 
fedora-announce-list mailing list
fedora-announce-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-announce-list


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From pemboa at gmail.com  Thu Oct  4 15:58:34 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 4 Oct 2007 10:58:34 -0500
Subject: Default Firefox settings
In-Reply-To: <19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
References: <16de708d0710030854k2e50e45bw9da435414d1bbbc@mail.gmail.com>
	<4703CBB8.5060109@kanarip.com>
	<16de708d0710031115v1ca0e581w6933a8ee4d535730@mail.gmail.com>
	<20071003185256.GM6066@angus.ind.WPI.EDU>
	<f6e5806f0710031548i28c1ec85n6f7ca19c1f12390@mail.gmail.com>
	<16de708d0710031603h6dbc52e8i4e658caabf5a028d@mail.gmail.com>
	<19085.192.54.193.51.1191485107.squirrel@rousalka.dyndns.org>
Message-ID: <16de708d0710040858s65925aady6d76ea13a9c97cd5@mail.gmail.com>

On 10/4/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Jeu 4 octobre 2007 01:03, Arthur Pemberton a ?crit :
> > On 10/3/07, darrell pfeifer <darrellpf at gmail.com> wrote:
>
> >> In preferences/network/setting, "auto detect proxy settings" was
> >> set.
> >> I changed to "direct connection to internet" and firefox works at a
> >> decent speed.
>
> > When firefox is slow, it is _really_ slow. Is this acceptable by
> > default?
>
> You do need to auto detect proxy settings - when a proxy is available
> most of the times you won't be allowed direct internet connection.

I don't think I turned of auto proxy detect to get the speed boost.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From oliver at linux-kernel.at  Thu Oct  4 16:22:49 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 04 Oct 2007 18:22:49 +0200
Subject: short koji repo question
In-Reply-To: <1191511672.9485.10.camel@localhost.localdomain>
References: <47021F9D.7060103@linux-kernel.at>	<20071002083628.1de8ff80@redhat.com>	<47023DCA.5050506@linux-kernel.at>	<20071002110223.5cfb5e45@redhat.com>	<47026129.2080001@linux-kernel.at>	<470270C6.60309@linux-kernel.at>	<20071002142722.1857e919@redhat.com>	<4703669C.2060600@linux-kernel.at>
	<20071003073244.538e9091@redhat.com>	<4703FD44.4060708@linux-kernel.at>
	<1191511672.9485.10.camel@localhost.localdomain>
Message-ID: <47051359.9080106@linux-kernel.at>

On 10/04/2007 05:27 PM, Mike Bonnet wrote:
> On Wed, 2007-10-03 at 22:36 +0200, Oliver Falk wrote:
>> Hi!
>>
>> Is there any good reason, why koji doesn't also create the sqlite
>> database with createrepo (passing -d option)?
> 
> createrepo in koji also uses the --update flag if a previous repo
> exists.  This causes it to parse the existing repodata and reuse it for
> all packages that haven't changed.  This is a *huge* increase in speed,
> since only 1 or 2 packages have changed between repo regens in the
> normal case.
> 
> I'm not sure if --update will work with sqlite database, but if not, I'd
> like to see that support added before changing the createrepo call.

I'm quite sure --update doesn't work with sqlite databases. They get
recreated each time AFAICS. In my case, it makes sense, as our Alpha
builders do need a lot of CPU (and time) to create the sqlite database
on their own. The kojihub is a dual cpu intel machine - and is the only
machine doing createrepo - and is very fast in doing so...

If I find some time I'll post the request to work-in sqlite-support into
--update on the correct m/l.

Best,
 Oliver



From dcbw at redhat.com  Thu Oct  4 17:36:28 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 04 Oct 2007 13:36:28 -0400
Subject: NetworkManager-0.7 can't make new wireless connection
In-Reply-To: <20071003222658.GO6066@angus.ind.WPI.EDU>
References: <1190823905.15397.16.camel@vincent52.localdomain>
	<loom.20070926T224337-568@post.gmane.org>
	<f6e5806f0709271028v48022df3t54275de33a25144d@mail.gmail.com>
	<20070927201036.GA21031@jadzia.bu.edu>
	<20070927202009.GR6066@angus.ind.WPI.EDU>
	<1191041189.9155.7.camel@xo-3E-67-34.localdomain>
	<20071003222658.GO6066@angus.ind.WPI.EDU>
Message-ID: <1191519388.27644.7.camel@localhost.localdomain>

On Wed, 2007-10-03 at 18:26 -0400, Chuck Anderson wrote:
> On Sat, Sep 29, 2007 at 12:46:29AM -0400, Dan Williams wrote:
> > On Thu, 2007-09-27 at 16:20 -0400, Chuck Anderson wrote:
> > > On Thu, Sep 27, 2007 at 04:10:36PM -0400, Matthew Miller wrote:
> > > > On Thu, Sep 27, 2007 at 10:28:36AM -0700, darrell pfeifer wrote:
> > > > > With NetworkManager-0.7.0-0.3.svn2886.fc8 most of the strangeness has
> > > > > gone away.  I can use it to connect to wireless networks again without
> > > > > a lot of service restarting.
> > > > 
> > > > Yeah, works for me too.
> > > 
> > > Not working here.  I use the ath5k driver and it scans and find 
> > > wireless networks, but when I click on them (WPA/WPA2 Enterprise 
> > > required) nothing happens--no pop up, no dialog asking for certificate 
> > > files, nothing.
> > 
> > ath5k is still pretty immature; it hasn't worked for me with
> > wpa_supplicant/NM and only recently stopped hanging the machine on even
> > a plain 'ifup' at boot time.  I'll have a go at seeing whether or not
> > this is an NM, wpa_supplicant, or driver problem.  But just know that it
> > may be rocky with ath5k for a while since it's still under really heavy
> > development, about where mac80211 itself was this spring.
> 
> Newer stuff is now working great on the open wireless network I tried.  
> NM scans and finds the network.  I have to manually select it, and it 
> DHCPs and works fine from there on.  This is all with the ath5k 
> driver.
> 
> Unfortunately, WPA/WPA2 Enterprise (e.g. certificate-based, not PSK) 
> is still doing absolutely nothing, no dialog box at all, no chance to 
> configure it with certs...  How is this supposed to work?

It's not supposed to work quite yet.  UI bits still need integrating.

> I built madwifi ath_pci driver from Livna for the 214.rc8.git2.fc8 
> kernel, and it behaves the same way w.r.t. WPA.  I'll retry the open 
> network with that driver later tonight.
> 
> But basically, this seems like a regression.  Wireless networks that 
> worked before should ideally continue to work with the new NM.

Yes, lack of WPA/WPA2 Enterprise (and Dynamic WEP and LEAP) is a
regression that will be fixed by the time F8 GM comes out.

Dan




From linville at redhat.com  Thu Oct  4 17:47:51 2007
From: linville at redhat.com (John W. Linville)
Date: Thu, 4 Oct 2007 13:47:51 -0400
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191510135.4157.22.camel@localhost.localdomain>
References: <1191510135.4157.22.camel@localhost.localdomain>
Message-ID: <20071004174751.GC8375@redhat.com>

On Thu, Oct 04, 2007 at 04:02:15PM +0100, Paul wrote:

> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wlan0 ; Device or resource busy
> 
> It can then not get an IP address. dmesg gives me
> 
> b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac:
> ff:ff:ff:ff:ff:ff
> b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
> ff:ff:ff:ff:ff:ff
> wlan0: Initial auth_alg=0
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authentication with AP 00:1b:2f:44:23:32 timed out
> 
> How do I get it to work? I'm using the v4 driver

What is the content of your ifcfg-wlan0?

John
-- 
John W. Linville
linville at redhat.com



From kagesenshi.87 at gmail.com  Thu Oct  4 18:20:31 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Fri, 5 Oct 2007 02:20:31 +0800
Subject: Icons enlarged
In-Reply-To: <1191464544.2247.2.camel@scrappy.miketc.com>
References: <1191464544.2247.2.camel@scrappy.miketc.com>
Message-ID: <c44298520710041120p7f18ea76o5938c08ec1388e9b@mail.gmail.com>

On 10/4/07, Mike Chambers <mike at miketc.com> wrote:
> I may have missed this topic/bug if it was discussed due to some other
> reasons, but wanted to point it out anyway just in case.  I have noticed
> that after today's rawhide updates that lot of my icons and buttons are
> enlarged?  Like some of my evo buttons are really big,and the volume
> control icon on my panel is big.  But nothing else on the panel is.  I
> am also running the echo-icon-them just in case that is relevant.

I'm experiencing the same issue .. seems like happens only with
echo-icon-theme ..

i've bugzilla'd it .. https://bugzilla.redhat.com/show_bug.cgi?id=318921

>
> --
> Mike Chambers
> Madisonville, KY
>
> "Best lil town on Earth!"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From jon at fedoraunity.org  Thu Oct  4 18:38:53 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Thu, 04 Oct 2007 12:38:53 -0600
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191510135.4157.22.camel@localhost.localdomain>
References: <1191510135.4157.22.camel@localhost.localdomain>
Message-ID: <4705333D.1020800@fedoraunity.org>

Paul wrote:
> Hi,
> 
> I have a broadcom wireless card in my box. lspci is showing it haapily
> as
> 
> 02:06.0 Network controller: Broadcom Corporation BCM4318 [AirForce One
> 54g] 802.11g Wireless LAN Controller (rev 02)


Let me know if you get this card working with b43. I've never had any
luck and currently use ndiswrapper.


> 
> and b43 is showing up in lsmod.
> 
> I've used b43-fcutter to install the firmware into /lib/firmware/b43 and
> have an alias in /etc/modprobe.conf for wlan0
> 
> So far so good - the activity light comes on on the card and I'm happy.
> 
> My problem comes activating it. /sbin/ifup wlan0 comes up with

I got just about as far. The card seemed to "work" but I was unable to
associate with any of the WAPs I could see.


> 
> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wlan0 ; Device or resource busy
> 
> It can then not get an IP address. dmesg gives me
> 
> b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac:
> ff:ff:ff:ff:ff:ff
> b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
> ff:ff:ff:ff:ff:ff
> wlan0: Initial auth_alg=0
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authenticate with AP 00:1b:2f:44:23:32
> wlan0: authentication with AP 00:1b:2f:44:23:32 timed out
> 
> How do I get it to work? I'm using the v4 driver
> 

Jonathan Steffan



From paul at all-the-johnsons.co.uk  Thu Oct  4 18:52:25 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 04 Oct 2007 19:52:25 +0100
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <20071004174751.GC8375@redhat.com>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
Message-ID: <1191523945.4157.25.camel@localhost.localdomain>

Hi,

> > How do I get it to work? I'm using the v4 driver
> 
> What is the content of your ifcfg-wlan0?

I have ifcfg-wireless, but no ifcfg-wlan0

the ifcfg-wireless reads

#!/bin/bash
# Network Interface Configuration System
# Copyright (c) 1996-2002 Red Hat, Inc. all rights reserved.
#
# Based on PCMCIA wireless script by (David Hinds/Jean Tourrilhes)
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License, version 2,
# as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA
#
# Configure wireless network device options.  See iwconfig(8) for more
info.
# Valid variables:
#    MODE: Ad-Hoc, Managed, etc.
#    ESSID: Name of the wireless network
#    NWID: Name of this machine on the network.  Hostname is default
#    FREQ: Frequency to operate on.  See CHANNEL
#    CHANNEL: Numbered frequency to operate on.  See FREQ
#    SENS: Sensitivity threshold for packet rejection.
#    RATE: Transfer rate.  Usually one of Auto, 11, 5, 2, or 1.
#    KEY: Encryption key for WEP.
#    RTS: Explicit RTS handshake.  Usually not specified (auto)
#    FRAG: Fragmentation threshold to split packets.  Usually not
specified.
#    SPYIPS: List of IP addresses to "spy" on for link performance
stats.
#    IWCONFIG: Extra parameters to pass directly to IWCONFIG
#    SECURITYMODE: Security mode, e.g: 'open' or 'restricted'
#    IWPRIV: Extra parameters to pass directly to IWPRIV

# Only meant to be called from ifup.

# Set link up (some cards require this.)
/sbin/ip link set dev ${DEVICE} up

# Mode need to be first : some settings apply only in a specific mode !
#if [ -n "$MODE" ] ; then
#    iwconfig $DEVICE mode master
#fi
# This is a bit hackish, but should do the job right...
if [ -n "$ESSID" -o -n "$MODE" ] ; then
    NICKNAME=`/bin/hostname`
    iwconfig $DEVICE nick "$NICKNAME" >/dev/null 2>&1
fi
# Regular stuff...
if [ -n "$NWID" ] ; then
    iwconfig $DEVICE nwid $NWID
fi
if [ -n "$FREQ" -a "$MODE" != "Managed" ] ; then
    iwconfig $DEVICE freq $FREQ
elif [ -n "$CHANNEL" -a "$MODE" != "Managed" ] ; then
    iwconfig $DEVICE channel $CHANNEL
fi
if [ -n "$SENS" ] ; then
    iwconfig $DEVICE sens $SENS
fi
if [ -n "$RATE" ] ; then
    iwconfig $DEVICE rate "$RATE"
fi
if [ -n "$KEY" -o -n "$KEY1" -o -n "$KEY2" -o -n "$KEY3" -o -n
"$KEY4" ] ; then
    [ -n "$KEY1" ] && iwconfig $DEVICE key "[1]" $KEY1
    [ -n "$KEY2" ] && iwconfig $DEVICE key "[2]" $KEY2
    [ -n "$KEY3" ] && iwconfig $DEVICE key "[3]" $KEY3
    [ -n "$KEY4" ] && iwconfig $DEVICE key "[4]" $KEY4
    [ -n "$DEFAULTKEY" ] && iwconfig $DEVICE key "[${DEFAULTKEY}]"
    [ -n "$KEY" ] && iwconfig $DEVICE key $KEY
else
    iwconfig $DEVICE key off
fi
if [ -n "$SECURITYMODE" ]; then
    iwconfig $DEVICE enc $SECURITYMODE
fi
if [ -n "$RTS" ] ; then
    iwconfig $DEVICE rts $RTS
fi
if [ -n "$FRAG" ] ; then
    iwconfig $DEVICE frag $FRAG
fi

# More specific parameters passed directly to IWCONFIG
if [ -n "$IWCONFIG" ] ; then
    iwconfig $DEVICE $IWCONFIG
fi

if [ -n "$SPYIPS" ] ; then
    for IP in $SPYIPS; do
	iwspy $DEVICE + $IP
    done
fi
if [ -n "$IWPRIV" ] ; then
    iwpriv $DEVICE $IWPRIV
fi

# ESSID need to be last : most device re-perform the scanning/discovery
# when this is set, and things like encryption keys are better be
# defined if we want to discover the right set of APs/nodes.
if [ -n "$ESSID" ] ; then
    iwconfig $DEVICE essid "$ESSID"
else
    # use any essid
    iwconfig $DEVICE essid any >/dev/null 2>&1
fi

I've removed the mode to see if makes a difference and guess what.... it
didn't!

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071004/87c80dc1/attachment.sig>

From linville at redhat.com  Thu Oct  4 19:09:09 2007
From: linville at redhat.com (John W. Linville)
Date: Thu, 4 Oct 2007 15:09:09 -0400
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191523945.4157.25.camel@localhost.localdomain>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
Message-ID: <20071004190909.GD8375@redhat.com>

On Thu, Oct 04, 2007 at 07:52:25PM +0100, Paul wrote:
> Hi,
> 
> > > How do I get it to work? I'm using the v4 driver
> > 
> > What is the content of your ifcfg-wlan0?
> 
> I have ifcfg-wireless, but no ifcfg-wlan0

So, you are using ifup but you never setup the card w/
system-config-network?  Does that even work w/ wired interfaces?
It surely seems unlikely to work with wireless.

Perhaps you should start by running "service NetworkManager start"
and using the nm-applet icon on your GNOME desktop to choose from
any available networks?

If you know the SSID of an open WLAN nearby, you might alternatively
try something like this form the command line:

	service NetworkManager stop # just in case it is running
	ifconfig wlan0 up # this is important
	iwlist wlan0 scan
	iwconfig wlan0 essid <SSID> # replace <SSID> w/ appropriate value for your WLAN
	dhclient wlan0

> the ifcfg-wireless reads

Actually, what you posted looks like the contents of ifup-wireless
(up instead of cfg), and since it isn't intended to be customized it
really isn't interesting anyway. :-)

John
-- 
John W. Linville
linville at redhat.com



From linville at redhat.com  Thu Oct  4 19:11:33 2007
From: linville at redhat.com (John W. Linville)
Date: Thu, 4 Oct 2007 15:11:33 -0400
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <4705333D.1020800@fedoraunity.org>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<4705333D.1020800@fedoraunity.org>
Message-ID: <20071004191133.GE8375@redhat.com>

On Thu, Oct 04, 2007 at 12:38:53PM -0600, Jonathan Steffan wrote:

> > So far so good - the activity light comes on on the card and I'm happy.
> > 
> > My problem comes activating it. /sbin/ifup wlan0 comes up with
> 
> I got just about as far. The card seemed to "work" but I was unable to
> associate with any of the WAPs I could see.

Did you open a bugzilla?

John
-- 
John W. Linville
linville at redhat.com



From orion at cora.nwra.com  Thu Oct  4 19:25:10 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 04 Oct 2007 13:25:10 -0600
Subject: Problems with recent F7 updates comps-f7.xml
Message-ID: <47053E16.800@cora.nwra.com>

I do F7 kickstart installs here and I add a repo line for the F7 updates 
so that they get installed automatically.  Today I get an error from 
anaconda complaining that it can't find the comps-f7.xml file, though it 
does download it fine.  I'm guessing that it is actually a parsing 
error, though no diagnostics make it into anaconda.log.  I did a 
successful install on the 1st, so the change must be recent.


Any ideas?


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From ml at deadbabylon.de  Thu Oct  4 19:23:50 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Thu, 4 Oct 2007 21:23:50 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <1191508118.5234.11.camel@localhost.localdomain>
References: <1191508118.5234.11.camel@localhost.localdomain>
Message-ID: <20071004212350.51ca2f5f@htpc>

Am Thu, 04 Oct 2007 10:28:38 -0400
schrieb Jeremy Katz <katzj at redhat.com>:

>  * Fedora 8 Test 3 can be installed via Live image, regular DVD, or
> via network installation.  You can find the DVD images as well as the
> primary live images at:
> 
> http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/

Can someone explain to me why the KDE-LiveCD is only available via
torrent? Bandwith? Did I missed a thread where that was discussed?


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

From katzj at redhat.com  Thu Oct  4 19:32:10 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 04 Oct 2007 15:32:10 -0400
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <47053E16.800@cora.nwra.com>
References: <47053E16.800@cora.nwra.com>
Message-ID: <1191526330.16124.3.camel@localhost.localdomain>

On Thu, 2007-10-04 at 13:25 -0600, Orion Poplawski wrote:
> I do F7 kickstart installs here and I add a repo line for the F7 updates 
> so that they get installed automatically.  Today I get an error from 
> anaconda complaining that it can't find the comps-f7.xml file, though it 
> does download it fine.  I'm guessing that it is actually a parsing 
> error, though no diagnostics make it into anaconda.log.  I did a 
> successful install on the 1st, so the change must be recent.

The comps file on the mirrors didn't match the repodata (a sha1 is used
to verify).  Should be fixed with the updates push underway.  We hope.  

No clue how it happened, though :-/

Jeremy



From katzj at redhat.com  Thu Oct  4 19:33:43 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 04 Oct 2007 15:33:43 -0400
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <20071004212350.51ca2f5f@htpc>
References: <1191508118.5234.11.camel@localhost.localdomain>
	<20071004212350.51ca2f5f@htpc>
Message-ID: <1191526423.16124.7.camel@localhost.localdomain>

On Thu, 2007-10-04 at 21:23 +0200, Sebastian Vahl wrote:
> Am Thu, 04 Oct 2007 10:28:38 -0400 schrieb Jeremy Katz <katzj at redhat.com>:
> >  * Fedora 8 Test 3 can be installed via Live image, regular DVD, or
> > via network installation.  You can find the DVD images as well as the
> > primary live images at:
> > 
> > http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/
> 
> Can someone explain to me why the KDE-LiveCD is only available via
> torrent? Bandwith? Did I missed a thread where that was discussed?

Timing.  To get things on the mirrors, they needed to be available for
syncing on Monday.  The KDE live images were done at the end of the day
on Tuesday due to scrambling around the knetworkmanager stuff.

They'll be back to normally available for the final release.  Although
the current thinking is for the developer and FEL spins to be
torrent-only

Jeremy



From ml at deadbabylon.de  Thu Oct  4 19:33:26 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Thu, 4 Oct 2007 21:33:26 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <1191526423.16124.7.camel@localhost.localdomain>
References: <1191508118.5234.11.camel@localhost.localdomain>
	<20071004212350.51ca2f5f@htpc>
	<1191526423.16124.7.camel@localhost.localdomain>
Message-ID: <20071004213326.257e9407@htpc>

Am Thu, 04 Oct 2007 15:33:43 -0400
schrieb Jeremy Katz <katzj at redhat.com>:

> On Thu, 2007-10-04 at 21:23 +0200, Sebastian Vahl wrote:
> > Am Thu, 04 Oct 2007 10:28:38 -0400 schrieb Jeremy Katz
> > <katzj at redhat.com>:
> > >  * Fedora 8 Test 3 can be installed via Live image, regular DVD,
> > > or via network installation.  You can find the DVD images as well
> > > as the primary live images at:
> > > 
> > > http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/
> > 
> > Can someone explain to me why the KDE-LiveCD is only available via
> > torrent? Bandwith? Did I missed a thread where that was discussed?
> 
> Timing.  To get things on the mirrors, they needed to be available for
> syncing on Monday.  The KDE live images were done at the end of the
> day on Tuesday due to scrambling around the knetworkmanager stuff.
> 
> They'll be back to normally available for the final release.  Although
> the current thinking is for the developer and FEL spins to be
> torrent-only

Ok. Thanks for the explanation.

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

From wwoods at redhat.com  Thu Oct  4 19:38:06 2007
From: wwoods at redhat.com (Will Woods)
Date: Thu, 04 Oct 2007 15:38:06 -0400
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <47053E16.800@cora.nwra.com>
References: <47053E16.800@cora.nwra.com>
Message-ID: <1191526686.3020.36.camel@metroid.rdu.redhat.com>

On Thu, 2007-10-04 at 13:25 -0600, Orion Poplawski wrote:
> I do F7 kickstart installs here and I add a repo line for the F7 updates 
> so that they get installed automatically.  Today I get an error from 
> anaconda complaining that it can't find the comps-f7.xml file, though it 
> does download it fine.  I'm guessing that it is actually a parsing 
> error, though no diagnostics make it into anaconda.log.  I did a 
> successful install on the 1st, so the change must be recent.

To give a little more detail, there was a bug with comps file creation
for today's updates so the file didn't match the checksum. Pup will
catch this problem (yay!), but it gives you a completely unhelpful error
message "unable to start due to a configuration error", with a Details
box containing: "None". Oops. 

Like Jeremy said, it should be fixed as soon as the updates are finished
being pushed/synched. 

Also I'm pretty sure that pup in rawhide/F8 will give you a more helpful
message, so if it happens again in the future things should be a little
less confusing.

-w
-------------- 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/20071004/c468c730/attachment.sig>

From jon at fedoraunity.org  Thu Oct  4 19:40:15 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Thu, 04 Oct 2007 13:40:15 -0600
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <20071004191133.GE8375@redhat.com>
References: <1191510135.4157.22.camel@localhost.localdomain>	<4705333D.1020800@fedoraunity.org>
	<20071004191133.GE8375@redhat.com>
Message-ID: <4705419F.3050600@fedoraunity.org>

John W. Linville wrote:
> On Thu, Oct 04, 2007 at 12:38:53PM -0600, Jonathan Steffan wrote:
> 
>>> So far so good - the activity light comes on on the card and I'm happy.
>>>
>>> My problem comes activating it. /sbin/ifup wlan0 comes up with
>> I got just about as far. The card seemed to "work" but I was unable to
>> associate with any of the WAPs I could see.
> 
> Did you open a bugzilla?


No, I tried solving the issue on my own (this was back with fc6) but
then gave up and just used ndiswrapper. For F7, I tried bcm43xx again
and was able to scan for networks but was unable to associate. Similar
results were reported by a few people with the same hardware, so I gave
up and went back to using ndiswrapper. I got in communication with the
bcm43xx dev team and they blamed [[ insert fedora incorrect
implementation here ]], something to do with the new 80211mac (or
whatever). Anywho, no, no I didn't file a bug.

Jonathan Steffan
daMaestro



From ml at deadbabylon.de  Thu Oct  4 19:40:26 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Thu, 4 Oct 2007 21:40:26 +0200
Subject: Announcing Fedora 8 Test 3 (7.92)!
In-Reply-To: <1191508118.5234.11.camel@localhost.localdomain>
References: <1191508118.5234.11.camel@localhost.localdomain>
Message-ID: <20071004214026.0dc940ec@htpc>

Am Thu, 04 Oct 2007 10:28:38 -0400
schrieb Jeremy Katz <katzj at redhat.com>:

>  * You can also download the DVD and Live images via bittorrent at:
> 
> http://torrent.fedoraproject.org
> 

Are there problems with the different torrents? Here the
KDE-, FEL-, and Developer-Images have no traffic:
http://torrent.linux.duke.edu:6969/

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

From paul at all-the-johnsons.co.uk  Thu Oct  4 19:43:29 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 04 Oct 2007 20:43:29 +0100
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <20071004190909.GD8375@redhat.com>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
	<20071004190909.GD8375@redhat.com>
Message-ID: <1191527009.4157.32.camel@T7.Linux>

Hi,

> > > What is the content of your ifcfg-wlan0?
> > 
> > I have ifcfg-wireless, but no ifcfg-wlan0
> 
> So, you are using ifup but you never setup the card w/
> system-config-network?  Does that even work w/ wired interfaces?
> It surely seems unlikely to work with wireless.

D'oh - wrong config file! The card was set up with s-c-n initially. The
config reads

# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Wireless
DEVICE=wlan0
HWADDR=00:1b:fc:3e:41:11
BOOTPROTO=dhcp
NETMASK=
DHCP_HOSTNAME=
IPADDR=
DOMAIN=
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
ESSID=SKYabcde (not letters, but numbers)
CHANNEL=1
MODE=Managed
RATE=Auto

> Perhaps you should start by running "service NetworkManager start"
> and using the nm-applet icon on your GNOME desktop to choose from
> any available networks?

It continually asks me for the passphrase or network key


-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071004/4b7f6a5c/attachment.sig>

From luya_tfz at thefinalzone.com  Thu Oct  4 19:48:59 2007
From: luya_tfz at thefinalzone.com (Luya Tshimbalanga)
Date: Thu, 04 Oct 2007 12:48:59 -0700
Subject: Icons enlarged
In-Reply-To: <c44298520710041120p7f18ea76o5938c08ec1388e9b@mail.gmail.com>
References: <1191464544.2247.2.camel@scrappy.miketc.com>
	<c44298520710041120p7f18ea76o5938c08ec1388e9b@mail.gmail.com>
Message-ID: <470543AB.4040203@thefinalzone.com>

Hikaru Amano a ?crit :
> On 10/4/07, Mike Chambers <mike at miketc.com> wrote:
>   
>> I may have missed this topic/bug if it was discussed due to some other
>> reasons, but wanted to point it out anyway just in case.  I have noticed
>> that after today's rawhide updates that lot of my icons and buttons are
>> enlarged?  Like some of my evo buttons are really big,and the volume
>> control icon on my panel is big.  But nothing else on the panel is.  I
>> am also running the echo-icon-them just in case that is relevant.
>>     
>
> I'm experiencing the same issue .. seems like happens only with
> echo-icon-theme ..
>
> i've bugzilla'd it .. https://bugzilla.redhat.com/show_bug.cgi?id=318921
>   
It was my fault. I forgot to modify the index.theme as SVG icons are not
included.
The fix will be available on rawhide. Should you be impatient,
http://koji.fedoraproject.org/koji/buildinfo?buildID=20178

Luya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/6f4b6f7e/attachment.htm>

From katzj at redhat.com  Thu Oct  4 19:55:01 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 04 Oct 2007 15:55:01 -0400
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <1191526686.3020.36.camel@metroid.rdu.redhat.com>
References: <47053E16.800@cora.nwra.com>
	<1191526686.3020.36.camel@metroid.rdu.redhat.com>
Message-ID: <1191527701.16124.9.camel@localhost.localdomain>

On Thu, 2007-10-04 at 15:38 -0400, Will Woods wrote:
> Also I'm pretty sure that pup in rawhide/F8 will give you a more helpful
> message, so if it happens again in the future things should be a little
> less confusing.

... and that pirut package will also be making its way to F7-updates to
accompany yum 3.2.6 in the near future

Jeremy



From snecklifter at gmail.com  Thu Oct  4 20:02:35 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Thu, 4 Oct 2007 21:02:35 +0100
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <1191526686.3020.36.camel@metroid.rdu.redhat.com>
References: <47053E16.800@cora.nwra.com>
	<1191526686.3020.36.camel@metroid.rdu.redhat.com>
Message-ID: <364d303b0710041302h36bef057rdd2adb42db027a68@mail.gmail.com>

On 04/10/2007, Will Woods <wwoods at redhat.com> wrote:
>
> On Thu, 2007-10-04 at 13:25 -0600, Orion Poplawski wrote:
> > I do F7 kickstart installs here and I add a repo line for the F7 updates
> > so that they get installed automatically.  Today I get an error from
> > anaconda complaining that it can't find the comps-f7.xml file, though it
> > does download it fine.  I'm guessing that it is actually a parsing
> > error, though no diagnostics make it into anaconda.log.  I did a
> > successful install on the 1st, so the change must be recent.
>
> To give a little more detail, there was a bug with comps file creation
> for today's updates so the file didn't match the checksum. Pup will
> catch this problem (yay!), but it gives you a completely unhelpful error
> message "unable to start due to a configuration error", with a Details
> box containing: "None". Oops.
>
> Like Jeremy said, it should be fixed as soon as the updates are finished
> being pushed/synched.
>
> Also I'm pretty sure that pup in rawhide/F8 will give you a more helpful
> message, so if it happens again in the future things should be a little
> less confusing.


RFE: Pup displays a roly-poly lovable puppy in a gtk window which has a
click-able belly that makes it rollover.

Rationale: Barbara doesn't care that when updating her Fedora 7 system
sha1sum fails to verify the comps file against the repodata so a clickable
puppy hides all this until the mirror re-syncs.

Documentation: None required - everyone knows a puppy likes having his belly
clicked.

Also consider ponies.

Cheers!
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071004/c320e6ae/attachment.htm>

From linville at redhat.com  Thu Oct  4 20:29:25 2007
From: linville at redhat.com (John W. Linville)
Date: Thu, 4 Oct 2007 16:29:25 -0400
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191527009.4157.32.camel@T7.Linux>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
	<20071004190909.GD8375@redhat.com>
	<1191527009.4157.32.camel@T7.Linux>
Message-ID: <20071004202924.GF8375@redhat.com>

On Thu, Oct 04, 2007 at 08:43:29PM +0100, Paul wrote:
> Hi,
> 
> > > > What is the content of your ifcfg-wlan0?
> > > 
> > > I have ifcfg-wireless, but no ifcfg-wlan0
> > 
> > So, you are using ifup but you never setup the card w/
> > system-config-network?  Does that even work w/ wired interfaces?
> > It surely seems unlikely to work with wireless.
> 
> D'oh - wrong config file! The card was set up with s-c-n initially. The
> config reads
> 
> # Please read /usr/share/doc/initscripts-*/sysconfig.txt
> # for the documentation of these parameters.
> TYPE=Wireless
> DEVICE=wlan0
> HWADDR=00:1b:fc:3e:41:11
> BOOTPROTO=dhcp
> NETMASK=
> DHCP_HOSTNAME=
> IPADDR=
> DOMAIN=
> ONBOOT=yes
> USERCTL=no
> IPV6INIT=no
> PEERDNS=yes
> ESSID=SKYabcde (not letters, but numbers)
> CHANNEL=1
> MODE=Managed
> RATE=Auto
> 
> > Perhaps you should start by running "service NetworkManager start"
> > and using the nm-applet icon on your GNOME desktop to choose from
> > any available networks?
> 
> It continually asks me for the passphrase or network key

Is the SSID "hidden" (i.e. do you see it in the output of 'iwlist
wlan0 scan')?

-- 
John W. Linville
linville at redhat.com



From bpepple at fedoraproject.org  Thu Oct  4 20:37:49 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 04 Oct 2007 16:37:49 -0400
Subject: FESCo Meeting Summary for 2007-10-04
Message-ID: <1191530269.18627.7.camel@kennedy>

Members Present
      * Brian Pepple (bpepple) 
      * Jason Tibbitts (tibbs) 
      * Jeremy Katz (jeremy) 
      * Christian Iseli (c4chris) 
      * Christopher Aillon (caillon) 
      * Kevin Fenzi (nirik) 
      * Dennis Gilmore (dgilmore) 
      * Bill Nottingham (notting) 
      * Tom Callaway (spot) 
      * Warren Togami (warren)

Absent
      * Jesse Keating (f13) 
      * David Woodhouse (dwmw2) 
      * Josh Boyer (jwb)

== Summary ==
=== FPC Tex Proposal ===
      * FESCo approved the FPC's naming proposal for Tex-related
        packages.
        https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00081.html

=== F8 Features ===
      * FESCo reviewed the features that were not shown as 100%
        complete. In most cases, it appears the respective owners of the
        features just need to update the status. The various owners will
        be contacted to correct this.
        http://fedoraproject.org/wiki/Releases/8/FeatureList

=== Misc ===
      * dgilmore: "we wont have any secondary arch releases at F-8
        time" 

IRC log can be found at:
http://bpepple.fedorapeople.org/FESCo-2007-10-04.html

BTW, here's a link to last week's FESCo meeting summary:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070927

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071004/63d0e7a4/attachment.sig>

From rdieter at math.unl.edu  Thu Oct  4 19:35:46 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 04 Oct 2007 14:35:46 -0500
Subject: Problems with recent F7 updates comps-f7.xml
References: <47053E16.800@cora.nwra.com>
	<1191526330.16124.3.camel@localhost.localdomain>
Message-ID: <fe3fai$5r1$1@sea.gmane.org>

Jeremy Katz wrote:

> On Thu, 2007-10-04 at 13:25 -0600, Orion Poplawski wrote:
>> I do F7 kickstart installs here and I add a repo line for the F7 updates
>> so that they get installed automatically.  Today I get an error from
>> anaconda complaining that it can't find the comps-f7.xml file, though it
>> does download it fine.  I'm guessing that it is actually a parsing
>> error, though no diagnostics make it into anaconda.log.  I did a
>> successful install on the 1st, so the change must be recent.
> 
> The comps file on the mirrors didn't match the repodata (a sha1 is used
> to verify).  Should be fixed with the updates push underway.  We hope.

Yes, I can confirm after sync'ing my local mirror that comps-f7.xml is
better now.

-- Rex



From paul at all-the-johnsons.co.uk  Thu Oct  4 20:42:14 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 04 Oct 2007 21:42:14 +0100
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <20071004202924.GF8375@redhat.com>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
	<20071004190909.GD8375@redhat.com> <1191527009.4157.32.camel@T7.Linux>
	<20071004202924.GF8375@redhat.com>
Message-ID: <1191530534.4199.4.camel@T7.Linux>

Hi,

> > It continually asks me for the passphrase or network key
> 
> Is the SSID "hidden" (i.e. do you see it in the output of 'iwlist
> wlan0 scan')?

Yep. I can see it in the iwlist.

That said, with kernel-2.6.23-0.217.rc9.git.fc8, neat is telling me that
bcm43_mac80211 device wlan0 does not seem to be present!

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071004/593a93a5/attachment.sig>

From lmacken at redhat.com  Thu Oct  4 20:51:00 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 4 Oct 2007 16:51:00 -0400
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <1191526330.16124.3.camel@localhost.localdomain>
References: <47053E16.800@cora.nwra.com>
	<1191526330.16124.3.camel@localhost.localdomain>
Message-ID: <20071004205100.GA7991@crow.myhome.westell.com>

On Thu, Oct 04, 2007 at 03:32:10PM -0400, Jeremy Katz wrote:
> On Thu, 2007-10-04 at 13:25 -0600, Orion Poplawski wrote:
> > I do F7 kickstart installs here and I add a repo line for the F7 updates 
> > so that they get installed automatically.  Today I get an error from 
> > anaconda complaining that it can't find the comps-f7.xml file, though it 
> > does download it fine.  I'm guessing that it is actually a parsing 
> > error, though no diagnostics make it into anaconda.log.  I did a 
> > successful install on the 1st, so the change must be recent.
> 
> The comps file on the mirrors didn't match the repodata (a sha1 is used
> to verify).  Should be fixed with the updates push underway.  We hope.  

The new repository seemed looks to have sync'd out with the correct
comps-f7.xml, so this should hopefully be fixed.

> No clue how it happened, though :-/

I have no idea either.  The repository that bodhi mashed was fine, but
somehow a corrupted comps-f7.xml hit the master mirror.
We're looking into it.

luke



From a.badger at gmail.com  Thu Oct  4 21:50:14 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 04 Oct 2007 14:50:14 -0700
Subject: Proposal: Rename cvsextras to packager
Message-ID: <47056016.8060607@gmail.com>

Warren has advanced a proposal to rename the "cvsextras" group in the 
account system to "packager".  The change is to occur when we do the 
mass CVS branching (final development freeze, scheduled for: 17 October 
2007).  Proposal is here:

https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg00007.html

I've volunteered to make the required changes in the packagedb, 
fedora-accounts, and scripts being used by admins and cron jobs on the 
cvs server.

If you have another script that uses the cvsextras group, you should be 
able to modify the code to fix things simply by changing "cvsextras" to 
"packager" on or after October 17.  Feel free to contact me if you run 
into something more difficult and need some help.

We have a ticket open in Fedora Infrastructure to track the changes that 
we need to make.  Feel free to add to it if you know of any problems 
that need to be addressed when this happens.

https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/177

-Toshio



From lightsolphoenix at gmail.com  Thu Oct  4 21:56:08 2007
From: lightsolphoenix at gmail.com (Kelly)
Date: Thu, 4 Oct 2007 17:56:08 -0400
Subject: MySQL Administrator crashes KWin?
Message-ID: <200710041756.08749.lightsolphoenix@gmail.com>

Because I'm taking PHP again at college, I've been looking into getting 
Apache, PHP and MySQL running on my Fedora install again.  It isn't hard, 
because it's not the first time I've done it, but I DO notice something 
strange...

When I try to run MySQL Administrator or MySQL Query Browser, and I select 
to "Save Connection", the resulting window causes KWin to crash and part of 
Kicker to disappear.  The error doesn't seem to be with Administrator or QB 
themselves (I don't see any errors from them), and I'm not sure what the 
problem might be...
-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



From mmcgrath at redhat.com  Thu Oct  4 21:54:16 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 04 Oct 2007 16:54:16 -0500
Subject: Problems with recent F7 updates comps-f7.xml
In-Reply-To: <47053E16.800@cora.nwra.com>
References: <47053E16.800@cora.nwra.com>
Message-ID: <47056108.3080106@redhat.com>

Orion Poplawski wrote:
> I do F7 kickstart installs here and I add a repo line for the F7 
> updates so that they get installed automatically.  Today I get an 
> error from anaconda complaining that it can't find the comps-f7.xml 
> file, though it does download it fine.  I'm guessing that it is 
> actually a parsing error, though no diagnostics make it into 
> anaconda.log.  I did a successful install on the 1st, so the change 
> must be recent.
>
>
> Any ideas?

Just an update on this, it appears the comps file was corrupt (it had 
bad lines in it).  The file that ended up on the mirrors is also not the 
file that mash created.  We suspect something went wrong during a file 
copy or possibly on the filesystem on the main mirror.  I've filed a 
ticket to see if our main filer threw any errors.  We're going to treat 
this as a freak accident as we couldn't recreate it during the fix but 
are keeping a close eye on tonight

    -Mike



From pemboa at gmail.com  Thu Oct  4 23:40:37 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 4 Oct 2007 18:40:37 -0500
Subject: MySQL Administrator crashes KWin?
In-Reply-To: <200710041756.08749.lightsolphoenix@gmail.com>
References: <200710041756.08749.lightsolphoenix@gmail.com>
Message-ID: <16de708d0710041640v6a8aba03jb991b2121a60ba58@mail.gmail.com>

On 10/4/07, Kelly <lightsolphoenix at gmail.com> wrote:
> Because I'm taking PHP again at college, I've been looking into getting
> Apache, PHP and MySQL running on my Fedora install again.  It isn't hard,
> because it's not the first time I've done it, but I DO notice something
> strange...
>
> When I try to run MySQL Administrator or MySQL Query Browser, and I select
> to "Save Connection", the resulting window causes KWin to crash and part of
> Kicker to disappear.  The error doesn't seem to be with Administrator or QB
> themselves (I don't see any errors from them), and I'm not sure what the
> problem might be...


MySQL Administrator on Linux is full of bugs, you're better of using phpMyAdmin

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From mike at miketc.com  Fri Oct  5 00:10:07 2007
From: mike at miketc.com (Mike Chambers)
Date: Thu, 04 Oct 2007 19:10:07 -0500
Subject: Icons enlarged
In-Reply-To: <470543AB.4040203@thefinalzone.com>
References: <1191464544.2247.2.camel@scrappy.miketc.com>
	<c44298520710041120p7f18ea76o5938c08ec1388e9b@mail.gmail.com>
	<470543AB.4040203@thefinalzone.com>
Message-ID: <1191543007.11601.0.camel@scrappy.miketc.com>

On Thu, 2007-10-04 at 12:48 -0700, Luya Tshimbalanga wrote:

> It was my fault. I forgot to modify the index.theme as SVG icons are
> not included.
> The fix will be available on rawhide. Should you be impatient, 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=20178

Thanks for the quick fix, that did the trick.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Fri Oct  5 00:12:30 2007
From: mike at miketc.com (Mike Chambers)
Date: Thu, 04 Oct 2007 19:12:30 -0500
Subject: F8t3 k3b and sound problems
Message-ID: <1191543150.11601.4.camel@scrappy.miketc.com>

2 problems that I have found so far with current testing/rawhide, is k3b
not detecting both my cdroms, nor sound able to work.

Sound is discussed here currently..

https://bugzilla.redhat.com/show_bug.cgi?id=290151

k3b problem I haven't seen discussed yet.  I can see the kernel messages
and the cdroms are found.  But k3b nor xcdroast are able to detect them
for whatever reason.

Any ideas or anyone else?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From wtogami at redhat.com  Fri Oct  5 01:54:27 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 04 Oct 2007 21:54:27 -0400
Subject: FYI: kernel 218 breaks iwl3945 and 4965
Message-ID: <47059953.1030703@redhat.com>

http://koji.fedoraproject.org/packages/kernel/2.6.23/
Please help to test kernels before they hit the nightly build.

-------- Original Message --------
Subject: Untagged kernel-2.6.23-0.218.rc9.git1.fc8
Date: Thu, 04 Oct 2007 21:48:55 -0400
From: Warren Togami <wtogami at redhat.com>
To: John W. Linville <linville at redhat.com>, Dave Jones 
<davej at redhat.com>,        Chuck Ebbert <cebbert at redhat.com>, Dan 
Williams <dcbw at redhat.com>,        rel-eng <rel-eng at fedoraproject.org>

I have untagged kernel-2.6.23-0.218.rc9.git1.fc8 because it is confirmed
to break WEP and WPA on iwl3945 on x86_64.  iwl4965 showed similar
trouble.  218 didn't hit a public rawhide tree yet.

kernel-2.6.23-0.217.rc9.git1.fc8 works.

Warren Togami
wtogami at redhat.com



From orion at cora.nwra.com  Fri Oct  5 01:56:35 2007
From: orion at cora.nwra.com (orion at cora.nwra.com)
Date: Thu, 4 Oct 2007 19:56:35 -0600 (MDT)
Subject: rpmdb and /var filesystem corruption in F7+
In-Reply-To: <20070927161510.GB20637@xi.wantstofly.org>
References: <46FBC5D2.60902@cora.nwra.com>
	<20070927161510.GB20637@xi.wantstofly.org>
Message-ID: <3423.71.208.77.226.1191549395.squirrel@www.co-ra.com>

> On Thu, Sep 27, 2007 at 09:01:38AM -0600, Orion Poplawski wrote:
>
>> I have a lot of problems with rpmdb corruption occurring during
>> (network) installs since around February 2007, and with yum updates
>> afterwards.  I've reported the problem here
>> <https://bugzilla.redhat.com/show_bug.cgi?id=230362>.
>
> One shred of evidence that seems to point in this direction is that
> I haven't seen this corruption occur on any of my ARM systems since
> we started mlock()ing the RPM database environment into memory:
>
> 	http://fedora-arm.wantstofly.org/diffs-f/rpm-4.4.2.1-10.fc8/rpm-4.4.2-always-mlock.patch
>

I re-spun F7 using pungi and rpm-4.4.2.1-1.fc7 rebuilt with this patch. 
Still got corruption on the first yum install after rebooting the
installed system.  This seems pretty common these days.  I'll try
respinning F8 with the equivalent, but I'm not terribly optimistic.

Would I need to rebuild anaconda with the new rpm-devel?  Not sure if I'm
dealing with dynamic or static linking here (I see that rpm-devel does
ship  .a's).

- Orion



From wtogami at redhat.com  Fri Oct  5 04:26:28 2007
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 05 Oct 2007 00:26:28 -0400
Subject: Test NetworkManager-openvpn?
Message-ID: <4705BCF4.2070207@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=239824
I just discovered that Selinux was again denying NetworkManager-vpnc to 
function while operating NetworkManager in --no-daemon mode for 
debugging.  We had the same problem before F7.

Can someone test the equivalent for NetworkManager-openvpn with Selinux 
enforcing enabled?  Please test it in both "service NetworkManager 
start" and "NetworkManager --no-daemon" mode to be sure both are 
functioning properly.

Warren Togami
wtogami at redhat.com



From lemenkov at gmail.com  Fri Oct  5 07:00:46 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 5 Oct 2007 11:00:46 +0400
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
Message-ID: <adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>

Hello All!
Just for clarification - is it allowed to mix macros and native
command in spec-file? For instance

%make
make %{?_smp_mflags}

%install
%{_rm} -rf  $RPM_BUILD_ROOT
make DESTDIR=%{buildroot} install


--
With best regards!



From oliver at linux-kernel.at  Fri Oct  5 07:02:10 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Fri, 05 Oct 2007 09:02:10 +0200
Subject: October 71% OFF
In-Reply-To: <20071005154136.20526.qmail@relay.kbumb.ru>
References: <20071005154136.20526.qmail@relay.kbumb.ru>
Message-ID: <4705E172.60900@linux-kernel.at>

On 10/05/2007 06:24 AM, fedora-cvs-commits at redhat.com wrote:
> *Click to buy Official VIAG?A for as low as $1.79 ***
> <http://www.kortstroy.ru/7554.html>****
> 

How could that come trough?

:-)

-of



From j.w.r.degoede at hhs.nl  Fri Oct  5 07:02:11 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 05 Oct 2007 09:02:11 +0200
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
Message-ID: <4705E173.5020807@hhs.nl>

Peter Lemenkov wrote:
> Hello All!
> Just for clarification - is it allowed to mix macros and native
> command in spec-file? For instance
> 
> %make
> make %{?_smp_mflags}
> 
> %install
> %{_rm} -rf  $RPM_BUILD_ROOT
> make DESTDIR=%{buildroot} install
> 
> 

Allowed as in the RPM will build, yes, allowed as in what do the guidelines 
say. No, either use all macros or all native commands.

Regards,

Hans



From oliver at linux-kernel.at  Fri Oct  5 07:04:40 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Fri, 05 Oct 2007 09:04:40 +0200
Subject: [pkgdb] silo summary updated by ausil
In-Reply-To: <200710050253.l952rbj0016916@bastion.fedora.phx.redhat.com>
References: <200710050253.l952rbj0016916@bastion.fedora.phx.redhat.com>
Message-ID: <4705E208.3050105@linux-kernel.at>

On 10/05/2007 04:53 AM, Fedora PackageDB (pkgdb) wrote:
> Dennis Gilmore (ausil) set package silo summary to The SILO boot loader for SPARCs
> 
> To make changes to this package see:
>   https://admin.fedoraproject.org/pkgdb/packages/name/silo

That's funny - Now we finally have aboot (Alpha bootloader) and silo
(Sparc bootloader) in CVS...

-of



From sundaram at fedoraproject.org  Fri Oct  5 07:10:50 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 05 Oct 2007 12:40:50 +0530
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
Message-ID: <4705E37A.6030209@fedoraproject.org>

Peter Lemenkov wrote:
> Hello All!
> Just for clarification - is it allowed to mix macros and native
> command in spec-file? For instance
> 
> %make
> make %{?_smp_mflags}
> 
> %install
> %{_rm} -rf  $RPM_BUILD_ROOT
> make DESTDIR=%{buildroot} install

It would work but it is explicitly recommended against in the guidelines.

Rahul



From aportal at univ-montp2.fr  Fri Oct  5 07:44:08 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Fri, 5 Oct 2007 09:44:08 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <20071002100910.GD3535@free.fr>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<20071002100910.GD3535@free.fr>
Message-ID: <200710050944.08371.aportal@univ-montp2.fr>

Le Tuesday 02 October 2007 12:09:11 Patrice Dumas, vous avez ?crit?:
> On Tue, Oct 02, 2007 at 11:29:47AM +0200, Alain PORTAL wrote:
> > Hi,
> >
> > PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and
> > automake-1.9 were not found:
> > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2
> >.4-1.fc6/
> >
> > Can somebody help me to fix?
>
> There is more than one way to fix such issues, but in that case it is
> a bit strange that autotools are rerun since you didn't patch the
> corresponding files (as far as I can tell from looking at the build
> log). Maybe the timestamps are not right in the upstream tarball?
> The make commands calling the autotools should only be called if a
> resulting file is older than the file it comes from.
>
> A ugly workaround -- but I doubt it is right in that case -- could also
> be to package automake19 and BuildRequires it.

In order to know what is the automake version (finding a symlink as 
automake-1.9) for ppc arch in FC-6, I tried:
"repoquery --list --archlist=ppc automake"
as explained in the repoquery man page, but the command line return is empty.

Same is for
"repoquery --list --archlist=i386 automake"

Is it a bug in repoquery?

Can somebody tell me what is the automake version on ppc arch for FC-6?

Regards,
Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From laurent.rineau__fedora at normalesup.org  Fri Oct  5 08:20:30 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Fri, 5 Oct 2007 10:20:30 +0200
Subject: MySQL Administrator crashes KWin?
In-Reply-To: <16de708d0710041640v6a8aba03jb991b2121a60ba58@mail.gmail.com>
References: <200710041756.08749.lightsolphoenix@gmail.com>
	<16de708d0710041640v6a8aba03jb991b2121a60ba58@mail.gmail.com>
Message-ID: <200710051020.30554@rineau.tsetse>

On Friday 05 October 2007 01:40:37 Arthur Pemberton wrote:
> On 10/4/07, Kelly <lightsolphoenix at gmail.com> wrote:
> > Because I'm taking PHP again at college, I've been looking into getting
> > Apache, PHP and MySQL running on my Fedora install again.  It isn't hard,
> > because it's not the first time I've done it, but I DO notice something
> > strange...
> >
> > When I try to run MySQL Administrator or MySQL Query Browser, and I
> > select to "Save Connection", the resulting window causes KWin to crash
> > and part of Kicker to disappear.  The error doesn't seem to be with
> > Administrator or QB themselves (I don't see any errors from them), and
> > I'm not sure what the problem might be...
>
> MySQL Administrator on Linux is full of bugs, you're better of using
> phpMyAdmin

Even if KWin dies because of a bug in MySQL Administrator, it nevertheless 
means that KWin is buggy too. Well, let wait for KWin4 and see if the bug is 
still here.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From harald at redhat.com  Fri Oct  5 08:48:11 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 05 Oct 2007 10:48:11 +0200
Subject: F8t3 k3b and sound problems
In-Reply-To: <1191543150.11601.4.camel@scrappy.miketc.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
Message-ID: <4705FA4B.4010503@redhat.com>

Mike Chambers schrieb:
> 2 problems that I have found so far with current testing/rawhide, is k3b
> not detecting both my cdroms, nor sound able to work.
> 
> Sound is discussed here currently..
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=290151
> 
> k3b problem I haven't seen discussed yet.  I can see the kernel messages
> and the cdroms are found.  But k3b nor xcdroast are able to detect them
> for whatever reason.
> 
> Any ideas or anyone else?
> 

https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00062.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3623 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/6304eee8/attachment.bin>

From lemenkov at gmail.com  Fri Oct  5 09:14:41 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 5 Oct 2007 13:14:41 +0400
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <4705E37A.6030209@fedoraproject.org>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
	<4705E37A.6030209@fedoraproject.org>
Message-ID: <adf480660710050214s78ba957eyb5f502f37126bd57@mail.gmail.com>

2007/10/5, Rahul Sundaram <sundaram at fedoraproject.org>:
> Peter Lemenkov wrote:
> > Hello All!
> > Just for clarification - is it allowed to mix macros and native
> > command in spec-file? For instance

[sorry, skipped]

> It would work but it is explicitly recommended against in the guidelines.

Sorry, but I can't find exact place in Fedora's Wiki where it's stated.

-- 
With best regards!



From paul at all-the-johnsons.co.uk  Fri Oct  5 10:06:19 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 05 Oct 2007 11:06:19 +0100
Subject: Co-maintaining mono packages
Message-ID: <1191578779.4199.11.camel@T7.Linux>

Hi,

Currently, mono in rawhide is dropping behind the actual releases which
is causing problems with the likes of monodevelop being updated and more
over, stuff I do for work!

Is there anything I need to do to start co-maintaining the mono tree?

TTFN

Paul
(getting back on his feet at last!)
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071005/dbe85638/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Oct  5 10:06:57 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 05 Oct 2007 19:06:57 +0900
Subject: aldrin broken dependency [Fwd: Broken dependencies: aldrin]
In-Reply-To: <1191577566.5109.2.camel@dev31.iconmobile.de>
References: <1191577566.5109.2.camel@dev31.iconmobile.de>
Message-ID: <47060CC1.5050500@ioa.s.u-tokyo.ac.jp>

Hello.
I received a mail from my sponsornee as below.

Alexander Kahl wrote, at 10/05/2007 06:46 PM +9:00:
> Hi Mamoru,
> 
> buildsys keeps sending this to me; but how am I supposed to fix the
> build for ppc64 now? Unfortunately I have no such system available. The
> only thing I could try is sourceforge's build farm.
> 
> Cheers
> Alex
> 
> -------- Forwarded Message --------
>> From: buildsys at fedoraproject.org
>> To: akahl at fedoraproject.org
>> Subject: Broken dependencies: aldrin
>> Date: Fri, 5 Oct 2007 00:50:14 -0700
>>
>>
>> aldrin has broken dependencies in the development tree:
>> On ppc64:
>> 	aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
>> Please resolve this as soon as possible.
>>

Here aldrin itself is "noarch", however aldrin requires pyzzub, which
is arch dependent and currently pyzzub is not available on ppc64.

How should this broken dependency be treated? Do we have to mark
aldrin as arch dependent? Or should we simply ignore this?

Regards,
Mamoru



From mike at miketc.com  Fri Oct  5 10:19:45 2007
From: mike at miketc.com (Mike Chambers)
Date: Fri, 05 Oct 2007 05:19:45 -0500
Subject: F8t3 k3b and sound problems
In-Reply-To: <4705FA4B.4010503@redhat.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
Message-ID: <1191579585.12607.1.camel@scrappy.miketc.com>

On Fri, 2007-10-05 at 10:48 +0200, Harald Hoyer wrote:
> Mike Chambers schrieb:
> > 2 problems that I have found so far with current testing/rawhide, is k3b
> > not detecting both my cdroms, nor sound able to work.
> > 
> > Sound is discussed here currently..
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=290151
> > 
> > k3b problem I haven't seen discussed yet.  I can see the kernel messages
> > and the cdroms are found.  But k3b nor xcdroast are able to detect them
> > for whatever reason.
> > 
> > Any ideas or anyone else?
> > 
> 
> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00062.html

[mike at scrappy ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5
Mapping udi /org/freedesktop/Hal/devices/storage_model_DVDRW_SHW_160P6S
to device /dev/sr1
Mapping udi /org/freedesktop/Hal/devices/storage_model_LTR_52327S to
device /dev/sr0
/dev/sr1 resolved to /dev/sr1
(K3bDevice::Device) could not open device /dev/sr1 for reading
                    (Permission denied)
could not open device /dev/sr1 (Permission denied)
/dev/sr0 resolved to /dev/sr0
(K3bDevice::Device) could not open device /dev/sr0 for reading
                    (Permission denied)
could not open device /dev/sr0 (Permission denied)
Devices:
------------------------------

This is a fresh install, so *I* didn't do anything.  What file/program
do the permissions pertain to?  What permissions should be set?

[mike at scrappy dev]$ ls -la sr*
brw-r----- 1 root disk 11, 0 2007-10-03 21:01 sr0
brw-r----- 1 root disk 11, 1 2007-10-03 21:01 sr1

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Fri Oct  5 10:29:47 2007
From: mike at miketc.com (Mike Chambers)
Date: Fri, 05 Oct 2007 05:29:47 -0500
Subject: F8t3 k3b and sound problems
In-Reply-To: <1191579585.12607.1.camel@scrappy.miketc.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
Message-ID: <1191580187.12607.4.camel@scrappy.miketc.com>

On Fri, 2007-10-05 at 05:19 -0500, Mike Chambers wrote:

> [mike at scrappy ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5
> Mapping udi /org/freedesktop/Hal/devices/storage_model_DVDRW_SHW_160P6S
> to device /dev/sr1
> Mapping udi /org/freedesktop/Hal/devices/storage_model_LTR_52327S to
> device /dev/sr0
> /dev/sr1 resolved to /dev/sr1
> (K3bDevice::Device) could not open device /dev/sr1 for reading
>                     (Permission denied)
> could not open device /dev/sr1 (Permission denied)
> /dev/sr0 resolved to /dev/sr0
> (K3bDevice::Device) could not open device /dev/sr0 for reading
>                     (Permission denied)
> could not open device /dev/sr0 (Permission denied)
> Devices:
> ------------------------------
> 
> This is a fresh install, so *I* didn't do anything.  What file/program
> do the permissions pertain to?  What permissions should be set?
> 
> [mike at scrappy dev]$ ls -la sr*
> brw-r----- 1 root disk 11, 0 2007-10-03 21:01 sr0
> brw-r----- 1 root disk 11, 1 2007-10-03 21:01 sr1

Ok, after running this program from root, it works and detects/uses the
cdroms.  But from a normal user it doesn't.  Permissions or something
need to be changed I guess to allow normal user to run it and detect/use
the cdroms?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mschwendt.tmp0701.nospam at arcor.de  Fri Oct  5 10:34:46 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 5 Oct 2007 12:34:46 +0200
Subject: aldrin broken dependency [Fwd: Broken dependencies: aldrin]
In-Reply-To: <47060CC1.5050500@ioa.s.u-tokyo.ac.jp>
References: <1191577566.5109.2.camel@dev31.iconmobile.de>
	<47060CC1.5050500@ioa.s.u-tokyo.ac.jp>
Message-ID: <20071005123446.9d10f972.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 05 Oct 2007 19:06:57 +0900, Mamoru Tasaka wrote:

> Hello.
> I received a mail from my sponsornee as below.
> 
> Alexander Kahl wrote, at 10/05/2007 06:46 PM +9:00:
> > Hi Mamoru,
> > 
> > buildsys keeps sending this to me; but how am I supposed to fix the
> > build for ppc64 now? Unfortunately I have no such system available. The
> > only thing I could try is sourceforge's build farm.
> > 
> > Cheers
> > Alex
> > 
> > -------- Forwarded Message --------
> >> From: buildsys at fedoraproject.org
> >> To: akahl at fedoraproject.org
> >> Subject: Broken dependencies: aldrin
> >> Date: Fri, 5 Oct 2007 00:50:14 -0700
> >>
> >>
> >> aldrin has broken dependencies in the development tree:
> >> On ppc64:
> >> 	aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
> >> Please resolve this as soon as possible.
> >>
> 
> Here aldrin itself is "noarch", however aldrin requires pyzzub, which
> is arch dependent and currently pyzzub is not available on ppc64.
> 
> How should this broken dependency be treated? Do we have to mark
> aldrin as arch dependent? Or should we simply ignore this?

"ExcludeArch: ppc64" in the aldrin spec file. That information is added to
the src.rpm only, however, but in turn the compose tool doesn't publish
the noarch build for ppc64.



From buildsys at redhat.com  Fri Oct  5 10:58:45 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 5 Oct 2007 06:58:45 -0400
Subject: rawhide report: 20071005 changes
Message-ID: <200710051058.l95Awjr0014139@porkchop.devel.redhat.com>

New package PyQt4
	Python bindings for Qt4

New package R-DynDoc
	Functions for dynamic documents

New package aget
	Console download accelerator

New package asylum
	SDL port of the game Asylum, originally for the Archimedes

New package freecol
	The FreeCol multi-player strategy game

New package gurlchecker
	A Gnome link validity checker

New package perl-Net-IRC
	Perl interface to the Internet Relay Chat protocol

New package superiotool
	Simple program for detecting Super I/O on your mainboard

New package tempest
	Tempest OpenGL screensaver


 
Updated Packages:

R-2.6.0-1.fc8
-------------
* Thu Oct 04 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-1
- bump to 2.6.0

* Sun Aug 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.5.1-3
- fix license tag
- rebuild for ppc32

* Thu Jul 05 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.5.1-2
- add rpm helper macros, script

TnL-070909-2.fc8
----------------
* Wed Oct 03 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 070909-2
- Use TnL everywhere for consistency
- Add missing boost-devel BuildRequires
- Exit gracefully when the game cannot open the soundcard
- Use opengl-games-utils wrapper to show error dialog when DRI is missing
azureus-2.5.0.4-3.fc8
---------------------
* Thu Oct 04 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 2.5.0.4-3
- Build against swt 3.3.
- Update startup script.
- Resolves: rhbz#296911

bluez-utils-3.19-2.fc8
----------------------
* Thu Oct 04 2007 - Bastien Nocera <bnocera at redhat.com> 3.19-2
- Disable hid2hci by default, it causes more problems than
  it solves on stock installations (especially on Macs, #157971)

claws-mail-3.0.2-1.fc8
----------------------
* Fri Oct 05 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.0.2-1
- version upgrade

dbus-1.1.2-7.fc8
----------------
* Thu Oct 04 2007 Matthias Clasen <mclasen at redhat.com> - 1.1.2-7
- Make the daemon a PIE executable  (#210039)

dejagnu-1:1.4.4-10
------------------
* Thu Oct 04 2007 Petr Machata <pmachata at redhat.com> - 1:1.4.4-10
- A few more cleanups after discussion with reviewer.
- Resolves: #225679

dircproxy-1.2.0-0.6beta2.fc8
----------------------------
* Thu Oct 04 2007 Warren Togami <wtogami at redhat.com> - 1.2.0-0.6.beta2
- Fix segfault on blank /me

echo-icon-theme-0.3-3.git.fc8
-----------------------------
* Thu Oct 04 2007 Martin Sourada <martin.sourada> - 0.3-3.git
- Fix big icons issue

eclipse-cdt-1:4.0.1-1.fc8
-------------------------
* Thu Oct 04 2007 Jeff Johnston <jjohnstn at redhat.com> 4.0.1-1
- Use official CDT 4.0.1 source tarball
- Update autotools to 0.9.5
- Resolves #315811

eclipse-egit-0.3.0-2.fc8
------------------------
* Thu Oct 04 2007 Ben Konrath <bkonrath at redhat.com> 0.3.0-2.fc8
- Require git-core instead of git.
- Resolves: #319321

* Mon Sep 24 2007 Ben Konrath <bkonrath at redhat.com> 0.3.0-1.fc8
- 0.3.0

* Wed Sep 19 2007 Ben Konrath <bkonrath at redhat.com> 0.2.99-0.git20070919.fc8
- 0.2.99 git20070919

emacspeak-26-3.fc8
------------------
* Thu Oct 04 2007 Jens Petersen <petersen at redhat.com> - 26-3
- use requires instead of prereq for post and preun install-info

* Mon Aug 13 2007 Jens Petersen <petersen at redhat.com>
- some lisp subdirs are BSD

evolution-2.12.0-5.fc8
----------------------
* Thu Oct 04 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-5.fc8
- Require gnome-themes (RH bug #235617).

* Wed Oct 03 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-4.fc8
- Revise patch for GNOME bug #477045 (run-time warnings when composing mail).

* Wed Sep 19 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-3.fc8
- Re-enable the inline audio plugin since it now uses GStreamer 0.10.

gnome-keyring-2.20-3.fc8
------------------------
* Thu Oct 04 2007 Alexander Larsson <alexl at redhat.com> - 2.20-3
- Add NO_MATCH error patch from svn. Will fix apps that
  can't handle empty list matches

* Wed Oct 03 2007 Alexander Larsson <alexl at redhat.com> - 2.20-2
- Backport fix from svn where newly created keyrings weren't
  found
- Don't unset default keyring on daemon shutdown

* Mon Sep 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20-1
- Update to 2.20

gtk-vnc-0.2.0-3.fc8
-------------------
* Thu Oct 04 2007 Daniel P. Berrange <berrange at redhat.com> - 0.2.0-3.fc8
- Fixed coroutine caller to avoid SEGV

gtk2-2.12.0-5.fc8
-----------------
* Thu Oct 04 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-5
- Fix a grab problem with multiple volume buttons

* Tue Sep 25 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-4
- Fix a crash in simple search
- Drop obsolete Obsoletes and Conflicts

* Thu Sep 20 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-3
- Fix a problem with swt and tooltips

hunspell-en-0.20061130-3.fc8
----------------------------
* Mon Sep 17 2007 Caolan McNamara <caolanm at redhat.com> - 0.20061130-3
- new varient alias
irqbalance-2:0.55-6.fc8
-----------------------
* Thu Oct 04 2007 Neil Horman <nhorman at redhat.com> - 2:0.55-6
- Fix irqbalance init script (bz 317219)

kdelibs4-3.93.0-11.fc8
----------------------
* Thu Oct 04 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-11
- don't make this the default kdelibs on F9 yet
- retry ppc64 build (#300571)

kdepimlibs-3.93.0-4.fc8
-----------------------
* Thu Oct 04 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-4
- drop ExcludeArch: ppc64 (#300591)

kernel-2.6.23-0.217.rc9.git1.fc8
--------------------------------
* Tue Oct 02 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git1

* Tue Oct 02 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9

* Sun Sep 30 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc8-git4

kicad-2007.07.09-1.fc8
----------------------
* Thu Oct 04 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 2007.07.09-1
- New upstream version
  - Merge previous patches
  - Remove X-Fedora, Electronics and Engineering categories
  - Update desktop file

* Mon Aug 27 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 2007.01.15-4
- License tag clarification

libmtp-0.2.2-1.fc8
------------------
* Fri Aug 17 2007 Linus Walleij <triad at df.lth.se> 0.2.2-1
- New upstream release.

make-1:3.81-8.fc8
-----------------
* Thu Oct 04 2007 Petr Machata <pmachata at redhat.com> - 1:3.81-8
- Cleaned up per merge review.
- Related: #226120

* Thu Aug 16 2007 Petr Machata <pmachata at redhat.com> - 1:3.81-7
- Fix licensing tag.

* Fri Mar 16 2007 Petr Machata <pmachata at redhat.com> - 1:3.81-6
- Always run testsuite with C locale.
- Resolves: #232607

ncurses-5.6-10.20070812.fc8
---------------------------
* Thu Oct 04 2007 Miroslav Lichvar <mlichvar at redhat.com> 5.6-10.20070812
- fix comp_hash string output
- avoid comparing padding in cchar_t structure
- remove gawk from buildrequires

openldap-2.3.38-3.fc8
---------------------
* Thu Oct 04 2007 Jan Safranek <jsafranek at redhat.com> 2.3.38-3.fc8
- BDB downgraded back to 4.4.20 because 4.6.18 is not supported by 
  openldap (#314821)

parted-1.8.6-10.fc8
-------------------
* Thu Oct 04 2007 David Cantrell <dcantrell at redhat.com> - 1.8.6-10
- Do not install the testsuite tools

* Thu Oct 04 2007 David Cantrell <dcantrell at redhat.com> - 1.8.6-9
- Always define PED_DEVICE_DM regardless of compile time options

php-pear-1:1.6.2-2.fc8
----------------------
* Thu Oct 04 2007 Joe Orton <jorton at redhat.com> 1:1.6.2-2
- require php-cli not php

policycoreutils-2.0.27-7.fc8
----------------------------
* Tue Oct 02 2007 Dan Walsh <dwalsh at redhat.com> 2.0.27-7
- Add genhomedircon script to rebuild file_context for shadow-utils

postfix-2:2.4.5-2.fc8
---------------------
* Thu Oct 04 2007 Thomas Woerner <twoerner at redhat.com> 2:2.4.5-2
- made init script lsb conform (#243286, rhbz#247025)
- added link to postfix sasl readme into Postfix-SASL-RedHat readme

pykickstart-1.17-1.fc8
----------------------
* Thu Oct 04 2007 Chris Lumens <clumens at redhat.com> 1.17-1
- Simplify argument processing and printing.

python-html2text-2.28-1.1
-------------------------
* Thu Oct 04 2007 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.28-1
- update to 2.28 (just one line actually different)

python-virtinst-0.300.1-2.fc8
-----------------------------
* Thu Oct 04 2007 Daniel P. Berrange <berrange at redhat.com> - 0.300.1-2.fc8
- Remove USB tablet for all except Windows (rhbz #302951)

qt-1:3.3.8-9.fc8
----------------
* Thu Oct 04 2007 Than Ngo <than at redhat.com> - 3.3.8-9
- rh#309091, qt should provide %{qtdir}/plugins/styles
- rh#276521, qt-copy patches 0079, 0080, 0082 and 0084

* Mon Sep 17 2007 Than Ngo <than at redhat.com> - 3.3.8-8
- CVE-2007-4137

* Wed Aug 29 2007 Than Ngo <than at redhat.com> - 1:3.3.8-7.fc7.1
- CVE-2007-0242

qt4-4.3.2-1.fc8
---------------
* Thu Oct 04 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-1
- qt-4.3.2
- (re)fix ppc64 segfaults, ppc64 fix upstreamed (previous patch was 
  inadvertantly not applied) (#246324)

rss-glx-0.8.1.p-14.fc8
----------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-14
- prefix xscreensaver symlinks with "rss-glx-" as well (#318611)

selinux-policy-3.0.8-17.fc8
---------------------------
* Tue Oct 02 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-17
- Check asound.state

system-config-printer-0.7.74.4-2.fc8
------------------------------------
* Wed Oct 03 2007 Tim Waugh <twaugh at redhat.com> 0.7.74.4-2
- Include two more fixes from stable branch.
- No need to run update-desktop-database because there are no MimeKey
  lines in the desktop files.
- Consistent macro style.

system-config-users-1.2.69-1.fc8
--------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.69
- prohibit home directories which are not absolute paths or contain path
  components which are empty, ".", ".." or too long (#303971)

* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com>
- limit username and groupname entries to their respective maximum lengths
  (#303931)

* Mon Oct 01 2007 Nils Philippsen <nphilipp at redhat.com>
- limit homedir entry to maximum path length (#304011)

util-linux-ng-2.13-2.fc8
------------------------
* Thu Oct 04 2007 Karel Zak <kzak at redhat.com> 2.13-2
- update to the latest upstream stable branch

vim-2:7.1.135-1.fc8
-------------------
* Thu Oct 04 2007 Karsten Hopp <karsten at redhat.com> 7.1.135-1
- patchlevel 135

* Wed Sep 26 2007 Karsten Hopp <karsten at redhat.com> 7.1.122-1
- patchlevel 122

* Tue Sep 25 2007 Karsten Hopp <karsten at redhat.com> 7.1.119-1
- patchlevel 119

virt-manager-0.5.2-1.fc8
------------------------
* Thu Oct 04 2007 Daniel P. Berrange <berrange at redhat.com> - 0.5.2-1.fc8
- Update to 0.5.2 release
- No scrollbars for high res guest in low res host (rhbz 273181)
- Unable to remove network device (rhbz 242900)
- Fixed broken menu items (rhbz 307551)
- Require libvirt 0.3.3 to get CDROM change capability for Xen

xorg-x11-drv-ati-6.7.194-3.fc8
------------------------------
* Fri Oct 05 2007 Dave Airlie <airlied at redhat.com> 6.7.194-3
- radeon-6.7.194-upstream-fixes - Upstream LVDS fixes
  improve chances of working on more panels.

xorg-x11-drv-avivo-0.0.1-6.fc8
------------------------------
* Thu Oct 04 2007 Kristian H??gsberg <krh at redhat.com> - 0.0.1-6
- Add patch to add X2300 PCI IDs.

xorg-x11-drv-i810-2.1.1-4.fc8
-----------------------------
* Fri Oct 05 2007 Dave Airlie <airlied at redhat.com> 2.1.1-4
- intel-2.1.1-quirk-update.patch - update quirks from master

Broken deps for i386
----------------------------------------------------------
	fwbuilder - 2.1.12-3.fc8.i386 requires libfwbuilder = 0:2.1.12
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	rpy - 1.0-0.1.RC3.fc8.i386 requires R = 0:2.5.1



Broken deps for x86_64
----------------------------------------------------------
	fwbuilder - 2.1.12-3.fc8.x86_64 requires libfwbuilder = 0:2.1.12
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit)
	openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	rpy - 1.0-0.1.RC3.fc8.x86_64 requires R = 0:2.5.1



Broken deps for ppc
----------------------------------------------------------
	fwbuilder - 2.1.12-3.fc8.ppc requires libfwbuilder = 0:2.1.12
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	rpy - 1.0-0.1.RC3.fc8.ppc requires R = 0:2.5.1



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc64 requires gnome-python2-gtkmozembed
	aldrin - 0.11-5.fc8.noarch requires pyzzub = 0:0.2.3
	anaconda - 11.3.0.36-1.ppc64 requires gnome-python2-gtkhtml2
	blogtk - 1.1-8.fc7.noarch requires gnome-python2-gtkhtml2
	catfish-engines - 0.3-0.2.c.fc8.noarch requires beagle
	elisa - 0.3.1-2.fc8.noarch requires gnome-python2-extras
	exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkhtml2
	exaile - 0.2.10-3.fc8.ppc64 requires gnome-python2-gtkmozembed
	fwbuilder - 2.1.12-3.fc8.ppc64 requires libfwbuilder = 0:2.1.12
	gimmie - 0.2.7-2.fc8.ppc64 requires gnome-python2-libegg
	gnochm - 0.9.10-1.fc8.noarch requires gnome-python2-gtkhtml2
	gnome-applets - 1:2.20.0-6.fc8.ppc64 requires gnome-python2-libegg
	gnome-blog - 0.9.1-5.fc7.noarch requires gnome-python2-gtkspell
	gramps - 2.2.8-3.fc8.noarch requires gnome-python2-gtkspell
	istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-libegg
	istanbul - 0.2.2-4.fc8.ppc64 requires gnome-python2-extras
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-gtkhtml2
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-libegg
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-gtkmozembed
	listen - 0.5-15.fc7.1.ppc64 requires gnome-python2-extras
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	quodlibet - 1.0-2.fc8.ppc64 requires gnome-python2-libegg
	rpy - 1.0-0.1.RC3.fc8.ppc64 requires R = 0:2.5.1
	scribes - 0.3.2.9-1.fc8.noarch requires gnome-python2-gtkspell >= 0:2.12
	setroubleshoot - 1.10.7-1.fc8.noarch requires gnome-python2-gtkhtml2
	solfege - 3.8.0-1.fc8.ppc64 requires gnome-python2-gtkhtml2
	sonata - 1.2.3-1.fc8.ppc64 requires gnome-python2-libegg
	straw - 0.27-9.fc8.noarch requires gnome-python2-gtkhtml2
	straw - 0.27-9.fc8.noarch requires gnome-python2-libegg
	wuja - 0.0.8-2.fc8.noarch requires gnome-python2-libegg >= 0:2.14.3
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Oct  5 11:37:44 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 05 Oct 2007 20:37:44 +0900
Subject: aldrin broken dependency [Fwd: Broken dependencies: aldrin]
In-Reply-To: <20071005123446.9d10f972.mschwendt.tmp0701.nospam@arcor.de>
References: <1191577566.5109.2.camel@dev31.iconmobile.de>	<47060CC1.5050500@ioa.s.u-tokyo.ac.jp>
	<20071005123446.9d10f972.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <47062208.1020309@ioa.s.u-tokyo.ac.jp>

Michael Schwendt wrote, at 10/05/2007 07:34 PM +9:00:

>> Here aldrin itself is "noarch", however aldrin requires pyzzub, which
>> is arch dependent and currently pyzzub is not available on ppc64.
>>
>> How should this broken dependency be treated? Do we have to mark
>> aldrin as arch dependent? Or should we simply ignore this?
> 
> "ExcludeArch: ppc64" in the aldrin spec file. That information is added to
> the src.rpm only, however, but in turn the compose tool doesn't publish
> the noarch build for ppc64.
> 

Thank you.

Mamoru



From jkeating at redhat.com  Fri Oct  5 11:44:13 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 5 Oct 2007 07:44:13 -0400
Subject: Test NetworkManager-openvpn?
In-Reply-To: <4705BCF4.2070207@redhat.com>
References: <4705BCF4.2070207@redhat.com>
Message-ID: <20071005074413.07744715@redhat.com>

On Fri, 05 Oct 2007 00:26:28 -0400
Warren Togami <wtogami at redhat.com> wrote:

> Can someone test the equivalent for NetworkManager-openvpn with
> Selinux enforcing enabled?  Please test it in both "service
> NetworkManager start" and "NetworkManager --no-daemon" mode to be
> sure both are functioning properly.

That's a little difficult when NM-openvpn hasn't yet been ported to
NM-0.7 infrastructure.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/1ae1dd0e/attachment.sig>

From jkeating at redhat.com  Fri Oct  5 11:48:00 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 5 Oct 2007 07:48:00 -0400
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
Message-ID: <20071005074800.556b0819@redhat.com>

On Fri, 5 Oct 2007 11:00:46 +0400
"Peter Lemenkov" <lemenkov at gmail.com> wrote:

> Hello All!
> Just for clarification - is it allowed to mix macros and native
> command in spec-file? For instance
> 
> %make
> make %{?_smp_mflags}
> 
> %install
> %{_rm} -rf  $RPM_BUILD_ROOT
> make DESTDIR=%{buildroot} install

This is an unclear example.  Are you talking about mixing 'make' and
'%{_rm}', or are you talking about mixing '$RPM_BUILD_ROOT' and
'%{buildroot}' ?  The former is allowed both in rpm and the
guidelines, the latter is allowed in rpm but disallowed in the
guidelines.  Our guidelines ask you to use one macro style throughout
a spec instead of mixing types. 

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/69329011/attachment.sig>

From sundaram at fedoraproject.org  Fri Oct  5 11:50:51 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 05 Oct 2007 17:20:51 +0530
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <adf480660710050214s78ba957eyb5f502f37126bd57@mail.gmail.com>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>	<4705E37A.6030209@fedoraproject.org>
	<adf480660710050214s78ba957eyb5f502f37126bd57@mail.gmail.com>
Message-ID: <4706251B.8070102@fedoraproject.org>

Peter Lemenkov wrote:
> 2007/10/5, Rahul Sundaram <sundaram at fedoraproject.org>:
>> Peter Lemenkov wrote:
>>> Hello All!
>>> Just for clarification - is it allowed to mix macros and native
>>> command in spec-file? For instance
> 
> [sorry, skipped]
> 
>> It would work but it is explicitly recommended against in the guidelines.
> 
> Sorry, but I can't find exact place in Fedora's Wiki where it's stated.

http://fedoraproject.org/wiki/Packaging/Guidelines#head-f3d77b27a5d29dfc1f5600ef3fc836f2e317badf

Rahul



From rdieter at math.unl.edu  Fri Oct  5 12:14:13 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 05 Oct 2007 07:14:13 -0500
Subject: F8t3 k3b and sound problems
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
	<1191580187.12607.4.camel@scrappy.miketc.com>
Message-ID: <fe59ql$ahr$1@sea.gmane.org>

Mike Chambers wrote:


> Ok, after running this program from root, it works and detects/uses the
> cdroms.  But from a normal user it doesn't.  Permissions or something
> need to be changed I guess to allow normal user to run it and detect/use
> the cdroms?

What DE are you running?  kde?  gnome?  other?

-- Rex




From alexl at redhat.com  Fri Oct  5 12:45:37 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 05 Oct 2007 14:45:37 +0200
Subject: Co-maintaining mono packages
In-Reply-To: <1191578779.4199.11.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
Message-ID: <1191588337.22332.99.camel@localhost.localdomain>

On Fri, 2007-10-05 at 11:06 +0100, Paul wrote:
> Hi,
> 
> Currently, mono in rawhide is dropping behind the actual releases which
> is causing problems with the likes of monodevelop being updated and more
> over, stuff I do for work!
> 
> Is there anything I need to do to start co-maintaining the mono tree?

Not really. That seems like a good idea. 

I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
but it seems i can only add myself. Can you add yourself there and I'll
approve it.



From paul at all-the-johnsons.co.uk  Fri Oct  5 13:05:36 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 05 Oct 2007 14:05:36 +0100
Subject: Co-maintaining mono packages
In-Reply-To: <1191588337.22332.99.camel@localhost.localdomain>
References: <1191578779.4199.11.camel@T7.Linux>
	<1191588337.22332.99.camel@localhost.localdomain>
Message-ID: <1191589536.4199.13.camel@T7.Linux>

Hi,

> > Is there anything I need to do to start co-maintaining the mono tree?
> 
> Not really. That seems like a good idea. 
> 
> I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
> but it seems i can only add myself. Can you add yourself there and I'll
> approve it.

Probably because I've not used it for ages, my login seems dead. How do
I get it back working?

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071005/495d12b2/attachment.sig>

From paul at all-the-johnsons.co.uk  Fri Oct  5 13:06:47 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 05 Oct 2007 14:06:47 +0100
Subject: Co-maintaining mono packages
In-Reply-To: <1191588337.22332.99.camel@localhost.localdomain>
References: <1191578779.4199.11.camel@T7.Linux>
	<1191588337.22332.99.camel@localhost.localdomain>
Message-ID: <1191589607.4199.15.camel@T7.Linux>

Hi,

> I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
> but it seems i can only add myself. Can you add yourself there and I'll
> approve it.

Done!

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071005/1bf68857/attachment.sig>

From alexl at redhat.com  Fri Oct  5 13:10:28 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 05 Oct 2007 15:10:28 +0200
Subject: Co-maintaining mono packages
In-Reply-To: <1191589607.4199.15.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
	<1191588337.22332.99.camel@localhost.localdomain>
	<1191589607.4199.15.camel@T7.Linux>
Message-ID: <1191589828.22332.101.camel@localhost.localdomain>

On Fri, 2007-10-05 at 14:06 +0100, Paul wrote:
> Hi,
> 
> > I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
> > but it seems i can only add myself. Can you add yourself there and I'll
> > approve it.
> 
> Done!

Weird. I don't see you there.



From paul at all-the-johnsons.co.uk  Fri Oct  5 14:06:44 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 05 Oct 2007 15:06:44 +0100
Subject: Co-maintaining mono packages
In-Reply-To: <1191589828.22332.101.camel@localhost.localdomain>
References: <1191578779.4199.11.camel@T7.Linux>
	<1191588337.22332.99.camel@localhost.localdomain>
	<1191589607.4199.15.camel@T7.Linux>
	<1191589828.22332.101.camel@localhost.localdomain>
Message-ID: <1191593204.4199.18.camel@T7.Linux>

Hi,

> > > I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
> > > but it seems i can only add myself. Can you add yourself there and I'll
> > > approve it.
> > 
> > Done!
> 
> Weird. I don't see you there.

Odd...

Should be there now.

What is very odd is that there isn't a user pfj in CVSROOT/passwd for
me!

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071005/80912fc5/attachment.sig>

From wtogami at redhat.com  Fri Oct  5 14:16:11 2007
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 05 Oct 2007 10:16:11 -0400
Subject: Help Needed: Test zd1211rw-mac80211, b43, rt73usb Wireless
Message-ID: <4706472B.1070903@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=319071
We need help testing mac80211-based drivers, e.g. zd1211rw-mac80211, 
b43, rt73usb, etc.

http://koji.fedoraproject.org/packages/kernel/2.6.23/
Kernel 217 is known to work with iwl3945 and iwl4965, but kernel 218 
broke it.  We need these other network drivers tested between 217 and 
218.  Please report your findings to the above bug report.

Thanks,
Warren Togami
wtogami at redhat.com



From paul at all-the-johnsons.co.uk  Fri Oct  5 14:19:56 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 05 Oct 2007 15:19:56 +0100
Subject: cvs access problem
Message-ID: <1191593996.4199.24.camel@T7.Linux>

Hi,

Probably because I've not done anything for ages, my box doesn't like
cvs for fedora.

In my home directory, I've opened a terminal window and typed

export CVS_RSH=ssh
export CVSROOT=:pserver:my_user_name at cvs.fedoraproject.org:/cvs/pkgs 
cd extras
cvs co common owners

cvs then throws back

no such user my_user_name in CVSROOT/passwd

(my_user_name is replaced with my actual user name)

Any ideas on what's going wrong?

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071005/4d882944/attachment.sig>

From mr.ecik at gmail.com  Fri Oct  5 14:22:12 2007
From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=)
Date: Fri, 5 Oct 2007 16:22:12 +0200
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
Message-ID: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>

Gnome-python2-libegg isn't in fact available in ppc64. However I took
a look into gnome-python2-extras spec file and it seems that
ExcludeArch: ppc64 is used only for gnome-python2-gdl subpackage. In
koji [1] I can see that no package is built under ppc64.
Does gnome-python2-extras need to be rebuilt or is it a bug in koji?
I don't want to ExcludeArch: ppc64 for sonata unless it's necessity.
1: http://koji.fedoraproject.org/koji/buildinfo?buildID=19841

---------- Forwarded message ----------
From: buildsys at fedoraproject.org <buildsys at fedoraproject.org>
Date: 05-10-2007 09:50
Subject: Broken dependencies: sonata
To: ecik at fedoraproject.org




sonata has broken dependencies in the development tree:
On ppc64:
        sonata - 1.2.3-1.fc8.ppc64 requires gnome-python2-libegg
Please resolve this as soon as possible.




-- 
Micha? Bentkowski
mr.ecik at gmail.com



From katzj at redhat.com  Fri Oct  5 14:27:22 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 05 Oct 2007 10:27:22 -0400
Subject: cvs access problem
In-Reply-To: <1191593996.4199.24.camel@T7.Linux>
References: <1191593996.4199.24.camel@T7.Linux>
Message-ID: <1191594442.16124.11.camel@localhost.localdomain>

On Fri, 2007-10-05 at 15:19 +0100, Paul wrote:
> In my home directory, I've opened a terminal window and typed
> 
> export CVS_RSH=ssh
> export CVSROOT=:pserver:my_user_name at cvs.fedoraproject.org:/cvs/pkgs 

CVSROOT=:ext:user at cvs.fedoraproject.org:/cvs/pkgs

not pserver

Jeremy



From alexl at redhat.com  Fri Oct  5 14:34:56 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 05 Oct 2007 16:34:56 +0200
Subject: Co-maintaining mono packages
In-Reply-To: <1191593204.4199.18.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
	<1191588337.22332.99.camel@localhost.localdomain>
	<1191589607.4199.15.camel@T7.Linux>
	<1191589828.22332.101.camel@localhost.localdomain>
	<1191593204.4199.18.camel@T7.Linux>
Message-ID: <1191594896.22332.107.camel@localhost.localdomain>

On Fri, 2007-10-05 at 15:06 +0100, Paul wrote:
> Hi,
> 
> > > > I looked at https://admin.fedoraproject.org/pkgdb/packages/name/mono
> > > > but it seems i can only add myself. Can you add yourself there and I'll
> > > > approve it.
> > > 
> > > Done!
> > 
> > Weird. I don't see you there.
> 
> Odd...
> 
> Should be there now.

Approved!



From stickster at gmail.com  Fri Oct  5 14:47:09 2007
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 05 Oct 2007 10:47:09 -0400
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
In-Reply-To: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
References: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
Message-ID: <1191595629.3685.1.camel@localhost.localdomain>

On Fri, 2007-10-05 at 16:22 +0200, Micha? Bentkowski wrote:
> Gnome-python2-libegg isn't in fact available in ppc64. However I took
> a look into gnome-python2-extras spec file and it seems that
> ExcludeArch: ppc64 is used only for gnome-python2-gdl subpackage. In
> koji [1] I can see that no package is built under ppc64.
> Does gnome-python2-extras need to be rebuilt or is it a bug in koji?
> I don't want to ExcludeArch: ppc64 for sonata unless it's necessity.
> 1: http://koji.fedoraproject.org/koji/buildinfo?buildID=19841
> 
> ---------- Forwarded message ----------
> From: buildsys at fedoraproject.org <buildsys at fedoraproject.org>
> Date: 05-10-2007 09:50
> Subject: Broken dependencies: sonata
> To: ecik at fedoraproject.org
> 
> sonata has broken dependencies in the development tree:
> On ppc64:
>         sonata - 1.2.3-1.fc8.ppc64 requires gnome-python2-libegg
> Please resolve this as soon as possible.

I'm getting the same sort of warning for gnome-python2-gtkhtml2, a
dependency of blogtk.  That package is also missing from the ppc64 devel
tree.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- 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/20071005/a25fa056/attachment.sig>

From jsacco at gnome.org  Fri Oct  5 14:51:28 2007
From: jsacco at gnome.org (Joseph Sacco)
Date: Fri, 05 Oct 2007 10:51:28 -0400
Subject: printing problems with some applications
Message-ID: <1191595888.2142.8.camel@rt.jesacco.com>

Evolution and evince no longer print after updating to the latest
version of rawhide [05-Oct-07].  Other applications print OK as does the
test page from the printer set up. I can also print text files from the
command line using lp.

Anyone else seeing this?


-Joseph


-- 
jsacco [at] gnome [dot] org



From katzj at redhat.com  Fri Oct  5 15:00:02 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 05 Oct 2007 11:00:02 -0400
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
In-Reply-To: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
References: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
Message-ID: <1191596402.16124.13.camel@localhost.localdomain>

On Fri, 2007-10-05 at 16:22 +0200, Micha? Bentkowski wrote:
> Gnome-python2-libegg isn't in fact available in ppc64. However I took
> a look into gnome-python2-extras spec file and it seems that
> ExcludeArch: ppc64 is used only for gnome-python2-gdl subpackage. In
> koji [1] I can see that no package is built under ppc64.
> Does gnome-python2-extras need to be rebuilt or is it a bug in koji?

It's a bug in gnome-python2-extras.  It should have the gdl subpackage
ifarch'd and not be trying to use an ExcludeArch

Jeremy



From 440volt.tux at gmail.com  Fri Oct  5 15:15:27 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Fri, 5 Oct 2007 20:45:27 +0530
Subject: broken dependencies
Message-ID: <539333cb0710050815n5182e5adv9572ae5cca2a5488@mail.gmail.com>

Hi !

currently i am receiving mail from buildsys about broken dependencies of straw

>straw has broken dependencies in the development tree:
>On ppc64:
>       straw - 0.27-9.fc8.noarch requires gnome-python2-gtkhtml2
>      straw - 0.27-9.fc8.noarch requires gnome-python2-libegg
>Please resolve this as soon as possible.

Now straw is an noarch. what to do with these dependencies? will i
exclude ppc64 from spec file ??
please help.

-- 
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From jdennis at redhat.com  Fri Oct  5 15:24:14 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 05 Oct 2007 11:24:14 -0400
Subject: broken dependencies
In-Reply-To: <539333cb0710050815n5182e5adv9572ae5cca2a5488@mail.gmail.com>
References: <539333cb0710050815n5182e5adv9572ae5cca2a5488@mail.gmail.com>
Message-ID: <4706571E.40006@redhat.com>

subhodip biswas wrote:
> Hi !
> 
> currently i am receiving mail from buildsys about broken dependencies of straw
> 
>> straw has broken dependencies in the development tree:
>> On ppc64:
>>       straw - 0.27-9.fc8.noarch requires gnome-python2-gtkhtml2
>>      straw - 0.27-9.fc8.noarch requires gnome-python2-libegg
>> Please resolve this as soon as possible.
> 
> Now straw is an noarch. what to do with these dependencies? will i
> exclude ppc64 from spec file ??
> please help.
> 

I believe the problem was tracked down to an error in the 
gnome-python-extras spec file which did not properly restrict its 
ExcludeArch to a single sub-package. The remedy is to get this fixed in 
the gnome-python-extras rpm.

--
John Dennis <jdennis at redhat.com>




From jdennis at redhat.com  Fri Oct  5 15:53:46 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 05 Oct 2007 11:53:46 -0400
Subject: printing problems with some applications
In-Reply-To: <1191595888.2142.8.camel@rt.jesacco.com>
References: <1191595888.2142.8.camel@rt.jesacco.com>
Message-ID: <47065E0A.80305@redhat.com>

Joseph Sacco wrote:
> Evolution and evince no longer print after updating to the latest
> version of rawhide [05-Oct-07].  Other applications print OK as does the
> test page from the printer set up. I can also print text files from the
> command line using lp.
> 
> Anyone else seeing this?

I've been experiencing printer errors on my LaserJet 2100 which seem to only be 
triggered when printing from a rawhide box. I did file a bugzilla. I have not 
been able to determine the cause of the errors. The behavior is to put the 
printer in some type of error state with it's error light illuminated, pressing 
the "GO" button clears the error and printing continues normally.

-- 
John Dennis <jdennis at redhat.com>



From jsacco at gnome.org  Fri Oct  5 16:01:54 2007
From: jsacco at gnome.org (Joseph Sacco)
Date: Fri, 05 Oct 2007 12:01:54 -0400
Subject: printing problems with some applications
In-Reply-To: <47065E0A.80305@redhat.com>
References: <1191595888.2142.8.camel@rt.jesacco.com>
	<47065E0A.80305@redhat.com>
Message-ID: <1191600114.14922.5.camel@rt.jesacco.com>

On Fri, 2007-10-05 at 11:53 -0400, John Dennis wrote:
> Joseph Sacco wrote:
> > Evolution and evince no longer print after updating to the latest
> > version of rawhide [05-Oct-07].  Other applications print OK as does the
> > test page from the printer set up. I can also print text files from the
> > command line using lp.
> > 
> > Anyone else seeing this?
> 
> I've been experiencing printer errors on my LaserJet 2100 which seem to only be 
> triggered when printing from a rawhide box. I did file a bugzilla. I have not 
> been able to determine the cause of the errors. The behavior is to put the 
> printer in some type of error state with it's error light illuminated, pressing 
> the "GO" button clears the error and printing continues normally.
> 
> -- 
> John Dennis <jdennis at redhat.com>

Interesting...  I am also using an HP2100M.

What happens when I attempt to print from either evince or evolution is
a dialog box pops up *immediately* and says "too many errors".  The
printer error light does not illuminate. Printing from another app, e.g.
gedit, then works without having to reset the printer.

FWIW,  printing from a currently updated version of FC7 works fine for
both evolution and evince.


-Joseph


-- 
jsacco [at] gnome [dot] org



From mclasen at redhat.com  Fri Oct  5 16:17:51 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 05 Oct 2007 12:17:51 -0400
Subject: Mixing of macros and native commands in specs.
In-Reply-To: <4705E173.5020807@hhs.nl>
References: <adf480660710042359q54e0ff0cwc2265b9fd3da0d26@mail.gmail.com>
	<adf480660710050000r6151df70u1d4a0a3c10e0029@mail.gmail.com>
	<4705E173.5020807@hhs.nl>
Message-ID: <1191601071.23375.4.camel@localhost.localdomain>


On Fri, 2007-10-05 at 09:02 +0200, Hans de Goede wrote:
> Peter Lemenkov wrote:
> > Hello All!
> > Just for clarification - is it allowed to mix macros and native
> > command in spec-file? For instance
> > 
> > %make
> > make %{?_smp_mflags}
> > 
> > %install
> > %{_rm} -rf  $RPM_BUILD_ROOT
> > make DESTDIR=%{buildroot} install
> > 
> > 
> 
> Allowed as in the RPM will build, yes, allowed as in what do the guidelines 
> say. No, either use all macros or all native commands.

The guidelines don't talk about macros like %{__rm} vs native commands
at all. The only mention of macros is $RPM_BUILD_ROOT vs %{buildroot}. 



From mrtom at fedoraproject.org  Fri Oct  5 16:18:05 2007
From: mrtom at fedoraproject.org (Thomas Canniot)
Date: Fri, 5 Oct 2007 18:18:05 +0200
Subject: Test NetworkManager-openvpn?
In-Reply-To: <20071005074413.07744715@redhat.com>
References: <4705BCF4.2070207@redhat.com> <20071005074413.07744715@redhat.com>
Message-ID: <20071005181805.4a85545d@localhost.localdomain>

Le Fri, 5 Oct 2007 07:44:13 -0400,
Jesse Keating <jkeating at redhat.com> a ?crit :

> On Fri, 05 Oct 2007 00:26:28 -0400
> Warren Togami <wtogami at redhat.com> wrote:
> 
> > Can someone test the equivalent for NetworkManager-openvpn with
> > Selinux enforcing enabled?  Please test it in both "service
> > NetworkManager start" and "NetworkManager --no-daemon" mode to be
> > sure both are functioning properly.
> 
> That's a little difficult when NM-openvpn hasn't yet been ported to
> NM-0.7 infrastructure.
> 

On FC7, I had absolutely no problem using it... in fact, it is the
light at the end of the tunnel for me. It works so great and out of the
box (certificate and login / pwd identification on a wpa network). I
can now connect very easily in my university.

Thomas



From jdennis at redhat.com  Fri Oct  5 16:58:18 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 05 Oct 2007 12:58:18 -0400
Subject: printing problems with some applications
In-Reply-To: <1191600114.14922.5.camel@rt.jesacco.com>
References: <1191595888.2142.8.camel@rt.jesacco.com>	<47065E0A.80305@redhat.com>
	<1191600114.14922.5.camel@rt.jesacco.com>
Message-ID: <47066D2A.5030801@redhat.com>

Joseph Sacco wrote:
> On Fri, 2007-10-05 at 11:53 -0400, John Dennis wrote:
>> Joseph Sacco wrote:
>>> Evolution and evince no longer print after updating to the latest
>>> version of rawhide [05-Oct-07].  Other applications print OK as does the
>>> test page from the printer set up. I can also print text files from the
>>> command line using lp.
>>>
>>> Anyone else seeing this?
>> I've been experiencing printer errors on my LaserJet 2100 which seem to only be 
>> triggered when printing from a rawhide box. I did file a bugzilla. I have not 
>> been able to determine the cause of the errors. The behavior is to put the 
>> printer in some type of error state with it's error light illuminated, pressing 
>> the "GO" button clears the error and printing continues normally.
>>
>> -- 
>> John Dennis <jdennis at redhat.com>
> 
> Interesting...  I am also using an HP2100M.
> 
> What happens when I attempt to print from either evince or evolution is
> a dialog box pops up *immediately* and says "too many errors".  The
> printer error light does not illuminate. Printing from another app, e.g.
> gedit, then works without having to reset the printer.
> 
> FWIW,  printing from a currently updated version of FC7 works fine for
> both evolution and evince.

FWIW the bug I filed is:
https://bugzilla.redhat.com/show_bug.cgi?id=312491

Consistent with your observation, this only seems to be triggered from 
rawhide.
-- 
John Dennis <jdennis at redhat.com>



From buildsys at fedoraproject.org  Fri Oct  5 17:18:24 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri,  5 Oct 2007 13:18:24 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-05
Message-ID: <20071005171824.34CC215212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 6

NEW asylum-0.2.2-2.fc6 : SDL port of the game Asylum, originally for the Archimedes
    dircproxy-1.2.0-0.6beta2.fc6
    jd-1.9.6-1.fc6
NEW perl-Net-IRC-0.75-2.fc6 : Perl interface to the Internet Relay Chat protocol
    qt4-4.3.2-1.fc6
NEW tempest-0-0.3.20070929.fc6 : Tempest OpenGL screensaver


Changes in Fedora Extras 6: 


asylum-0.2.2-2.fc6
------------------
* Fri Oct 05 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.2.2-2
- Release bump

* Sun Sep 09 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.2.2-1
- Initial release

dircproxy-1.2.0-0.6beta2.fc6
----------------------------
* Thu Oct 04 2007 Warren Togami <wtogami at redhat.com> - 1.2.0-0.6.beta2
- Fix segfault on blank /me

jd-1.9.6-1.fc6
--------------
* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-1
- 1.9.6

perl-Net-IRC-0.75-2.fc6
-----------------------
* Mon Oct 01 2007 Christopher Stone <chris.stone at gmail.com> 0.75-2
- Add irctest and t/ to %doc

* Sun Sep 30 2007 Christopher Stone <chris.stone at gmail.com> 0.75-1
- Initial Release.

qt4-4.3.2-1.fc6
---------------
* Thu Oct 04 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-1
- qt-4.3.2
- (re)fix ppc64 segfaults, ppc64 fix upstreamed (previous patch was 
  inadvertantly not applied) (#246324)

* Fri Sep 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.1-8
- -x11: Req: redhat-rpm-config rpm, app-wrapper/multilib fun (#277581)

* Thu Sep 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.1-7
- include qt4-logo icon, used by qtdemo/qtconfig (#241452)
- linguist.desktop: use new linguist4 icons
- -devel,-x11: %post/%postun scriptlets (icons, mimetypes)

* Thu Sep 13 2007 Than Ngo <than at redhat.com> -  4.3.1-4
- fixed bz241452, add qtdemo/qtconfig icons
- fixed bz249242, designer4 - segmentation fault on s390x

tempest-0-0.3.20070929.fc6
--------------------------
* Mon Oct 01 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0-0.3.20070929
- Minor SPEC changes
- Fixed gnome support. Missing symlink

* Mon Oct 01 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>  0-0.2.20070929
- Support xscreensaver, gnome-screensaver as well as kscreensaver

* Sat Sep 29 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0-0.1.20070929
- Initial release



From tmz at pobox.com  Fri Oct  5 17:38:19 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Oct 2007 13:38:19 -0400
Subject: bodhi update problem
Message-ID: <20071005173819.GH10067@psilocybe.teonanacatl.org>

I built an updated vorbis-tools package to fix bz#244757[1] but bodhi
won't let me push the update for F7.  When I select Add Update, I get
an error that states:

    tmz does not have commit access to vorbis-tools

This is partly true.  Though the package is open to cvsextras, which
is how I had acccess to commit the changes.  What's the best way to
solve this?  Do I need to nag one of the primary maintainers of
vorbis-tools to do the actual push in bodhi (or request more
privileges from the pkgdb)?

Would it be reasonable to allow members of cvsextras to push an update
to -testing if the package is open to cvs commits from cvsextras?
That'd facilitate someone coming along and helping fix low-hanging
fruit bugs like this -- freeing up the maintainers to work on the
harder and more pressing bugs.

Pushing to -testing would provide some warning to the primary
maintainers if someone were to try and push an update they thought
shouldn't be pushed.  Then they could unpush it to prevent it from
getting into the stable updates.

(I'm not sure what the best balance is here, I can see reasons for
allowing or for denying such access in bodhi.)

[1] https://bugzilla.redhat.com/244757

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Excess on occasion is exhilarating. It prevents moderation from
acquiring the deadening effect of a habit.
    -- W. Somerset Maugham

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/2cb631cd/attachment.sig>

From abo at kth.se  Fri Oct  5 18:41:57 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 05 Oct 2007 20:41:57 +0200
Subject: cvs access problem
In-Reply-To: <1191594442.16124.11.camel@localhost.localdomain>
References: <1191593996.4199.24.camel@T7.Linux>
	<1191594442.16124.11.camel@localhost.localdomain>
Message-ID: <1191609717.5560.50.camel@home.alexander.bostrom.net>

fre 2007-10-05 klockan 10:27 -0400 skrev Jeremy Katz:
> On Fri, 2007-10-05 at 15:19 +0100, Paul wrote:
> > In my home directory, I've opened a terminal window and typed
> > 
> > export CVS_RSH=ssh
> > export CVSROOT=:pserver:my_user_name at cvs.fedoraproject.org:/cvs/pkgs 
> 
> CVSROOT=:ext:user at cvs.fedoraproject.org:/cvs/pkgs

Do people actually use that variable? It just seems so impractical.

I never use it, I always use cvs -d instead, since I actually have more
than one CVS repository that I care about.

/abo




From alain.portal at free.fr  Fri Oct  5 19:20:02 2007
From: alain.portal at free.fr (Alain PORTAL)
Date: Fri, 5 Oct 2007 21:20:02 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <20071002100910.GD3535@free.fr>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<20071002100910.GD3535@free.fr>
Message-ID: <200710052120.05292.alain.portal@free.fr>

Le mardi 02 octobre 2007, Patrice Dumas a ?crit :
> On Tue, Oct 02, 2007 at 11:29:47AM +0200, Alain PORTAL wrote:
> > Hi,
> >
> > PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and
> > automake-1.9 were not found:
> > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2
> >.4-1.fc6/
> >
> > Can somebody help me to fix?
>
> There is more than one way to fix such issues,

I found one, I'll exclude ppc arch

-- 
Les pages de manuel Linux en fran?ais
http://manpagesfr.free.fr/
-------------- 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/20071005/9b463e32/attachment.sig>

From jspaleta at gmail.com  Fri Oct  5 19:26:45 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Oct 2007 11:26:45 -0800
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
In-Reply-To: <1191596402.16124.13.camel@localhost.localdomain>
References: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
	<1191596402.16124.13.camel@localhost.localdomain>
Message-ID: <604aa7910710051226t6d37daadt43befa5d605a5c06@mail.gmail.com>

On 10/5/07, Jeremy Katz <katzj at redhat.com> wrote:
> It's a bug in gnome-python2-extras.  It should have the gdl subpackage
> ifarch'd and not be trying to use an ExcludeArch


Is this filed or better yet resolved yet?

-jef



From lmacken at redhat.com  Fri Oct  5 19:34:44 2007
From: lmacken at redhat.com (Luke Macken)
Date: Fri, 5 Oct 2007 15:34:44 -0400
Subject: bodhi update problem
In-Reply-To: <20071005173819.GH10067@psilocybe.teonanacatl.org>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
Message-ID: <20071005193444.GB3424@crow.myhome.westell.com>

On Fri, Oct 05, 2007 at 01:38:19PM -0400, Todd Zullinger wrote:
> I built an updated vorbis-tools package to fix bz#244757[1] but bodhi
> won't let me push the update for F7.  When I select Add Update, I get
> an error that states:
> 
>     tmz does not have commit access to vorbis-tools
> 
> This is partly true.  Though the package is open to cvsextras, which
> is how I had acccess to commit the changes.  What's the best way to
> solve this?  Do I need to nag one of the primary maintainers of
> vorbis-tools to do the actual push in bodhi (or request more
> privileges from the pkgdb)?
> 
> Would it be reasonable to allow members of cvsextras to push an update
> to -testing if the package is open to cvs commits from cvsextras?
> That'd facilitate someone coming along and helping fix low-hanging
> fruit bugs like this -- freeing up the maintainers to work on the
> harder and more pressing bugs.
> 
> Pushing to -testing would provide some warning to the primary
> maintainers if someone were to try and push an update they thought
> shouldn't be pushed.  Then they could unpush it to prevent it from
> getting into the stable updates.
> 
> (I'm not sure what the best balance is here, I can see reasons for
> allowing or for denying such access in bodhi.)

Right now bodhi only looks at the individuals with commit access from
the pkgdb.  It should definitely also check the ACL, and in the case
of vorbis-tools, allow you to push updates for it.

Toshio is throwing together a patch for bodhi now.

luke



From orion at cora.nwra.com  Fri Oct  5 19:39:26 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 05 Oct 2007 13:39:26 -0600
Subject: sqlite over NFS (locking)
Message-ID: <470692EE.2020703@cora.nwra.com>

I just recently got bitten by issues accessing sqlite databases over NFS 
(trying to run pungi on Fedora devel and putting the output on our F7 
fileserver).  Now, http://www.sqlite.org/faq.html#q5 explicitly states 
that one should avoid this:

But use caution: this locking mechanism might not work correctly if the 
database file is kept on an NFS filesystem. This is because fcntl() file 
locking is broken on many NFS implementations. You should avoid putting 
SQLite database files on NFS if multiple processes might try to access 
the file at the same time.


Now, is NFS fctl() locking really broken going from Fedora devel to 
Fedora 7?  rpc.statd is running.  Filesystem is exported "sync".

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From tmz at pobox.com  Fri Oct  5 19:40:09 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Oct 2007 15:40:09 -0400
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
In-Reply-To: <604aa7910710051226t6d37daadt43befa5d605a5c06@mail.gmail.com>
References: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
	<1191596402.16124.13.camel@localhost.localdomain>
	<604aa7910710051226t6d37daadt43befa5d605a5c06@mail.gmail.com>
Message-ID: <20071005194009.GL10067@psilocybe.teonanacatl.org>

Jeff Spaleta wrote:
> On 10/5/07, Jeremy Katz <katzj at redhat.com> wrote:
>> It's a bug in gnome-python2-extras.  It should have the gdl
>> subpackage ifarch'd and not be trying to use an ExcludeArch
> 
> 
> Is this filed or better yet resolved yet?

The latter, I believe:

    http://koji.fedoraproject.org/koji/buildinfo?buildID=20281

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A great many people think they are thinking when they are merely
rearranging their prejudices.
    -- William James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/29f3831e/attachment.sig>

From katzj at redhat.com  Fri Oct  5 19:45:05 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 05 Oct 2007 15:45:05 -0400
Subject: Fwd: Broken dependencies: sonata | gnome-python2-libegg
In-Reply-To: <604aa7910710051226t6d37daadt43befa5d605a5c06@mail.gmail.com>
References: <668bb39a0710050722w50a1a6aejed67c4faafb91eee@mail.gmail.com>
	<1191596402.16124.13.camel@localhost.localdomain>
	<604aa7910710051226t6d37daadt43befa5d605a5c06@mail.gmail.com>
Message-ID: <1191613505.16124.29.camel@localhost.localdomain>

On Fri, 2007-10-05 at 11:26 -0800, Jeff Spaleta wrote:
> On 10/5/07, Jeremy Katz <katzj at redhat.com> wrote:
> > It's a bug in gnome-python2-extras.  It should have the gdl subpackage
> > ifarch'd and not be trying to use an ExcludeArch
> 
> Is this filed or better yet resolved yet?

mbarnes fixed it right after lunch

Jeremy



From tmz at pobox.com  Fri Oct  5 19:51:56 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 5 Oct 2007 15:51:56 -0400
Subject: bodhi update problem
In-Reply-To: <20071005193444.GB3424@crow.myhome.westell.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
Message-ID: <20071005195156.GO10067@psilocybe.teonanacatl.org>

Luke Macken wrote:
> Right now bodhi only looks at the individuals with commit access
> from the pkgdb.  It should definitely also check the ACL, and in the
> case of vorbis-tools, allow you to push updates for it.
> 
> Toshio is throwing together a patch for bodhi now.

Thanks for the quick reply Luke (and Toshio for the patch).  Will this
make it to the production bodhi pretty soon or will it wait for the
next upgrade opportunity?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Philosophy:  A route of many roads leading from nowhere to nothing.
    -- Ambrose Bierce

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

From davej at redhat.com  Fri Oct  5 20:02:21 2007
From: davej at redhat.com (Dave Jones)
Date: Fri, 5 Oct 2007 16:02:21 -0400
Subject: readahead_early.
Message-ID: <20071005200221.GA28441@redhat.com>

Right now we're running readahead early way too late.
At a time when we've just sat doing no IO at all for 10
seconds whilst (amongst other things) we waited for a
DHCP lease.   We're also running it at a time when
we're competing for disk bandwidth with other processes.
The result is that disabling the service completely shows
no change in boot time at all.
http://www.codemonkey.org.uk/junk/bootchart-before.png

Moving the readahead_early service to start really early
wins back 4 seconds of boot up time.
http://www.codemonkey.org.uk/junk/bootchart-after.png

Any reason not to change this for F8 ?

Note in the 'after' png that there's now a segment
of no IO occuring between 31s and 33s. Maybe moving
the later readahead service slightly earlier will provide
additional wins.

	Dave

-- 
http://www.codemonkey.org.uk



From davej at redhat.com  Fri Oct  5 20:15:56 2007
From: davej at redhat.com (Dave Jones)
Date: Fri, 5 Oct 2007 16:15:56 -0400
Subject: FYI: kernel 218 breaks iwl3945 and 4965
In-Reply-To: <47059953.1030703@redhat.com>
References: <47059953.1030703@redhat.com>
Message-ID: <20071005201556.GA13216@redhat.com>

On Thu, Oct 04, 2007 at 09:54:27PM -0400, Warren Togami wrote:
 > http://koji.fedoraproject.org/packages/kernel/2.6.23/
 > Please help to test kernels before they hit the nightly build.

Alternatively, this..

$ sudo bash
$ cd /etc/yum.repos.d
$ wget http://people.redhat.com/davej/kernels/Fedora/f7.92/kernel.repo

That repo gets the latest builds within an hour of them hitting koji.

	Dave

-- 
http://www.codemonkey.org.uk



From a.badger at gmail.com  Fri Oct  5 20:49:05 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Oct 2007 13:49:05 -0700
Subject: bodhi update problem
In-Reply-To: <20071005193444.GB3424@crow.myhome.westell.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
Message-ID: <4706A341.8040408@gmail.com>

Luke Macken wrote:
> On Fri, Oct 05, 2007 at 01:38:19PM -0400, Todd Zullinger wrote:
>> I built an updated vorbis-tools package to fix bz#244757[1] but bodhi
>> won't let me push the update for F7.  When I select Add Update, I get
>> an error that states:
>>
>>     tmz does not have commit access to vorbis-tools
>>
>> This is partly true.  Though the package is open to cvsextras, which
>> is how I had acccess to commit the changes.  What's the best way to
>> solve this?  Do I need to nag one of the primary maintainers of
>> vorbis-tools to do the actual push in bodhi (or request more
>> privileges from the pkgdb)?
>>
>> Would it be reasonable to allow members of cvsextras to push an update
>> to -testing if the package is open to cvs commits from cvsextras?
>> That'd facilitate someone coming along and helping fix low-hanging
>> fruit bugs like this -- freeing up the maintainers to work on the
>> harder and more pressing bugs.
>>
>> Pushing to -testing would provide some warning to the primary
>> maintainers if someone were to try and push an update they thought
>> shouldn't be pushed.  Then they could unpush it to prevent it from
>> getting into the stable updates.
>>
>> (I'm not sure what the best balance is here, I can see reasons for
>> allowing or for denying such access in bodhi.)
> 
> Right now bodhi only looks at the individuals with commit access from
> the pkgdb.  It should definitely also check the ACL, and in the case
> of vorbis-tools, allow you to push updates for it.
> 
> Toshio is throwing together a patch for bodhi now.
> 

Here's a patch for considering group-acls as part of authentication check.

There are several people working on a proposal for unsponsored 
comaintainers.  When that happens, the behavior of groups may change 
slightly but I'll announce the changes when we have a more concrete plan.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: group-acls.patch
Type: text/x-patch
Size: 4716 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/347a3c2b/attachment.bin>

From kevin.kofler at chello.at  Fri Oct  5 21:36:45 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 5 Oct 2007 21:36:45 +0000 (UTC)
Subject: cvs access problem
References: <1191593996.4199.24.camel@T7.Linux>
	<1191594442.16124.11.camel@localhost.localdomain>
	<1191609717.5560.50.camel@home.alexander.bostrom.net>
Message-ID: <loom.20071005T213554-517@post.gmane.org>

Alexander Bostr?m <abo <at> kth.se> writes:
> > CVSROOT=:ext:user <at> cvs.fedoraproject.org:/cvs/pkgs
> 
> Do people actually use that variable? It just seems so impractical.
> 
> I never use it, I always use cvs -d instead, since I actually have more
> than one CVS repository that I care about.

I use Cervisia for all my CVS accesses.

        Kevin Kofler



From a.badger at gmail.com  Fri Oct  5 21:57:21 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 05 Oct 2007 14:57:21 -0700
Subject: Unsponsored Comaintainers
Message-ID: <4706B341.4060905@gmail.com>

Rahul and Jef Spaleta asked me about this recently so I decided to throw 
this out as a conversation starter.  Please comment on this as Luke and 
I need some input from releng or FESCo about whether this is a goal we 
should be aiming for before we can implement it.

= Unsponsored Comaintainers =

Sometimes a contributor wants to get involved with a single Fedora 
package.  This is often the case with upstream maintainers who are 
interested in seeing their software run well on Fedora but either lack 
the time to participate in or are disinterested in Fedora as a whole.

One way to enable this is to have current Fedora Packagers "mentor" the 
upstream maintainers.  The Fedora Packager can be the owner of record 
for the package and make sure that it integrates with the rest of 
Fedora.  The upstream maintainer would take the role of comaintainer for 
the package and help mainly with code-related bugs.

For this sort of work, it would be ideal if the comaintainer could 
commit to the package but not build or push.  The package owner would 
then have the ability to check the changes that the upstream maintainer 
made to verify they followed the Fedora Packaging Guidelines and 
integrated with things going on in the rest of the distro.

At the moment we are constrained by the limitations of the tools we're 
working with (koji, packagedb, cvs repository, and bodhi).  So here's a 
three phase approach to getting to the ideal:

== Phase 1 ==

Upstream maintainer and Fedora Package owner decide to collaborate.  The 
Upstream maintainer signs the CLA.  Someone from a group of sponsors 
willing to work on this as a pilot program sponsors them into cvsextras.

The comaintainer can now request commit acls on the package.  This gives 
them access to commit to cvs, build in koji, and push via bodhi for this 
package.  There is an understanding among the participants that the 
upstream maintainer should not work on packages for which they have not 
been granted commit access.  The sponsor has to watch the commits list 
for changes made by the upstream maintainer that violate this policy.

This requires no changes to our tools but requires:
1) a pool of sponsors willing to work on this
2) commitment from unsponsored comaintainers to follow the rules and 
sponsors who are willing to police those comaintainers to make sure 
they're abiding by them.

== Phase 2 ==

In phase 2, we can remove the pool of sponsors.  Instead we allow people 
without cvsextras to sign up to comaintain a package.  If the primary 
package maintainer approves, the comaintainer is allowed to use any of 
the acls they are approved for.  The package owner would still have to 
watch to make sure the comaintainer is not doing more than they are 
supposed to on that particular package.

This requires changes to the cvs repository so people not in cvsextras 
but explicitly in the acl are allowed to commit.  This could be a bit 
tricky as we currently have two levels of security in the repository: 1) 
People must be in the acl to access resources of the repository, 2) they 
must be in cvsextras.  We'll want something equivalent in the new setup.

== Phase 3 ==

In this stage, we make sure that acls prevent people from doing things 
they are not supposed to, freeing the package owner from some of the 
manual policing they had to do before.  The PackageDB will have acls for 
pushing and building as well as committing.  This will allow package 
owners to specify that a maintainer should only be allowed to commit or 
only allowed to commit and build.

The packagedb will need to allow changing of build and push acls. [easy]
Bodhi will need to operate on the push acls instead of the commit acls. 
[easy]
koji will need to support restricting builds.

-Toshio



From Matt_Domsch at dell.com  Fri Oct  5 22:03:05 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 5 Oct 2007 17:03:05 -0500
Subject: Distributing Fedora packages under GPLv2 3(b)
Message-ID: <20071005220305.GA11072@auslistsprd01.us.dell.com>

Fedora distributes code online under GNU GPLv2 paragraph 3a (source
posted alongside and concurrent with binaries).  Fedora also
distributes binaries on CD and DVD (such as at trade shows) without
necessarily handing out CDs and DVDs with the source code.  For these
instances I'd like to see a written source code offer per GPLv2 paragraph
3b.

For Spins and derivatives, it would be nice for us to provide code
under GPLv2 3b.  This frees non-commercial Spins and derivatives from
having to publish the (unchanged) source code on their own site or
media - they can distribute under GPLv2 paragraph 3c and point at our
3b offer.  This lowers the barrier to entry for Spins and derivatives.

Under 3a, we can remove the source and binaries at any time from the
download servers, because they were posted concurrently.  We
regularly remove outdated packages from updates/.  However, if a Spin
or derivative used a package from updates/, now they are on the hook
to provide source (or a written offer for source, or a pass-through
written offer for source), and they can't (currently) count on those
packages to exist on Fedora's servers, so they can't use 3c (because
Fedora isn't using 3b).

I suggest using Fedora's Source Code Control System (currently CVS) as
the canonical location for all source code, and suggest we build a web
app that can generate versioned SRPMS on request based on CVS tags.
Jef Spaleta has built a proof-of-concept[1].  This would let us remove
SRPMS from the download servers at will, but upon request someone
could still regenerate and download them.


Here's some text I think could go into a README-SOURCE file inside the
fedora-release package, to land on CD/DVD media.  I haven't passed
this by a lawyer, and we'd want to do that.

Thoughts?

Thanks,
Matt

[1] http://fedoraproject.org/wiki/Infrastructure/RFR/SRPMSFromVersionControl

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux


Proposed Text of README-SOURCE:

Fedora is a Linux-based operating system that showcases the latest in
free and open source software. Fedora is always free for anyone to
use, modify, and distribute.

In accordance with the copyright licenses under which all Fedora
software is licensed, you may obtain a complete machine-readable copy
of the source code for each program.  This offer is valid for at least
three years from the date the software is released, and is applicable
to anyone.  There may be a nominal fee charged to you for the physical
act of transferring a copy.

You may obtain source code in several ways:

* The canonical method is by downloading the source code via the
  Internet from Fedora's Source Control System.  See
  http://fedoraproject.org for instructions.

* The Source RPM package for each Binary RPM package is distributed
  concurrently on the Fedora download servers.  See
  http://fedoraproject.org for a list of download servers.

* Several organizations produce physical media containing the Fedora
  distribution and source code.  A list of such organizations can be
  found at http://fedoraproject.org.

* Should all of the above methods be unavailable to you, you may write
  to source-offer at fedoraproject.org and request the source for any
  package.



From nicolas.mailhot at laposte.net  Fri Oct  5 22:10:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 06 Oct 2007 00:10:07 +0200
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071005220305.GA11072@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
Message-ID: <4706B63F.2090702@laposte.net>

Matt Domsch a ?crit :

> I suggest using Fedora's Source Code Control System (currently CVS) as
> the canonical location for all source code, and suggest we build a web
> app that can generate versioned SRPMS on request based on CVS tags.

IMHO if we go that way we should just never purge koji srpms during 3 
years. Koji is already hugely useful as an archive of fedora builds.

-- 
Nicolas Mailhot



From sundaram at fedoraproject.org  Fri Oct  5 22:13:11 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 06 Oct 2007 03:43:11 +0530
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071005220305.GA11072@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
Message-ID: <4706B6F7.3040306@fedoraproject.org>

Matt Domsch wrote:
> Fedora distributes code online under GNU GPLv2 paragraph 3a (source
> posted alongside and concurrent with binaries).  Fedora also
> distributes binaries on CD and DVD (such as at trade shows) without
> necessarily handing out CDs and DVDs with the source code.  For these
> instances I'd like to see a written source code offer per GPLv2 paragraph
> 3b.
> 
> For Spins and derivatives, it would be nice for us to provide code
> under GPLv2 3b.  This frees non-commercial Spins and derivatives from
> having to publish the (unchanged) source code on their own site or
> media - they can distribute under GPLv2 paragraph 3c and point at our
> 3b offer.  This lowers the barrier to entry for Spins and derivatives.

This would also help respins that fold in updates to point to us for the 
source? Are we willing to let derivatives use Fedora infrastructure for 
their packages (temporary folks and such) assuming that they are under 
Free software licenses. There is already one example of this: OLPC but I 
was wondering if that was more of an exception rather than the norm.

> Here's some text I think could go into a README-SOURCE file inside the
> fedora-release package, to land on CD/DVD media.  I haven't passed
> this by a lawyer, and we'd want to do that.
> 
> Thoughts?

Has anyone talked to FSF and got their input on how best to handle the 
requirements on source redistribution as well as specific 
interpretations on the terms if required?

Rahul



From jspaleta at gmail.com  Fri Oct  5 22:14:01 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Oct 2007 14:14:01 -0800
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <4706B63F.2090702@laposte.net>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
Message-ID: <604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>

On 10/5/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> IMHO if we go that way we should just never purge koji srpms during 3
> years. Koji is already hugely useful as an archive of fedora builds.

If we can commit to not purging koji srpms, that makes things very
easy moving forward. But I'm not sure we can commit to that.  My toy
script assumes we can't commit to that and we have to regenerate from
cvs and cvs look-aside cache of the source.

-jef



From mike at miketc.com  Fri Oct  5 22:45:10 2007
From: mike at miketc.com (Mike Chambers)
Date: Fri, 05 Oct 2007 17:45:10 -0500
Subject: F8t3 k3b and sound problems
In-Reply-To: <fe59ql$ahr$1@sea.gmane.org>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
	<1191580187.12607.4.camel@scrappy.miketc.com>
	<fe59ql$ahr$1@sea.gmane.org>
Message-ID: <1191624310.14309.0.camel@scrappy.miketc.com>

On Fri, 2007-10-05 at 07:14 -0500, Rex Dieter wrote:
> Mike Chambers wrote:
> 
> 
> > Ok, after running this program from root, it works and detects/uses the
> > cdroms.  But from a normal user it doesn't.  Permissions or something
> > need to be changed I guess to allow normal user to run it and detect/use
> > the cdroms?
> 
> What DE are you running?  kde?  gnome?  other?

Gnome

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From gilboad at gmail.com  Fri Oct  5 23:23:16 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 06 Oct 2007 01:23:16 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710012141.58217.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
Message-ID: <1191626596.27655.9.camel@gilboa-home-dev.localdomain>

Hello Ville,

On Mon, 2007-10-01 at 21:41 +0300, Ville Skytt? wrote:
> Hello,
> 
> I went through current devel packages that use htmlview or have unnecessarily 
> hardwired dependencies to firefox or evince.  Most of these should be using 
> xdg-open from xdg-utils instead.  Not hardcoding firefox as the browser and 
> evince as the PDF viewer should be trivial to understand, but why use 
> xdg-open instead of htmlview?  xdg-utils/xdg-open compared to htmlview:
> 
> - Works better in non-GNOME setups
> - Is a more standard implementation (more likely to be adopted upstream)
> - Understands the $BROWSER environment variable
> - Has slightly smaller dependency chain
> 
> So far, the only drawback of xdg-open compared to htmlview I've found is that 
> there doesn't seem to be real support for just opening a browser without an 
> URL to show in it.  "xdg-open about:blank" is one hacky workaround for this, 
> but I don't know how portable it is accross browsers (works at least in 
> Firefox and friends, and Konqueror).

This is a major issue for me (At least in icewm... less in gmrun) as the
browser button needs to open an empty browser window.
As you said, about:blank is not portable and pointing the browser to a
default web-page (say fedoraproject.org) will generate useless traffic.

Is there any chance that cleaner solution to this problem will be
implemented before we dump htmlview?

- Gilboa



From Matt_Domsch at dell.com  Sat Oct  6 01:06:52 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 5 Oct 2007 20:06:52 -0500
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
Message-ID: <20071006010652.GA22550@auslistsprd01.us.dell.com>

On Fri, Oct 05, 2007 at 02:14:01PM -0800, Jeff Spaleta wrote:
> On 10/5/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> > IMHO if we go that way we should just never purge koji srpms during 3
> > years. Koji is already hugely useful as an archive of fedora builds.
> 
> If we can commit to not purging koji srpms, that makes things very
> easy moving forward. But I'm not sure we can commit to that.  My toy
> script assumes we can't commit to that and we have to regenerate from
> cvs and cvs look-aside cache of the source.

I'd believe we can commit to keeping 4+ years of source code in a SCCM
before we could commit to keeping 4+ years of package builds online in
koji.  (GPLv2 is somewhat unclear if the 3 years is from the first
distribution, or the last...)  The koji archive with lots of
incremental builds would be many times the size of the SCCM storage
needs.

Fair enough to look in a koji repo first for a SRPM, then fall back to
building one from the SCCM.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From jima at beer.tclug.org  Sat Oct  6 01:38:57 2007
From: jima at beer.tclug.org (Jima)
Date: Fri, 5 Oct 2007 20:38:57 -0500 (CDT)
Subject: Unsponsored Comaintainers
In-Reply-To: <4706B341.4060905@gmail.com>
References: <4706B341.4060905@gmail.com>
Message-ID: <Pine.LNX.4.64.0710052035330.4486@beer.tclug.org>

On Fri, 5 Oct 2007, Toshio Kuratomi wrote:
> For this sort of work, it would be ideal if the comaintainer could commit to 
> the package but not build or push.

  I've mentioned this before during conversations on the subject, but I 
think it would be good if the upstream comaintainer could kick off scratch 
builds.
  Yeah, I know -- that makes things *way* easier for the Koji folks.  ;-) 
However, I suspect it wouldn't be a huge amount of extra overhead between 
restricting builds and restricting non-scratch builds.  Anyone with more 
intimate knowledge want to confirm or deny?
  Thanks for taking the initiative on this.

      Jima



From jkeating at redhat.com  Sat Oct  6 02:14:29 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 5 Oct 2007 22:14:29 -0400
Subject: sqlite over NFS (locking)
In-Reply-To: <470692EE.2020703@cora.nwra.com>
References: <470692EE.2020703@cora.nwra.com>
Message-ID: <20071005221429.07624592@redhat.com>

On Fri, 05 Oct 2007 13:39:26 -0600
Orion Poplawski <orion at cora.nwra.com> wrote:

> I just recently got bitten by issues accessing sqlite databases over
> NFS (trying to run pungi on Fedora devel and putting the output on
> our F7 fileserver).  Now, http://www.sqlite.org/faq.html#q5
> explicitly states that one should avoid this:
> 
> But use caution: this locking mechanism might not work correctly if
> the database file is kept on an NFS filesystem. This is because
> fcntl() file locking is broken on many NFS implementations. You
> should avoid putting SQLite database files on NFS if multiple
> processes might try to access the file at the same time.
> 
> 
> Now, is NFS fctl() locking really broken going from Fedora devel to 
> Fedora 7?  rpc.statd is running.  Filesystem is exported "sync".

I don't have an answer to this question, but I can surely agree that
trying to compose to a NFS dir did not work for me.  I discussed this
at length with Seth Vidal and others when I tried (shortly after -d
support became available in createrepo) and I think the general
consensus there was that createrepo should just avoid these situations
and instead use a local file system working dir to create the database
and then copy up the database to the destination directory when
finished.

However I never pursued this and failed to file any RFE bugs about it.
Now would probably be a good time for somebody to do that...  (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/af874650/attachment.sig>

From jkeating at redhat.com  Sat Oct  6 02:19:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 5 Oct 2007 22:19:11 -0400
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071006010652.GA22550@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
Message-ID: <20071005221911.4e7c1605@redhat.com>

On Fri, 5 Oct 2007 20:06:52 -0500
Matt Domsch <Matt_Domsch at dell.com> wrote:

> (GPLv2 is somewhat unclear if the 3 years is from the first
> distribution, or the last...)  The koji archive with lots of
> incremental builds would be many times the size of the SCCM storage
> needs.

This is what has made me reluctant to venture toward using 3b.  The
uncertainty of when that 3 years starts, added to that the people
making use of 3c, do we the 3b folks have to keep things around for 3
years after a 3c person makes a release?  Does the 3year clock start at
the first distribution of an update or does it start with each respin
that includes the update but still hosted by Fedora?

I'd like some serious clarification on these items, and I fear that the
FSF isn't going to be all that helpful in continuing the use of GPLv2.
What does v3 have to say on the matter?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071005/698da665/attachment.sig>

From tibbs at math.uh.edu  Sat Oct  6 03:00:59 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Oct 2007 22:00:59 -0500
Subject: sqlite over NFS (locking)
In-Reply-To: <20071005221429.07624592@redhat.com>
References: <470692EE.2020703@cora.nwra.com>
	<20071005221429.07624592@redhat.com>
Message-ID: <ufatzp5kkus.fsf@epithumia.math.uh.edu>

>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:

JK> I don't have an answer to this question, but I can surely agree
JK> that trying to compose to a NFS dir did not work for me.

It's failed for me as well.  What failure mode did you see?  For me
the creatrepo run simply failed to terminate; I just dropped '-d' and
went on with my business but I guess I could experiment.

What confuses me is that the problem should only show up as improper
locking for multiple accessors, but the only process anywhere which
should be accessing the database is createrepo.  It's not threaded, is
it?

 - J<



From bernie at codewiz.org  Sat Oct  6 03:02:00 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Fri, 05 Oct 2007 23:02:00 -0400
Subject: LANG=am_ET causes funny collating order
Message-ID: <4706FAA8.8030003@codewiz.org>

Hello Ulrich and Jakub,

sorry for bothering you for what seems to be an OLPC specific bug,
but I guess you can help me understand the issue here.

If I set LANG=am_ET, strcoll() acts as if strlen() was a sorting
criteria!

For example, ls outputs file names sorted by their lengths first,
and alphabetically when the length is the same.

As silly as it may seem, this only happens on the OLPC, not on a
regular PC with F7.  Nevertheless, our builds use the unaltered F7
version of glibc.  I also tried the latest F8 glibc package,
observing no change in behavior.  Running /bin/ls under strace and
ltrace does not reveal anything suspicious.

Any idea?

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/



From Matt_Domsch at dell.com  Sat Oct  6 03:02:06 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 5 Oct 2007 22:02:06 -0500
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071005221911.4e7c1605@redhat.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
Message-ID: <20071006030206.GA27282@auslistsprd01.us.dell.com>

On Fri, Oct 05, 2007 at 10:19:11PM -0400, Jesse Keating wrote:
> On Fri, 5 Oct 2007 20:06:52 -0500
> Matt Domsch <Matt_Domsch at dell.com> wrote:
> 
> > (GPLv2 is somewhat unclear if the 3 years is from the first
> > distribution, or the last...)  The koji archive with lots of
> > incremental builds would be many times the size of the SCCM storage
> > needs.
> 
> This is what has made me reluctant to venture toward using 3b.  The
> uncertainty of when that 3 years starts, added to that the people
> making use of 3c, do we the 3b folks have to keep things around for 3
> years after a 3c person makes a release?  Does the 3year clock start at
> the first distribution of an update or does it start with each respin
> that includes the update but still hosted by Fedora?
> 
> I'd like some serious clarification on these items, and I fear that the
> FSF isn't going to be all that helpful in continuing the use of GPLv2.
> What does v3 have to say on the matter?

GPLv3 says:

--- snip ---

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of
sections 4 and 5, provided that you also convey the machine-readable
Corresponding Source under the terms of this License, in one of these
ways:

    * a) Convey the object code in, or embodied in, a physical product
      (including a physical distribution medium), accompanied by the
      Corresponding Source fixed on a durable physical medium
      customarily used for software interchange.
    * b) Convey the object code in, or embodied in, a physical product
      (including a physical distribution medium), accompanied by a
      written offer, valid for at least three years and valid for as
      long as you offer spare parts or customer support for that
      product model, to give anyone who possesses the object code
      either (1) a copy of the Corresponding Source for all the
      software in the product that is covered by this License, on a
      durable physical medium customarily used for software
      interchange, for a price no more than your reasonable cost of
      physically performing this conveying of source, or (2) access to
      copy the Corresponding Source from a network server at no
      charge.
    * c) Convey individual copies of the object code with a copy of
      the written offer to provide the Corresponding Source. This
      alternative is allowed only occasionally and noncommercially,
      and only if you received the object code with such an offer, in
      accord with subsection 6b.
    * d) Convey the object code by offering access from a designated
      place (gratis or for a charge), and offer equivalent access to
      the Corresponding Source in the same way through the same place
      at no further charge. You need not require recipients to copy
      the Corresponding Source along with the object code. If the
      place to copy the object code is a network server, the
      Corresponding Source may be on a different server (operated by
      you or a third party) that supports equivalent copying
      facilities, provided you maintain clear directions next to the
      object code saying where to find the Corresponding
      Source. Regardless of what server hosts the Corresponding
      Source, you remain obligated to ensure that it is available for
      as long as needed to satisfy these requirements.
    * e) Convey the object code using peer-to-peer transmission,
      provided you inform other peers where the object code and
      Corresponding Source of the work are being offered to the
      general public at no charge under subsection 6d.

(snip anti-Tivoization and format stuff that follows)

--- snip ---

In the past with GPLv2, the FSF stance has been that you must make
sources available in a similar manner to how you make the binaries
available.  e.g. if you only posted binaries on the net and never on a
CD, you could post source only on the net.  But as soon as you
produced a CD to hand someone, you would also be obligated to provide
them source on CD upon request.  With v3, you can put binaries on CD,
and put source on the net, and be fine.

The "three years" part isn't really clarified in v3 either.  A
pessimistic read would be "three years from the last distribution",
which would be forever if you don't know when the last distribution
was.  I can't believe this is what they intend, but IANAL, and
definitely IANAFSFL.

http://gpl-violations.org/faq/sourcecode-faq.html
uses the words "last distributed"...

  Please note that if you chose GPL Option 3b (rather than 3a), then
  the obligation only lasts for three years. This means that you do
  not have to provide source code for any executable code that was
  last distributed more than three years ago.


When this was brought up on debian-legal in 2002:
http://lists.debian.org/debian-legal/2002/09/msg00098.html
David Turner, self-proclaimed Free Software License Guru with a
gnu.org address, responded
http://lists.debian.org/debian-legal/2002/09/msg00102.html
in essence last distribution by the originator; if downstream parties
rely on 3c for their redistribution, parties downstream of *them* may
be out of luck of enough time has passed.



At least with CVS or our SCM of choice, 4+ years storage is
significantly less than 4+ years of koji builds.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From Matt_Domsch at dell.com  Sat Oct  6 03:26:19 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 5 Oct 2007 22:26:19 -0500
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071006030206.GA27282@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
	<20071006030206.GA27282@auslistsprd01.us.dell.com>
Message-ID: <20071006032619.GC27282@auslistsprd01.us.dell.com>

On Fri, Oct 05, 2007 at 10:02:06PM -0500, Matt Domsch wrote:
> On Fri, Oct 05, 2007 at 10:19:11PM -0400, Jesse Keating wrote:
> > On Fri, 5 Oct 2007 20:06:52 -0500
> > Matt Domsch <Matt_Domsch at dell.com> wrote:
> > 
> > > (GPLv2 is somewhat unclear if the 3 years is from the first
> > > distribution, or the last...)  The koji archive with lots of
> > > incremental builds would be many times the size of the SCCM storage
> > > needs.
> > 
> > This is what has made me reluctant to venture toward using 3b.  The
> > uncertainty of when that 3 years starts, added to that the people
> > making use of 3c, do we the 3b folks have to keep things around for 3
> > years after a 3c person makes a release?  Does the 3year clock start at
> > the first distribution of an update or does it start with each respin
> > that includes the update but still hosted by Fedora?
> > 
> > I'd like some serious clarification on these items

BTW, we've had this discussion before...
http://www.redhat.com/archives/fedora-advisory-board/2007-March/msg00219.html

I've forwarded this thread and the above linked thread to
brett at fsf.org for comment.  My gut feeling is that using GPLv2 3b
means we need nearly infinite storage somewhere, which last time I
checked we don't have...

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From mattdm at mattdm.org  Sat Oct  6 04:12:52 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 6 Oct 2007 00:12:52 -0400
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071006032619.GC27282@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
	<20071006030206.GA27282@auslistsprd01.us.dell.com>
	<20071006032619.GC27282@auslistsprd01.us.dell.com>
Message-ID: <20071006041252.GA23666@jadzia.bu.edu>

On Fri, Oct 05, 2007 at 10:26:19PM -0500, Matt Domsch wrote:
> I've forwarded this thread and the above linked thread to
> brett at fsf.org for comment.  My gut feeling is that using GPLv2 3b
> means we need nearly infinite storage somewhere, which last time I
> checked we don't have...

Wouldn't it be *lot* easier and cheaper to just make some source code CDs
for trade shows?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From drepper at redhat.com  Sat Oct  6 04:18:38 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 05 Oct 2007 21:18:38 -0700
Subject: LANG=am_ET causes funny collating order
In-Reply-To: <4706FAA8.8030003@codewiz.org>
References: <4706FAA8.8030003@codewiz.org>
Message-ID: <47070C9E.3070504@redhat.com>

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

Bernardo Innocenti wrote:
> I also tried the latest F8 glibc package,

Define "latest".  It should work in 2.6.90-17.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHBwye2ijCOnn/RHQRAtaYAJ4sTTj4h/CPD9vpxdMbVqHBhTzn4gCgoYhJ
aNekBq094JSCVP2LpceF8Aw=
=oxhz
-----END PGP SIGNATURE-----



From loupgaroublond at gmail.com  Sat Oct  6 04:30:17 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Sat, 6 Oct 2007 00:30:17 -0400
Subject: +1/-1 voting
In-Reply-To: <46FB9F88.7060001@brentnorris.net>
References: <46F33D05.4020701@ncsu.edu>
	<31334.192.54.193.51.1190368128.squirrel@rousalka.dyndns.org>
	<20070921100859.GA6032@devserv.devel.redhat.com>
	<1190380783.2142.52.camel@cutter>
	<20070921093924.123e483b@localhost.localdomain>
	<1190382715.2142.56.camel@cutter>
	<20070921095601.035cc74d@localhost.localdomain>
	<20070921102620.5bb9ff5a.dcantrell@redhat.com>
	<1190864316.3259.47.camel@ignacio.lan>
	<46FB9F88.7060001@brentnorris.net>
Message-ID: <7f692fec0710052130l57265e7dke3e1fb892b860d1@mail.gmail.com>

On 9/27/07, Brent Norris <brent at brentnorris.net> wrote:
> Ignacio Vazquez-Abrams wrote:
> > On Fri, 2007-09-21 at 10:26 -0400, David Cantrell wrote:
> >> Where did the +1 and -1 trend come from because it's really freaking annoying.
> >
> > The earliest I've heard of it happening is on various Apache mailing
> > lists, to indicate acceptance or rejection of a change.
> >
> >
> I always thought it was a take off of the Slashdot mod system, but I
> guess that could have come from anywhere.

AFAIK it's from the python world.  They use {+1, +0, -0, -1} to
describe good feelings, bad feelings or just plain apatheticness.

-Yaakov



From lmacken at redhat.com  Sat Oct  6 07:03:53 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sat, 6 Oct 2007 03:03:53 -0400
Subject: bodhi update problem
In-Reply-To: <4706A341.8040408@gmail.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
Message-ID: <20071006070353.GA28933@crow.myhome.westell.com>

On Fri, Oct 05, 2007 at 01:49:05PM -0700, Toshio Kuratomi wrote:
> Luke Macken wrote:
>> On Fri, Oct 05, 2007 at 01:38:19PM -0400, Todd Zullinger wrote:
>>> I built an updated vorbis-tools package to fix bz#244757[1] but bodhi
>>> won't let me push the update for F7.  When I select Add Update, I get
>>> an error that states:
>>>
>>>     tmz does not have commit access to vorbis-tools
>>>
>>> This is partly true.  Though the package is open to cvsextras, which
>>> is how I had acccess to commit the changes.  What's the best way to
>>> solve this?  Do I need to nag one of the primary maintainers of
>>> vorbis-tools to do the actual push in bodhi (or request more
>>> privileges from the pkgdb)?
>>>
>>> Would it be reasonable to allow members of cvsextras to push an update
>>> to -testing if the package is open to cvs commits from cvsextras?
>>> That'd facilitate someone coming along and helping fix low-hanging
>>> fruit bugs like this -- freeing up the maintainers to work on the
>>> harder and more pressing bugs.
>>>
>>> Pushing to -testing would provide some warning to the primary
>>> maintainers if someone were to try and push an update they thought
>>> shouldn't be pushed.  Then they could unpush it to prevent it from
>>> getting into the stable updates.
>>>
>>> (I'm not sure what the best balance is here, I can see reasons for
>>> allowing or for denying such access in bodhi.)
>> Right now bodhi only looks at the individuals with commit access from
>> the pkgdb.  It should definitely also check the ACL, and in the case
>> of vorbis-tools, allow you to push updates for it.
>> Toshio is throwing together a patch for bodhi now.
>
> Here's a patch for considering group-acls as part of authentication check.

Applied, thanks!

luke



From bernie at codewiz.org  Sat Oct  6 07:30:59 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Sat, 06 Oct 2007 03:30:59 -0400
Subject: LANG=am_ET causes funny collating order
In-Reply-To: <47070C9E.3070504@redhat.com>
References: <4706FAA8.8030003@codewiz.org> <47070C9E.3070504@redhat.com>
Message-ID: <470739B3.9050102@codewiz.org>

Ulrich Drepper wrote:

> Define "latest".  It should work in 2.6.90-17.

Indeed, it does.  I was still using 2.6.90-16, from two days ago.

What was the fix?  I think we'll need to backport the patch to F7's
glibc for fork the package off in OLPC-2.

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/



From tmz at pobox.com  Sat Oct  6 07:31:57 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 6 Oct 2007 03:31:57 -0400
Subject: bodhi update problem
In-Reply-To: <20071006070353.GA28933@crow.myhome.westell.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
Message-ID: <20071006073157.GU10067@psilocybe.teonanacatl.org>

Luke Macken wrote:
>> Here's a patch for considering group-acls as part of authentication
>> check.
> 
> Applied, thanks!

This isn't applied to the production instance of bodhi, is it?  I
tried the vorbis-tools update again and still get the "does not have
commit access" error message.  I logged out of bodhi before I tried
this.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I always wanted to be a procrastinator, never got around to it.

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

From ville.skytta at iki.fi  Sat Oct  6 07:38:18 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sat, 6 Oct 2007 10:38:18 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <1191626596.27655.9.camel@gilboa-home-dev.localdomain>
References: <200710012141.58217.ville.skytta@iki.fi>
	<1191626596.27655.9.camel@gilboa-home-dev.localdomain>
Message-ID: <200710061038.18961.ville.skytta@iki.fi>

On Saturday 06 October 2007, Gilboa Davara wrote:
> On Mon, 2007-10-01 at 21:41 +0300, Ville Skytt? wrote:
>
> > So far, the only drawback of xdg-open compared to htmlview I've found is
> > that there doesn't seem to be real support for just opening a browser
> > without an URL to show in it.  "xdg-open about:blank" is one hacky
> > workaround for this, but I don't know how portable it is accross browsers
> > (works at least in Firefox and friends, and Konqueror).

By the way, there are two more features in htmlview that xdg-open lacks: error 
dialogs and the ability to open a tty browser in a GUI console.

> This is a major issue for me (At least in icewm... less in gmrun) as the
> browser button needs to open an empty browser window.
> As you said, about:blank is not portable and pointing the browser to a
> default web-page (say fedoraproject.org) will generate useless traffic.

For example /usr/share/doc/HTML/index.html could be used for that.  However, 
doing so has some problems too; eg. it disrespects the user configured home 
page for the browser, does not pick a localized version of that index.html, 
and fedora-release-notes could be conceivably not installed in some setups.

> Is there any chance that cleaner solution to this problem will be
> implemented before we dump htmlview?

I think in cases where xdg-open doesn't provide a satisfactory solution, we 
can stick with htmlview.  And htmlview could be internally changed to use 
xdg-open for cases where it is passed an argument which would make it honor 
non-GNOME desktop settings better too.



From abo at kth.se  Sat Oct  6 07:59:23 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 06 Oct 2007 09:59:23 +0200
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071005221911.4e7c1605@redhat.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
Message-ID: <1191657563.5560.72.camel@home.alexander.bostrom.net>

fre 2007-10-05 klockan 22:19 -0400 skrev Jesse Keating:
> do we the 3b folks have to keep things around for 3
> years after a 3c person makes a release? 

The 3c folks can only use the 3b archive if there's a written promise
about the 3b archive which the 3c folks can pass on. The promise can be
limited to a certain time period and it's the responsibility of the 3c
folks to make sure it's suitable for their needs.

Probably it's best to tell 3c folks that they should stop distributing
3+ years before the promise ends for anything that's within their spin,
and if they can't promise that, they should provide their own source
code archive.

That would be fine if they're making a spin to hand out in DVD form at
some event, which they then stop distributing. If they're making it
available on their FTP server, it's a shame that they have to delete it
after a while and that's something they might forget to do, os in that
case it would still be strongly recommended that they distribute the
source themselves.

But as Matthew Miller points out, building and maintaining this
CVStoSRPM web app might be more work than just telling people to hand
out two CD:s/DVD:s. It looks like the source ISO is slightly smaller
than the binary ISO in the F7 i386 vs. src case, but can you count on
that for every spin? Does the source for the Live CD fit on a CD? If
not, that is a limitation to the size of a spin.

/abo



From mschwendt.tmp0701.nospam at arcor.de  Sat Oct  6 09:16:26 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sat, 6 Oct 2007 11:16:26 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <200710052120.05292.alain.portal@free.fr>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<20071002100910.GD3535@free.fr>
	<200710052120.05292.alain.portal@free.fr>
Message-ID: <20071006111626.e927f0cc.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 5 Oct 2007 21:20:02 +0200, Alain PORTAL wrote:

> Le mardi 02 octobre 2007, Patrice Dumas a ?crit :
> > On Tue, Oct 02, 2007 at 11:29:47AM +0200, Alain PORTAL wrote:
> > > Hi,
> > >
> > > PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and
> > > automake-1.9 were not found:
> > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2
> > >.4-1.fc6/
> > >
> > > Can somebody help me to fix?
> >
> > There is more than one way to fix such issues,
> 
> I found one, I'll exclude ppc arch

Your package is broken, resp. the upstream tarball is broken. A
tarball user running the configure script should not need autotools
for building the software.

You don't "BuildRequires: automake" either:

http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops-0.2.4-1.fc6/ppc/root.log

Hence it isn't available in the buildroot. And that is not specific
to ppc.

Fedora Core 6 includes automake-1.9.6-2.1 which would suffice:

http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/
http://download.fedora.redhat.com/pub/fedora/linux/core/6/source/SRPMS/automake-1.9.6-2.1.src.rpm

> In order to know what is the automake version (finding a symlink as 
> automake-1.9) for ppc arch in FC-6, [...]
>
> Can somebody tell me what is the automake version on ppc arch for FC-6?

Huh? It's the same as for all other archs, of course.



From fedora at camperquake.de  Sat Oct  6 10:42:18 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 6 Oct 2007 12:42:18 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <1191626596.27655.9.camel@gilboa-home-dev.localdomain>
References: <200710012141.58217.ville.skytta@iki.fi>
	<1191626596.27655.9.camel@gilboa-home-dev.localdomain>
Message-ID: <20071006124218.297a6e02@lain.camperquake.de>

Hi.

On Sat, 06 Oct 2007 01:23:16 +0200, Gilboa Davara wrote

> This is a major issue for me (At least in icewm... less in gmrun) as
> the browser button needs to open an empty browser window.
> As you said, about:blank is not portable and pointing the browser to a
> default web-page (say fedoraproject.org) will generate useless
> traffic.

Which browser does not understand about:blank?



From pertusus at free.fr  Sat Oct  6 10:43:56 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Oct 2007 12:43:56 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <20071006124218.297a6e02@lain.camperquake.de>
References: <200710012141.58217.ville.skytta@iki.fi>
	<1191626596.27655.9.camel@gilboa-home-dev.localdomain>
	<20071006124218.297a6e02@lain.camperquake.de>
Message-ID: <20071006104356.GA22426@free.fr>

On Sat, Oct 06, 2007 at 12:42:18PM +0200, Ralf Ertzinger wrote:
> Hi.
> 
> On Sat, 06 Oct 2007 01:23:16 +0200, Gilboa Davara wrote
> 
> > This is a major issue for me (At least in icewm... less in gmrun) as
> > the browser button needs to open an empty browser window.
> > As you said, about:blank is not portable and pointing the browser to a
> > default web-page (say fedoraproject.org) will generate useless
> > traffic.
> 
> Which browser does not understand about:blank?

It doesn't work with mimeopen. Maybe what could be needed is a wrapper
around mimeopen such that uri are opened by another application and this
other application delegates file opening to mimeopen. Is there something
similar than mimeopen, but for uri?

--
Pat



From pertusus at free.fr  Sat Oct  6 11:03:20 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 6 Oct 2007 13:03:20 +0200
Subject: sqlite over NFS (locking)
In-Reply-To: <470692EE.2020703@cora.nwra.com>
References: <470692EE.2020703@cora.nwra.com>
Message-ID: <20071006110320.GB22426@free.fr>

On Fri, Oct 05, 2007 at 01:39:26PM -0600, Orion Poplawski wrote:
>
> But use caution: this locking mechanism might not work correctly if the 
> database file is kept on an NFS filesystem. This is because fcntl() file 
> locking is broken on many NFS implementations. You should avoid putting 
> SQLite database files on NFS if multiple processes might try to access the 
> file at the same time.
>
>
> Now, is NFS fctl() locking really broken going from Fedora devel to Fedora 
> 7?  rpc.statd is running.  Filesystem is exported "sync".

fcntl() shouldn't be brocken on fedora, it seems to me to be an nfs bug
if it is. (looking at the web, looks like it should work from about linux 
2.2.13). Now it is true that nfs locking is more fragile than local file
locking, especially lock recovery and all the stuff that happens through
statd/lockd. Also there may be some issues between lockf/fcntl, but
unless I am wrong, this is not an issue on, at least, recent fedora. In 
any case if fcntl is not working in a well setup system, it is a bug. You 
can also have a look at

http://nfs.sourceforge.net/#faq_d7
http://nfs.sourceforge.net/#faq_d10

--
Pat



From buildsys at redhat.com  Sat Oct  6 12:20:52 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 6 Oct 2007 08:20:52 -0400
Subject: rawhide report: 20071006 changes
Message-ID: <200710061220.l96CKq8l001321@porkchop.devel.redhat.com>

New package fedorainfinity-kdm-theme
	Fedora Infinity KDM theme

New package nafees-web-naskh-fonts
	Nafees Web font for writing Urdu in the Naskh script

New package python-sqlalchemy0.3
	Modular and flexible ORM library for python

New package qstars
	A screensaver simulating planets and asteroids in space

New package sirius
	Reversi game for Gnome


Removed package openalpp

Updated Packages:

TurboGears-1.0.3.2-4.fc8
------------------------
* Fri Oct 05 2007 Toshio Kuratomi <a.badger at gmail.com> 1.0.3.2-4
- Require sqlalchemy 0.3.

* Thu Sep 27 2007 Toshio Kuratomi <a.badger at gmail.com> 1.0.3.2-3
- Update setuptools patch to modify quickstart template for compat eggs as well.

abicheck-1.2-15
---------------
* Fri Oct 05 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 1.2-15
- Patch unbound_match.
- Update fortify-source patch.

aldrin-0.11-6.fc8
-----------------
* Fri Oct 05 2007 Alexander Kahl <akahl at iconmobile.com> - 0.11-6
- added ExludeArch for ppc64 to reflect libzzub unavailability on that arch

at-3.1.10-17.fc8
----------------
* Fri Oct 05 2007 Marcela Maslanova <mmaslano at redhat.com> - 3.1.10-17
- Bug 250147: add optional support for gnome-keyring to passwd pam stack

* Wed Aug 22 2007 Marcela Maslanova <mmaslano at redhat.com> - 3.1.10-16
- macro with_pam instead of have_pam
- license tag is gplv2+ because of license in source files

* Wed Jul 11 2007 Marcela Maslanova <mmaslano at redhat.com> - 3.1.10-15
- rewrite init script
- add own session - setsid
- Resolves: rhbz#247091

audit-1.6.2-3.fc8
-----------------
* Fri Oct 05 2007 Steve Grubb <sgrubb at redhat.com> 1.6.2-3
- Fix syscall name to number conversion in libaudit.

bigboard-0.5.22-1.fc8
---------------------
* Fri Oct 05 2007 Colin Walters <walters at redhat.com> - 0.5.22-1
- new upstream

bluez-libs-3.20-1.fc8
---------------------
* Fri Oct 05 2007 - Bastien Nocera <bnocera at redhat.com> - 3.20-1
- Update to 3.20

bluez-utils-3.20-1.fc8
----------------------
* Fri Oct 05 2007 - Bastien Nocera <bnocera at redhat.com> 3.20-1
- Update the init header so that chkconfig starts hcid after
  D-Bus has, patch from Will Woods <wwoods at redhat.com> (#279291)
- Update to bluez-utils 3.20
- Disable sync and transfer services and prune buildreqs

catfish-0.3-0.3.c.fc8
---------------------
* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-0.3.c
- Remove beagle dependency for now because beagle is not
  available on ppc64 (although catfish itself is noarch :( )

compiz-0.5.2-13.6b86f3.fc8
--------------------------
* Fri Oct 05 2007 Matthias Clasen <mclasen at redhat.com> - 0.5.2-13
- Also install gwd.schemas (#319621)

* Thu Sep 20 2007 Kristian H??gsberg <krh at redhat.com> - 0.5.2-12
- Update to more recent 0.6 branch snapshot (fixes #253575).

* Fri Sep 14 2007 Warren Togami <wtogami at redhat.com> - 0.5.2-11
- compiz-gnome: install core schema so it actually works
- remove unnecessary gconf stuff from %install

evolution-2.12.0-6.fc8
----------------------
* Fri Oct 05 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-6.fc8
- Require libbonobo >= 2.16.0 (RH bug #213823).

* Thu Oct 04 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-5.fc8
- Require gnome-themes (RH bug #235617).

* Wed Oct 03 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-4.fc8
- Revise patch for GNOME bug #477045 (run-time warnings when composing mail).

fwbuilder-2.1.14-1.fc8
----------------------
* Wed Oct 03 2007 Ralf Ertzinger <ralf at skytale.net> 2.1.14-1
- Update to 2.1.14
- Fix license tag

gcalctool-5.20.1-1.fc8
----------------------
* Fri Oct 05 2007 Matthias Clasen <mclasen at redhat.com> - 5.20.1-1
- 5.20.1 (fix XOR in non-arithmetic mode)

gnome-commander-1.2.4-4.fc8
---------------------------
* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.2.4-4
- Drop yelp dependency

gnome-keyring-2.20-4.fc8
------------------------
* Thu Oct 04 2007 Alexander Larsson <alexl at redhat.com> - 2.20-4
- Have the pam module tell the daemon to init the login keyring 
  without using the socket as selinux limits access to that

* Thu Oct 04 2007 Alexander Larsson <alexl at redhat.com> - 2.20-3
- Add NO_MATCH error patch from svn. Will fix apps that
  can't handle empty list matches

* Wed Oct 03 2007 Alexander Larsson <alexl at redhat.com> - 2.20-2
- Backport fix from svn where newly created keyrings weren't
  found
- Don't unset default keyring on daemon shutdown

gnome-power-manager-2.20.0-4.fc8
--------------------------------
* Fri Oct 05 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-4
- Rebuild

* Fri Oct 05 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-3
- Fix the "Sleep problem" popup (#312761)

* Fri Oct 05 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Make the inhibit applet work with all background settings 
  of the panel.

gnome-python2-extras-2.19.1-7.fc8
---------------------------------
* Fri Oct 05 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-7.fc8
- Use ifarch instead of ExcludeArch to skip building the gdl subpackage
  on ppc64.  ExcludeArch affects the whole spec.

gnome-screensaver-2.20.0-7.fc8
------------------------------
* Fri Oct 05 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-7
- fix up gamma handling, patch by John Bryant (should fix 290611)

* Fri Sep 28 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-6
- Use small bullets in the password entry

* Mon Sep 24 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-5
- Fix up GConf requires (#220547)

gutenprint-5.0.1-5.fc8
----------------------
* Fri Oct 05 2007 Tim Waugh <twaugh at redhat.com> 5.0.1-5
- Don't ship samples in the main package.

hunspell-da-1.7.16-1.fc8
------------------------
* Fri Oct 05 2007 Caolan McNamara <caolanm at redhat.com> - 1.7.16-1
- latest version

hunspell-pl-0.20071004-1.fc8
----------------------------
* Fri Oct 05 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071004-1
- new version

hunspell-pt-0.20071003-1.fc8
----------------------------
* Fri Oct 05 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071003-1
- next version

initscripts-8.58-1
------------------
* Fri Oct 05 2007 Bill Nottingham <notting at redhat.com> - 8.58-1
- revert kernel conflict so that xen can still work (#319401)
- rename_device, 60-net.rules: only suggest an interface name (part of #264901)
- require newer udev for persistent net rules (part of #264901)
- don't hang if someone puts a dangling pipe in /etc/rhgb/temp (#251219)
- genhostid: fix for 64-bit systems (#306811)
- more bash matching fixes (#220887)
- translation updates: is, nb

iscsi-initiator-utils-6.2.0.865-0.2.fc8
---------------------------------------
* Fri Oct 05 2007 Mike Christie <mchristie at redhat.com> - 6.2.0.865-0.2
- Rebase to upstream's bug fix release.
- Revert init script startup changes from 225915 which reviewers did
 not like.

* Wed Jun 20 2007 Mike Christie <mchristie at redhat.com> - 6.2.0.754-0.1
- 225915 From Adrian Reber - Fix up spec and init files for rpmlint.

* Tue Feb 06 2007 Mike Christie <mchristie at redhat.com> - 6.2.0.754-0.0
- Rebase to upstream.
- Add back --map functionality but in session mode to match RHEL5 fixes
- Break up iscsi init script into two, so iscsid can be started early for root

jd-1.9.6-1.fc8
--------------
* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-1
- 1.9.6

* Sun Sep 30 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-0.6.rc070930
- 1.9.6 rc 070930

* Tue Sep 18 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-0.5.beta070918
- 1.9.6 beta 070918

kde-settings-3.5-32.fc8
-----------------------
* Tue Oct 02 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5-32
- f8: Requires: fedorainfinity-kdm-theme (#314041)
      kdmrc: [X-*-Greeter] Theme=.../FedoraInfinity
      kdmrc: [X-*-Greeter] ColorScheme=FedoraInfinity

kdebase4-3.93.0-5.fc8
---------------------
* Thu Oct 04 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-5
- don't make this the default kdebase on F9 yet
- drop ExcludeArch: ppc64 (#300601)

kernel-2.6.23-0.220.rc9.git2.fc8
--------------------------------
* Fri Oct 05 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git2

* Fri Oct 05 2007 John W. Linville <linville at redhat.com>
- Back-out last round of wireless updates

* Wed Oct 03 2007 John W. Linville <linville at redhat.com>
- Update wireless bits from upstream

libpng10-1.0.29-1.fc8
---------------------
* Fri Oct 05 2007 Paul Howarth <paul at city-fan.org> 1.0.29-1
- update to 1.0.29

libselinux-2.0.37-1.fc8
-----------------------
* Fri Oct 05 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.37-1
- Upgrade to upstream
	* Merged selinux_get_callback, avc_open, empty string mapping from Eamon Walsh.

* Fri Sep 28 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.36-1
- Upgrade to upstream
	* Fix segfault resulting from missing file_contexts file.

libsemanage-2.0.12-1.fc8
------------------------
* Fri Oct 05 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.12-1
- Upgrade to latest from NSA
	* ustr cleanups from James Antill.
	* Ensure that /root gets labeled even if using the default context from Dan Walsh.

libsoup-2.2.101-1.fc8
---------------------
* Fri Oct 05 2007 Matthew Barnes <mbarnes at redhat.com> - 2.2.101-1
- Update to 2.2.101

* Wed Aug 08 2007 Matthias Clasen <mclasen at redhat.com> - 2.2.100-3
- Update the license field

* Sat Apr 21 2007 Matthias Clasen <mclasen at redhat.com> - 2.2.100-2
- Don't install INSTALL

make-1:3.81-10.fc8
------------------
* Thu Oct 04 2007 Petr Machata <pmachata at redhat.com> - 1:3.81-10
- Fix parallel builds with reexec.
- Related: #212111, #211290

mugshot-1.1.56-1.fc8
--------------------
* Fri Oct 05 2007 Colin Walters <walters at redhat.com> - 1.1.56-1
- new upstream

nautilus-image-converter-0.2.0-1.fc8
------------------------------------
* Fri Oct 05 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.2.0-1
- Update to 0.2.0, which only has translation changes.

online-desktop-0.2.19-1.fc8
---------------------------
* Fri Oct 05 2007 Colin Walters <walters at redhat.com> - 0.2.19-1
- new upstream

openarena-0.7.1-3.fc8
---------------------
* Fri Oct 05 2007 Micha?? Bentkowski <mr.ecik at gmail.com> - 0.7.1-3
- Add support for opengl-games-utils

openoffice.org-1:2.3.0-6.1.fc8
------------------------------
* Thu Oct 04 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.1
- Resolves: rhbz#299391 Serbian langpack name update
- Resolves: rhbz#286221 allow custom printing commands
- Resolves: rhbz#303431 some printing problems
- add openoffice.org-2.3.0.ooo81936.sc.maketypesagree.patch

* Mon Sep 17 2007 Jan Navratil <jnavrati at redhat.com> - 1:2.3.0-5.1
- release candidate

* Thu Sep 06 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-4.1
- next version
- ooo#77672 fix ::boost::spirit::parse to use ::boost::spirit::end_p to
  make drawing shapes work properly again with new boost 1.34
- add openoffice.org-2.3.0.ooo81321.cppu.silencewarnings.patch
- add openoffice.org-2.3.0.ooo81323.svtools.sixtyfour.patch
- disable custom launchers, it breaks icedtea for some reason I haven't time to
  figure out
- disable visibility for now, seems screwed up.

pirut-1.3.23-1.fc8
------------------
* Fri Oct 05 2007 Jeremy Katz <katzj at redhat.com> - 1.3.23-1
- Don't hang on an empty search (#317151)
- Pull proxy bits out of gconf when launching from desktop files (#259581)

policycoreutils-2.0.28-1.fc8
----------------------------
* Fri Oct 05 2007 Dan Walsh <dwalsh at redhat.com> 2.0.28-1
- Update to upstream
	* Update semodule man page for -D from Dan Walsh.
	* Add boolean, locallist, deleteall, and store support to semanage from Dan Walsh.

postgresql-pgpool-II-1.2.1-1.fc8
--------------------------------
* Fri Oct 05 2007 Devrim Gunduz <devrim at CommandPrompt.com> 1.2.1-1
- Update to 1.2.1

* Wed Aug 29 2007 Devrim Gunduz <devrim at CommandPrompt.com> 1.2-5
- Chmod sysconfig/pgpool to 644, not 755. Per BZ review.
- Run chkconfig --add pgpool during %post.

qgis-0.9.0-2.fc8
----------------
* Fri Oct 05 2007 Douglas E. Warner <silfreed at silfreed.net> 0.9.0-2
- enabling build for PPC64 (bug#247152)

rpy-1.0-0.2.RC3.fc8
-------------------
* Fri Oct 05 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.0-0.2.RC3
- Rebuild for R version 2.6.

sed-4.1.5-9.fc8
---------------
* Thu Oct 04 2007 Petr Machata <pmachata at redhat.com> - 4.1.5-9
- Fix licensing tag.
- Clean up per merge review comments.
- Resolves: #226404

* Wed Feb 07 2007 Petr Machata <pmachata at redhat.com> - 4.1.5-8
- tidy up the specfile per rpmlint comments
- use utf-8 and fix national characters in contributor's names

selinux-policy-3.0.8-18.fc8
---------------------------
* Thu Oct 04 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-18
- Remove homedir_template

specspo-15-1
------------
* Thu Oct 04 2007 Stepan Kasal <skasal at redhat.com> - 15-1
- Updated translations
- Fixed make_dist_pot, so that backslashes in the descriptions do not get
  mangled.
- Removed C.po, they do not contain any information; removed the code to handle
  them in the Makefile.
- Removed Makefile.rules, it is not used.
- specspo-make.patch: build *.mo only if both *.po are available.
- filter-out ku, lo, ro, sq, ur catalogues; they are malformed.

sylpheed-2.4.7-1
----------------
* Fri Oct 05 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.7-1
- Update to 2.4.7 (bug-fixes).
- Add more %doc files.

system-config-date-1.9.11-1.fc8
-------------------------------
* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.11
- don't remove notebook pages when acting as a firstboot module (#296711)
- pick up updated translations

taskjuggler-2.4.0-4.fc8
-----------------------
* Fri Oct 05 2007 Ondrej Vasik <ovasik at redhat.com> - 2.4.0-4
- fixed serious bug in floating point formatter(upstream)

tiquit-2.4-6.fc8
----------------
* Fri Oct 05 2007 Jon Ciesla <limb at jcomserv.net> - 2.4-6
- Fixed BADSOURCE.

vorbis-tools-1:1.1.1.svn20070412-4.fc8
--------------------------------------
* Thu Oct 04 2007 Todd Zullinger <tmz at pobox.com> - 1:1.1.1.svn20070412-4
- Upstream patch to fix oggdec writing silent wav files (#244757)

wallpapoz-0.4.1-2.fc8
---------------------
* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.1-2
- License update
- Drop yelp dependency

xfig-3.2.5-2.fc8
----------------
* Fri Oct 05 2007 Than Ngo <than at redhat.com> - 3.2.5-2
- rh#313321, use xdg-open

xmoto-edit-0.2.4-10.fc8
-----------------------
* Fri Oct 05 2007 Jon Ciesla <limb at jcomserv.net> 0.2.4-10
- Fixed BADSOURCE.

xorg-x11-server-1.3.0.0-29.fc8
------------------------------
* Fri Oct 05 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-29
- xserver-1.3.0-randr-preferred-mode-fix.patch: Fix infinite loop on X
  startup when a mode is requested in the config file. (#318731)
- Fix License tag.

yum-3.2.6-1.fc8
---------------
* Fri Oct 05 2007 Seth Vidal <skvidal at fedoraproject.org> 3.2.6-1
- 3.2.6 
- remove all old patches

* Tue Sep 25 2007 Jeremy Katz <katzj at redhat.com> - 3.2.5-4
- pull in fixes from upstream for media handling, pkgid (#291471), and 
  a potential depsolving bug

* Mon Sep 17 2007 Jeremy Katz <katzj at redhat.com> - 3.2.5-3
- fix traceback with closing repos

Broken deps for i386
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.202.rc8.fc8.i686 requires kernel-i686 = 0:2.6.23-0.202.rc8.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	rpy - 1.0-0.2.RC3.fc8.i386 requires R = 0:2.5.1



Broken deps for x86_64
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.202.rc8.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	rpy - 1.0-0.2.RC3.fc8.x86_64 requires R = 0:2.5.1



Broken deps for ppc
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc requires kernel-ppc = 0:2.6.23-0.202.rc8.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	rpy - 1.0-0.2.RC3.fc8.ppc requires R = 0:2.5.1



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.202.rc8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.202.rc8.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	rpy - 1.0-0.2.RC3.fc8.ppc64 requires R = 0:2.5.1
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From dcbw at redhat.com  Sat Oct  6 14:03:03 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sat, 06 Oct 2007 10:03:03 -0400
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191530534.4199.4.camel@T7.Linux>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
	<20071004190909.GD8375@redhat.com> <1191527009.4157.32.camel@T7.Linux>
	<20071004202924.GF8375@redhat.com> <1191530534.4199.4.camel@T7.Linux>
Message-ID: <1191679383.15421.3.camel@localhost.localdomain>

On Thu, 2007-10-04 at 21:42 +0100, Paul wrote:
> Hi,
> 
> > > It continually asks me for the passphrase or network key
> > 
> > Is the SSID "hidden" (i.e. do you see it in the output of 'iwlist
> > wlan0 scan')?
> 
> Yep. I can see it in the iwlist.

Do you see the SSID for your AP in iwlist, or do you only see the MAC
address of your AP, and the SSID is "<hidden>"?

In any case, can you post the output if iwlist for your AP (obfuscating
the MAC address if you like) ?  NM shouldn't be asking for a
passphrase/key if the AP's not encrypted.

Dan

> That said, with kernel-2.6.23-0.217.rc9.git.fc8, neat is telling me that
> bcm43_mac80211 device wlan0 does not seem to be present!
> 
> TTFN
> 
> Paul
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From lmacken at redhat.com  Sat Oct  6 14:08:32 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sat, 6 Oct 2007 10:08:32 -0400
Subject: bodhi update problem
In-Reply-To: <20071006073157.GU10067@psilocybe.teonanacatl.org>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
	<20071006073157.GU10067@psilocybe.teonanacatl.org>
Message-ID: <20071006140832.GB28933@crow.myhome.westell.com>

On Sat, Oct 06, 2007 at 03:31:57AM -0400, Todd Zullinger wrote:
> Luke Macken wrote:
> >> Here's a patch for considering group-acls as part of authentication
> >> check.
> > 
> > Applied, thanks!
> 
> This isn't applied to the production instance of bodhi, is it?  I
> tried the vorbis-tools update again and still get the "does not have
> commit access" error message.  I logged out of bodhi before I tried
> this.

Not yet; the patch broke a few unittests, so I need to figure out
what is going on first before I update our production instance.

luke



From jkeating at redhat.com  Sat Oct  6 14:21:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 6 Oct 2007 10:21:53 -0400
Subject: sqlite over NFS (locking)
In-Reply-To: <ufatzp5kkus.fsf@epithumia.math.uh.edu>
References: <470692EE.2020703@cora.nwra.com>
	<20071005221429.07624592@redhat.com>
	<ufatzp5kkus.fsf@epithumia.math.uh.edu>
Message-ID: <20071006102153.5a4c8382@redhat.com>

On 05 Oct 2007 22:00:59 -0500
Jason L Tibbitts III <tibbs at math.uh.edu> wrote:

> It's failed for me as well.  What failure mode did you see?  For me
> the creatrepo run simply failed to terminate; I just dropped '-d' and
> went on with my business but I guess I could experiment.

For me it just went extremely slow, and at times the db could be
corrupt.  The speed decrease was nowhere near acceptable, but now that
I think about it, I think the decrease was actually accessing the db on
an NFS share.  The seeking and whatnot within the db file was
excruciating, and this was because I had pungi putting it's yum
workfiles within the destination directory which was on NFS.  Not a
good thing to have your yum cache on NFS :/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071006/2c0517cf/attachment.sig>

From jkeating at redhat.com  Sat Oct  6 14:24:57 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 6 Oct 2007 10:24:57 -0400
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071006041252.GA23666@jadzia.bu.edu>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
	<20071006030206.GA27282@auslistsprd01.us.dell.com>
	<20071006032619.GC27282@auslistsprd01.us.dell.com>
	<20071006041252.GA23666@jadzia.bu.edu>
Message-ID: <20071006102457.24cdf490@redhat.com>

On Sat, 6 Oct 2007 00:12:52 -0400
Matthew Miller <mattdm at mattdm.org> wrote:

> Wouldn't it be *lot* easier and cheaper to just make some source code
> CDs for trade shows?

This doesn't help folks who respin the distro but want to point to us
for the srpms.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071006/d43790e1/attachment.sig>

From mclasen at redhat.com  Sat Oct  6 14:58:25 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 06 Oct 2007 10:58:25 -0400
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710061038.18961.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
	<1191626596.27655.9.camel@gilboa-home-dev.localdomain>
	<200710061038.18961.ville.skytta@iki.fi>
Message-ID: <1191682705.2588.1.camel@localhost.localdomain>


On Sat, 2007-10-06 at 10:38 +0300, Ville Skytt? wrote:

> I think in cases where xdg-open doesn't provide a satisfactory solution, we 
> can stick with htmlview.  And htmlview could be internally changed to use 
> xdg-open for cases where it is passed an argument which would make it honor 
> non-GNOME desktop settings better too.
> 

What do we win again by doing these silly wrappers around wrappers ? 
Remember, the xdg-open style utilities are meant to have some unified
way to start things for _third party_ applications. Then some people
came up with the agenda to push these wrapper scripts for use inside the
desktops, which does not really make a lot of sense.



From lmacken at redhat.com  Sat Oct  6 15:27:57 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sat, 6 Oct 2007 11:27:57 -0400
Subject: bodhi update problem
In-Reply-To: <4706A341.8040408@gmail.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
Message-ID: <20071006152757.GC28933@crow.myhome.westell.com>

On Fri, Oct 05, 2007 at 01:49:05PM -0700, Toshio Kuratomi wrote:
> Here's a patch for considering group-acls as part of authentication check.

Thanks again for the patch, Toshio.  However, after a quick run through bodhi's
test cases, it seemed to break in a couple of places..

> +               filter(lambda x: x in identity.current.groups, groups):

The second group tuple from get_pkg_pushes looks like this: (['cvsextras'], [])
So, I assume the above should be filtering through groups[0].

> +    pNotify = [pkg['packageListings'][0]['owneruser']]
> +    pAllowed = [notify[0]]

I'm assuming s/notify/pNotify/

If all of my assumptions are correct, I'll commit the fixes, and update
our production instance.

Thanks!

luke



From 440volt.tux at gmail.com  Sat Oct  6 15:40:51 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Sat, 6 Oct 2007 21:10:51 +0530
Subject: cvs help needed
Message-ID: <539333cb0710060840oe06bdf9wd028177ac762547@mail.gmail.com>

Hi!

i have few queries
if i had made a cvs tag build for a package ,how would i redo it again
if i need a rebuild?
 Is it possible to remove previously build tags from cvs ?

-- 
Regards
Subhodip Biswas

GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From ville.skytta at iki.fi  Sat Oct  6 15:50:33 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sat, 6 Oct 2007 18:50:33 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <1191682705.2588.1.camel@localhost.localdomain>
References: <200710012141.58217.ville.skytta@iki.fi>
	<200710061038.18961.ville.skytta@iki.fi>
	<1191682705.2588.1.camel@localhost.localdomain>
Message-ID: <200710061850.33946.ville.skytta@iki.fi>

On Saturday 06 October 2007, Matthias Clasen wrote:
> On Sat, 2007-10-06 at 10:38 +0300, Ville Skytt? wrote:
> > I think in cases where xdg-open doesn't provide a satisfactory solution,
> > we can stick with htmlview.  And htmlview could be internally changed to
> > use xdg-open for cases where it is passed an argument which would make it
> > honor non-GNOME desktop settings better too.
>
> What do we win again by doing these silly wrappers around wrappers ?

That's an implementation detail.

> Remember, the xdg-open style utilities are meant to have some unified
> way to start things for _third party_ applications. Then some people
> came up with the agenda to push these wrapper scripts for use inside the
> desktops, which does not really make a lot of sense.

If you know another way that makes it possible for let's say a KDE user to 
configure her preferred apps in *one* place (most natural way would be KDE 
control center) and have all KDE, GNOME, plain old X etc applications honor 
it, please let us know.  Solutions to this particular example like "don't use 
non-KDE apps" or "configure them all in KDE control center and GNOME control 
center and whatnot and keep all those in sync yourself" (which is the current 
situation) don't cut it.



From a.badger at gmail.com  Sat Oct  6 15:58:32 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 06 Oct 2007 08:58:32 -0700
Subject: bodhi update problem
In-Reply-To: <20071006152757.GC28933@crow.myhome.westell.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>	<20071005193444.GB3424@crow.myhome.westell.com>	<4706A341.8040408@gmail.com>
	<20071006152757.GC28933@crow.myhome.westell.com>
Message-ID: <4707B0A8.2090004@gmail.com>

Luke Macken wrote:
> On Fri, Oct 05, 2007 at 01:49:05PM -0700, Toshio Kuratomi wrote:
>> Here's a patch for considering group-acls as part of authentication check.
> 
> Thanks again for the patch, Toshio.  However, after a quick run through bodhi's
> test cases, it seemed to break in a couple of places..
> 
>> +               filter(lambda x: x in identity.current.groups, groups):
> 
> The second group tuple from get_pkg_pushes looks like this: (['cvsextras'], [])
> So, I assume the above should be filtering through groups[0].
> 
>> +    pNotify = [pkg['packageListings'][0]['owneruser']]
>> +    pAllowed = [notify[0]]
> 
> I'm assuming s/notify/pNotify/
> 
> If all of my assumptions are correct, I'll commit the fixes, and update
> our production instance.
> 
Yes to both of those.

-Toshio



From mschwendt.tmp0701.nospam at arcor.de  Sat Oct  6 16:14:55 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sat, 6 Oct 2007 18:14:55 +0200
Subject: cvs help needed
In-Reply-To: <539333cb0710060840oe06bdf9wd028177ac762547@mail.gmail.com>
References: <539333cb0710060840oe06bdf9wd028177ac762547@mail.gmail.com>
Message-ID: <20071006181455.86dcbb22.mschwendt.tmp0701.nospam@arcor.de>

On Sat, 6 Oct 2007 21:10:51 +0530, subhodip biswas wrote:

> Hi!
> 
> i have few queries
> if i had made a cvs tag build for a package ,how would i redo it again
> if i need a rebuild?

What kind of _re_build? After you have built and published packages
with a specified cvs tag before, you must not (re-)build them
again. Neither unmodified nor modified. Only when you increase the
%release, %version or %epoch of the package, the new build becomes a
valid update.

>  Is it possible to remove previously build tags from cvs ?

No. For small mistakes in a package you can force cvs to move a tag
when (re-)tagging the latest files (I don't explain that here,
however, since I don't want to see people shoot themselves into their
feet). But most of the time, simply increase the %release version,
create a new tag, and build with that tag.



From 440volt.tux at gmail.com  Sat Oct  6 16:14:30 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Sat, 6 Oct 2007 21:44:30 +0530
Subject: cvs help needed
In-Reply-To: <20071006181455.86dcbb22.mschwendt.tmp0701.nospam@arcor.de>
References: <539333cb0710060840oe06bdf9wd028177ac762547@mail.gmail.com>
	<20071006181455.86dcbb22.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <539333cb0710060914p55574b1ew4db057119cf5b428@mail.gmail.com>

Thanx for the help

On 10/6/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> On Sat, 6 Oct 2007 21:10:51 +0530, subhodip biswas wrote:
>
> > Hi!
> >
> > i have few queries
> > if i had made a cvs tag build for a package ,how would i redo it again
> > if i need a rebuild?
>
> What kind of _re_build? After you have built and published packages
> with a specified cvs tag before, you must not (re-)build them
> again. Neither unmodified nor modified. Only when you increase the
> %release, %version or %epoch of the package, the new build becomes a
> valid update.
>
> >  Is it possible to remove previously build tags from cvs ?
>
> No. For small mistakes in a package you can force cvs to move a tag
> when (re-)tagging the latest files (I don't explain that here,
> however, since I don't want to see people shoot themselves into their
> feet). But most of the time, simply increase the %release version,
> create a new tag, and build with that tag.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From ssorce at redhat.com  Sat Oct  6 16:31:53 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 06 Oct 2007 12:31:53 -0400
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <20071006030206.GA27282@auslistsprd01.us.dell.com>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
	<20071006030206.GA27282@auslistsprd01.us.dell.com>
Message-ID: <1191688313.14966.43.camel@localhost.localdomain>

On Fri, 2007-10-05 at 22:02 -0500, Matt Domsch wrote:
> The "three years" part isn't really clarified in v3 either.  A
> pessimistic read would be "three years from the last distribution",
> which would be forever if you don't know when the last distribution
> was.  I can't believe this is what they intend, but IANAL, and
> definitely IANAFSFL.

While sometimes legal matters seem to be complicated, this one is pretty
easy.
1st of all there is no concept of first, last or middle distribution, GA
date or anything in a license.

The license is binding at the moment of distribution.

So the 3 years promise is a promise to provide source code for that
specific GPLv2 package you distributed starting exactly the day it was
handed on.
So the 3 years promise for a Distribution on a CD start from the Day you
actually distributed the specific CD.
The reason why 3b is difficult to respect is that you have to keep
track, at least of the last time you distribute as binary only + promise
a specific package, and keep it's source code for 3 years since then.

To be clear, if you decide, for some reason, to distribute (binary only
CD) an old Fedora release say 2 years after it has been published, then
you have to keep sources for another 3 years.

That's why most vendors use this option only under controlled conditions
when they can keep track easily of the distributed material, all others
ship CDs with sources to avoid this problem or ship binaries only via
the net, as that way their obligations are fulfilled immediately and
don't have to keep track of anything for long periods of time.

Now this means at all effects: "3 years from last distribution", but it
should be corrected to: "3 years from last distribution on a media in
binary only *by the Fedora Project* itself"

If someone else make up a fedora CD and distributes it, it is *their*
duty to keep up the promise, as *they* are distributing not the Fedora
Project.

In Conclusion, I say we should always provide source CDs when Binary
only CDs are distributed. From what I can understand, picking up the
offered source CD is up to the person that accept the binary CD, we
don't need to force people to take the source CD as well. And this means
that most probably the number of CD with sources that someone need to
bring along is substantially inferior to the number of binary CDs as
most people will choose, at the moment, no to pick the sources CDs. But
*this* point should be evaluated by a real lawyer or asked the FSF.

Simo.



From ssorce at redhat.com  Sat Oct  6 16:35:19 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 06 Oct 2007 12:35:19 -0400
Subject: Distributing Fedora packages under GPLv2 3(b)
In-Reply-To: <1191688313.14966.43.camel@localhost.localdomain>
References: <20071005220305.GA11072@auslistsprd01.us.dell.com>
	<4706B63F.2090702@laposte.net>
	<604aa7910710051514l7d04f7bem8e24a29fd3abe9d2@mail.gmail.com>
	<20071006010652.GA22550@auslistsprd01.us.dell.com>
	<20071005221911.4e7c1605@redhat.com>
	<20071006030206.GA27282@auslistsprd01.us.dell.com>
	<1191688313.14966.43.camel@localhost.localdomain>
Message-ID: <1191688519.14966.45.camel@localhost.localdomain>

On Sat, 2007-10-06 at 12:31 -0400, Simo Sorce wrote:
> While sometimes legal matters seem to be complicated, this one is
> pretty
> easy.
> 1st of all there is no concept of first, last or middle distribution,
> GA
> date or anything in a license.

Sorry:
s/a license/the GPLv2 license/ 



From drepper at redhat.com  Sat Oct  6 16:45:26 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sat, 06 Oct 2007 09:45:26 -0700
Subject: LANG=am_ET causes funny collating order
In-Reply-To: <470739B3.9050102@codewiz.org>
References: <4706FAA8.8030003@codewiz.org> <47070C9E.3070504@redhat.com>
	<470739B3.9050102@codewiz.org>
Message-ID: <4707BBA6.7090406@redhat.com>

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

Bernardo Innocenti wrote:
> What was the fix?  I think we'll need to backport the patch to F7's
> glibc for fork the package off in OLPC-2.

Lot's of changes in at least three completely different places.  Just
use the F8 glibc, it can only be better.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHB7um2ijCOnn/RHQRAiEPAJ4q0tu2Z/r3UnY8ooS60HsCqlqCugCgnROf
n7IKeHGO4lyjIHI8yH9eK4c=
=vtGE
-----END PGP SIGNATURE-----



From mclasen at redhat.com  Sat Oct  6 17:39:29 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 06 Oct 2007 13:39:29 -0400
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <200710061850.33946.ville.skytta@iki.fi>
References: <200710012141.58217.ville.skytta@iki.fi>
	<200710061038.18961.ville.skytta@iki.fi>
	<1191682705.2588.1.camel@localhost.localdomain>
	<200710061850.33946.ville.skytta@iki.fi>
Message-ID: <1191692369.7113.0.camel@localhost.localdomain>


On Sat, 2007-10-06 at 18:50 +0300, Ville Skytt? wrote:
> On Saturday 06 October 2007, Matthias Clasen wrote:
> > On Sat, 2007-10-06 at 10:38 +0300, Ville Skytt? wrote:
> > > I think in cases where xdg-open doesn't provide a satisfactory solution,
> > > we can stick with htmlview.  And htmlview could be internally changed to
> > > use xdg-open for cases where it is passed an argument which would make it
> > > honor non-GNOME desktop settings better too.
> >
> > What do we win again by doing these silly wrappers around wrappers ?
> 
> That's an implementation detail.
> 
> > Remember, the xdg-open style utilities are meant to have some unified
> > way to start things for _third party_ applications. Then some people
> > came up with the agenda to push these wrapper scripts for use inside the
> > desktops, which does not really make a lot of sense.
> 
> If you know another way that makes it possible for let's say a KDE user to 
> configure her preferred apps in *one* place (most natural way would be KDE 
> control center) and have all KDE, GNOME, plain old X etc applications honor 
> it, please let us know.  Solutions to this particular example like "don't use 
> non-KDE apps" or "configure them all in KDE control center and GNOME control 
> center and whatnot and keep all those in sync yourself" (which is the current 
> situation) don't cut it.


I hope you have no illusions about xdg-open being a solution to this
problem...



From lmacken at redhat.com  Sat Oct  6 18:06:28 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sat, 6 Oct 2007 14:06:28 -0400
Subject: bodhi update problem
In-Reply-To: <20071006073157.GU10067@psilocybe.teonanacatl.org>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
	<20071006073157.GU10067@psilocybe.teonanacatl.org>
Message-ID: <20071006180628.GD28933@crow.myhome.westell.com>

On Sat, Oct 06, 2007 at 03:31:57AM -0400, Todd Zullinger wrote:
> Luke Macken wrote:
> >> Here's a patch for considering group-acls as part of authentication
> >> check.
> > 
> > Applied, thanks!
> 
> This isn't applied to the production instance of bodhi, is it?  I
> tried the vorbis-tools update again and still get the "does not have
> commit access" error message.  I logged out of bodhi before I tried
> this.

I just updated our production bodhi instance.

luke



From tmz at pobox.com  Sat Oct  6 18:22:11 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 6 Oct 2007 14:22:11 -0400
Subject: bodhi update problem
In-Reply-To: <20071006180628.GD28933@crow.myhome.westell.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
	<20071006073157.GU10067@psilocybe.teonanacatl.org>
	<20071006180628.GD28933@crow.myhome.westell.com>
Message-ID: <20071006182211.GA20108@psilocybe.teonanacatl.org>

Luke Macken wrote:
> I just updated our production bodhi instance.

Hmmm, I just tried the vorbis-tools update again and I still get the
same error (I'd just restarted firefox for other reasons, so I had
logged in freshly to bodhi and started a new update).  Got any ideas
why that'd still fail?

Thanks much for working on this.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
    -- Jerome K. Jerome

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071006/417af6c6/attachment.sig>

From myfedora at richip.dhs.org  Sat Oct  6 18:42:21 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 06 Oct 2007 12:42:21 -0600
Subject: gdm Create User
Message-ID: <1191696141.3754.6.camel@localhost6.localdomain6>

How about adding the functionality to create user accounts (local or
network) at the gdm login screen?

I recently installed F8T3 on one machine without reformatting the /home
partition so my user account's home directory keeps moving from one
iteration of Fedora to another, but I thought I wanted to see what a
default desktop setup looked like. So here I was at gdm and thinking
"Why do I have to log in to an account to create an account at the login
screen?" Seems pretty logical to add that functionality there. Seems
like it would satisfy a lot of home and enterprise use-cases, as well.

Thoughts?
--

Richi Plana



From gilboad at gmail.com  Sat Oct  6 18:55:06 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 06 Oct 2007 20:55:06 +0200
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <20071006124218.297a6e02@lain.camperquake.de>
References: <200710012141.58217.ville.skytta@iki.fi>
	<1191626596.27655.9.camel@gilboa-home-dev.localdomain>
	<20071006124218.297a6e02@lain.camperquake.de>
Message-ID: <1191696906.29628.8.camel@gilboa-home-dev.localdomain>

On Sat, 2007-10-06 at 12:42 +0200, Ralf Ertzinger wrote:
> Hi.
> 
> On Sat, 06 Oct 2007 01:23:16 +0200, Gilboa Davara wrote
> 
> > This is a major issue for me (At least in icewm... less in gmrun) as
> > the browser button needs to open an empty browser window.
> > As you said, about:blank is not portable and pointing the browser to a
> > default web-page (say fedoraproject.org) will generate useless
> > traffic.
> 
> Which browser does not understand about:blank?
> 

Dilo. (Jump to google.com)
w3m. (Sends out an "Invalid URI" error)

- Gilboa




From dmc.fedora at filteredperception.org  Sat Oct  6 18:58:05 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sat, 06 Oct 2007 13:58:05 -0500
Subject: gdm Create User
In-Reply-To: <1191696141.3754.6.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
Message-ID: <4707DABD.7060107@filteredperception.org>

Richi Plana wrote:
> How about adding the functionality to create user accounts (local or
> network) at the gdm login screen?

I think a cool *optional* functionality would be-

Whenever gdm receives an unknown username, *automatically* create that 
account as new, and log them in.

Perhaps the way to implement your functionality, would be to have the 
above, but after login attempt, a 15 second timeout prompt pops up (with 
cancel), notifying that it was an unrecognized login, and asking for the 
  adminstrative password to confirm account creation.  And then perhaps 
a checkbox to enable/disable continuation of login for that user.  Then 
you get back to my functionality with an administrative setting that 
just disables the popping up of the confirmation/authentication dialog.

-dmc


> I recently installed F8T3 on one machine without reformatting the /home
> partition so my user account's home directory keeps moving from one
> iteration of Fedora to another, but I thought I wanted to see what a
> default desktop setup looked like. So here I was at gdm and thinking
> "Why do I have to log in to an account to create an account at the login
> screen?" Seems pretty logical to add that functionality there. Seems
> like it would satisfy a lot of home and enterprise use-cases, as well.
> 
> Thoughts?
> --
> 
> Richi Plana
> 



From ville.skytta at iki.fi  Sat Oct  6 18:58:29 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sat, 6 Oct 2007 21:58:29 +0300
Subject: Using xdg-utils instead of htmlview, other hardwired apps
In-Reply-To: <1191692369.7113.0.camel@localhost.localdomain>
References: <200710012141.58217.ville.skytta@iki.fi>
	<200710061850.33946.ville.skytta@iki.fi>
	<1191692369.7113.0.camel@localhost.localdomain>
Message-ID: <200710062158.29762.ville.skytta@iki.fi>

On Saturday 06 October 2007, Matthias Clasen wrote:
> On Sat, 2007-10-06 at 18:50 +0300, Ville Skytt? wrote:
>
> > If you know another way that makes it possible for let's say a KDE user
> > to configure her preferred apps in *one* place (most natural way would be
> > KDE control center) and have all KDE, GNOME, plain old X etc applications
> > honor it, please let us know.  Solutions to this particular example like
> > "don't use non-KDE apps" or "configure them all in KDE control center and
> > GNOME control center and whatnot and keep all those in sync yourself"
> > (which is the current situation) don't cut it.
>
> I hope you have no illusions about xdg-open being a solution to this
> problem...

Shrug.  It works now for that purpose in applications that use xdg-open, no 
illusion there.  It might not be the prettiest possible way to do things, but 
I haven't seen anyone even suggest any other solutions.



From bernie at codewiz.org  Sat Oct  6 19:00:45 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Sat, 06 Oct 2007 15:00:45 -0400
Subject: LANG=am_ET causes funny collating order
In-Reply-To: <4707BBA6.7090406@redhat.com>
References: <4706FAA8.8030003@codewiz.org> <47070C9E.3070504@redhat.com>
	<470739B3.9050102@codewiz.org> <4707BBA6.7090406@redhat.com>
Message-ID: <4707DB5D.7080904@codewiz.org>

Ulrich Drepper wrote:

> Bernardo Innocenti wrote:
>> What was the fix?  I think we'll need to backport the patch to F7's
>> glibc for fork the package off in OLPC-2.
> 
> Lot's of changes in at least three completely different places.  Just
> use the F8 glibc, it can only be better.

Thanks!

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/



From myfedora at richip.dhs.org  Sat Oct  6 19:27:10 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 06 Oct 2007 13:27:10 -0600
Subject: gdm Create User
In-Reply-To: <4707DABD.7060107@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
Message-ID: <1191698830.4271.7.camel@localhost6.localdomain6>

On Sat, 2007-10-06 at 13:58 -0500, Douglas McClendon wrote:
> Richi Plana wrote:
> > How about adding the functionality to create user accounts (local or
> > network) at the gdm login screen?
> 
> I think a cool *optional* functionality would be-
> 
> Whenever gdm receives an unknown username, *automatically* create that 
> account as new, and log them in.
> 
> Perhaps the way to implement your functionality, would be to have the 
> above, but after login attempt, a 15 second timeout prompt pops up (with 
> cancel), notifying that it was an unrecognized login, and asking for the 
>   adminstrative password to confirm account creation.  And then perhaps 
> a checkbox to enable/disable continuation of login for that user.  Then 
> you get back to my functionality with an administrative setting that 
> just disables the popping up of the confirmation/authentication dialog.

Well, that certainly sounds like a smart system ... and I'm all for
computers trying to be smarter than their users (if they can do it
successfully). But why add a timeout? I'm assuming finding out a list of
users from the console isn't a security issue (since they're displayed
as a list by GDM) so why not make the computer think one of two things
has happened: 1) the user mistyped the username or 2) the user wants to
create a new user. The system could ask which and ask for the root
password or directory administrator's password if it was a request for
the creation of users.

It's not intuitive, though, so maybe a "Login (existing or create a new
one)" at the prompt would be nice.

Maybe then we could remove the "Create User" account at firstboot.
--

Richi Plana



From kamisamanou at kamisamanou.net  Sat Oct  6 19:33:27 2007
From: kamisamanou at kamisamanou.net (Kamisamanou Burgess)
Date: Sat, 6 Oct 2007 14:33:27 -0500
Subject: Help Needed: Test zd1211rw-mac80211, b43, rt73usb Wireless
In-Reply-To: <4706472B.1070903@redhat.com>
References: <4706472B.1070903@redhat.com>
Message-ID: <5dbb83710710061233k28289bf1h18dfa84601aba70b@mail.gmail.com>

Once I get F8T3 Live downloaded, I'll see if the evil bcm4318 will function

On 10/5/07, Warren Togami <wtogami at redhat.com> wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=319071
> We need help testing mac80211-based drivers, e.g. zd1211rw-mac80211,
> b43, rt73usb, etc.
>
> http://koji.fedoraproject.org/packages/kernel/2.6.23/
> Kernel 217 is known to work with iwl3945 and iwl4965, but kernel 218
> broke it.  We need these other network drivers tested between 217 and
> 218.  Please report your findings to the above bug report.
>
> Thanks,
> Warren Togami
> wtogami at redhat.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Sayonara,
Kamisamanou Burgess
http://www.kamisamanou.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071006/8ae83a58/attachment.htm>

From dmc.fedora at filteredperception.org  Sat Oct  6 19:33:30 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sat, 06 Oct 2007 14:33:30 -0500
Subject: gdm Create User
In-Reply-To: <1191698830.4271.7.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<4707DABD.7060107@filteredperception.org>
	<1191698830.4271.7.camel@localhost6.localdomain6>
Message-ID: <4707E30A.8090104@filteredperception.org>

Richi Plana wrote:
> On Sat, 2007-10-06 at 13:58 -0500, Douglas McClendon wrote:
>> Richi Plana wrote:
>>> How about adding the functionality to create user accounts (local or
>>> network) at the gdm login screen?
>> I think a cool *optional* functionality would be-
>>
>> Whenever gdm receives an unknown username, *automatically* create that 
>> account as new, and log them in.
>>
>> Perhaps the way to implement your functionality, would be to have the 
>> above, but after login attempt, a 15 second timeout prompt pops up (with 
>> cancel), notifying that it was an unrecognized login, and asking for the 
>>   adminstrative password to confirm account creation.  And then perhaps 
>> a checkbox to enable/disable continuation of login for that user.  Then 
>> you get back to my functionality with an administrative setting that 
>> just disables the popping up of the confirmation/authentication dialog.
> 
> Well, that certainly sounds like a smart system ... and I'm all for
> computers trying to be smarter than their users (if they can do it
> successfully). But why add a timeout?

I was thinking out loud...  I was sort of trying to fit it in so it sort 
of still behaved like the old way (i.e. screen jiggle pause and back to 
login prompt).  But since you brought it up and I thought about it, I 
don't see a compelling reason for the timeout.

  I'm assuming finding out a list of
> users from the console isn't a security issue (since they're displayed
> as a list by GDM)

I don't think what I described changes anything from that security 
perspective.  I.e. already you get a 'invalid username' response.

  so why not make the computer think one of two things
> has happened: 1) the user mistyped the username or 2) the user wants to
> create a new user. The system could ask which and ask for the root
> password or directory administrator's password if it was a request for
> the creation of users.
> 
> It's not intuitive, though, so maybe a "Login (existing or create a new
> one)" at the prompt would be nice.

sounds good.

> Maybe then we could remove the "Create User" account at firstboot.

To round out the missing bits, the root authentication prompt might also 
include-

- confirmation of the user's chosen password
- optional Real Name setting
( default desktop choice comes from normal gdm session selection )

-dmc



From mclasen at redhat.com  Sat Oct  6 19:49:21 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 06 Oct 2007 15:49:21 -0400
Subject: gdm Create User
In-Reply-To: <4707DABD.7060107@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
Message-ID: <1191700161.7113.6.camel@localhost.localdomain>


On Sat, 2007-10-06 at 13:58 -0500, Douglas McClendon wrote:
> Richi Plana wrote:
> > How about adding the functionality to create user accounts (local or
> > network) at the gdm login screen?
> 
> I think a cool *optional* functionality would be-
> 
> Whenever gdm receives an unknown username, *automatically* create that 
> account as new, and log them in.
> 
> Perhaps the way to implement your functionality, would be to have the 
> above, but after login attempt, a 15 second timeout prompt pops up (with 
> cancel), notifying that it was an unrecognized login, and asking for the 
>   adminstrative password to confirm account creation.  And then perhaps 
> a checkbox to enable/disable continuation of login for that user.  Then 
> you get back to my functionality with an administrative setting that 
> just disables the popping up of the confirmation/authentication dialog.
> 

A prototype for "guest account" functionality from the login screen can
be found here:

https://hosted.fedoraproject.org/projects/guest-account/



From abo at kth.se  Sat Oct  6 19:47:14 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 06 Oct 2007 21:47:14 +0200
Subject: gdm Create User
In-Reply-To: <4707DABD.7060107@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
Message-ID: <1191700034.5560.84.camel@home.alexander.bostrom.net>

l?r 2007-10-06 klockan 13:58 -0500 skrev Douglas McClendon:
> Richi Plana wrote:
> > How about adding the functionality to create user accounts (local or
> > network) at the gdm login screen?
> 
> I think a cool *optional* functionality would be-
> 
> Whenever gdm receives an unknown username, *automatically* create that 
> account as new, and log them in.

In a system I've used, the login conversation is either:

- What's your name?
+ My name is Foo Bar.
- What's your password?
+ My password is Blahonga.

Or:

- What's your name?
+ My name is Gazonk.
- Unknown user, is that really your name?
+ Yes.
- Would you like to create an account?'
...and so on.

Or:

- What's your name?
+ My name is Gazonk.
- Unknown user, is that really your name?
+ No.
- Please try again. What's your name?
...and so on.

That might serve as inspiration.

/abo




From dmc.fedora at filteredperception.org  Sat Oct  6 19:47:57 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sat, 06 Oct 2007 14:47:57 -0500
Subject: gdm Create User
In-Reply-To: <4707E30A.8090104@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<4707DABD.7060107@filteredperception.org>	<1191698830.4271.7.camel@localhost6.localdomain6>
	<4707E30A.8090104@filteredperception.org>
Message-ID: <4707E66D.5070201@filteredperception.org>

Douglas McClendon wrote:
> Richi Plana wrote:
>> On Sat, 2007-10-06 at 13:58 -0500, Douglas McClendon wrote:
>>> Richi Plana wrote:
>>>> How about adding the functionality to create user accounts (local or
>>>> network) at the gdm login screen?
>>> I think a cool *optional* functionality would be-
>>>
>>> Whenever gdm receives an unknown username, *automatically* create 
>>> that account as new, and log them in.
>>>
>>> Perhaps the way to implement your functionality, would be to have the 
>>> above, but after login attempt, a 15 second timeout prompt pops up 
>>> (with cancel), notifying that it was an unrecognized login, and 
>>> asking for the   adminstrative password to confirm account creation.  
>>> And then perhaps a checkbox to enable/disable continuation of login 
>>> for that user.  Then you get back to my functionality with an 
>>> administrative setting that just disables the popping up of the 
>>> confirmation/authentication dialog.
>>
>> Well, that certainly sounds like a smart system ... and I'm all for
>> computers trying to be smarter than their users (if they can do it
>> successfully). But why add a timeout?
> 
> I was thinking out loud...  I was sort of trying to fit it in so it sort 
> of still behaved like the old way (i.e. screen jiggle pause and back to 
> login prompt).  But since you brought it up and I thought about it, I 
> don't see a compelling reason for the timeout.
> 
>  I'm assuming finding out a list of
>> users from the console isn't a security issue (since they're displayed
>> as a list by GDM)
> 
> I don't think what I described changes anything from that security 
> perspective.  I.e. already you get a 'invalid username' response.
> 
>  so why not make the computer think one of two things
>> has happened: 1) the user mistyped the username or 2) the user wants to
>> create a new user. The system could ask which and ask for the root
>> password or directory administrator's password if it was a request for
>> the creation of users.
>>
>> It's not intuitive, though, so maybe a "Login (existing or create a new
>> one)" at the prompt would be nice.
> 
> sounds good.
> 
>> Maybe then we could remove the "Create User" account at firstboot.
> 
> To round out the missing bits, the root authentication prompt might also 
> include-
> 
> - confirmation of the user's chosen password
> - optional Real Name setting
> ( default desktop choice comes from normal gdm session selection )


Of course I had noticed, but wasn't keeping up on the highly relevant 
ongoing thread on fedora-desktop-list.  Skimming it-

If you wanted to merge my idea with what they've been talking about, it 
sounds like it would be a matter of gdm detecting the unknown login, and 
then bringing up the stock-gnome-user-creation-dialog, prepopulated with 
the username and the password (and prompt for root passwd).

I of course would then like 2 admin options: one to disable root passwd 
prompt, and another to not bring up the dialog, and just log in, 
assuming defaults, and let the user modify settings if desired via the 
normal admin/prefs.

-dmc



From ssorce at redhat.com  Sat Oct  6 22:12:47 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 06 Oct 2007 18:12:47 -0400
Subject: gdm Create User
In-Reply-To: <1191696141.3754.6.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
Message-ID: <1191708767.14966.64.camel@localhost.localdomain>

On Sat, 2007-10-06 at 12:42 -0600, Richi Plana wrote:
> How about adding the functionality to create user accounts (local or
> network) at the gdm login screen?
> 
> I recently installed F8T3 on one machine without reformatting the /home
> partition so my user account's home directory keeps moving from one
> iteration of Fedora to another, but I thought I wanted to see what a
> default desktop setup looked like. So here I was at gdm and thinking
> "Why do I have to log in to an account to create an account at the login
> screen?" Seems pretty logical to add that functionality there. Seems
> like it would satisfy a lot of home and enterprise use-cases, as well.
> 
> Thoughts?

Home?
Perhaps. Ideally you create all needed accounts at installation anyway.

Enterprise?
I don't see how, it's not like any user has the root password to create
their own account. You have to ask an admin which is usually already
logged in his own system and will just launch a command from there.

Simo.



From ssorce at redhat.com  Sat Oct  6 22:18:23 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 06 Oct 2007 18:18:23 -0400
Subject: gdm Create User
In-Reply-To: <4707DABD.7060107@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
Message-ID: <1191709103.14966.71.camel@localhost.localdomain>

On Sat, 2007-10-06 at 13:58 -0500, Douglas McClendon wrote:
> Whenever gdm receives an unknown username, *automatically* create
> that 
> account as new, and log them in.

Normally you can't distinguish between 'Authentication Failed' or 'User
unknown' for security reasons. Leaking the information that a user
exists or not is considered bad. Your proposal would make it easy to
leak the information.

If you consider that GDM can be reached via a network using XDMCP, that
means that you may expos an automated way to discover valid usernames on
a box.

Simo.



From myfedora at richip.dhs.org  Sun Oct  7 01:35:12 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 06 Oct 2007 19:35:12 -0600
Subject: gdm Create User
In-Reply-To: <1191708767.14966.64.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191708767.14966.64.camel@localhost.localdomain>
Message-ID: <1191720912.7237.6.camel@localhost6.localdomain6>

On Sat, 2007-10-06 at 18:12 -0400, Simo Sorce wrote:
> On Sat, 2007-10-06 at 12:42 -0600, Richi Plana wrote:
> > How about adding the functionality to create user accounts (local or
> > network) at the gdm login screen?
> > 
> > I recently installed F8T3 on one machine without reformatting the /home
> > partition so my user account's home directory keeps moving from one
> > iteration of Fedora to another, but I thought I wanted to see what a
> > default desktop setup looked like. So here I was at gdm and thinking
> > "Why do I have to log in to an account to create an account at the login
> > screen?" Seems pretty logical to add that functionality there. Seems
> > like it would satisfy a lot of home and enterprise use-cases, as well.
> > 
> > Thoughts?
> 
> Home?
> Perhaps. Ideally you create all needed accounts at installation anyway.

On Windows, at first I didn't even think multi-user accounts would be
something the regular windows users would want, much less add more
during its short lifespan. However, experience has taught me
differently. On the various Windows systems I've encountered, I've
actually seen regular users create new accounts for friends, relatives,
etc. that weren't created at installation. To some people, it's the
equivalent of the Nintendo Mii.

> Enterprise?
> I don't see how, it's not like any user has the root password to create
> their own account. You have to ask an admin which is usually already
> logged in his own system and will just launch a command from there.

I used to work at a company where Windows and Active Directory was the
standard. Each time a new employee would be given a desktop, the system
administrator would either log on as network admin from the machine he
was installing or go back to his terminal to create the user account.
(In our company, the network admins actually walk to our areas to
deliver the new machine so they aren't sitting around in front of their
machines all the time.) So, no, I wasn't thinking the regular employee
would be creating the account from the workstation but a network admin.
Saves him from having to log on using a different account or going to
another computer (the same scenarios I mentioned earlier).
--

Richi Plana



From debarshi.ray at gmail.com  Sun Oct  7 04:06:18 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 7 Oct 2007 09:36:18 +0530
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
	development freeze
In-Reply-To: <20071004062916.75dbec15@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
Message-ID: <3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>

I have requested and received a F-8 branch for most of my packages.
Now in the interim period before the Fedora 8 final stable release,
how do I handle updates. Previously I would do a cvs commit && make
tag build for the F-7 and devel branches. If I leave the F-8 branches
untouched till the release, will stuff from devel automatically get
included in Fedora 8 when it comes out? Or I need to tag and build for
F-8 too?

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sandeen at redhat.com  Sun Oct  7 04:57:21 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 06 Oct 2007 23:57:21 -0500
Subject: readahead_early.
In-Reply-To: <20071005200221.GA28441@redhat.com>
References: <20071005200221.GA28441@redhat.com>
Message-ID: <47086731.5000803@redhat.com>

Dave Jones wrote:
> Right now we're running readahead early way too late.
> At a time when we've just sat doing no IO at all for 10
> seconds whilst (amongst other things) we waited for a
> DHCP lease.   We're also running it at a time when
> we're competing for disk bandwidth with other processes.
> The result is that disabling the service completely shows
> no change in boot time at all.
> http://www.codemonkey.org.uk/junk/bootchart-before.png
> 
> Moving the readahead_early service to start really early
> wins back 4 seconds of boot up time.
> http://www.codemonkey.org.uk/junk/bootchart-after.png

FWIW, on my test box, entirely *disabling* readahead saves 2-4 seconds
on boot time... :)

-Eric



From fedora at leemhuis.info  Sun Oct  7 05:42:44 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 07 Oct 2007 07:42:44 +0200
Subject: Unsponsored Comaintainers
In-Reply-To: <4706B341.4060905@gmail.com>
References: <4706B341.4060905@gmail.com>
Message-ID: <470871D4.6060804@leemhuis.info>

First: thx for bringing this up again after a similar idea/concept got
lost in the merge.

On 05.10.2007 23:57, Toshio Kuratomi wrote:
> 
> = Unsponsored Comaintainers =

I really dislike this term -- even a single contributor that want to get
 hands only on one package needs someone to oversee him. In the document
below it's called mentor, but in fact the job is similar to the sponsers
job.

I'd prefer to get contributor levels in a easy form. E.g.

contributor level 1 -> what you outlined here
contributor level 2 -> what most contributors are right now
contributor level 3 -> sponsors right now

contributor from level <n> should oversee (aka sponsor) contributor from
level < n -1 >

Should we even need more levels we can redefine the current ones and put
one in between. E.g. "contributor level 2b -- people that contribute for
some time now where the sponser stopped looking after each step of that
contributer"

> Sometimes a contributor wants to get involved with a single Fedora 
> package.  This is often the case with upstream maintainers who are 
> interested in seeing their software run well on Fedora but either lack 
> the time to participate in or are disinterested in Fedora as a whole.

I think we should have a broader approach -- the concept should IMHO be
used for getting new contributors in even if they are not upstream
maintainers.

E.g. like:

foo> I want to contribute to Fedora
bar> are there any packages you are interested in?
foo> foobar and barfoo
* bar looks if those have co-maintainers already
bar> please ask baz; he maintains foobar alone until now; you could
become co-maintainer without build rights and baz will oversee your
work; if you're doing well for some months you'll get full access and
baz has more time to work on <more complicated stuff>

> One way to enable this is to have current Fedora Packagers "mentor" the 
> upstream maintainers.

Was "upstream maintainers" only meant as example or do you want to limit
it to them?

>  The Fedora Packager can be the owner of record 
> for the package and make sure that it integrates with the rest of 
> Fedora.  The upstream maintainer would take the role of comaintainer for 
> the package and help mainly with code-related bugs.
> 
> For this sort of work, it would be ideal if the comaintainer could 
> commit to the package but not build or push.  The package owner would 
> then have the ability to check the changes that the upstream maintainer 
> made to verify they followed the Fedora Packaging Guidelines and 
> integrated with things going on in the rest of the distro.
> 
> At the moment we are constrained by the limitations of the tools we're 
> working with (koji, packagedb, cvs repository, and bodhi).  So here's a 
> three phase approach to getting to the ideal:
> 
> == Phase 1 ==
> 
> Upstream maintainer and Fedora Package owner decide to collaborate.  The 
> Upstream maintainer signs the CLA.  Someone from a group of sponsors 
> willing to work on this as a pilot program sponsors them into cvsextras.
>
> The comaintainer can now request commit acls on the package.  This gives 
> them access to commit to cvs, build in koji, and push via bodhi for this 
> package.  There is an understanding among the participants that the 
> upstream maintainer should not work on packages for which they have not 
> been granted commit access. 

Even more people that easily get access to all our packages? Sounds
ridiculous to me (sorry for using such hard words) as you'll likely
remember from previous discussions.

> The sponsor has to watch the commits list 
> for changes made by the upstream maintainer that violate this policy.

More load on those rare people. I don't think that's wise and I doubt
many sponsors will sponsor "Unsponsored Comaintainers"

> This requires no changes to our tools but requires:
> 1) a pool of sponsors willing to work on this
> 2) commitment from unsponsored comaintainers to follow the rules and 
> sponsors who are willing to police those comaintainers to make sure 
> they're abiding by them.
> 
> == Phase 2 ==
> 
> In phase 2, we can remove the pool of sponsors.  Instead we allow people 
> without cvsextras to sign up to comaintain a package.  If the primary 
> package maintainer approves, the comaintainer is allowed to use any of 
> the acls they are approved for.  The package owner would still have to 
> watch to make sure the comaintainer is not doing more than they are 
> supposed to on that particular package.

That sounds way better then phase 1.

> This requires changes to the cvs repository so people not in cvsextras 
> but explicitly in the acl are allowed to commit.  This could be a bit 
> tricky as we currently have two levels of security in the repository: 1) 
> People must be in the acl to access resources of the repository, 2) they 
> must be in cvsextras.  We'll want something equivalent in the new setup.

/me wonders what the status of the "new VCS" is and how it matters to
this plan

> == Phase 3 ==
> 
> In this stage, we make sure that acls prevent people from doing things 
> they are not supposed to, freeing the package owner from some of the 
> manual policing they had to do before.  The PackageDB will have acls for 
> pushing and building as well as committing.  This will allow package 
> owners to specify that a maintainer should only be allowed to commit or 
> only allowed to commit and build. [...]

Sounds good to me.

Cu
knurd



From abo at kth.se  Sun Oct  7 07:54:46 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sun, 07 Oct 2007 09:54:46 +0200
Subject: gdm Create User
In-Reply-To: <1191720912.7237.6.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191708767.14966.64.camel@localhost.localdomain>
	<1191720912.7237.6.camel@localhost6.localdomain6>
Message-ID: <1191743686.5560.225.camel@home.alexander.bostrom.net>

l?r 2007-10-06 klockan 19:35 -0600 skrev Richi Plana:

> So, no, I wasn't thinking the regular employee
> would be creating the account from the workstation but a network admin.
> Saves him from having to log on using a different account or going to
> another computer (the same scenarios I mentioned earlier). 

In my experience that isn't really doable. It's a worthy goal, but right
now I'd say this would only be useful for local accounts or perhaps for
small organisations. I guess it's doable if you only have an LDAP server
and an NFS share, but accounts on larger computer systems are in my
experience usually created with special scripts that touch multiple
databases, perhaps pulling data from outside sources and so on. (To fix
this, one needs to start at the other end of the problem, with projects
such as FreeIPA.) Also, it's often unsafe for an admin to enter
important passwords on a workstation unless that computer has just been
(re)installed.

/abo




From laroche at redhat.com  Sun Oct  7 08:32:20 2007
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 7 Oct 2007 10:32:20 +0200
Subject: readahead_early.
In-Reply-To: <47086731.5000803@redhat.com>
References: <20071005200221.GA28441@redhat.com> <47086731.5000803@redhat.com>
Message-ID: <20071007083220.GA9381@dudweiler.stuttgart.redhat.com>

> FWIW, on my test box, entirely *disabling* readahead saves 2-4 seconds
> on boot time... :)

Shouldn't we then disable it for F8? AFAIK we also wanted to remove
many other less critical services that are only needed on a low
percentage of installed systems.

regards,

Florian La Roche



From buildsys at redhat.com  Sun Oct  7 10:21:13 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 7 Oct 2007 06:21:13 -0400
Subject: rawhide report: 20071007 changes
Message-ID: <200710071021.l97ALDpq010267@porkchop.devel.redhat.com>

 

 
Updated Packages:

HelixPlayer-1:1.0.9-1.fc8
-------------------------
* Sat Oct 06 2007 Aurelien Bompard <abompard at fedoraproject.org> 1:1.0.9-1
- add sparc, sparc64, and alpha to excluded archs
- update to 1.0.9

abyssinica-fonts-1.0-2.fc8
--------------------------

amarok-1.4.7-6.fc8
------------------
* Sat Oct 06 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-6
- add "alpha" to the list of archs where HelixPlayer is not available
  (bug 318431)

bluez-gnome-0.14-7.fc8
----------------------
* Sat Oct 06 2007 - Bastien Nocera <bnocera at redhat.com> - 0.14-7
- Provide virtual dbus-bluez-pin-helper for bluez-utils to use
  (#212421)

bluez-utils-3.20-2.fc8
----------------------
* Sat Oct 06 2007 - Bastien Nocera <bnocera at redhat.com> 3.20-2
- Remove hard-dependency on bluez-gnome, and use the virtual
  provides for dbus-bluez-pin-helper insted (#212421)

cupsddk-1.2.3-1.fc8
-------------------
* Sat Oct 06 2007 Tim Waugh <twaugh at redhat.com> 1.2.3-1
- 1.2.3.  Only change from 1.2.2 is to incorporate build fix.

devhelp-0.16.1-1.fc8
--------------------
* Sat Oct 06 2007 Matthew Barnes <mbarnes at redhat.com> - 0.16.1-1.fc8
- Update to 0.16.1

dvgrab-3.0-1.fc8
----------------
* Sun Oct 07 2007 Jarod Wilson <jwilson at redhat.com> - 3.0-1
- New upstream release

* Sun Feb 04 2007 Jarod Wilson <jwilson at redhat.com> - 2.1-3
- Minor clean-ups for core/extras merge review (#225713)

eclipse-1:3.3.0-26.fc8
----------------------
* Sat Oct 06 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-26
- Add encoding to desktop file.
- Fix %files list again.

* Fri Oct 05 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-25
- Fix %files list for Fedora Eclipse feature.

* Fri Oct 05 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-24
- Update branding plugin.
- Add branding feature.  This fixes the update manager issue when using
  the Fedora-branded product.
- Thanks to Alexander Kurtakov and Pascal Rapicault for helping track
  down this issue.

em8300-kmod-0.16.3-5.2.6.23_0.220.rc9.git2.fc8
----------------------------------------------
* Sat Oct 06 2007 Ville Skytt?? <ville.skytta at iki.fi>
- Rebuild for kernel 2.6.23-0.220.rc9.git2.fc8.

glest-2.0.1-3.fc8
-----------------
* Sat Oct 06 2007 Aurelien Bompard <abompard at fedoraproject.org> 2.0.1-3
- incorporate opengl-games-utils' functionality into the wrapper script

gnome-power-manager-2.20.0-5.fc8
--------------------------------
* Sat Oct 06 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-5
- Fix a thinko in the previous patch (#321671)

hatari-0.95-4.fc8
-----------------
* Sat Oct 06 2007 Andrea Musuruane <musuruan at gmail.com> 0.95-4
- Fixed doc/authors.txt file encoding
- Updated icon cache scriptlets to be compliant to new guidelines

kernel-2.6.23-0.222.rc9.git4.fc8
--------------------------------
* Sat Oct 06 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git4

* Fri Oct 05 2007 Chuck Ebbert <cebbert at redhat.com>
- Enable HID debugging in all kernels

* Fri Oct 05 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git2

ntfs-3g-2:1.1004-1.fc8
----------------------
* Sat Oct 06 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1004-1
- bump to 1.1004

pipepanic-0.1.3-4.fc8
---------------------
* Sat Oct 06 2007 Andrea Musuruane <musuruan at gmail.com> 0.1.3-4
- Fixed COPYING-ARTWORK file encoding
- Updated icon cache scriptlets to be compliant to new guidelines
superiotool-0-0.4.20071006svn2828.fc8
-------------------------------------
* Sat Oct 06 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.4.20071006svn2828
- svn ver. 2828 (added support for Winbond W83627HF/F/HG/G, SMSC LPC47M10x,
  ITE IT8661F, SMSC LPC47B387, ITE IT8705F/AF etc)
tecnoballz-0.91-6.fc8
---------------------
* Sat Aug 25 2007 Andrea Musuruane <musuruan at gmail.com> 0.91-6
- changed license due to new guidelines
- removed %{?dist} tag from changelog
- updated icon cache scriptlets to be compliant to new guidelines
- changed desktop categories from Game;ArcadeGame; to
  Game;ArcadeGame;BlocksGame; (resolves bugzilla #250940)

* Tue Apr 03 2007 Andrea Musuruane <musuruan at gmail.com> 0.91-5
- changed summary to avoid naming trademarks.

* Sun Apr 01 2007 Andrea Musuruane <musuruan at gmail.com> 0.91-4
- corrected silly error in the %postun script

xkeyboard-config-1.1-3.fc8
--------------------------
* Sat Oct 06 2007 Matthias Clasen <mclasen at redhat.com> - 1.1-3
- Somehow the Dell M65 model lost its vendor

xorg-x11-drv-ati-6.7.195-1.fc8
------------------------------
* Sat Oct 06 2007 Adam Jackson <ajax at redhat.com> 6.7.195-1
- xf86-video-ati 6.7.195

xscreensaver-1:5.03-10.fc8
--------------------------
* Sat Oct 06 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-10
- Fix the maximum value on demo configuration dialog
- Change the encoding of XScreenSaver.ad and man files

Broken deps for i386
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	rpy - 1.0-0.2.RC3.fc8.i386 requires R = 0:2.5.1



Broken deps for x86_64
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	rpy - 1.0-0.2.RC3.fc8.x86_64 requires R = 0:2.5.1



Broken deps for ppc
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	rpy - 1.0-0.2.RC3.fc8.ppc requires R = 0:2.5.1



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	rpy - 1.0-0.2.RC3.fc8.ppc64 requires R = 0:2.5.1
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From frank-buettner at gmx.net  Sun Oct  7 11:27:32 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 07 Oct 2007 13:27:32 +0200
Subject: Why are no packages signed since 12 days?
Message-ID: <4708C2A4.2020806@gmx.net>

Hello,
when I look at
http://buildsys.fedoraproject.org/build-status/success.psp
I must read, that since 12 day no packages have signed.
Is this an error at the build system or have someone forgot it.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/bfbcc12f/attachment.bin>

From frank-buettner at gmx.net  Sun Oct  7 11:27:37 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 07 Oct 2007 13:27:37 +0200
Subject: Why are no packages signed since 12 days?
Message-ID: <4708C2A9.8020607@gmx.net>

Hello,
when I look at
http://buildsys.fedoraproject.org/build-status/success.psp
I must read, that since 12 day no packages have signed.
Is this an error at the build system or have someone forgot it.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/08347e55/attachment.bin>

From sgrubb at redhat.com  Sun Oct  7 11:42:23 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Oct 2007 07:42:23 -0400
Subject: gdm Create User
In-Reply-To: <1191709103.14966.71.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191709103.14966.71.camel@localhost.localdomain>
Message-ID: <200710070742.23928.sgrubb@redhat.com>

On Saturday 06 October 2007 18:18:23 Simo Sorce wrote:
> > Whenever gdm receives an unknown username, *automatically* create
> > that account as new, and log them in.
>
> Normally you can't distinguish between 'Authentication Failed' or 'User
> unknown' for security reasons. Leaking the information that a user
> exists or not is considered bad. Your proposal would make it easy to
> leak the information.
>
> If you consider that GDM can be reached via a network using XDMCP, that
> means that you may expos an automated way to discover valid usernames on
> a box.

I completely agree here. From a security perspective, this is a bad idea. 
There is also an audit trail that has certain requirements, too. We need to 
know the real user ID that is creating the account. (Its not root.) Root is a 
shared account and we need the loginuid of the person creating the account. 
So, they really do need to log in so that a proper session is setup and all 
the things we need for the audit trail is filled in.

-Steve



From mattdm at mattdm.org  Sun Oct  7 12:06:22 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 7 Oct 2007 08:06:22 -0400
Subject: gdm Create User
In-Reply-To: <200710070742.23928.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191709103.14966.71.camel@localhost.localdomain>
	<200710070742.23928.sgrubb@redhat.com>
Message-ID: <20071007120622.GA15466@jadzia.bu.edu>

On Sun, Oct 07, 2007 at 07:42:23AM -0400, Steve Grubb wrote:
> > > Whenever gdm receives an unknown username, *automatically* create
> > > that account as new, and log them in.
> > If you consider that GDM can be reached via a network using XDMCP, that
> > means that you may expos an automated way to discover valid usernames on
> > a box.
> I completely agree here. From a security perspective, this is a bad idea. 

GDM knows if it's running locally or via xdmcp, though. It could act
differently.

> There is also an audit trail that has certain requirements, too. We need to 
> know the real user ID that is creating the account. (Its not root.) Root is a 
> shared account and we need the loginuid of the person creating the account. 
> So, they really do need to log in so that a proper session is setup and all 
> the things we need for the audit trail is filled in.

And yes, the feature should certainly be easy to deactivate. It's
inappropriate for a wide variety of situations.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From anders at trudheim.co.uk  Sun Oct  7 12:20:26 2007
From: anders at trudheim.co.uk (Anders Karlsson)
Date: Sun, 7 Oct 2007 13:20:26 +0100
Subject: Sierra Wireless on Rawhide
Message-ID: <20071007122026.GA5994@iota.fab.redhat.com>

Hi there,

I've been trying to get UMTS working through the Sierra chip in my
Thinkpad X60s and for some reason, the USB subsystem in F8 TestN and
Rawhide clocks that I have the Sierra chip, configures it (udev
creates /dev/ttyUSB[0-2]) and then immediately disconnects the device,
meaning I no longer see it in lsusb output etc. This was not the case
in F7.

I've tried reverting the Sierra driver to version 1.0.6 (known to work
on RHEL5), to no avail, and I've also tried booting with
usbcore.autosuspend=0 and usbcore.autosuspend=-1. Neither improves the
situation.

In /var/log/messages I get the following snippet around when sierra is
loaded;

---
Oct  7 12:44:02 iota kernel: usbcore: registered new interface driver hci_usb
Oct  7 12:44:02 iota kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for Sierra USB modem (1 port)
Oct  7 12:44:02 iota kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for Sierra USB modem (3 port)
Oct  7 12:44:02 iota kernel: sierra 3-1:1.0: Sierra USB modem (3 port) converter detected
Oct  7 12:44:02 iota kernel: usb 3-1: Sierra USB modem (3 port) converter now attached to ttyUSB0
Oct  7 12:44:02 iota kernel: usb 3-1: Sierra USB modem (3 port) converter now attached to ttyUSB1
Oct  7 12:44:02 iota kernel: usb 3-1: Sierra USB modem (3 port) converter now attached to ttyUSB2
Oct  7 12:44:02 iota kernel: usbcore: registered new interface driver sierra
Oct  7 12:44:02 iota kernel: /root/sierra.v.1.0.6/sierra.c: USB Driver for Sierra Wireless USB modems: v.1.0.6
Oct  7 12:44:02 iota kernel: iTCO_vendor_support: vendor-support=0
Oct  7 12:44:02 iota kernel: sdhci: Secure Digital Host Controller Interface driver
Oct  7 12:44:02 iota kernel: sdhci: Copyright(c) Pierre Ossman
Oct  7 12:44:02 iota kernel: sdhci: SDHCI controller found at 0000:15:00.2 [1180:0822] (rev 18)
Oct  7 12:44:02 iota kernel: ACPI: PCI Interrupt 0000:15:00.2[C] -> GSI 18 (level, low) -> IRQ 23
Oct  7 12:44:02 iota kernel: mmc0: SDHCI at 0xe4301800 irq 23 DMA
Oct  7 12:44:02 iota kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
Oct  7 12:44:02 iota kernel: iTCO_wdt: Found a ICH7-M TCO device (Version=2, TCOBASE=0x1060)
Oct  7 12:44:02 iota kernel: usb 3-1: USB disconnect, address 2
Oct  7 12:44:02 iota kernel: sierra3 ttyUSB0: Sierra USB modem (3 port) converter now disconnected from ttyUSB0
Oct  7 12:44:02 iota kernel: sierra3 ttyUSB1: Sierra USB modem (3 port) converter now disconnected from ttyUSB1
Oct  7 12:44:02 iota kernel: sierra3 ttyUSB2: Sierra USB modem (3 port) converter now disconnected from ttyUSB2
Oct  7 12:44:02 iota kernel: sierra 3-1:1.0: device disconnected
---

Can someone let me know how I can debug this so that this will work in
F8 when it is released?

Thanks!


-- 
Anders Karlsson <anders at trudheim.co.uk>
All-Round Linux Tinkerer & RHCE



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct  7 12:26:50 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 7 Oct 2007 14:26:50 +0200
Subject: Why are no packages signed since 12 days?
In-Reply-To: <4708C2A9.8020607@gmx.net>
References: <4708C2A9.8020607@gmx.net>
Message-ID: <20071007142650.2e9447c4.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 07 Oct 2007 13:27:37 +0200, Frank B?ttner wrote:

> Hello,
> when I look at
> http://buildsys.fedoraproject.org/build-status/success.psp
> I must read, that since 12 day no packages have signed.
> Is this an error at the build system or have someone forgot it.

Have you missed the build reports sent to this list and
epel-devel-list?

We have never before updated the plague build-status from "needsign"
to "finished" [1]. That means, what you see has been like that for several
years.

[1] It would likely need additional work in the plague codebase, too.
The signers would need to get plague admin privs and authenticate with
either local copies of their certs on the buildsys machine (less ideal)
or via a shared account or a different interface.



From lkundrak at redhat.com  Sun Oct  7 12:26:51 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 07 Oct 2007 14:26:51 +0200
Subject: gdm Create User
In-Reply-To: <1191709103.14966.71.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191709103.14966.71.camel@localhost.localdomain>
Message-ID: <1191760011.24051.3.camel@localhost.localdomain>


On Sat, 2007-10-06 at 18:18 -0400, Simo Sorce wrote:
> Leaking the information that a user exists or not is considered bad.

Though I do not think that gdm is the right place to create user
accounts, I disagree with this statement.

Knowing that an user exists or not is in principle about the same
dangerous as knowing whether a machine is up or not. Or should we
declare ping to be a security threat?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lkundrak at redhat.com  Sun Oct  7 12:28:03 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 07 Oct 2007 14:28:03 +0200
Subject: gdm Create User
In-Reply-To: <1191696141.3754.6.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
Message-ID: <1191760083.24051.5.camel@localhost.localdomain>


On Sat, 2007-10-06 at 12:42 -0600, Richi Plana wrote:
> How about adding the functionality to create user accounts (local or
> network) at the gdm login screen?

How about adding that functionality to sysvinit? Or grub?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From drago01 at gmail.com  Sun Oct  7 12:37:35 2007
From: drago01 at gmail.com (dragoran)
Date: Sun, 07 Oct 2007 14:37:35 +0200
Subject: Freeze over for Fedora 8 Test 3 - Still in continual development
 freeze
In-Reply-To: <20071003171803.324a63a9@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
Message-ID: <4708D30F.1090206@gmail.com>

Jesse Keating wrote:
> To that end we are now processing F-8 branch requests.
> If you request your package be branched for F-8, a branch will be made
> based on content currently in devel/.  Builds from F-8/ will obviously
> go to the dist-f8 collection and thus rawhide/release. 
will F-8 branches be automaticly created after F8 GA? Or do I have to 
fill cvs request for each of my packages?



From frank-buettner at gmx.net  Sun Oct  7 12:38:58 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 07 Oct 2007 14:38:58 +0200
Subject: Why are no packages signed since 12 days?
In-Reply-To: <20071007142650.2e9447c4.mschwendt.tmp0701.nospam@arcor.de>
References: <4708C2A9.8020607@gmx.net>
	<20071007142650.2e9447c4.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <4708D362.1090101@gmx.net>

Michael Schwendt schrieb:
> On Sun, 07 Oct 2007 13:27:37 +0200, Frank B?ttner wrote:
> 
>> Hello,
>> when I look at
>> http://buildsys.fedoraproject.org/build-status/success.psp
>> I must read, that since 12 day no packages have signed.
>> Is this an error at the build system or have someone forgot it.
> 
> Have you missed the build reports sent to this list and
> epel-devel-list?
No, I have only see the long list of packages:)
> 
> We have never before updated the plague build-status from "needsign"
> to "finished" [1]. That means, what you see has been like that for several
> years.
> 
> [1] It would likely need additional work in the plague codebase, too.
> The signers would need to get plague admin privs and authenticate with
> either local copies of their certs on the buildsys machine (less ideal)
> or via a shared account or a different interface.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/c54db964/attachment.bin>

From mattdm at mattdm.org  Sun Oct  7 12:58:32 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 7 Oct 2007 08:58:32 -0400
Subject: gdm Create User
In-Reply-To: <1191760011.24051.3.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
Message-ID: <20071007125832.GA22092@jadzia.bu.edu>

On Sun, Oct 07, 2007 at 02:26:51PM +0200, Lubomir Kundrak wrote:
> Knowing that an user exists or not is in principle about the same
> dangerous as knowing whether a machine is up or not. Or should we
> declare ping to be a security threat?

This isn't true. Many attack vectors require knowing an exist account name.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jkeating at redhat.com  Sun Oct  7 12:58:05 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 7 Oct 2007 08:58:05 -0400
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
 development freeze
In-Reply-To: <3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
	<3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
Message-ID: <20071007085805.38b4d698@redhat.com>

On Sun, 7 Oct 2007 09:36:18 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> I have requested and received a F-8 branch for most of my packages.
> Now in the interim period before the Fedora 8 final stable release,
> how do I handle updates. Previously I would do a cvs commit && make
> tag build for the F-7 and devel branches. If I leave the F-8 branches
> untouched till the release, will stuff from devel automatically get
> included in Fedora 8 when it comes out? Or I need to tag and build for
> F-8 too?

If you asked for a Fedora 8 branch, then builds from your devel/ branch
will be held in waiting for the next rawhide cycle (Fedora 9).  If you
want to build something for Fedora 8 you need to build it on the F-8/
branch.  Until we reach the final freeze builds from F-8 will go
directly into rawhide and Fedora 8.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/3d3e259e/attachment.sig>

From jkeating at redhat.com  Sun Oct  7 13:00:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 7 Oct 2007 09:00:26 -0400
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
 development freeze
In-Reply-To: <4708D30F.1090206@gmail.com>
References: <20071003171803.324a63a9@redhat.com> <4708D30F.1090206@gmail.com>
Message-ID: <20071007090026.09fd969e@redhat.com>

On Sun, 07 Oct 2007 14:37:35 +0200
dragoran <drago01 at gmail.com> wrote:

> will F-8 branches be automaticly created after F8 GA? Or do I have to 
> fill cvs request for each of my packages?

When we reach final freeze, all packages that haven't yet been branched
will be branched for you.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/990d99d0/attachment.sig>

From debarshi.ray at gmail.com  Sun Oct  7 13:33:30 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 7 Oct 2007 19:03:30 +0530
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
	development freeze
In-Reply-To: <20071007085805.38b4d698@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
	<3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
	<20071007085805.38b4d698@redhat.com>
Message-ID: <3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>

Thanks for the explanation.

> If you want to build something for Fedora 8 you need to build it on the
> F-8/ branch.

Do we need to add updates to the F-8 branch in Bodhi before final
Fedora 8 freeze or release?

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct  7 13:37:36 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 7 Oct 2007 15:37:36 +0200
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
 development freeze
In-Reply-To: <3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
	<3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
	<20071007085805.38b4d698@redhat.com>
	<3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>
Message-ID: <20071007153736.d8a1bc30.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 7 Oct 2007 19:03:30 +0530, Debarshi 'Rishi' Ray wrote:

> Thanks for the explanation.
> 
> > If you want to build something for Fedora 8 you need to build it on the
> > F-8/ branch.
> 
> Do we need to add updates to the F-8 branch in Bodhi before final
> Fedora 8 freeze or release?

No.



From jkeating at redhat.com  Sun Oct  7 13:53:21 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 7 Oct 2007 09:53:21 -0400
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
 development freeze
In-Reply-To: <3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
	<3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
	<20071007085805.38b4d698@redhat.com>
	<3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>
Message-ID: <20071007095321.34e16d0e@redhat.com>

On Sun, 7 Oct 2007 19:03:30 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> Do we need to add updates to the F-8 branch in Bodhi before final
> Fedora 8 freeze or release?


No.  Bodhi will start taking F8 updates once we reach the final freeze,
and builds from the F-8 branch will be directed to the
updates-candidate collection at that time.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/59546930/attachment.sig>

From debarshi.ray at gmail.com  Sun Oct  7 13:58:57 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 7 Oct 2007 19:28:57 +0530
Subject: Freeze over for Fedora 8 Test 3 - Still in continual
	development freeze
In-Reply-To: <20071007095321.34e16d0e@redhat.com>
References: <20071003171803.324a63a9@redhat.com>
	<3170f42f0710040026m7100dd06s59b65d14b6b302f2@mail.gmail.com>
	<20071004062916.75dbec15@redhat.com>
	<3170f42f0710062106k778724e9l5cba23dd498f36c4@mail.gmail.com>
	<20071007085805.38b4d698@redhat.com>
	<3170f42f0710070633q52dfd7cat575bac8601aa090f@mail.gmail.com>
	<20071007095321.34e16d0e@redhat.com>
Message-ID: <3170f42f0710070658q454ecfa3p2b15537df117ade3@mail.gmail.com>

> No.  Bodhi will start taking F8 updates once we reach the final freeze,
> and builds from the F-8 branch will be directed to the
> updates-candidate collection at that time.

Thanks again.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sgrubb at redhat.com  Sun Oct  7 14:00:10 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Oct 2007 10:00:10 -0400
Subject: gdm Create User
In-Reply-To: <1191760011.24051.3.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
Message-ID: <200710071000.10731.sgrubb@redhat.com>

On Sunday 07 October 2007 08:26:51 Lubomir Kundrak wrote:
> > Leaking the information that a user exists or not is considered bad.
>
> Though I do not think that gdm is the right place to create user
> accounts, I disagree with this statement.
>
> Knowing that an user exists or not is in principle about the same
> dangerous as knowing whether a machine is up or not.

Remember all the times that login programs or pam have been updated to fix 
timing attacks that sometimes reveal whether an account is valid? Let me show 
you one to refresh your memory (there are more):

http://marc.info/?l=bugtraq&m=105172058404810&w=2

A successful account breach requires 3 things: a machine name, a valid 
account, and the password. Letting people know that an account is valid cuts 
the attack down to a dictionary attack.

-Steve



From ssorce at redhat.com  Sun Oct  7 14:33:49 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 07 Oct 2007 10:33:49 -0400
Subject: gdm Create User
In-Reply-To: <1191720912.7237.6.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191708767.14966.64.camel@localhost.localdomain>
	<1191720912.7237.6.camel@localhost6.localdomain6>
Message-ID: <1191767629.14966.75.camel@localhost.localdomain>

On Sat, 2007-10-06 at 19:35 -0600, Richi Plana wrote:
> I used to work at a company where Windows and Active Directory was the
> standard. Each time a new employee would be given a desktop, the
> system
> administrator would either log on as network admin from the machine he
> was installing or go back to his terminal to create the user account. 

Well, maybe in small companies, they can think of doing something lie
that.
But in big organizations most of the time the admin that install or
deploy computers does not have the right to create accounts. And most of
the time accounts are generated by the HR department and added in the
system by scripts or meta directories.

Simo.



From ssorce at redhat.com  Sun Oct  7 14:37:28 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 07 Oct 2007 10:37:28 -0400
Subject: gdm Create User
In-Reply-To: <1191760011.24051.3.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
Message-ID: <1191767848.14966.78.camel@localhost.localdomain>

On Sun, 2007-10-07 at 14:26 +0200, Lubomir Kundrak wrote:
> On Sat, 2007-10-06 at 18:18 -0400, Simo Sorce wrote:
> > Leaking the information that a user exists or not is considered bad.
> 
> Though I do not think that gdm is the right place to create user
> accounts, I disagree with this statement.
> 
> Knowing that an user exists or not is in principle about the same
> dangerous as knowing whether a machine is up or not. Or should we
> declare ping to be a security threat?

Don't ask me, I do not agree with it :), as discovering user information
is usually very easy anyway, I just reported what many security
"experts" say or have said and how it is implemented in a lot of
software where returning "User not Found" has been replace in time.

Simo.



From nicolas.mailhot at laposte.net  Sun Oct  7 14:37:55 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Oct 2007 16:37:55 +0200
Subject: gdm Create User
In-Reply-To: <200710071000.10731.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
	<200710071000.10731.sgrubb@redhat.com>
Message-ID: <1191767875.25813.14.camel@rousalka.dyndns.org>


Le dimanche 07 octobre 2007 ? 10:00 -0400, Steve Grubb a ?crit :

> A successful account breach requires 3 things: a machine name, a valid 
> account, and the password. Letting people know that an account is valid cuts 
> the attack down to a dictionary attack.

However account names are terribly predictible anyway, so hiding them
helps little. Script kiddies routinely scan ssh ports with common
surnames, hoping to find accounts with no passwords.

Also a lot of people use account names in public mails, so?

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

From lkundrak at redhat.com  Sun Oct  7 15:33:45 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 07 Oct 2007 17:33:45 +0200
Subject: gdm Create User
In-Reply-To: <200710071000.10731.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
	<200710071000.10731.sgrubb@redhat.com>
Message-ID: <1191771225.24051.10.camel@localhost.localdomain>


On Sun, 2007-10-07 at 10:00 -0400, Steve Grubb wrote:
> On Sunday 07 October 2007 08:26:51 Lubomir Kundrak wrote:
> > > Leaking the information that a user exists or not is considered bad.
> >
> > Though I do not think that gdm is the right place to create user
> > accounts, I disagree with this statement.
> >
> > Knowing that an user exists or not is in principle about the same
> > dangerous as knowing whether a machine is up or not.
> 
> Remember all the times that login programs or pam have been updated to fix 
> timing attacks that sometimes reveal whether an account is valid? Let me show 
> you one to refresh your memory (there are more):
> 
> http://marc.info/?l=bugtraq&m=105172058404810&w=2
> 
> A successful account breach requires 3 things: a machine name, a valid 
> account, and the password. Letting people know that an account is valid cuts 
> the attack down to a dictionary attack.

So what about trying to hide the machine name? This is plain nonsense.
Time that was spent avoiding timing `attacks' was wasted. The _password_
is meant to be a key that is to be hidden, not the account name. If
anything, dictionary attacks can be done against the username-password
pair also.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicolas.mailhot at laposte.net  Sun Oct  7 15:39:01 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 07 Oct 2007 17:39:01 +0200
Subject: gdm Create User
In-Reply-To: <1191771225.24051.10.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
Message-ID: <1191771541.26738.1.camel@rousalka.dyndns.org>


Le dimanche 07 octobre 2007 ? 17:33 +0200, Lubomir Kundrak a ?crit :

> So what about trying to hide the machine name? This is plain nonsense.

It's sort of useful when you have common system accounts with well-known
default passwords. But even then attackers would probably just try them
instead of checking if the account is live first

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

From sgrubb at redhat.com  Sun Oct  7 15:43:53 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 7 Oct 2007 11:43:53 -0400
Subject: gdm Create User
In-Reply-To: <1191771225.24051.10.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
Message-ID: <200710071143.54481.sgrubb@redhat.com>

On Sunday 07 October 2007 11:33:45 Lubomir Kundrak wrote:
> > A successful account breach requires 3 things: a machine name, a valid
> > account, and the password. Letting people know that an account is valid
> > cuts the attack down to a dictionary attack.
>
> So what about trying to hide the machine name?

Yes that is a good thing to try, but likely to be exposed. NAT's do some 
degree of protecting this. But this is really not the point of this thread.

> This is plain nonsense. Time that was spent avoiding timing `attacks' was
> wasted. The _password_  is meant to be a key that is to be hidden, not the
> account name. 

No, it is both. This is why face logins are bad in a secure setting.

> If  anything, dictionary attacks can be done against the username-password
> pair also.

Yes that is true. But not having a valid account name doubles the complexity 
and requires you to work even longer.

-Steve



From ssorce at redhat.com  Sun Oct  7 15:52:42 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 07 Oct 2007 11:52:42 -0400
Subject: gdm Create User
In-Reply-To: <200710071143.54481.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
Message-ID: <1191772362.14966.85.camel@localhost.localdomain>

On Sun, 2007-10-07 at 11:43 -0400, Steve Grubb wrote:
> On Sunday 07 October 2007 11:33:45 Lubomir Kundrak wrote:
> > > A successful account breach requires 3 things: a machine name, a valid
> > > account, and the password. Letting people know that an account is valid
> > > cuts the attack down to a dictionary attack.
> >
> > So what about trying to hide the machine name?
> 
> Yes that is a good thing to try, but likely to be exposed. NAT's do some 
> degree of protecting this. But this is really not the point of this thread.

And I really hope you don't advocate NAT as a security feature, please!

/me hates NAT and I hope nobody will be allowed to reintroduce something
like that with IPv6

> > This is plain nonsense. Time that was spent avoiding timing `attacks' was
> > wasted. The _password_  is meant to be a key that is to be hidden, not the
> > account name. 
> 
> No, it is both. This is why face logins are bad in a secure setting.

I think this kind of reasoning make sense only when made in a vacuum. In
most cases the username is just too easy to find out anyway. Trying to
regard it as a secret to protect is just plainly voodoo security IMO, I
concur with Lubomir on this.

> > If  anything, dictionary attacks can be done against the username-password
> > pair also.
> 
> Yes that is true. But not having a valid account name doubles the complexity 
> and requires you to work even longer.

That is a function of username lenght and passord lenght: These 2 cases
show same complexity:
A) 8 char username + 8 char password
b) 16 chars password

Want to bet the odds, make the password longer (make it a passphrase)
and stop caring about the username being public or not.

Simo.

> -Steve
> 



From alan at redhat.com  Sun Oct  7 16:28:33 2007
From: alan at redhat.com (Alan Cox)
Date: Sun, 7 Oct 2007 12:28:33 -0400
Subject: gdm Create User
In-Reply-To: <1191771225.24051.10.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191709103.14966.71.camel@localhost.localdomain>
	<1191760011.24051.3.camel@localhost.localdomain>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
Message-ID: <20071007162833.GA14857@devserv.devel.redhat.com>

On Sun, Oct 07, 2007 at 05:33:45PM +0200, Lubomir Kundrak wrote:
> So what about trying to hide the machine name? This is plain nonsense.

If its a key to something why not ?

> Time that was spent avoiding timing `attacks' was wasted. The _password_
> is meant to be a key that is to be hidden, not the account name. If
> anything, dictionary attacks can be done against the username-password
> pair also.

And the amount of work required grows enormously. I'd refer you to the
cisco VPN flaws which clearly demonstrated there are situations where
hiding the user name is enormously beneficial and made the cracking time
much much longer.

Alan



From alan at redhat.com  Sun Oct  7 16:30:01 2007
From: alan at redhat.com (Alan Cox)
Date: Sun, 7 Oct 2007 12:30:01 -0400
Subject: gdm Create User
In-Reply-To: <200710071143.54481.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
Message-ID: <20071007163001.GB14857@devserv.devel.redhat.com>

On Sun, Oct 07, 2007 at 11:43:53AM -0400, Steve Grubb wrote:
> Yes that is true. But not having a valid account name doubles the complexity 
> and requires you to work even longer.

More than doubles. You've now got to guess two items from the dictionary as
a matching pair. Thats like trying to throw double one rather than a single
one on dice (only these dice are multi-million sided)



From lkundrak at redhat.com  Sun Oct  7 16:41:25 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 07 Oct 2007 18:41:25 +0200
Subject: gdm Create User
In-Reply-To: <20071007163001.GB14857@devserv.devel.redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
	<20071007163001.GB14857@devserv.devel.redhat.com>
Message-ID: <1191775285.24051.14.camel@localhost.localdomain>


On Sun, 2007-10-07 at 12:30 -0400, Alan Cox wrote:
> On Sun, Oct 07, 2007 at 11:43:53AM -0400, Steve Grubb wrote:
> > Yes that is true. But not having a valid account name doubles the complexity 
> > and requires you to work even longer.
> 
> More than doubles. You've now got to guess two items from the dictionary as
> a matching pair. Thats like trying to throw double one rather than a single
> one on dice (only these dice are multi-million sided)

Right. And now add guessing of the machine's address to the complexity
of bruteforcing the login information.

Would the system, where an user would have to know ten passwords and
five usernames be more secure than one, where account is protected just
with the password? If yes, why don't we do that now?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From snecklifter at gmail.com  Sun Oct  7 18:01:14 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Sun, 7 Oct 2007 19:01:14 +0100
Subject: Co-maintaining mono packages
In-Reply-To: <1191578779.4199.11.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
Message-ID: <364d303b0710071101j7d70f295tfe334f5fb164c2fa@mail.gmail.com>

On 05/10/2007, Paul <paul at all-the-johnsons.co.uk> wrote:
>
> Hi,
>
> Currently, mono in rawhide is dropping behind the actual releases which
> is causing problems with the likes of monodevelop being updated and more
> over, stuff I do for work!
>
> Is there anything I need to do to start co-maintaining the mono tree?
>
> TTFN
>
> Paul
> (getting back on his feet at last!)


If any mono bods are interested I have a couple of packages waiting for
review as I'm currently trying to get iFolder accepted.

https://bugzilla.redhat.com/show_bug.cgi?id=283951
https://bugzilla.redhat.com/show_bug.cgi?id=285801

Good to hear you're back in the saddle Paul - you were good enough to help
out with my first package review (Jokosher) which you may remember.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071007/4f7f1223/attachment.htm>

From buildsys at fedoraproject.org  Sun Oct  7 19:41:52 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Sun,  7 Oct 2007 15:41:52 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-07
Message-ID: <20071007194152.366F115212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 8

    bzr-0.91-1.fc6
    bzr-gtk-0.91.0-2.fc6
    bzrtools-0.91.0-1.fc6
    cupsddk-1.2.3-1.fc6
    isomaster-1.1-2.fc6
    ntfs-3g-1.1004-1.fc6
NEW qstars-0.4-3.fc6 : A screensaver simulating planets and asteroids in space
    superiotool-0-0.4.20071006svn2828.fc6


Changes in Fedora Extras 6: 


bzr-0.91-1.fc6
--------------
* Tue Aug 28 2007 Toshio Kuratomi <a.badger at gmail.com> - 0.91-1
- Update to 0.91.
  + Fixes some issues with using tag-enabled branches.

* Tue Aug 28 2007 Toshio Kuratomi <a.badger at gmail.com> - 0.90-1
- Update to 0.90

* Mon Aug 27 2007 Toshio Kuratomi <a.badger at gmail.com> - 0.90-0.1.rc1
- Update to 0.90rc1.
- 0.90 contains some pyrex code to speed things up.  bzr is now arch specific.
- Update license tag.

* Wed Jul 25 2007 Warren Togami <wtogami at redhat.com> - 0.18-1
- Update to 0.18.

* Tue Jun 26 2007 Warren Togami <wtogami at redhat.com>  - 0.17-2
- Update to 0.17.

* Tue May 08 2007 Toshio Kuratomi <toshio at tiki-lounge.com> - 0.16-1
- Update to 0.16.

bzr-gtk-0.91.0-2.fc6
--------------------
* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-2
- Olive must be moved to an arch specific directory as well for now.
  If rpm could have noarch subpackages, this would be fine to leave in
  python_sitelib.
- Disable nautilus extension on FC-6 as it has never been built for FC-6 and
  I don't have an FC-6 box on which to test nautilus integration.

* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-1
- Update to 0.91.0.

* Thu Aug 30 2007 Toshio Kuratomi <a.badger at gmail.com> 0.90.0-2
- Move the plugins manually as distutils doesn't know that bzr is arch
  specific.

* Tue Aug 28 2007 Toshio Kuratomi <a.badger at gmail.com> 0.90.0-1
- Update to 0.90.0.
- Update license tag to the new Licensing Guidelines.
- Bzr is now arch specific so all its plugins have to be as well.

* Wed Jul 25 2007 Warren Togami <wtogami at redhat.com> 0.18.0-1
- Update to 0.18.0.

* Thu Jun 28 2007 Warren Togami <wtogami at redhat.com> 0.17.0-1
- Update to 0.17.0.

* Fri May 11 2007 Toshio Kuratomi <toshio at tiki-lounge.com> 0.16.0-1
- Update to 0.16.0.
- Apply patch to fix traceback in nautilus module.

* Mon Apr 30 2007 Toshio Kuratomi <toshio at tiki-lounge.com> 0.15.2-3
- Add a nautilus subpackage as there's now a nautilus-python package in Fedora.

* Wed Apr 18 2007 Toshio Kuratomi <toshio at tiki-lounge.com> 0.15.2-2
- Fix olive description.

bzrtools-0.91.0-1.fc6
---------------------
* Wed Sep 26 2007 Toshio Kuratomi <a.badger at gmail.com> 0.91.0-1
- Update to 0.91.0.

* Thu Aug 30 2007 Toshio Kuratomi <a.badger at gmail.com> 0.90.0-2
- Move plugin manually since setuptools has no way of knowing that bzr is
  arch specific.
- Disable debuginfo packages.

* Tue Aug 28 2007 Toshio Kuratomi <a.badger at gmail.com> 0.90.0-1
- Update to 0.90.0.
- Fix License tag to conform to the new Licensing Guidelines.
- Bzr is now arch specific so all its plugins have to be as well.

* Wed Jul 25 2007 Warren Togami <wtogami at redhat.com> 0.18.0-1
- Update to 0.18.0.

* Thu Jun 28 2007 Warren Togami <wtogami at redhat.com> 0.17.1-1
- Update to 0.17.1.

cupsddk-1.2.3-1.fc6
-------------------
* Sat Oct 06 2007 Tim Waugh <twaugh at redhat.com> 1.2.3-1
- 1.2.3.  Only change from 1.2.2 is to incorporate build fix.

isomaster-1.1-2.fc6
-------------------
* Wed Aug 29 2007 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.1-2
- added text-editor.sh to find existing GUI text editor

* Wed Aug 29 2007 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.1-1
- updated to 1.1
- a default viewer is called by xdg-open (from xdg-utils)

* Sat Aug 25 2007 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.0-2
- specified licence type (due to a new Licensing Guidelines)

ntfs-3g-1.1004-1.fc6
--------------------
* Sat Oct 06 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1004-1
- bump to 1.1004

qstars-0.4-3.fc6
----------------
* Tue Oct 02 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.4-3
- Minor SPEC changes
- Removed gnome support, appears to be incompatible.

* Tue Oct 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>  0.4-2
- Support xscreensaver, gnome-screensaver as wall as kxscreensaver

* Sat Sep 29 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.4-1
- Initial release

superiotool-0-0.4.20071006svn2828.fc6
-------------------------------------
* Sat Oct 06 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.4.20071006svn2828
- svn ver. 2828 (added support for Winbond W83627HF/F/HG/G, SMSC LPC47M10x,
  ITE IT8661F, SMSC LPC47B387, ITE IT8705F/AF etc)



From arjan at infradead.org  Sun Oct  7 20:02:09 2007
From: arjan at infradead.org (Arjan van de Ven)
Date: Sun, 7 Oct 2007 13:02:09 -0700
Subject: Kernel VMI (Virtual Machine Interface) in F7/F8?
In-Reply-To: <fdp2jf$59a$1@sea.gmane.org>
References: <fdp2jf$59a$1@sea.gmane.org>
Message-ID: <20071007130209.7c148950@laptopd505.fenrus.org>

On Sun, 30 Sep 2007 18:57:17 -0200
Thomas M Steenholdt <tmus at tmus.dk> wrote:

> Hi there...
> 
> It seems (noted in releasenotes) that F7 should have a VMI (Virtual 
> Machine Interface) enabled kernel by default, but from what I can
> find in the .config files it doesn't... Do I need a special kernel
> (i.e. only the XEN kernel has VMI or something) or was it lost in a
> kernel update or...?
> 

there's overhead with paravirt ops though ;)
at one point it was about 5% even in non-virtual environments... no
idea what it's at now.



From kanarip at kanarip.com  Sun Oct  7 20:03:31 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 07 Oct 2007 22:03:31 +0200
Subject: gdm Create User
In-Reply-To: <20071007163001.GB14857@devserv.devel.redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<200710071000.10731.sgrubb@redhat.com>	<1191771225.24051.10.camel@localhost.localdomain>	<200710071143.54481.sgrubb@redhat.com>
	<20071007163001.GB14857@devserv.devel.redhat.com>
Message-ID: <47093B93.7030508@kanarip.com>

Alan Cox wrote:
> On Sun, Oct 07, 2007 at 11:43:53AM -0400, Steve Grubb wrote:
>> Yes that is true. But not having a valid account name doubles the complexity 
>> and requires you to work even longer.
> 
> More than doubles. You've now got to guess two items from the dictionary as
> a matching pair. Thats like trying to throw double one rather than a single
> one on dice (only these dice are multi-million sided)
> 

Right; it's increasing exponentially ;-) Throw in a smart card or any
other third authentication token then calculate the attackers odds ;-)

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From davej at redhat.com  Sun Oct  7 20:08:49 2007
From: davej at redhat.com (Dave Jones)
Date: Sun, 7 Oct 2007 16:08:49 -0400
Subject: Kernel VMI (Virtual Machine Interface) in F7/F8?
In-Reply-To: <20071007130209.7c148950@laptopd505.fenrus.org>
References: <fdp2jf$59a$1@sea.gmane.org>
	<20071007130209.7c148950@laptopd505.fenrus.org>
Message-ID: <20071007200849.GA20749@redhat.com>

On Sun, Oct 07, 2007 at 01:02:09PM -0700, Arjan van de Ven wrote:
 > On Sun, 30 Sep 2007 18:57:17 -0200
 > Thomas M Steenholdt <tmus at tmus.dk> wrote:
 > 
 > > Hi there...
 > > 
 > > It seems (noted in releasenotes) that F7 should have a VMI (Virtual 
 > > Machine Interface) enabled kernel by default, but from what I can
 > > find in the .config files it doesn't... Do I need a special kernel
 > > (i.e. only the XEN kernel has VMI or something) or was it lost in a
 > > kernel update or...?
 > > 
 > 
 > there's overhead with paravirt ops though ;)
 > at one point it was about 5% even in non-virtual environments... no
 > idea what it's at now.

According to the paravirt-ops developers, it should be negligable now,
though I admit to not having seen recent numbers on this myself.

	Dave

-- 
http://www.codemonkey.org.uk



From ssorce at redhat.com  Sun Oct  7 20:14:49 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 07 Oct 2007 16:14:49 -0400
Subject: gdm Create User
In-Reply-To: <20071007163001.GB14857@devserv.devel.redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
	<20071007163001.GB14857@devserv.devel.redhat.com>
Message-ID: <1191788089.14966.87.camel@localhost.localdomain>

On Sun, 2007-10-07 at 12:30 -0400, Alan Cox wrote:
> On Sun, Oct 07, 2007 at 11:43:53AM -0400, Steve Grubb wrote:
> > Yes that is true. But not having a valid account name doubles the complexity 
> > and requires you to work even longer.
> 
> More than doubles. You've now got to guess two items from the dictionary as
> a matching pair. Thats like trying to throw double one rather than a single
> one on dice (only these dice are multi-million sided)

Not really, it is like a doubly long password but with one half very
weak (as it is derived from a name usually). And you have the advantage
that you know which half is weak.

Simo.



From dmc.fedora at filteredperception.org  Sun Oct  7 20:22:12 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 07 Oct 2007 15:22:12 -0500
Subject: gdm Create User
In-Reply-To: <200710071143.54481.sgrubb@redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<200710071000.10731.sgrubb@redhat.com>	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
Message-ID: <47093FF4.8040109@filteredperception.org>

Steve Grubb wrote:
> On Sunday 07 October 2007 11:33:45 Lubomir Kundrak wrote:
>>> A successful account breach requires 3 things: a machine name, a valid
>>> account, and the password. Letting people know that an account is valid
>>> cuts the attack down to a dictionary attack.
>> So what about trying to hide the machine name?
> 
> Yes that is a good thing to try, but likely to be exposed. NAT's do some 
> degree of protecting this. But this is really not the point of this thread.
> 
>> This is plain nonsense. Time that was spent avoiding timing `attacks' was
>> wasted. The _password_  is meant to be a key that is to be hidden, not the
>> account name. 
> 
> No, it is both. This is why face logins are bad in a secure setting.

Since I seem to have helped start this thread with some random comments 
off of my head, including the mistaken assumption that gdm reports 
'invalid username', I'll just say here-

+1 to face logins _providing_ usernames, as opposed to this whole debate 
about 'invalid username' leaking _non-usernames_.  I.e, if people 
actually wanted to implement something like I suggested, i.e. unknown 
username spawning create-user process, then the disabling of the feature 
for security reasons should be advertised right next to the disablement 
of the face-login feature, for the same reasons.

Again, it all boils down to threat models, and the balance of 
convenience with respect to providing the most benefit for what is 
targeted as the default installation.  Thus the question is, for the 
default installation, does the increased vulnerability outweigh the 
increased convenience.  Clearly if face-login is enabled by default, it 
seems like this leakage of non-usernames is not a serious increase in 
vulnerability, as long as it is obvious to disable it at the same time 
and for the same reasons as disabling the face-login feature.

$0.02...

-dmc

"For me, given my threat model and how much my time is worth, life is 
too short for SELinux."



From alan at redhat.com  Sun Oct  7 22:20:42 2007
From: alan at redhat.com (Alan Cox)
Date: Sun, 7 Oct 2007 18:20:42 -0400
Subject: gdm Create User
In-Reply-To: <1191775285.24051.14.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
	<20071007163001.GB14857@devserv.devel.redhat.com>
	<1191775285.24051.14.camel@localhost.localdomain>
Message-ID: <20071007222042.GA24585@devserv.devel.redhat.com>

On Sun, Oct 07, 2007 at 06:41:25PM +0200, Lubomir Kundrak wrote:
> Would the system, where an user would have to know ten passwords and
> five usernames be more secure than one, where account is protected just
> with the password? If yes, why don't we do that now?

I'm sort of scared anybody in a security team would even ask that question
as is.

A system with one common password if the password is good should reduce
the changes of a user forgetting it and the human tendancies to do dumb
things (although there are good arguments that writing it down isn't actually
that dumb in the general case)

Multiple login/password sets means a breach of one system does not trigger
a breach of another. This is why your credit card number isn't a good password
for the local irc server or MUD.

Alan



From mattdm at mattdm.org  Sun Oct  7 22:33:56 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 7 Oct 2007 18:33:56 -0400
Subject: gdm Create User
In-Reply-To: <20071007222042.GA24585@devserv.devel.redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
	<20071007163001.GB14857@devserv.devel.redhat.com>
	<1191775285.24051.14.camel@localhost.localdomain>
	<20071007222042.GA24585@devserv.devel.redhat.com>
Message-ID: <20071007223356.GA2731@jadzia.bu.edu>

On Sun, Oct 07, 2007 at 06:20:42PM -0400, Alan Cox wrote:
> Multiple login/password sets means a breach of one system does not trigger
> a breach of another. This is why your credit card number isn't a good password
> for the local irc server or MUD.

Oh, *now* you tell me.

Just a minute. I have to go call the bank!

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From alan at redhat.com  Sun Oct  7 22:34:37 2007
From: alan at redhat.com (Alan Cox)
Date: Sun, 7 Oct 2007 18:34:37 -0400
Subject: gdm Create User
In-Reply-To: <47093FF4.8040109@filteredperception.org>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<200710071000.10731.sgrubb@redhat.com>
	<1191771225.24051.10.camel@localhost.localdomain>
	<200710071143.54481.sgrubb@redhat.com>
	<47093FF4.8040109@filteredperception.org>
Message-ID: <20071007223437.GD24585@devserv.devel.redhat.com>

On Sun, Oct 07, 2007 at 03:22:12PM -0500, Douglas McClendon wrote:
> Since I seem to have helped start this thread with some random comments 
> username spawning create-user process, then the disabling of the feature 
> for security reasons should be advertised right next to the disablement 
> of the face-login feature, for the same reasons.

Its in the gdm config tool as standard in Gnome

> Again, it all boils down to threat models, and the balance of 
> convenience with respect to providing the most benefit for what is 

In a system with serious threats (or integrity requirements) the PC is
probably in a locked box somewhat remote from you and the login box
says something like "Insert smartcard and type PIN on smartcard reader *ONLY*"



From dmc.fedora at filteredperception.org  Sun Oct  7 22:47:17 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 07 Oct 2007 17:47:17 -0500
Subject: gdm Create User
In-Reply-To: <20071007222042.GA24585@devserv.devel.redhat.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<200710071000.10731.sgrubb@redhat.com>	<1191771225.24051.10.camel@localhost.localdomain>	<200710071143.54481.sgrubb@redhat.com>	<20071007163001.GB14857@devserv.devel.redhat.com>	<1191775285.24051.14.camel@localhost.localdomain>
	<20071007222042.GA24585@devserv.devel.redhat.com>
Message-ID: <470961F5.4010008@filteredperception.org>

Alan Cox wrote:
> On Sun, Oct 07, 2007 at 06:41:25PM +0200, Lubomir Kundrak wrote:
>> Would the system, where an user would have to know ten passwords and
>> five usernames be more secure than one, where account is protected just
>> with the password? If yes, why don't we do that now?
> 
> I'm sort of scared anybody in a security team would even ask that question
> as is.

I assumed s/he was being facetious, and describing a system, not 
compartmentalized with many independent components, but rather just 
comically expanding the login process to require a serial entry of 5 
usernames and 10 passwords.

And yes, I do know how to disable face login.  It appears to be also 
possible from the standard admin->login gui tool, by unchecking the 
'include users from passwd' checkbox.  If I implement the feature I 
described, this is where I would put both it's disable-totally, and 
dont-even-bother-asking-for-root-passwd options.  (as well as the gdm 
text config file of course).

-dmc

"For me, given my threat model and how much my time is worth, life is 
too short for SELinux."  --Ted Ts'o



From sundaram at fedoraproject.org  Sun Oct  7 23:23:34 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 08 Oct 2007 04:53:34 +0530
Subject: Fedora 8 Release Notes - Last Call
Message-ID: <47096A76.8050306@fedoraproject.org>

Hi

According to the Fedora 8 documentation release schedule at 
http://fedoraproject.org/wiki/DocsProject/Schedule/8, Oct 8 is the last 
date before the wiki is frozen and the changes are send to our L10N team 
for translation. Any changes after this date will only be available in 
the web as an update and not be part of the ISO release images.

We have several easy ways to contribute to the release notes described 
at http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process. Help 
us continue to publish the best and most comprehensive release notes.

Rahul



From seandarcy2 at gmail.com  Mon Oct  8 00:17:24 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sun, 07 Oct 2007 20:17:24 -0400
Subject: f8t3 live: no networking on presario 700
Message-ID: <febsul$oim$1@sea.gmane.org>

I have compaq presario 714n notebook, Intel G965 chipset. wireless is 
Broadcom BCM94311MCG mini-pci, which shows up in lspci.

dmesg does not show it. dmesg does show eth0 as RTL8139, the wired lan. 
It also shows:

eth1: link down
ADDRCONF(NETDEVUP): eth1 link is not ready

/var/log/messages shows NetworkManager trying to bring up eth1 as a 
wired device using 8139too.

Nothing about the wireless device.

When booted under Vista, this notebook makes the wireless connection.

I'd file a bug report, but where??

In any event, any suggestions how to get this working by Tuesday.

sean



From kloczek at zie.pg.gda.pl  Mon Oct  8 00:27:42 2007
From: kloczek at zie.pg.gda.pl (=?UTF-8?Q?K=C5=82oczko?= Tomasz)
Date: Mon, 08 Oct 2007 02:27:42 +0200
Subject: Q: Java console redirection applet (Dell DRAC)
Message-ID: <1191803262.3459.6.camel@dhcppc0>


Anyone know something about what is necessary for run Java console
redirection applet in web browser under Fedora ?
Is it possible manage remote consoles under Linux managed by Dell DRACs
or Sun BMCs ? (also boot media redirection)

kloczek




From katzj at redhat.com  Mon Oct  8 00:55:35 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 07 Oct 2007 20:55:35 -0400
Subject: f8t3 live: no networking on presario 700
In-Reply-To: <febsul$oim$1@sea.gmane.org>
References: <febsul$oim$1@sea.gmane.org>
Message-ID: <1191804935.28263.38.camel@localhost.localdomain>

On Sun, 2007-10-07 at 20:17 -0400, sean darcy wrote:
> I have compaq presario 714n notebook, Intel G965 chipset. wireless is 
> Broadcom BCM94311MCG mini-pci, which shows up in lspci.

Broadcom does not make firmware for their wireless cards available in a
freely redistributable form, so Fedora cannot distribute this firmware.
Thus, it cannot work out of the box.  You can generate a firmware file
using the b43-fwcutter utility, but this doesn't help much for the live
environment.  Feel free to request that Broadcom provide freely
redistributable firmware for their wireless products!

Jeremy



From seandarcy2 at gmail.com  Mon Oct  8 01:45:59 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sun, 07 Oct 2007 21:45:59 -0400
Subject: f8t3 live: no networking on presario 700
In-Reply-To: <1191804935.28263.38.camel@localhost.localdomain>
References: <febsul$oim$1@sea.gmane.org>
	<1191804935.28263.38.camel@localhost.localdomain>
Message-ID: <fec24n$3fu$1@sea.gmane.org>

Jeremy Katz wrote:
> On Sun, 2007-10-07 at 20:17 -0400, sean darcy wrote:
>> I have compaq presario 714n notebook, Intel G965 chipset. wireless is 
>> Broadcom BCM94311MCG mini-pci, which shows up in lspci.
> 
> Broadcom does not make firmware for their wireless cards available in a
> freely redistributable form, so Fedora cannot distribute this firmware.
> Thus, it cannot work out of the box.  You can generate a firmware file
> using the b43-fwcutter utility, but this doesn't help much for the live
> environment.  Feel free to request that Broadcom provide freely
> redistributable firmware for their wireless products!
> 
> Jeremy
> 
Well, would this work:

I'm using live to install on a 20gig partition that already has windows 
installed.

Can I install f8 ( from dvd or livecd ), download the fw43-cutter rpm 
under windows, use ntfs-utils to copy to the linux partition, install 
it, and Voila! ??

Is fw43-cutter on the dvd?

sean



From seandarcy2 at gmail.com  Mon Oct  8 01:58:56 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sun, 07 Oct 2007 21:58:56 -0400
Subject: f8t3 Live on ibm a20m: how do I login?
Message-ID: <fec2t0$4tn$1@sea.gmane.org>

Trying to run live cd on something, I've tried to run it on an ibm a20m 
notebook ( 2000 vintage, pentium 3 700mz ).

The gdm throws up the login screen asking for the user name, and says 
user fedora will login in 60 seconds.

The seconds counter decreases, then goes negative - but no login.

Is there some special login? I've tried root.

sean



From seandarcy2 at gmail.com  Mon Oct  8 03:03:38 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sun, 07 Oct 2007 23:03:38 -0400
Subject: f8t3 Live on ibm a20m: how do I login?
In-Reply-To: <fec2t0$4tn$1@sea.gmane.org>
References: <fec2t0$4tn$1@sea.gmane.org>
Message-ID: <fec6ma$cal$1@sea.gmane.org>

sean darcy wrote:
> Trying to run live cd on something, I've tried to run it on an ibm a20m 
> notebook ( 2000 vintage, pentium 3 700mz ).
> 
> The gdm throws up the login screen asking for the user name, and says 
> user fedora will login in 60 seconds.
> 
> The seconds counter decreases, then goes negative - but no login.
> 
> Is there some special login? I've tried root.
> 
> sean
> 

Just to make it clear, I also tried fedora.

sean



From th.springer at gmx.net  Mon Oct  8 03:04:23 2007
From: th.springer at gmx.net (Thomas Springer)
Date: Mon, 08 Oct 2007 05:04:23 +0200
Subject: f8t3 Live on ibm a20m: how do I login?
In-Reply-To: <fec2t0$4tn$1@sea.gmane.org>
References: <fec2t0$4tn$1@sea.gmane.org>
Message-ID: <1191812663.3073.5.camel@localhost.localdomain>

sean darcy:
> Trying to run live cd on something, I've tried to run it on an ibm a20m 
> notebook ( 2000 vintage, pentium 3 700mz ).
> 
> The gdm throws up the login screen asking for the user name, and says 
> user fedora will login in 60 seconds.
> 
> The seconds counter decreases, then goes negative - but no login.

;-). I've not seen this.

> 
> Is there some special login? I've tried root.
> 
> sean
> 


Just enter fedora as username and hit <enter> as mentioned in the
release notes:

http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Live.html#sn-Usage-Information
-------------- 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/20071008/38114529/attachment.sig>

From cjdahlin at ncsu.edu  Mon Oct  8 03:28:02 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Sun, 07 Oct 2007 23:28:02 -0400
Subject: gdm Create User
In-Reply-To: <1191708767.14966.64.camel@localhost.localdomain>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191708767.14966.64.camel@localhost.localdomain>
Message-ID: <4709A3C2.7010204@ncsu.edu>

Simo Sorce wrote:
> On Sat, 2007-10-06 at 12:42 -0600, Richi Plana wrote:
>   
>> How about adding the functionality to create user accounts (local or
>> network) at the gdm login screen?
>>
>> I recently installed F8T3 on one machine without reformatting the /home
>> partition so my user account's home directory keeps moving from one
>> iteration of Fedora to another, but I thought I wanted to see what a
>> default desktop setup looked like. So here I was at gdm and thinking
>> "Why do I have to log in to an account to create an account at the login
>> screen?" Seems pretty logical to add that functionality there. Seems
>> like it would satisfy a lot of home and enterprise use-cases, as well.
>>
>> Thoughts?
>>     
>
> Home?
> Perhaps. Ideally you create all needed accounts at installation anyway.
>
> Enterprise?
> I don't see how, it's not like any user has the root password to create
> their own account. You have to ask an admin which is usually already
> logged in his own system and will just launch a command from there.
>
> Simo.
>
>   

For a long time Fedora offered a "Recovery Console" that was accessible 
from GDM and simply brought up a minimal terminal. What about a similar 
option for a more sophisticated graphical admin tool containing features 
like this one?

--CJD



From mattdm at mattdm.org  Mon Oct  8 04:30:54 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 8 Oct 2007 00:30:54 -0400
Subject: gdm Create User
In-Reply-To: <4709A3C2.7010204@ncsu.edu>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<1191708767.14966.64.camel@localhost.localdomain>
	<4709A3C2.7010204@ncsu.edu>
Message-ID: <20071008043054.GA30068@jadzia.bu.edu>

On Sun, Oct 07, 2007 at 11:28:02PM -0400, Casey Dahlin wrote:
> For a long time Fedora offered a "Recovery Console" that was accessible 
> from GDM and simply brought up a minimal terminal. What about a similar 
> option for a more sophisticated graphical admin tool containing features 
> like this one?

As suggested in another thread, that should be precisely what you get if you
log in as root.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From kzak at redhat.com  Mon Oct  8 07:27:18 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 8 Oct 2007 09:27:18 +0200
Subject: readahead_early.
In-Reply-To: <20071007083220.GA9381@dudweiler.stuttgart.redhat.com>
References: <20071005200221.GA28441@redhat.com> <47086731.5000803@redhat.com>
	<20071007083220.GA9381@dudweiler.stuttgart.redhat.com>
Message-ID: <20071008072718.GA6828@petra.dvoda.cz>

On Sun, Oct 07, 2007 at 10:32:20AM +0200, Florian La Roche wrote:
> > FWIW, on my test box, entirely *disabling* readahead saves 2-4 seconds
> > on boot time... :)

 Unfortunately you're right. I'm really thinking that we need to
 complete remove this package from Fedora 9.

> Shouldn't we then disable it for F8? AFAIK we also wanted to remove
> many other less critical services that are only needed on a low
> percentage of installed systems.

 I agree that readahead_{easy,later} should be disabled by default.

 I'd like to test it on an old HW (for example a laptop with slow HDD)
 and see more bootcharts.

 Volunteers? ...

 # chkconfig readahead_early on
 # chkconfig readahead_later on
 # yum install bootchart
 # reboot
  ...
 # mutt -a /var/log/bootchart.tgz -s "bootchart: <hw description>" kzak at redhat.com

 (For more details: http://www.bootchart.org/.)

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From harald at redhat.com  Mon Oct  8 07:49:00 2007
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 08 Oct 2007 09:49:00 +0200
Subject: F8t3 k3b and sound problems
In-Reply-To: <1191579585.12607.1.camel@scrappy.miketc.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
Message-ID: <4709E0EC.8010902@redhat.com>

Mike Chambers wrote:
> On Fri, 2007-10-05 at 10:48 +0200, Harald Hoyer wrote:
>> Mike Chambers schrieb:
>>> 2 problems that I have found so far with current testing/rawhide, is k3b
>>> not detecting both my cdroms, nor sound able to work.
>>>
>>> Sound is discussed here currently..
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=290151
>>>
>>> k3b problem I haven't seen discussed yet.  I can see the kernel messages
>>> and the cdroms are found.  But k3b nor xcdroast are able to detect them
>>> for whatever reason.
>>>
>>> Any ideas or anyone else?
>>>
>> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00062.html
> 
> [mike at scrappy ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5
> Mapping udi /org/freedesktop/Hal/devices/storage_model_DVDRW_SHW_160P6S
> to device /dev/sr1
> Mapping udi /org/freedesktop/Hal/devices/storage_model_LTR_52327S to
> device /dev/sr0
> /dev/sr1 resolved to /dev/sr1
> (K3bDevice::Device) could not open device /dev/sr1 for reading
>                     (Permission denied)
> could not open device /dev/sr1 (Permission denied)
> /dev/sr0 resolved to /dev/sr0
> (K3bDevice::Device) could not open device /dev/sr0 for reading
>                     (Permission denied)
> could not open device /dev/sr0 (Permission denied)
> Devices:
> ------------------------------
> 
> This is a fresh install, so *I* didn't do anything.  What file/program
> do the permissions pertain to?  What permissions should be set?
> 
> [mike at scrappy dev]$ ls -la sr*
> brw-r----- 1 root disk 11, 0 2007-10-03 21:01 sr0
> brw-r----- 1 root disk 11, 1 2007-10-03 21:01 sr1
> 

Looks like ConsoleKit is not running on your system.



From dan at danny.cz  Mon Oct  8 07:54:52 2007
From: dan at danny.cz (Dan Hor=?ISO-8859-2?Q?=E1?=k)
Date: Mon,  8 Oct 2007 09:54:52 +0200
Subject: readahead_early.
Message-ID: <200710080954.AA2045640840@danny.cz>

> # chkconfig readahead_early on
> # chkconfig readahead_later on
> # yum install bootchart
> # reboot
>  ...
> # mutt -a /var/log/bootchart.tgz -s "bootchart: <hw description>" kzak at redhat.com
>

maybe an ideal situation for usage of smolt profiles?

Dan



From aportal at univ-montp2.fr  Mon Oct  8 07:56:38 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 8 Oct 2007 09:56:38 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <20071006111626.e927f0cc.mschwendt.tmp0701.nospam@arcor.de>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<200710052120.05292.alain.portal@free.fr>
	<20071006111626.e927f0cc.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200710080956.38846.aportal@univ-montp2.fr>

Le Saturday 06 October 2007 11:16:26 Michael Schwendt, vous avez ?crit?:
> On Fri, 5 Oct 2007 21:20:02 +0200, Alain PORTAL wrote:
> > Le mardi 02 octobre 2007, Patrice Dumas a ?crit :
> > > On Tue, Oct 02, 2007 at 11:29:47AM +0200, Alain PORTAL wrote:
> > > > Hi,
> > > >
> > > > PikLoops failed to build on ppc arch for FC-6 because aclocal-1.9 and
> > > > automake-1.9 were not found:
> > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36512-pikloops
> > > >-0.2 .4-1.fc6/
> > > >
> > > > Can somebody help me to fix?
> > >
> > > There is more than one way to fix such issues,
> >
> > I found one, I'll exclude ppc arch
>
> Your package is broken, resp. the upstream tarball is broken. A
> tarball user running the configure script should not need autotools
> for building the software.
>
> You don't "BuildRequires: automake" either:

Humm... Sorry.
Previously, I "BuildRequires: automake", but it seems I made a mistake and I 
removed it...

Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From buildsys at redhat.com  Mon Oct  8 09:31:31 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 8 Oct 2007 05:31:31 -0400
Subject: rawhide report: 20071008 changes
Message-ID: <200710080931.l989VVNE007407@porkchop.devel.redhat.com>

 

 
Updated Packages:

amarok-1.4.7-7.fc8
------------------
* Sun Oct 07 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-7
- use xdg-open to start the configured browser

* Sat Oct 06 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-6
- add "alpha" to the list of archs where HelixPlayer is not available
  (bug 318431)

* Fri Sep 28 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-5
- add patch 1 to fix Fedora bug 242862: Amarok doesn't support transfer
  of Unicode filenames to MTP devices

blobby-0.6-0.7.a.fc8
--------------------
* Sun Oct 07 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.6-0.7.a
- detect OpenGL using opengl-games-utils

gnome-password-generator-1.5-2.fc8
----------------------------------
* Sat Oct 06 2007 Debarshi Ray <rishi at fedoraproject.org> - 1.5-2
- Removed 'Requires: redhat-artwork' and fixed the sources. Closes Red Hat
  Bugzilla bug #313981.

gnome-theme-clearlooks-bigpack-0.6-6.fc8
----------------------------------------
* Sun Oct 07 2007 Peter Gordon <peter at thecodergeek.com> - 0.6-6
- Add some sed invocations at build-time to remove unused menuitemstyle,
  listviewitemstyle, progressbarstyle, and sunkenmenu configuration options.
- Resolves: bug 242031 (Clearlooks bigpack warnings)
- Clarify License version (GPL+) for compliance with new Licensing guidelines.

grisbi-0.5.9-4.fc8
------------------
* Sun Oct 07 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.5.9-4
- use xdg-open instead of htmlview

kdebluetooth-1.0-0.34.beta8.fc8
-------------------------------
* Sat Oct 06 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-34.beta8
- Beta8. (First official release since beta3)
- Remove redundant beta3 patches.
- LANG support by Ville Skytta.
- Virtual provides: dbus-bluez-pin-helper.

keepassx-0.2.2-4.fc8
--------------------
* Sun Oct 07 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.2.2-4
- use xdg-open instead of htmlview
module-init-tools-3.4-2.fc8
---------------------------
* Sun Oct 07 2007 Jon Masters <jcm at redhat.com> - 3.4-2
- Rebase to latest upstream release.
- Sychronize weak-modules with RHEL.

Broken deps for i386
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	rpy - 1.0-0.2.RC3.fc8.i386 requires R = 0:2.5.1



Broken deps for x86_64
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	rpy - 1.0-0.2.RC3.fc8.x86_64 requires R = 0:2.5.1



Broken deps for ppc
----------------------------------------------------------
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	rpy - 1.0-0.2.RC3.fc8.ppc requires R = 0:2.5.1



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	rpy - 1.0-0.2.RC3.fc8.ppc64 requires R = 0:2.5.1
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From spng.yang at gmail.com  Mon Oct  8 10:01:00 2007
From: spng.yang at gmail.com (Ken YANG)
Date: Mon, 08 Oct 2007 18:01:00 +0800
Subject: A lot of selinux execstack denials in rawhide when starting
 audio apps
In-Reply-To: <1191065377.30523.47.camel@localhost.localdomain>
References: <1191065377.30523.47.camel@localhost.localdomain>
Message-ID: <4709FFDC.5080608@gmail.com>

Martin Sourada wrote:
> Hi,
> 
> I enabled SELinux for the first time and I got a lot of execstack
> denials when starting applications providing audio output (so far I got
> it with listen, rhythmbox, totem and gxine). I have new clean install
> from latest rawhide live (plus some additional applications). Are these
> worth filling bugs or are they false positives? I attach an output from
> this denial for listen music player. I didn't do any actions to fix
> these denials and the applications seem to work OK. I have SELinux
> policy set to enforcing. If you need more info, ask. Not sure whether
> this is for test or devel list so CC-ing devel.

do you relabel your file system when enabling selinux from disable to
enforcing?

your label of python is wrong, it should be bin_t

by the way, you should send this kind of mails to fedora-selinux

> 
> Thanks,
> Martin
> 



From dwalsh at redhat.com  Mon Oct  8 11:44:17 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 08 Oct 2007 07:44:17 -0400
Subject: A lot of selinux execstack denials in rawhide when starting
 audio apps
In-Reply-To: <4709FFDC.5080608@gmail.com>
References: <1191065377.30523.47.camel@localhost.localdomain>
	<4709FFDC.5080608@gmail.com>
Message-ID: <470A1811.5030405@redhat.com>

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

Ken YANG wrote:
> Martin Sourada wrote:
>> Hi,
>>
>> I enabled SELinux for the first time and I got a lot of execstack
>> denials when starting applications providing audio output (so far I got
>> it with listen, rhythmbox, totem and gxine). I have new clean install
>> from latest rawhide live (plus some additional applications). Are these
>> worth filling bugs or are they false positives? I attach an output from
>> this denial for listen music player. I didn't do any actions to fix
>> these denials and the applications seem to work OK. I have SELinux
>> policy set to enforcing. If you need more info, ask. Not sure whether
>> this is for test or devel list so CC-ing devel.
> 
> do you relabel your file system when enabling selinux from disable to
> enforcing?
> 
> your label of python is wrong, it should be bin_t
> 
> by the way, you should send this kind of mails to fedora-selinux
> 
>> Thanks,
>> Martin
>>
> 
Yes please file any execstack avc's with the appropriate application,
and cc me.  You can turn off the execstack protections in order to get
the apps working by executing

setsebool -P allow_execstack 1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHChgRrlYvE4MpobMRAvT+AJ9ZKzQjhKIiEVJvJE5Z6hne6z0PrACg2ikv
vJqcFqcExiCe+v9LlqYeMxU=
=l8IG
-----END PGP SIGNATURE-----



From seandarcy2 at gmail.com  Mon Oct  8 12:42:57 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Mon, 08 Oct 2007 08:42:57 -0400
Subject: f8t3 Live on ibm a20m: how do I login?
In-Reply-To: <1191812663.3073.5.camel@localhost.localdomain>
References: <fec2t0$4tn$1@sea.gmane.org>
	<1191812663.3073.5.camel@localhost.localdomain>
Message-ID: <fed8kh$e0v$1@sea.gmane.org>

Thomas Springer wrote:
> sean darcy:
>> Trying to run live cd on something, I've tried to run it on an ibm a20m 
>> notebook ( 2000 vintage, pentium 3 700mz ).
>>
>> The gdm throws up the login screen asking for the user name, and says 
>> user fedora will login in 60 seconds.
>>
>> The seconds counter decreases, then goes negative - but no login.
> 
> ;-). I've not seen this.
> 
>> Is there some special login? I've tried root.
>>
>> sean
>>
> 
> 
> Just enter fedora as username and hit <enter> as mentioned in the
> release notes:
> 
> http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Live.html#sn-Usage-Information
> 

I did that. Also tried root.

Then I edited the grub login to init 3. I logged in at the command line 
as fedora ( root also works ).

It died at startx. It showed creating three xauth, then just hung.

FWIW, knoppix works fine.

I'd file a bug, but under what?

sean



From kzak at redhat.com  Mon Oct  8 13:08:17 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 8 Oct 2007 15:08:17 +0200
Subject: readahead_early.
In-Reply-To: <20071005200221.GA28441@redhat.com>
References: <20071005200221.GA28441@redhat.com>
Message-ID: <20071008130817.GA3866@petra.dvoda.cz>

On Fri, Oct 05, 2007 at 04:02:21PM -0400, Dave Jones wrote:
> Right now we're running readahead early way too late.
> At a time when we've just sat doing no IO at all for 10
> seconds whilst (amongst other things) we waited for a
> DHCP lease.   We're also running it at a time when
> we're competing for disk bandwidth with other processes.
> The result is that disabling the service completely shows
> no change in boot time at all.
> http://www.codemonkey.org.uk/junk/bootchart-before.png
> 
> Moving the readahead_early service to start really early
> wins back 4 seconds of boot up time.
> http://www.codemonkey.org.uk/junk/bootchart-after.png

 Please, define "really early".

 I have (workstation, F7, 2GB RAM):

   - /etc/rc5.d/S01readahead_early

   - /etc/readahead.d/custom.early
     (generated by readahead-collector from F8)

   - only one readahaed list 
     (merged .early and .later lists)

 results (readahead on/off):

 http://people.redhat.com/kzak/readahead/f7-on.png
 http://people.redhat.com/kzak/readahead/f7-off.png

 .. so nothing useful :-(

> Any reason not to change this for F8 ?

 I don't believe that readahead is able to really improve Fedora boot
 time.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From mike at miketc.com  Mon Oct  8 13:22:24 2007
From: mike at miketc.com (Mike Chambers)
Date: Mon, 08 Oct 2007 08:22:24 -0500
Subject: [SOLVED] F8t3 k3b and sound problems
In-Reply-To: <4709E0EC.8010902@redhat.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
	<4709E0EC.8010902@redhat.com>
Message-ID: <1191849744.2204.1.camel@scrappy.miketc.com>

On Mon, 2007-10-08 at 09:49 +0200, Harald Hoyer wrote:
> Mike Chambers wrote:
> > On Fri, 2007-10-05 at 10:48 +0200, Harald Hoyer wrote:
> >> Mike Chambers schrieb:
> >>> 2 problems that I have found so far with current testing/rawhide, is k3b
> >>> not detecting both my cdroms, nor sound able to work.
> >>>
> >>> Sound is discussed here currently..
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=290151
> >>>
> >>> k3b problem I haven't seen discussed yet.  I can see the kernel messages
> >>> and the cdroms are found.  But k3b nor xcdroast are able to detect them
> >>> for whatever reason.
> >>>
> >>> Any ideas or anyone else?
> >>>
> >> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00062.html
> > 
> > [mike at scrappy ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5
> > Mapping udi /org/freedesktop/Hal/devices/storage_model_DVDRW_SHW_160P6S
> > to device /dev/sr1
> > Mapping udi /org/freedesktop/Hal/devices/storage_model_LTR_52327S to
> > device /dev/sr0
> > /dev/sr1 resolved to /dev/sr1
> > (K3bDevice::Device) could not open device /dev/sr1 for reading
> >                     (Permission denied)
> > could not open device /dev/sr1 (Permission denied)
> > /dev/sr0 resolved to /dev/sr0
> > (K3bDevice::Device) could not open device /dev/sr0 for reading
> >                     (Permission denied)
> > could not open device /dev/sr0 (Permission denied)
> > Devices:
> > ------------------------------
> > 
> > This is a fresh install, so *I* didn't do anything.  What file/program
> > do the permissions pertain to?  What permissions should be set?
> > 
> > [mike at scrappy dev]$ ls -la sr*
> > brw-r----- 1 root disk 11, 0 2007-10-03 21:01 sr0
> > brw-r----- 1 root disk 11, 1 2007-10-03 21:01 sr1
> > 
> 
> Looks like ConsoleKit is not running on your system.

Welp, turning on Consolekit and a quick reboot and BOTH k3b and my sound
now seem to work.  So this *has* to be on for those type devices
(removable and so on?) to work?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jkeating at redhat.com  Mon Oct  8 13:33:51 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 09:33:51 -0400
Subject: [SOLVED] F8t3 k3b and sound problems
In-Reply-To: <1191849744.2204.1.camel@scrappy.miketc.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<4705FA4B.4010503@redhat.com>
	<1191579585.12607.1.camel@scrappy.miketc.com>
	<4709E0EC.8010902@redhat.com>
	<1191849744.2204.1.camel@scrappy.miketc.com>
Message-ID: <20071008093351.1592a8e5@redhat.com>

On Mon, 08 Oct 2007 08:22:24 -0500
Mike Chambers <mike at miketc.com> wrote:

> Welp, turning on Consolekit and a quick reboot and BOTH k3b and my
> sound now seem to work.  So this *has* to be on for those type devices
> (removable and so on?) to work?

ConsoleKit and PolicyKit work together to assign ACLs to the devices
for the active console user.  If it isn't running, the ACLs won't be
applied and you won't have access to use them.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/f0616256/attachment.sig>

From debarshi.ray at gmail.com  Mon Oct  8 13:39:28 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 8 Oct 2007 19:09:28 +0530
Subject: Pushing updates in Bodhi
Message-ID: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>

https://admin.fedoraproject.org/updates/F7/pending/bouml-2.31.3-1.fc7

It has been 4 days since I requested the above update to be pushed to
testing. I see that there are 84 pending updates. So has something
changed with the way updates are pushed through Bodhi?

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lmacken at redhat.com  Mon Oct  8 13:54:18 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 8 Oct 2007 09:54:18 -0400
Subject: Pushing updates in Bodhi
In-Reply-To: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
References: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
Message-ID: <20071008135418.GB3722@crow.boston.redhat.com>

On Mon, Oct 08, 2007 at 07:09:28PM +0530, Debarshi 'Rishi' Ray wrote:
> https://admin.fedoraproject.org/updates/F7/pending/bouml-2.31.3-1.fc7
> 
> It has been 4 days since I requested the above update to be pushed to
> testing. I see that there are 84 pending updates. So has something
> changed with the way updates are pushed through Bodhi?

No, nothing has changed.  jkeating, who signs the updates, has been out
of town for the past few days.  I'll try and get an ETA for the next
push.

luke



From lmacken at redhat.com  Mon Oct  8 13:58:12 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 8 Oct 2007 09:58:12 -0400
Subject: Pushing updates in Bodhi
In-Reply-To: <20071008135418.GB3722@crow.boston.redhat.com>
References: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
	<20071008135418.GB3722@crow.boston.redhat.com>
Message-ID: <20071008135812.GC3722@crow.boston.redhat.com>

On Mon, Oct 08, 2007 at 09:54:18AM -0400, Luke Macken wrote:
> On Mon, Oct 08, 2007 at 07:09:28PM +0530, Debarshi 'Rishi' Ray wrote:
> > https://admin.fedoraproject.org/updates/F7/pending/bouml-2.31.3-1.fc7
> > 
> > It has been 4 days since I requested the above update to be pushed to
> > testing. I see that there are 84 pending updates. So has something
> > changed with the way updates are pushed through Bodhi?
> 
> No, nothing has changed.  jkeating, who signs the updates, has been out
> of town for the past few days.  I'll try and get an ETA for the next
> push.

The next batch of updates is getting pushed as we speak.

luke



From jkeating at redhat.com  Mon Oct  8 13:57:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 09:57:32 -0400
Subject: Pushing updates in Bodhi
In-Reply-To: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
References: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
Message-ID: <20071008095732.6eabb09a@redhat.com>

On Mon, 8 Oct 2007 19:09:28 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> https://admin.fedoraproject.org/updates/F7/pending/bouml-2.31.3-1.fc7
> 
> It has been 4 days since I requested the above update to be pushed to
> testing. I see that there are 84 pending updates. So has something
> changed with the way updates are pushed through Bodhi?


No, I've just been on vacation and wasn't able to get enough computer
time at once to do the pushing until this morning.  A push of updates
are being composed now.

Work is progressing on the signing server to allow more than just me to
push updates.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/2cfb3e41/attachment.sig>

From orion at cora.nwra.com  Mon Oct  8 15:36:56 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 08 Oct 2007 09:36:56 -0600
Subject: Mock x86_64/i386 build issues
Message-ID: <470A4E98.4020200@cora.nwra.com>

I'm having trouble building some i386 packages (rpm, anaconda) on my 
x86_64 machine with mock.  It seems that the build process picks up that 
the processor in x86_64.  How does koji or anyone else handle this?

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From skvidal at fedoraproject.org  Mon Oct  8 15:37:45 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 08 Oct 2007 11:37:45 -0400
Subject: Mock x86_64/i386 build issues
In-Reply-To: <470A4E98.4020200@cora.nwra.com>
References: <470A4E98.4020200@cora.nwra.com>
Message-ID: <1191857865.6741.170.camel@cutter>


On Mon, 2007-10-08 at 09:36 -0600, Orion Poplawski wrote:
> I'm having trouble building some i386 packages (rpm, anaconda) on my 
> x86_64 machine with mock.  It seems that the build process picks up that 
> the processor in x86_64.  How does koji or anyone else handle this?
> 

cat /etc/rpm/platform

if it is there remove it.

-sv




From davej at redhat.com  Mon Oct  8 15:47:28 2007
From: davej at redhat.com (Dave Jones)
Date: Mon, 8 Oct 2007 11:47:28 -0400
Subject: readahead_early.
In-Reply-To: <20071008130817.GA3866@petra.dvoda.cz>
References: <20071005200221.GA28441@redhat.com>
	<20071008130817.GA3866@petra.dvoda.cz>
Message-ID: <20071008154728.GA12691@redhat.com>

On Mon, Oct 08, 2007 at 03:08:17PM +0200, Karel Zak wrote:
 > On Fri, Oct 05, 2007 at 04:02:21PM -0400, Dave Jones wrote:
 > > Right now we're running readahead early way too late.
 > > At a time when we've just sat doing no IO at all for 10
 > > seconds whilst (amongst other things) we waited for a
 > > DHCP lease.   We're also running it at a time when
 > > we're competing for disk bandwidth with other processes.
 > > The result is that disabling the service completely shows
 > > no change in boot time at all.
 > > http://www.codemonkey.org.uk/junk/bootchart-before.png
 > > 
 > > Moving the readahead_early service to start really early
 > > wins back 4 seconds of boot up time.
 > > http://www.codemonkey.org.uk/junk/bootchart-after.png
 > 
 >  Please, define "really early".

I moved it to S01
 
 >  results (readahead on/off):
 > 
 >  http://people.redhat.com/kzak/readahead/f7-on.png
 >  http://people.redhat.com/kzak/readahead/f7-off.png
 > 
 >  .. so nothing useful :-(
 > 
 > > Any reason not to change this for F8 ?
 > 
 >  I don't believe that readahead is able to really improve Fedora boot
 >  time.
 
So over the weekend I reinstalled that test box with test3, and
made the same change to readahead.  This time it didn't make
any difference at all, so I'm inclined to believe you.

Eric Sandeen noted that it actually *slows down* his boot too,
so perhaps switching it off is the best plan.

	Dave

-- 
http://www.codemonkey.org.uk



From billcrawford1970 at gmail.com  Mon Oct  8 16:18:03 2007
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Mon, 8 Oct 2007 17:18:03 +0100
Subject: gdm Create User
In-Reply-To: <1191698830.4271.7.camel@localhost6.localdomain6>
References: <1191696141.3754.6.camel@localhost6.localdomain6>
	<4707DABD.7060107@filteredperception.org>
	<1191698830.4271.7.camel@localhost6.localdomain6>
Message-ID: <544eb990710080918r18719d44j149a721f879731d6@mail.gmail.com>

On 06/10/2007, Richi Plana <myfedora at richip.dhs.org> wrote:

> Well, that certainly sounds like a smart system ... and I'm all for
> computers trying to be smarter than their users (if they can do it
> successfully). But why add a timeout? I'm assuming finding out a list of
> users from the console isn't a security issue (since they're displayed
> as a list by GDM) so why not make the computer think one of two things
> has happened: 1) the user mistyped the username or 2) the user wants to
> create a new user. The system could ask which and ask for the root
> password or directory administrator's password if it was a request for
> the creation of users.

Because if you mistyped, you don't want some dialog popping up, or any
kind of other UI, appearing in place of the username and password
boxes you're about to fill in, again, hopefully with the correct
username and password this time :) without a reasonable delay (given
that someone who's expecting to be allowed to create a guest account
will either wait, or ask the owner of the machine what to do next, or
...).

Actually, how about just having a "create as new account" button
appear, but NOT FOCUSSED BY DEFAULT along with the login failure
message?



From chris.stone at gmail.com  Mon Oct  8 16:19:47 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 09:19:47 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in stable
	release
Message-ID: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>

Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
ExcludeArch: ppc64

He did this on a stable release without blocking any excludearch bugs
or notifiying anyone as far as I can tell!

This has been a real pain for me and I'm a little upset that package
maintainers who depend on OSG-devel were not notified.  If I missed
some email then I apologize.

Is there not some procedure or guideline for adding excludearch on a
package in a stable release?



From devrim at CommandPrompt.com  Mon Oct  8 16:28:48 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Mon, 08 Oct 2007 09:28:48 -0700
Subject: Pushing updates in Bodhi
In-Reply-To: <20071008135418.GB3722@crow.boston.redhat.com>
References: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
	<20071008135418.GB3722@crow.boston.redhat.com>
Message-ID: <1191860928.22874.43.camel@localhost.localdomain>

Hi,

On Mon, 2007-10-08 at 09:54 -0400, Luke Macken wrote:
> jkeating, who signs the updates, has been out of town for the past few
> days. 

Don't we have someone as a backup?

Regards,
-- 
Devrim G?ND?Z
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.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/20071008/60155c9f/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Mon Oct  8 16:39:32 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 8 Oct 2007 18:39:32 +0200
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
Message-ID: <20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 8 Oct 2007 09:19:47 -0700, Christopher Stone wrote:

> Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
> ExcludeArch: ppc64
> 
> He did this on a stable release without blocking any excludearch bugs
> or notifiying anyone as far as I can tell!

Look once more:

* Thu Jun 21 2007 Ralf Cors?pius <rc040203 freenet de> - 1.2-4
 - ExcludeArch: ppc64 (BZ 245192, 245196).

> This has been a real pain for me and I'm a little upset that package
> maintainers who depend on OSG-devel were not notified.  If I missed
> some email then I apologize.
>
> Is there not some procedure or guideline for adding excludearch on a
> package in a stable release?



From sandeen at redhat.com  Mon Oct  8 16:39:51 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Mon, 08 Oct 2007 11:39:51 -0500
Subject: readahead_early.
In-Reply-To: <20071008130817.GA3866@petra.dvoda.cz>
References: <20071005200221.GA28441@redhat.com>
	<20071008130817.GA3866@petra.dvoda.cz>
Message-ID: <470A5D57.2010604@redhat.com>

Karel Zak wrote:

>  I don't believe that readahead is able to really improve Fedora boot
>  time.

I was going to try a few other things with readahead... including using
readahead-collector on my system.  But, booting with that as init=
didn't seem to generate anything.  Is this supposed to work...?

Also, when testing with/without readahead, I realized that I should
probably first manually sort the lists before running any tests, yes?
My original tests were probably on a default unsorted list, which
probably made things look worse than they are.

Thanks,
-Eric



From orion at cora.nwra.com  Mon Oct  8 16:41:56 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 08 Oct 2007 10:41:56 -0600
Subject: Mock x86_64/i386 build issues
In-Reply-To: <1191857865.6741.170.camel@cutter>
References: <470A4E98.4020200@cora.nwra.com> <1191857865.6741.170.camel@cutter>
Message-ID: <470A5DD4.9090805@cora.nwra.com>

seth vidal wrote:
> On Mon, 2007-10-08 at 09:36 -0600, Orion Poplawski wrote:
>> I'm having trouble building some i386 packages (rpm, anaconda) on my 
>> x86_64 machine with mock.  It seems that the build process picks up that 
>> the processor in x86_64.  How does koji or anyone else handle this?
>>
> 
> cat /etc/rpm/platform
> 
> if it is there remove it.

Didn't help.  In the anaconda case:

RPM build errors:
     File not found by glob: 
/var/tmp/anaconda-11.3.0.36-1.cora.1-root-mockbuild/usr/lib/python?.?/site-packages/pyisomd5sum.so
     Installed (but unpackaged) file(s) found:
    /usr/lib64/python2.5/site-packages/pyisomd5sum.so


Installed with:

         install -m 755 pyisomd5sum.so 
$(DESTDIR)/usr/$(LIBDIR)/$(PYTHON)/site-packages

LIBDIR is set with:

FULLARCH := $(shell uname -m)

ifneq (,$(filter ppc64 x86_64 s390x,$(FULLARCH)))
LIBDIR = lib64
else
LIBDIR = lib
endif


$ mock --arch=i386 -r fedora-devel-i386 shell
init
mock-chroot> uname -m
x86_64

Looks like I need setarch?

$ setarch i386 mock --arch=i386 -r fedora-devel-i386 shell
init
mock-chroot> uname -m
i686

Seems like --arch=i386 should take care of this.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From skvidal at fedoraproject.org  Mon Oct  8 16:48:02 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 08 Oct 2007 12:48:02 -0400
Subject: Mock x86_64/i386 build issues
In-Reply-To: <470A5DD4.9090805@cora.nwra.com>
References: <470A4E98.4020200@cora.nwra.com>
	<1191857865.6741.170.camel@cutter>  <470A5DD4.9090805@cora.nwra.com>
Message-ID: <1191862082.6741.173.camel@cutter>


On Mon, 2007-10-08 at 10:41 -0600, Orion Poplawski wrote:
> seth vidal wrote:
> > On Mon, 2007-10-08 at 09:36 -0600, Orion Poplawski wrote:
> >> I'm having trouble building some i386 packages (rpm, anaconda) on my 
> >> x86_64 machine with mock.  It seems that the build process picks up that 
> >> the processor in x86_64.  How does koji or anyone else handle this?
> >>
> > 
> > cat /etc/rpm/platform
> > 
> > if it is there remove it.
> 
> Didn't help.  In the anaconda case:
> 
> RPM build errors:
>      File not found by glob: 
> /var/tmp/anaconda-11.3.0.36-1.cora.1-root-mockbuild/usr/lib/python?.?/site-packages/pyisomd5sum.so
>      Installed (but unpackaged) file(s) found:
>     /usr/lib64/python2.5/site-packages/pyisomd5sum.so
> 
> 
> Installed with:
> 
>          install -m 755 pyisomd5sum.so 
> $(DESTDIR)/usr/$(LIBDIR)/$(PYTHON)/site-packages
> 
> LIBDIR is set with:
> 
> FULLARCH := $(shell uname -m)
> 
> ifneq (,$(filter ppc64 x86_64 s390x,$(FULLARCH)))
> LIBDIR = lib64
> else
> LIBDIR = lib
> endif
> 
> 
> $ mock --arch=i386 -r fedora-devel-i386 shell
> init
> mock-chroot> uname -m
> x86_64
> 
> Looks like I need setarch?
> 
> $ setarch i386 mock --arch=i386 -r fedora-devel-i386 shell
> init
> mock-chroot> uname -m
> i686
> 
> Seems like --arch=i386 should take care of this.
> 

you're not even running 'setarch'? Oh - you have to do that - but no,
--arch= won't run setarch for you b/c

1. it doesn't need to know what your running arch is
2. would it then make sense for it to run qemu if you want to build ppc.

so the order of ops:

1. remove /etc/rpm/platform
2. run inside setarch

-sv




From chris.stone at gmail.com  Mon Oct  8 16:55:44 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 09:55:44 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>

On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> On Mon, 8 Oct 2007 09:19:47 -0700, Christopher Stone wrote:
>
> > Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
> > ExcludeArch: ppc64
> >
> > He did this on a stable release without blocking any excludearch bugs
> > or notifiying anyone as far as I can tell!
>
> Look once more:
>
> * Thu Jun 21 2007 Ralf Cors?pius <rc040203 freenet de> - 1.2-4
>  - ExcludeArch: ppc64 (BZ 245192, 245196).
>
> > This has been a real pain for me and I'm a little upset that package
> > maintainers who depend on OSG-devel were not notified.  If I missed
> > some email then I apologize.
> >
> > Is there not some procedure or guideline for adding excludearch on a
> > package in a stable release?

>From the review guidelines:
 The bug number should then be placed in a comment, next to the
corresponding ExcludeArch line.

That's where I looked, I also checked the bugzilla for
ExcludeArch-ppc64 but didn't look back far enough.  I figured this was
a bug filed recently since the change was just done, apparently this
was filed three months ago!

There has got to be some easier way, is every package maintainer who
uses a devel package supposed to be CC'd on these ExcludeArch bugs?

Why can't we have some easier automated way for devel package
maintainers to notify other package maintainers who depened on their
package when changes like this are made?



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct  8 17:09:51 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 8 Oct 2007 19:09:51 +0200
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
Message-ID: <20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 8 Oct 2007 09:55:44 -0700, Christopher Stone wrote:

> On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> > On Mon, 8 Oct 2007 09:19:47 -0700, Christopher Stone wrote:
> >
> > > Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
> > > ExcludeArch: ppc64
> > >
> > > He did this on a stable release without blocking any excludearch bugs
> > > or notifiying anyone as far as I can tell!
> >
> > Look once more:
> >
> > * Thu Jun 21 2007 Ralf Cors?pius <rc040203 freenet de> - 1.2-4
> >  - ExcludeArch: ppc64 (BZ 245192, 245196).
> >
> > > This has been a real pain for me and I'm a little upset that package
> > > maintainers who depend on OSG-devel were not notified.  If I missed
> > > some email then I apologize.
> > >
> > > Is there not some procedure or guideline for adding excludearch on a
> > > package in a stable release?
> 
> >From the review guidelines:
>  The bug number should then be placed in a comment, next to the
> corresponding ExcludeArch line.
> 
> That's where I looked,

$ pwd
/home/qa/fedora/packages/OpenSceneGraph/FC-6

$ grep -B2 Exc OpenSceneGraph.spec
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# BZ: 245192, 245196
ExcludeArch:    ppc64
--
%changelog
* Thu Jun 21 2007 Ralf Cors?pius <rc040203 at freenet.de> - 1.2-4
- ExcludeArch: ppc64 (BZ 245192, 245196).


Same for F-7.



From chris.stone at gmail.com  Mon Oct  8 17:16:57 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 10:16:57 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>

On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> On Mon, 8 Oct 2007 09:55:44 -0700, Christopher Stone wrote:
>
> > On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> > > On Mon, 8 Oct 2007 09:19:47 -0700, Christopher Stone wrote:
> > >
> > > > Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
> > > > ExcludeArch: ppc64
> > > >
> > > > He did this on a stable release without blocking any excludearch bugs
> > > > or notifiying anyone as far as I can tell!
> > >
> > > Look once more:
> > >
> > > * Thu Jun 21 2007 Ralf Cors?pius <rc040203 freenet de> - 1.2-4
> > >  - ExcludeArch: ppc64 (BZ 245192, 245196).
> > >
> > > > This has been a real pain for me and I'm a little upset that package
> > > > maintainers who depend on OSG-devel were not notified.  If I missed
> > > > some email then I apologize.
> > > >
> > > > Is there not some procedure or guideline for adding excludearch on a
> > > > package in a stable release?
> >
> > >From the review guidelines:
> >  The bug number should then be placed in a comment, next to the
> > corresponding ExcludeArch line.
> >
> > That's where I looked,
>
> $ pwd
> /home/qa/fedora/packages/OpenSceneGraph/FC-6
>
> $ grep -B2 Exc OpenSceneGraph.spec
> BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> # BZ: 245192, 245196
> ExcludeArch:    ppc64
> --
> %changelog
> * Thu Jun 21 2007 Ralf Cors?pius <rc040203 at freenet.de> - 1.2-4
> - ExcludeArch: ppc64 (BZ 245192, 245196).
>
>
> Same for F-7.


Hrm okay I don't know how I missed it, anyway the point is there needs
to be a better way to notify people on changes like this.

There is only one person CC'd on the ppc64 bugzilla, with the current
procedure, every package maintainer who needs a devel package should
be CC'd on these excludearch bugs, no??

Why can't we develop some way for a devel package maintainer to email
package maintainers who buildrequire your devel package?



From rdieter at math.unl.edu  Mon Oct  8 17:02:32 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 08 Oct 2007 12:02:32 -0500
Subject: Mock x86_64/i386 build issues
References: <470A4E98.4020200@cora.nwra.com> <1191857865.6741.170.camel@cutter>
	<470A5DD4.9090805@cora.nwra.com>
Message-ID: <fednr8$b6k$1@sea.gmane.org>

Orion Poplawski wrote:

> seth vidal wrote:
>> On Mon, 2007-10-08 at 09:36 -0600, Orion Poplawski wrote:
>>> I'm having trouble building some i386 packages (rpm, anaconda) on my
>>> x86_64 machine with mock.  It seems that the build process picks up that
>>> the processor in x86_64.  How does koji or anyone else handle this?
>>>
>> 
>> cat /etc/rpm/platform
>> 
>> if it is there remove it.
> 
> Didn't help.  In the anaconda case:

That, and:
setarch i386 mock ...

-- Rex



From chris.stone at gmail.com  Mon Oct  8 17:19:55 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 10:19:55 -0700
Subject: HEADS-UP: openalpp osgal osgcal excludingarch ppc64 on FC-6 F-7 now!
Message-ID: <d9c612bf0710081019x3facef3cp5799197c4072c30@mail.gmail.com>

These packages are now excluding arch ppc64 on F-7 and FC-6:
openalpp, osgal, and osgcal because OSG-devel is no longer available
for these distros.

If you maintain a package which buildrequires any of these devel
packages you will need to ExcludeArch ppc64 now.

https://bugzilla.redhat.com/show_bug.cgi?id=323321
https://bugzilla.redhat.com/show_bug.cgi?id=323331
https://bugzilla.redhat.com/show_bug.cgi?id=323341



From lmacken at redhat.com  Mon Oct  8 17:20:34 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 8 Oct 2007 13:20:34 -0400
Subject: bodhi update problem
In-Reply-To: <20071006182211.GA20108@psilocybe.teonanacatl.org>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
	<20071006073157.GU10067@psilocybe.teonanacatl.org>
	<20071006180628.GD28933@crow.myhome.westell.com>
	<20071006182211.GA20108@psilocybe.teonanacatl.org>
Message-ID: <20071008172034.GE3722@crow.boston.redhat.com>

On Sat, Oct 06, 2007 at 02:22:11PM -0400, Todd Zullinger wrote:
> Luke Macken wrote:
> > I just updated our production bodhi instance.
> 
> Hmmm, I just tried the vorbis-tools update again and I still get the
> same error (I'd just restarted firefox for other reasons, so I had
> logged in freshly to bodhi and started a new update).  Got any ideas
> why that'd still fail?
> 
> Thanks much for working on this.

Fixed!

There was a little bit of backwards logic in the patch

+               filter(lambda x: x in identity.current.groups, groups):

should have been:

+               not filter(lambda x: x in identity.current.groups, groups):


luke



From orion at cora.nwra.com  Mon Oct  8 17:24:27 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 08 Oct 2007 11:24:27 -0600
Subject: Mock x86_64/i386 build issues
In-Reply-To: <1191862082.6741.173.camel@cutter>
References: <470A4E98.4020200@cora.nwra.com>	<1191857865.6741.170.camel@cutter>
	<470A5DD4.9090805@cora.nwra.com> <1191862082.6741.173.camel@cutter>
Message-ID: <470A67CB.1010209@cora.nwra.com>

seth vidal wrote:
> you're not even running 'setarch'? Oh - you have to do that - but no,
> --arch= won't run setarch for you b/c
> 
> 1. it doesn't need to know what your running arch is
> 2. would it then make sense for it to run qemu if you want to build ppc.
> 
> so the order of ops:
> 
> 1. remove /etc/rpm/platform
> 2. run inside setarch
> 
> -sv
> 
> 

Sorry, should have read
http://fedoraproject.org/wiki/PackageMaintainers/MockTricks?highlight=%28mock%29%7C%28setarch%29#head-d06dc48ddb22d925bbe184b74661ca7754f574e3

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From tmz at pobox.com  Mon Oct  8 17:26:18 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 8 Oct 2007 13:26:18 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
Message-ID: <20071008172617.GE32528@psilocybe.teonanacatl.org>

Christopher Stone wrote:
> Why can't we develop some way for a devel package maintainer to
> email package maintainers who buildrequire your devel package?

Limited hours in the day and limited folks who know the code for
bodhi, koji, and the other infrastructure tools to write a patch to
implement it.

One thing you can do now, which might help you out, is add a
notification in koji.  That way you'll get a heads up whenever someone
builds a package you depend on (and you can check the changelog for
things like "add excludearch..." or whatever).

http://koji.fedoraproject.org/koji/notificationcreate

Won't help you for FC-6, but that won't be a problem for long.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If Stupidity got us into this mess, then why can't it get us out?
    -- Will Rogers (1879-1935)

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

From tmz at pobox.com  Mon Oct  8 17:28:21 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 8 Oct 2007 13:28:21 -0400
Subject: bodhi update problem
In-Reply-To: <20071008172034.GE3722@crow.boston.redhat.com>
References: <20071005173819.GH10067@psilocybe.teonanacatl.org>
	<20071005193444.GB3424@crow.myhome.westell.com>
	<4706A341.8040408@gmail.com>
	<20071006070353.GA28933@crow.myhome.westell.com>
	<20071006073157.GU10067@psilocybe.teonanacatl.org>
	<20071006180628.GD28933@crow.myhome.westell.com>
	<20071006182211.GA20108@psilocybe.teonanacatl.org>
	<20071008172034.GE3722@crow.boston.redhat.com>
Message-ID: <20071008172821.GF32528@psilocybe.teonanacatl.org>

Luke Macken wrote:
> Fixed!
> 
> There was a little bit of backwards logic in the patch
> 
> +               filter(lambda x: x in identity.current.groups, groups):
> 
> should have been:
> 
> +               not filter(lambda x: x in identity.current.groups, groups):

Yeah, thanks for working on this and getting it fixed up quickly Luke
(and Toshio).  I don't care what I read about you on the 'net, you're
alright.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no pleasure in having nothing to do; the fun is in having
lots to do and not doing it.
    -- Mary Wilson Little

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

From mschwendt.tmp0701.nospam at arcor.de  Mon Oct  8 17:54:28 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 8 Oct 2007 19:54:28 +0200
Subject: HEADS-UP: openalpp osgal osgcal excludingarch ppc64 on FC-6 F-7
 now!
In-Reply-To: <d9c612bf0710081019x3facef3cp5799197c4072c30@mail.gmail.com>
References: <d9c612bf0710081019x3facef3cp5799197c4072c30@mail.gmail.com>
Message-ID: <20071008195428.624949e4.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 8 Oct 2007 10:19:55 -0700, Christopher Stone wrote:

> These packages are now excluding arch ppc64 on F-7 and FC-6:
> openalpp, osgal, and osgcal because OSG-devel is no longer available
> for these distros.

FE6 is not built for ppc64, OpenSceneGraph has not been updated
since Oct 2006, so you've just built some superfluous updates.
It makes no sense to published those builds.



From chris.stone at gmail.com  Mon Oct  8 17:56:38 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 10:56:38 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008172617.GE32528@psilocybe.teonanacatl.org>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
Message-ID: <d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>

On 10/8/07, Todd Zullinger <tmz at pobox.com> wrote:
> Christopher Stone wrote:
> > Why can't we develop some way for a devel package maintainer to
> > email package maintainers who buildrequire your devel package?
>
> Limited hours in the day and limited folks who know the code for
> bodhi, koji, and the other infrastructure tools to write a patch to
> implement it.

I think this would be a very useful feature, perhaps a checkbox in
bodhi to notify package maintianers who buildrequire this package
about your update?

I do not know anything about the new packagedb system, but I think
this should be easy to implement and extremely useful.

Is there some killer feature in the db that needs to be added like
figuring out which maintainers BR's a devel package?  This is just an
SQL query correct?



From chris.stone at gmail.com  Mon Oct  8 18:10:27 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 11:10:27 -0700
Subject: HEADS-UP: openalpp osgal osgcal excludingarch ppc64 on FC-6 F-7
	now!
In-Reply-To: <20071008195428.624949e4.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710081019x3facef3cp5799197c4072c30@mail.gmail.com>
	<20071008195428.624949e4.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <d9c612bf0710081110m10ea5871u92d78af5349d0601@mail.gmail.com>

On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> On Mon, 8 Oct 2007 10:19:55 -0700, Christopher Stone wrote:
>
> > These packages are now excluding arch ppc64 on F-7 and FC-6:
> > openalpp, osgal, and osgcal because OSG-devel is no longer available
> > for these distros.
>
> FE6 is not built for ppc64, OpenSceneGraph has not been updated
> since Oct 2006, so you've just built some superfluous updates.
> It makes no sense to published those builds.

Okay, well I don't know why Ralf updated the spec file for FC-6 then.
I simply rebuilt it because the osg spec changed on FC-6 also.

Sorry, it has been a busy and hectic day trying to get my packages
fixed.  It would have been nice had I been notified by Ralf that I had
to update my packages a few days ago when this change was pushed...



From dmc.fedora at filteredperception.org  Mon Oct  8 18:41:26 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Mon, 08 Oct 2007 13:41:26 -0500
Subject: gdm Create User
In-Reply-To: <544eb990710080918r18719d44j149a721f879731d6@mail.gmail.com>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<4707DABD.7060107@filteredperception.org>	<1191698830.4271.7.camel@localhost6.localdomain6>
	<544eb990710080918r18719d44j149a721f879731d6@mail.gmail.com>
Message-ID: <470A79D6.60203@filteredperception.org>

Bill Crawford wrote:
> On 06/10/2007, Richi Plana <myfedora at richip.dhs.org> wrote:
> 
>> Well, that certainly sounds like a smart system ... and I'm all for
>> computers trying to be smarter than their users (if they can do it
>> successfully). But why add a timeout? I'm assuming finding out a list of
>> users from the console isn't a security issue (since they're displayed
>> as a list by GDM) so why not make the computer think one of two things
>> has happened: 1) the user mistyped the username or 2) the user wants to
>> create a new user. The system could ask which and ask for the root
>> password or directory administrator's password if it was a request for
>> the creation of users.
> 
> Because if you mistyped, you don't want some dialog popping up, or any
> kind of other UI, appearing in place of the username and password
> boxes you're about to fill in, again, hopefully with the correct
> username and password this time :) without a reasonable delay (given
> that someone who's expecting to be allowed to create a guest account
> will either wait, or ask the owner of the machine what to do next, or
> ...).

> Actually, how about just having a "create as new account" button
> appear, but NOT FOCUSSED BY DEFAULT along with the login failure
> message?

I admit, that I haven't completely sold myself on the idea as it was.  I 
really was aiming at having a really open-to-guests mode.  Then I tried 
to combine that with the desire to have user creation at gdm.

Something like what you said, but a bit different, would be to have the 
login button focused by default, but a button next to it as 'create new 
user and login'.  Then have things happen pretty much the same (as f7), 
though perhaps with the failed login user/passwd 'text' remaining in 
that highlighted-but-will-disappear-on-keystroke way, and a failure 
message that indicates that the user can either attempt to retype in the 
failed user/passwd, or click the 'create user' button which will spawn 
that dialog prepopulated with the existing user/passwd.

Basically what that gets you, is that you can legitimately accidentally 
mistype your username, get the same failure message (jiggle), then with 
the exact same keystrokes as before, retype in 
username-tab-password-enter, and login.  Or, if you had really wanted to 
create a new user, you either would have clicked the alternate create 
user button rather than using the default focused login button via 
<enter>, or, now upon seeing the 'invalid username/passwd' message but 
the text still there, click on that button.

$0.02...

-dmc





From kzak at redhat.com  Mon Oct  8 19:01:00 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 8 Oct 2007 21:01:00 +0200
Subject: readahead_early.
In-Reply-To: <470A5D57.2010604@redhat.com>
References: <20071005200221.GA28441@redhat.com>
	<20071008130817.GA3866@petra.dvoda.cz>
	<470A5D57.2010604@redhat.com>
Message-ID: <20071008190100.GD3866@petra.dvoda.cz>

On Mon, Oct 08, 2007 at 11:39:51AM -0500, Eric Sandeen wrote:
> Karel Zak wrote:
> 
> >  I don't believe that readahead is able to really improve Fedora boot
> >  time.
> 
> I was going to try a few other things with readahead... including using
> readahead-collector on my system.  But, booting with that as init=
> didn't seem to generate anything.  Is this supposed to work...?

Sorry, the collector doesn't work in F7 (I'm going to update it this
evening).

> Also, when testing with/without readahead, I realized that I should
> probably first manually sort the lists before running any tests, yes?

Not, you needn't to sort anything manually. The readahead is
sorting the lists on the fly. You can also pre-sort the lists
by /etc/cron.daily/readahead.cron.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From a.badger at gmail.com  Mon Oct  8 19:21:11 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 08 Oct 2007 12:21:11 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change
 in	stable release
In-Reply-To: <d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
Message-ID: <470A8327.1020204@gmail.com>

Christopher Stone wrote:
> On 10/8/07, Todd Zullinger <tmz at pobox.com> wrote:
>> Christopher Stone wrote:
>>> Why can't we develop some way for a devel package maintainer to
>>> email package maintainers who buildrequire your devel package?
>> Limited hours in the day and limited folks who know the code for
>> bodhi, koji, and the other infrastructure tools to write a patch to
>> implement it.
> 
> I think this would be a very useful feature, perhaps a checkbox in
> bodhi to notify package maintianers who buildrequire this package
> about your update?
> 
> I do not know anything about the new packagedb system, but I think
> this should be easy to implement and extremely useful.
> 
> Is there some killer feature in the db that needs to be added like
> figuring out which maintainers BR's a devel package?  This is just an
> SQL query correct?
> 
If koji keeps track of dependencies it would be easier to implement this 
there than in the packagedb at the moment.  The packagedb doesn't 
currently track dependencies because the other tools do that.  We could 
change that, but we probably need to sit down and talk about what tools 
we want storing which information in the dbs.

-Toshio



From cjdahlin at ncsu.edu  Mon Oct  8 19:21:12 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Mon, 08 Oct 2007 15:21:12 -0400
Subject: gdm Create User
In-Reply-To: <20071008043054.GA30068@jadzia.bu.edu>
References: <1191696141.3754.6.camel@localhost6.localdomain6>	<1191708767.14966.64.camel@localhost.localdomain>	<4709A3C2.7010204@ncsu.edu>
	<20071008043054.GA30068@jadzia.bu.edu>
Message-ID: <470A8328.8080706@ncsu.edu>

Matthew Miller wrote:
> On Sun, Oct 07, 2007 at 11:28:02PM -0400, Casey Dahlin wrote:
>   
>> For a long time Fedora offered a "Recovery Console" that was accessible 
>> from GDM and simply brought up a minimal terminal. What about a similar 
>> option for a more sophisticated graphical admin tool containing features 
>> like this one?
>>     
>
> As suggested in another thread, that should be precisely what you get if you
> log in as root.
>   
As of now, or is that plans for the future? If not yet implemented, is 
someone assigned to it?



From chris.stone at gmail.com  Mon Oct  8 19:31:59 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 12:31:59 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <470A8327.1020204@gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
	<470A8327.1020204@gmail.com>
Message-ID: <d9c612bf0710081231m20403c46j2491d873725dbf39@mail.gmail.com>

On 10/8/07, Toshio Kuratomi <a.badger at gmail.com> wrote:
> Christopher Stone wrote:
> > On 10/8/07, Todd Zullinger <tmz at pobox.com> wrote:
> >> Christopher Stone wrote:
> >>> Why can't we develop some way for a devel package maintainer to
> >>> email package maintainers who buildrequire your devel package?
> >> Limited hours in the day and limited folks who know the code for
> >> bodhi, koji, and the other infrastructure tools to write a patch to
> >> implement it.
> >
> > I think this would be a very useful feature, perhaps a checkbox in
> > bodhi to notify package maintianers who buildrequire this package
> > about your update?
> >
> > I do not know anything about the new packagedb system, but I think
> > this should be easy to implement and extremely useful.
> >
> > Is there some killer feature in the db that needs to be added like
> > figuring out which maintainers BR's a devel package?  This is just an
> > SQL query correct?
> >
> If koji keeps track of dependencies it would be easier to implement this
> there than in the packagedb at the moment.  The packagedb doesn't
> currently track dependencies because the other tools do that.  We could
> change that, but we probably need to sit down and talk about what tools
> we want storing which information in the dbs.

Okay, please let me know if there is a bug or ticket I can create or
view to track this feature.  Thanks.



From j.w.r.degoede at hhs.nl  Mon Oct  8 20:29:39 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 08 Oct 2007 22:29:39 +0200
Subject: CVS: ACL access denied for a new package
Message-ID: <470A9333.4000900@hhs.nl>

Hi All,

2 hours ago 3 new cvs modules were created for new packages of mine: enet 
egoboo egoboo-data

However I just tried importing them and this fails with:
**** Access denied: jwrdegoede is not in ACL for rpms/enet/devel
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!

Since more then 2 hours have lapsed since CVS modules creation, I don't think 
this is the usual wait for CVS ro sync with packagedb issue.

Regards,

Hans



From a.badger at gmail.com  Mon Oct  8 21:07:44 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 08 Oct 2007 14:07:44 -0700
Subject: CVS: ACL access denied for a new package
In-Reply-To: <470A9333.4000900@hhs.nl>
References: <470A9333.4000900@hhs.nl>
Message-ID: <470A9C20.1040902@gmail.com>

Hans de Goede wrote:
> Hi All,
> 
> 2 hours ago 3 new cvs modules were created for new packages of mine: 
> enet egoboo egoboo-data
> 
> However I just tried importing them and this fails with:
> **** Access denied: jwrdegoede is not in ACL for rpms/enet/devel
> cvs commit: Pre-commit check failed
> cvs [commit aborted]: correct above errors first!
> 
> Since more then 2 hours have lapsed since CVS modules creation, I don't 
> think this is the usual wait for CVS ro sync with packagedb issue.
> 
You are correct.  We're having a some hardware replaced in the colo and 
it's caused some of our scripts to fail.  I've fixed the genacls script 
and run it so this should be fixed.

-Toshio



From rc040203 at freenet.de  Mon Oct  8 21:25:40 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 08 Oct 2007 23:25:40 +0200
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1191878740.3395.467.camel@mccallum.corsepiu.local>

On Mon, 2007-10-08 at 19:09 +0200, Michael Schwendt wrote:
> On Mon, 8 Oct 2007 09:55:44 -0700, Christopher Stone wrote:
> 
> > On 10/8/07, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> > > On Mon, 8 Oct 2007 09:19:47 -0700, Christopher Stone wrote:
> > >
> > > > Ralf Corsepius has updated OpenSceneGraph-devel in F-7 and FC-6 to
> > > > ExcludeArch: ppc64
> > > >
> > > > He did this on a stable release without blocking any excludearch bugs
> > > > or notifiying anyone as far as I can tell!
> > >
> > > Look once more:
> > >
> > > * Thu Jun 21 2007 Ralf Cors?pius <rc040203 freenet de> - 1.2-4
> > >  - ExcludeArch: ppc64 (BZ 245192, 245196).
> > >
> > > > This has been a real pain for me and I'm a little upset that package
> > > > maintainers who depend on OSG-devel were not notified.  If I missed
> > > > some email then I apologize.
> > > >
> > > > Is there not some procedure or guideline for adding excludearch on a
> > > > package in a stable release?
> > 
> > >From the review guidelines:
> >  The bug number should then be placed in a comment, next to the
> > corresponding ExcludeArch line.
> > 
> > That's where I looked,
> 
> $ pwd
> /home/qa/fedora/packages/OpenSceneGraph/FC-6
> 
> $ grep -B2 Exc OpenSceneGraph.spec
> BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> # BZ: 245192, 245196
> ExcludeArch:    ppc64
> --
> %changelog
> * Thu Jun 21 2007 Ralf Cors?pius <rc040203 at freenet.de> - 1.2-4
> - ExcludeArch: ppc64 (BZ 245192, 245196).
> 
> 
> Same for F-7.

I fail to understand why you are making all this fuzz.

* FC-6/ppc64 has never been supported, because ppc64 did not exist. 

* OSG (and therefore all packages depending on it) has never been
supported on FC-7/ppc64.


This issue had been hidden, because OSG in FC-7's release had predated
introduction of the ppc64 (there had not been a mass-rebuild!)

After FC-7 had been released, post-release rebuilds of OSG had shown to
be problematic on ppc64, which had made it inevitable to resort to
"ExcludeArch: ppc64" to let building succeed for other archs.

i.e. the rebuild of FC-7's OSG simply has made a problem with your specs
and with Fedora's infrastructure explicit, but actually nothing has
changed anything.

Ralf





From ville.skytta at iki.fi  Mon Oct  8 21:34:12 2007
From: ville.skytta at iki.fi (=?ISO-8859-1?Q?Ville_Skytt=E4?=)
Date: Tue, 9 Oct 2007 00:34:12 +0300
Subject: samba license change
In-Reply-To: <1191420459.8632.60.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
Message-ID: <8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>

On 10/3/07, Simo Sorce <ssorce at redhat.com> wrote:
> Samba has changed it's license from GPLv2+ to GPLv3+
> The license change affects version 3.2.0 (still a pre-release now).
> In F-8 we will still have 3.0.X so the change affects F-9

Looks like KDE may suffer from this, both kdebase and kdebase4 are
labeled GPLv2 (no "+").



From chris.stone at gmail.com  Mon Oct  8 21:45:12 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 8 Oct 2007 14:45:12 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <1191878740.3395.467.camel@mccallum.corsepiu.local>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<1191878740.3395.467.camel@mccallum.corsepiu.local>
Message-ID: <d9c612bf0710081445m3486a9qea90741ca9095712@mail.gmail.com>

On 10/8/07, Ralf Corsepius <rc040203 at freenet.de> wrote:
> I fail to understand why you are making all this fuzz.

Don't worry about it, I had to rebuild my packages for F-7 today and
was just surprised that the builds failed.  Please try to inform me in
the future if OSG changes will require a rebuild for my packages.

I am hopeful that a feature can be added to the Fedora infrastructure
to allow automatic rebuilds of dependent packages when required.



From ssorce at redhat.com  Mon Oct  8 22:25:14 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Mon, 08 Oct 2007 18:25:14 -0400
Subject: samba license change
In-Reply-To: <8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
Message-ID: <1191882314.2199.7.camel@localhost.localdomain>

On Tue, 2007-10-09 at 00:34 +0300, Ville Skytt? wrote:
> On 10/3/07, Simo Sorce <ssorce at redhat.com> wrote:
> > Samba has changed it's license from GPLv2+ to GPLv3+
> > The license change affects version 3.2.0 (still a pre-release now).
> > In F-8 we will still have 3.0.X so the change affects F-9
> 
> Looks like KDE may suffer from this, both kdebase and kdebase4 are
> labeled GPLv2 (no "+").

Is this because of the QT license?
If so it seem that QT has a lot of exceptions:
http://trolltech.com/products/qt/gplexception
I wonder why GPLv3 is not on the list yet.

Does anyone have more details?

Simo.



From katzj at redhat.com  Mon Oct  8 23:57:13 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 08 Oct 2007 19:57:13 -0400
Subject: f8t3 live: no networking on presario 700
In-Reply-To: <fec24n$3fu$1@sea.gmane.org>
References: <febsul$oim$1@sea.gmane.org>
	<1191804935.28263.38.camel@localhost.localdomain>
	<fec24n$3fu$1@sea.gmane.org>
Message-ID: <1191887833.28263.41.camel@localhost.localdomain>

On Sun, 2007-10-07 at 21:45 -0400, sean darcy wrote:
> Jeremy Katz wrote:
> > On Sun, 2007-10-07 at 20:17 -0400, sean darcy wrote:
> >> I have compaq presario 714n notebook, Intel G965 chipset. wireless is 
> >> Broadcom BCM94311MCG mini-pci, which shows up in lspci.
> > 
> > Broadcom does not make firmware for their wireless cards available in a
> > freely redistributable form, so Fedora cannot distribute this firmware.
> > Thus, it cannot work out of the box.  You can generate a firmware file
> > using the b43-fwcutter utility, but this doesn't help much for the live
> > environment.  Feel free to request that Broadcom provide freely
> > redistributable firmware for their wireless products!
> > 
> Well, would this work:
> 
> I'm using live to install on a 20gig partition that already has windows 
> installed.
> 
> Can I install f8 ( from dvd or livecd ), download the fw43-cutter rpm 
> under windows, use ntfs-utils to copy to the linux partition, install 
> it, and Voila! ??

Yes.

> Is fw43-cutter on the dvd?

Not as of test3.  I just adjusted comps so that it will be on the DVD
and the live images for the final release to help making this hardware a
little easier

Jeremy



From katzj at redhat.com  Mon Oct  8 23:58:24 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 08 Oct 2007 19:58:24 -0400
Subject: f8t3 Live on ibm a20m: how do I login?
In-Reply-To: <fec2t0$4tn$1@sea.gmane.org>
References: <fec2t0$4tn$1@sea.gmane.org>
Message-ID: <1191887904.28263.44.camel@localhost.localdomain>

On Sun, 2007-10-07 at 21:58 -0400, sean darcy wrote:
> Trying to run live cd on something, I've tried to run it on an ibm a20m 
> notebook ( 2000 vintage, pentium 3 700mz ).
> 
> The gdm throws up the login screen asking for the user name, and says 
> user fedora will login in 60 seconds.

If you type fedora and hit enter before the counter goes negative, does
it work?  Or click on the Fedora user on the left column?  It _should_.
But I've seen this before, usually on machines with the wrong time in
the hwclock.  Worth filing against gdm if it's not already filed

Jeremy



From jkeating at redhat.com  Tue Oct  9 00:04:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 20:04:14 -0400
Subject: Pushing updates in Bodhi
In-Reply-To: <1191860928.22874.43.camel@localhost.localdomain>
References: <3170f42f0710080639m218adb8blea094a6e8d03e5d7@mail.gmail.com>
	<20071008135418.GB3722@crow.boston.redhat.com>
	<1191860928.22874.43.camel@localhost.localdomain>
Message-ID: <20071008200414.0aa7da3b@redhat.com>

On Mon, 08 Oct 2007 09:28:48 -0700
"Devrim G?ND?Z" <devrim at CommandPrompt.com> wrote:

> Don't we have someone as a backup?

There are other people that know the keys, and with some work could
figure out the current process to get updates out.  I didn't really
give them a heads up that I was leaving because I expected to have more
computer time to keep updates flowing.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/3884c4a6/attachment.sig>

From jkeating at redhat.com  Tue Oct  9 00:05:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 20:05:34 -0400
Subject: Mock x86_64/i386 build issues
In-Reply-To: <470A4E98.4020200@cora.nwra.com>
References: <470A4E98.4020200@cora.nwra.com>
Message-ID: <20071008200534.3d388536@redhat.com>

On Mon, 08 Oct 2007 09:36:56 -0600
Orion Poplawski <orion at cora.nwra.com> wrote:

> I'm having trouble building some i386 packages (rpm, anaconda) on my 
> x86_64 machine with mock.  It seems that the build process picks up
> that the processor in x86_64.  How does koji or anyone else handle
> this?

setarch i686 mock -r fedora-devel-i386 foo.src.rpm

The 'setarch i686' is the important part.  (some packages may actually
need 'setarch i386', I last ran into this with emacs a long time ago on
RHL7.something.  Don't ask.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/a70512ff/attachment.sig>

From jkeating at redhat.com  Tue Oct  9 00:07:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 20:07:45 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
Message-ID: <20071008200745.3612acb4@redhat.com>

On Mon, 8 Oct 2007 10:16:57 -0700
"Christopher Stone" <chris.stone at gmail.com> wrote:

> Why can't we develop some way for a devel package maintainer to email
> package maintainers who buildrequire your devel package?

Because that can change on a minute to minute basis, among other
technical difficulties.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/015b2208/attachment.sig>

From jkeating at redhat.com  Tue Oct  9 00:11:03 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 20:11:03 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <470A8327.1020204@gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
	<470A8327.1020204@gmail.com>
Message-ID: <20071008201103.2d814b5a@redhat.com>

On Mon, 08 Oct 2007 12:21:11 -0700
Toshio Kuratomi <a.badger at gmail.com> wrote:

> If koji keeps track of dependencies it would be easier to implement
> this there than in the packagedb at the moment.  The packagedb
> doesn't currently track dependencies because the other tools do
> that.  We could change that, but we probably need to sit down and
> talk about what tools we want storing which information in the dbs.


Actually in the koji db there are listed rpm requirements.

http://koji.fedoraproject.org/koji/rpminfo?rpmID=228266 is an example of srpm Requires which are the same as BuildRequires in the spec.  The problem is that many times these requires are somewhat generic and can be serviced by multiple packages and/or rely on indirect BuildRequires that are pulled in from the direct BuildRequires or the minimal buildroot.

It is really quite difficult to get an accurate map of exactly which
packages will ultimately need your package to build.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/51088019/attachment.sig>

From jkeating at redhat.com  Tue Oct  9 00:12:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 8 Oct 2007 20:12:31 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <1191878740.3395.467.camel@mccallum.corsepiu.local>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<1191878740.3395.467.camel@mccallum.corsepiu.local>
Message-ID: <20071008201231.156c7027@redhat.com>

On Mon, 08 Oct 2007 23:25:40 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> This issue had been hidden, because OSG in FC-7's release had predated
> introduction of the ppc64 (there had not been a mass-rebuild!)

Actually there was, done on the side and imported into koji for all the
things that could build on ppc64, those that couldn't were dropped on
the blocker list (or were supposed to).  It was a release engineering
done build not one that relied upon all the maintainers.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071008/920db128/attachment.sig>

From mjs at CLEMSON.EDU  Tue Oct  9 00:28:27 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 08 Oct 2007 20:28:27 -0400
Subject: Another readahead issue
Message-ID: <1191889707.25531.49.camel@vincent52.localdomain>

Not sure if I should have started a new thread, but...

If you *are* going to keep or eventually revive readahead, it would be
nice to deal with the fact that all the firefox entries in default.later
are /usr/lib/firefox-2.0.0.3/, but the current firefox is
firefox-2.0.0.5.  

That is, version-dependent listings in readahead don't get updated when
the target package version changes.  Firefox is the most likely to get
out of sync, but there do seem to be some other version-dependent
listings.

-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From roland at redhat.com  Tue Oct  9 00:33:28 2007
From: roland at redhat.com (Roland McGrath)
Date: Mon,  8 Oct 2007 17:33:28 -0700 (PDT)
Subject: Mock x86_64/i386 build issues
In-Reply-To: Jesse Keating's message of  Monday, 8 October 2007 20:05:34 -0400
	<20071008200534.3d388536@redhat.com>
References: <470A4E98.4020200@cora.nwra.com>
	<20071008200534.3d388536@redhat.com>
Message-ID: <20071009003328.3FEC24D04CC@magilla.localdomain>

> setarch i686 mock -r fedora-devel-i386 foo.src.rpm
> 
> The 'setarch i686' is the important part.  

It really seems to me that mock ought to be taught to do this.  There's no
good reason that "you need setarch foo if `uname -m` !~ bar" shouldn't be
part of that very config file that -r selects.

> (some packages may actually need 'setarch i386', I last ran into this
> with emacs a long time ago on RHL7.something.  Don't ask.

I won't even tell.  I believe any package so affected by now has a kludge
to do %ifarch blah\nsetarch i386 make dump\n%elsemake dump\n%endif or whatever.


Thanks,
Roland



From rc040203 at freenet.de  Tue Oct  9 00:50:16 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 09 Oct 2007 02:50:16 +0200
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008201231.156c7027@redhat.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<1191878740.3395.467.camel@mccallum.corsepiu.local>
	<20071008201231.156c7027@redhat.com>
Message-ID: <1191891016.3395.491.camel@mccallum.corsepiu.local>

On Mon, 2007-10-08 at 20:12 -0400, Jesse Keating wrote:
> On Mon, 08 Oct 2007 23:25:40 +0200
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > This issue had been hidden, because OSG in FC-7's release had predated
> > introduction of the ppc64 (there had not been a mass-rebuild!)
> 
> Actually there was, done on the side and imported into koji for all the
> things that could build on ppc64, those that couldn't were dropped on
> the blocker list (or were supposed to).  It was a release engineering
> done build not one that relied upon all the maintainers.
Well, then I can't avoid to ask why the results of this built had not
been communicated to the maintainers, esp. for the ppc64, where several
packages must have failed building - not necessarily nice.

Ralf




From s.adam at diffingo.com  Tue Oct  9 00:49:15 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Mon, 08 Oct 2007 20:49:15 -0400
Subject: Merging totem and totem-xine
Message-ID: <1191890955.14085.11.camel@Diffingo.localdomain>

Hi,

Since xine-lib has been moved to Fedora, I realized so could totem-xine.
I've been working on a totem spec that includes both gstreamer and xine
backends. As of now, the spec generates the usual subpackages plus
'totem-gstreamer' and 'totem-xine' which contain the binaries for the
gstreamer- and xine-based binary totem. I've used --program-suffix at
compile time, so they are parallel installable.

What do you think the best approach is to packaging this, if at all? Two
options I'm thinking of are having the two engines conflict or using
alternatives to have a configurable backend (switching "on demand").

Stewart



From sandeen at redhat.com  Tue Oct  9 00:57:59 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Mon, 08 Oct 2007 19:57:59 -0500
Subject: Another readahead issue
In-Reply-To: <1191889707.25531.49.camel@vincent52.localdomain>
References: <1191889707.25531.49.camel@vincent52.localdomain>
Message-ID: <470AD217.8080701@redhat.com>

Matthew Saltzman wrote:
> Not sure if I should have started a new thread, but...
> 
> If you *are* going to keep or eventually revive readahead, it would be
> nice to deal with the fact that all the firefox entries in default.later
> are /usr/lib/firefox-2.0.0.3/, but the current firefox is
> firefox-2.0.0.5.  
> 
> That is, version-dependent listings in readahead don't get updated when
> the target package version changes.  Firefox is the most likely to get
> out of sync, but there do seem to be some other version-dependent
> listings.
> 

I think the readahead list *really* needs to be self-healing somehow (if
it can be demonstrated that it actually does optimize boot performance
when properly set up.)

-Eric



From peter at thecodergeek.com  Tue Oct  9 01:59:26 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 08 Oct 2007 18:59:26 -0700
Subject: rpms/emerald/devel emerald.spec,1.13,1.14
In-Reply-To: <200710081535.l98FZv86006715@cvs-int.fedora.redhat.com>
References: <200710081535.l98FZv86006715@cvs-int.fedora.redhat.com>
Message-ID: <1191895166.14135.1.camel@localhost.localdomain>

On Mon, 2007-10-08 at 11:35 -0400, Jarod Wilson wrote:
> Log Message:
> Disable ppc64 build (no compiz-devel.ppc64 available)

When you ExcludeArch PPC64, please remember to file a bug against your
package which blocks the FE-ExcludeArch-ppc64 tracker (bug 238953) if
you have not already done so.

Thanks.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071008/ac7eb5a7/attachment.sig>

From zaitcev at redhat.com  Tue Oct  9 02:23:28 2007
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Mon, 8 Oct 2007 19:23:28 -0700
Subject: Sierra Wireless on Rawhide
In-Reply-To: <20071007122026.GA5994@iota.fab.redhat.com>
References: <20071007122026.GA5994@iota.fab.redhat.com>
Message-ID: <20071008192328.84405765.zaitcev@redhat.com>

On Sun, 7 Oct 2007 13:20:26 +0100, Anders Karlsson <anders at trudheim.co.uk> wrote:

> I've been trying to get UMTS working through the Sierra chip in my
> Thinkpad X60s and for some reason, the USB subsystem in F8 TestN and
> Rawhide clocks that I have the Sierra chip, configures it (udev
> creates /dev/ttyUSB[0-2]) and then immediately disconnects the device,
> meaning I no longer see it in lsusb output etc. This was not the case
> in F7.

> Oct  7 12:44:02 iota kernel: sierra 3-1:1.0: Sierra USB modem (3 port) converter detected
> Oct  7 12:44:02 iota kernel: usb 3-1: USB disconnect, address 2

Linux never disconnects anything by itself, but something we do makes
your device to roll over and play dead. Please send me a usbmon trace
(see /usr/share/doc/kernel-doc-2.6.22/Documentation/usb/usbmon.txt).
Also, I'd like to see /proc/bus/usb/devices (please disable sierra
driver by renaming or blacklisting it temporarily so it does not
kill the device before you can capture the devices file). I'll poke
the upstream about it we can put together an error case.

-- Pete



From louisg00 at bellsouth.net  Tue Oct  9 04:21:54 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Tue, 09 Oct 2007 00:21:54 -0400
Subject: irqbalance problems
Message-ID: <1191903714.3141.3.camel@tiger>

This service seems to die and will not shutdown properly. The services
capplet has 'irqbalance dead but subsys locked' as the status.

-Louis



From s.adam at diffingo.com  Tue Oct  9 04:51:52 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 09 Oct 2007 00:51:52 -0400
Subject: irqbalance problems
In-Reply-To: <1191903714.3141.3.camel@tiger>
References: <1191903714.3141.3.camel@tiger>
Message-ID: <1191905512.13052.2.camel@Diffingo.localdomain>

On Tue, 2007-10-09 at 00:21 -0400, Louis E Garcia II wrote:
> This service seems to die and will not shutdown properly. The services
> capplet has 'irqbalance dead but subsys locked' as the status.
> 
> -Louis
I've noticed this too - I can never find when or why it dies,
but it's always a matter of minutes before it dies.

Stewart



From a.badger at gmail.com  Tue Oct  9 05:15:25 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 08 Oct 2007 22:15:25 -0700
Subject: Merging totem and totem-xine
In-Reply-To: <1191890955.14085.11.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
Message-ID: <470B0E6D.3000606@gmail.com>

Stewart Adam wrote:
> Hi,
> 
> Since xine-lib has been moved to Fedora, I realized so could totem-xine.
> I've been working on a totem spec that includes both gstreamer and xine
> backends. As of now, the spec generates the usual subpackages plus
> 'totem-gstreamer' and 'totem-xine' which contain the binaries for the
> gstreamer- and xine-based binary totem. I've used --program-suffix at
> compile time, so they are parallel installable.
> 
> What do you think the best approach is to packaging this, if at all? Two
> options I'm thinking of are having the two engines conflict or using
> alternatives to have a configurable backend (switching "on demand").
> 
Pick one as the default (Probably totem-gstreamer since the rest of our 
infrastructure is based around gstreamer.)  The other one can either be 
invoked by using totem-xine or a shell script can be used to select 
which one to run (based on what's installed, an environment variable, 
and the default.)

-Toshio



From davej at redhat.com  Tue Oct  9 05:21:10 2007
From: davej at redhat.com (Dave Jones)
Date: Tue, 9 Oct 2007 01:21:10 -0400
Subject: irqbalance problems
In-Reply-To: <1191905512.13052.2.camel@Diffingo.localdomain>
References: <1191903714.3141.3.camel@tiger>
	<1191905512.13052.2.camel@Diffingo.localdomain>
Message-ID: <20071009052110.GD12691@redhat.com>

On Tue, Oct 09, 2007 at 12:51:52AM -0400, Stewart Adam wrote:
 > On Tue, 2007-10-09 at 00:21 -0400, Louis E Garcia II wrote:
 > > This service seems to die and will not shutdown properly. The services
 > > capplet has 'irqbalance dead but subsys locked' as the status.
 > > 
 > > -Louis
 > I've noticed this too - I can never find when or why it dies,
 > but it's always a matter of minutes before it dies.

irqbalances init script seems to be terminally ill.

see what happens if you do..

init 3 ; init 5 ; init 3
ps ax | grep irqbalance

for example.  I filed a bug on this last week.
Different problem to what you're seeing most likely, but it could
definitly use some love from someone with the inclination/time to fix it.

	Dave

-- 
http://www.codemonkey.org.uk



From sundaram at fedoraproject.org  Tue Oct  9 06:26:40 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Oct 2007 11:56:40 +0530
Subject: samba license change
In-Reply-To: <1191882314.2199.7.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
Message-ID: <470B1F20.1010905@fedoraproject.org>

Simo Sorce wrote:

> Is this because of the QT license?
> If so it seem that QT has a lot of exceptions:
> http://trolltech.com/products/qt/gplexception
> I wonder why GPLv3 is not on the list yet.
> 
> Does anyone have more details?

Last I heard TrollTech was still evaluating this option.

http://chani.wordpress.com/2007/07/18/uhoh/#comment-1932

Essentially unless the entire dependency chain for Samba is GPLv3 
compatible, a new samba version under GPLv3 or later would be impossible 
to pull as incompatible licensing is a liability for the distribution 
and not necessarily for the individual components.

Rahul



From lkundrak at redhat.com  Tue Oct  9 06:39:26 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 09 Oct 2007 08:39:26 +0200
Subject: samba license change
In-Reply-To: <470B1F20.1010905@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
Message-ID: <1191911966.7000.4.camel@localhost.localdomain>


On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> Simo Sorce wrote:
> 
> > Is this because of the QT license?
> > If so it seem that QT has a lot of exceptions:
> > http://trolltech.com/products/qt/gplexception
> > I wonder why GPLv3 is not on the list yet.
> > 
> > Does anyone have more details?
> 
> Last I heard TrollTech was still evaluating this option.
> 
> http://chani.wordpress.com/2007/07/18/uhoh/#comment-1932
> 
> Essentially unless the entire dependency chain for Samba is GPLv3 
> compatible, a new samba version under GPLv3 or later would be impossible 
> to pull as incompatible licensing is a liability for the distribution 
> and not necessarily for the individual components.

This also applies to the patches from the samba upstream. Simo: do you
have an idea wheter it would be possible to convince the samba upstream
to release at least security fixes for samba under GPLv2?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From j.w.r.degoede at hhs.nl  Tue Oct  9 07:23:10 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 09 Oct 2007 09:23:10 +0200
Subject: Merging totem and totem-xine
In-Reply-To: <1191890955.14085.11.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
Message-ID: <470B2C5E.7010906@hhs.nl>

Stewart Adam wrote:
> Hi,
> 
> Since xine-lib has been moved to Fedora, I realized so could totem-xine.
> I've been working on a totem spec that includes both gstreamer and xine
> backends. As of now, the spec generates the usual subpackages plus
> 'totem-gstreamer' and 'totem-xine' which contain the binaries for the
> gstreamer- and xine-based binary totem. I've used --program-suffix at
> compile time, so they are parallel installable.
> 
> What do you think the best approach is to packaging this, if at all? Two
> options I'm thinking of are having the two engines conflict or using
> alternatives to have a configurable backend (switching "on demand").
> 

Please use alternatives, so that totem-moz-plugin can be switched between the 2 
too.

Regards,

Hans



From pertusus at free.fr  Tue Oct  9 07:55:59 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Oct 2007 09:55:59 +0200
Subject: rpm and post script install/run order question (texlive)
Message-ID: <20071009075559.GB2616@free.fr>

Hello,

I have some questions regarding rpm installation and script run order.
It is for texlive, and I use letters that corresponds with:

A texlive
B texlive-texmf
C kpathsea
D texlive-fonts
E texlive-fonts-texmf

sA updmap-sys



We have:

A
Requires: B C D

B
Requires: C
Requires(post): sA

C doesn't requires anything, but has a post script (ldconfig) that must 
  be run before it can be used by programs in A or B.

D
Requires: E
Requires(post): sA

E
Requires(post): sA

The script sA is in A, but to be succesfull, it has to be run with A, B,
C and D installed. If run multiple time, only the last run must be 
succesfull, but it should be run with all the packages that Requires it 
installed (B E), it is not a problem if previous runs are done wrong.

Unless I am wrong, in that kind of setup all the packages will be
installed in the same batch (except maybe for C, but no user will 
ever install C directly).

I am not sure, however, what would be the order of installation of those
packages, nor when would sA be called. For example, since C doesn't have
any Requires(post) on A would it be possible to have an install order
with C in the end, and the post scripts run before C is installed? 
Maybe there are other subtle possible failures? Also is the installation 
and post script run order dependent on which package is selected for,
say a yum install, that is will:

yum install A
yum install E
yum install B

and so on and so forth give the same installation and post script run
order?

My question may be a bit confused, so don't hesitate to ask for more
info. Also I couldn't find a place where such issues are explained in 
depth. In the usual rpm manuals there are some explanations, but not
precise enough. Is there some doc I could have missed?

The example is a bit simplified, since additionnally there is a
dependency cycle between texlive-dvips and texlive-fonts, and also there
is texlive-latex, but the issues faced shouldn't be different than for
the example above, unless I missed something.

--
Pat



From pertusus at free.fr  Tue Oct  9 08:05:28 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Oct 2007 10:05:28 +0200
Subject: rpm and post script install/run order question (texlive) [2]
Message-ID: <20071009080528.GC2616@free.fr>

Hello,

My previous mail had errors, sorry. Resending.

I have some questions regarding rpm installation and script run order.
It is for texlive, and I use letters that corresponds with:

A texlive
B texlive-texmf
C kpathsea
D texlive-fonts
E texlive-fonts-texmf

sA1 updmap-sys
sA2 texconfig-sys


We have:

A
Requires: B C D
Requires(post): sA2

B
Requires(post): sA1 sA2

C doesn't requires anything, but has a post script (ldconfig) that must
  be run before it can be used by programs in A or D.

D
Requires: E C
Requires(post): sA2

E
Requires(post): sA1 sA2

The script sA1 is in A, but to be succesfull, it has to be run with A, B,
C and D installed. If run multiple time, only the last run must be
succesfull, but it should be run with all the packages that Requires it
installed (B E), it is not a problem if previous runs are done wrong.
sA2 is in A, but only requires A to be present to be successfull.

Unless I am wrong, in that kind of setup all the packages will be
installed in the same batch (except maybe for C, but no user will
ever install C directly).

I am not sure, however, what would be the order of installation of those
packages, nor when would sA be called. For example, since C doesn't have
any Requires(post) on A would it be possible to have an install order
with C in the end, and the post scripts run before C is installed?
Maybe there are other subtle possible failures? Also is the installation
and post script run order dependent on which package is selected for,
say a yum install, that is will:

yum install A
yum install E
yum install B

and so on and so forth give the same installation and post script run
order?

My question may be a bit confused, so don't hesitate to ask for more
info. Also I couldn't find a place where such issues are explained in
depth. In the usual rpm manuals there are some explanations, but not
precise enough. Is there some doc I could have missed?

The example is a bit simplified, since additionnally there is a
dependency cycle between texlive-dvips and texlive-fonts, and also there
is texlive-latex, but the issues faced shouldn't be different than for
the example above, unless I missed something.

--
Pat



From nicolas.mailhot at laposte.net  Tue Oct  9 08:59:47 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 9 Oct 2007 10:59:47 +0200 (CEST)
Subject: samba license change
In-Reply-To: <1191911966.7000.4.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
	<1191911966.7000.4.camel@localhost.localdomain>
Message-ID: <20675.192.54.193.51.1191920387.squirrel@rousalka.dyndns.org>


Le Mar 9 octobre 2007 08:39, Lubomir Kundrak a ?crit :
>
> On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
>> Simo Sorce wrote:

>> Essentially unless the entire dependency chain for Samba is GPLv3
>> compatible, a new samba version under GPLv3 or later would be
>> impossible
>> to pull as incompatible licensing is a liability for the
>> distribution
>> and not necessarily for the individual components.
>
> This also applies to the patches from the samba upstream. Simo: do you
> have an idea wheter it would be possible to convince the samba
> upstream
> to release at least security fixes for samba under GPLv2?

The samba project will continue to do maintenance and security fixes
on the last GPLv2 release however it won't get all the improvements of
the next one. So IMHO it's totally unrealistic to expect to keep using
the GPLv2 samba branch even mid-term. Users will start begging for
GPLv3 samba features soon.

That means all the projects that depend on samba will have to move to
GPLv3 compatibility quickly. There is no status-quo escape - the samba
people know they can not be replaced (past forks didn't get any
traction, and no one really wants to dig in MS bugs in their place)
and they've been deeply involved in EU MS litigation (so they know
GPLv2 is not sufficient). The probability of Samba going back to GPLv2
is actually lower than the probability of the kernel going GPLv3.

Some people have blinded themselves thinking their dislike of the FSF
was shared by everyone and boycotting the GPLv3 process would ensure a
bad license no one would use. Groups that had to taste real-world
litigation like Samba, however, have always make clear they were not
happy with GPLv2 and would move their code to GPLv3 no matter what
others chose.

-- 
Nicolas Mailhot



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Tue Oct  9 09:23:24 2007
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Tue, 9 Oct 2007 11:23:24 +0200
Subject: Test NetworkManager-openvpn?
In-Reply-To: <20071005181805.4a85545d@localhost.localdomain>
References: <4705BCF4.2070207@redhat.com> <20071005074413.07744715@redhat.com>
	<20071005181805.4a85545d@localhost.localdomain>
Message-ID: <20071009112324.42606788@python3.es.egwn.lan>

Thomas Canniot wrote :

> Le Fri, 5 Oct 2007 07:44:13 -0400,
> Jesse Keating <jkeating at redhat.com> a ?crit :
> 
> > On Fri, 05 Oct 2007 00:26:28 -0400
> > Warren Togami <wtogami at redhat.com> wrote:
> > 
> > > Can someone test the equivalent for NetworkManager-openvpn with
> > > Selinux enforcing enabled?  Please test it in both "service
> > > NetworkManager start" and "NetworkManager --no-daemon" mode to be
> > > sure both are functioning properly.
> > 
> > That's a little difficult when NM-openvpn hasn't yet been ported to
> > NM-0.7 infrastructure.
> > 
> 
> On FC7, I had absolutely no problem using it... in fact, it is the
> light at the end of the tunnel for me. It works so great and out of the
> box (certificate and login / pwd identification on a wpa network). I
> can now connect very easily in my university.

WPA? Then you probably mean Wireless, not VPN :-)

I use NM with OpenVPN on F-7, and although it "mostly works" (I use
certificates with login/pass), it gets things completely wrong
regarding network routes. I still have some open bug reports about this
upstream...

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7
Load : 0.27 0.37 0.36



From kagesenshi.87 at gmail.com  Tue Oct  9 09:37:54 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Tue, 9 Oct 2007 17:37:54 +0800
Subject: Pulseaudio not restarting after crash
Message-ID: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>

if the pulseaudio daemon crashed, it doesnt restart itself .. and it
need to be manually restarted ... It would be nice to have it restarts
after crash because normal users wont know how to restart it ..

plus .. if the folder /tmp/pulse-username exist, pulseaudio refuses to
start and returns

E: pid.c: Daemon already running.
E: main.c: pa_pid_file_create() failed.

but the daemon is not running so I had to delete the folder manually ..

btw.. where does the autostart script pulseaudio daemon located?? I
couldnt find it .. (I wanted to add a simple while loop hack for
restarting the daemon for my own use) ..



-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From anders at trudheim.co.uk  Tue Oct  9 10:07:27 2007
From: anders at trudheim.co.uk (Anders Karlsson)
Date: Tue, 9 Oct 2007 11:07:27 +0100
Subject: Sierra Wireless on Rawhide
In-Reply-To: <20071008192328.84405765.zaitcev@redhat.com>
References: <20071007122026.GA5994@iota.fab.redhat.com>
	<20071008192328.84405765.zaitcev@redhat.com>
Message-ID: <20071009100727.GB3537@iota.fab.redhat.com>

Thus, Pete Zaitcev at Tue Oct  9 03:23:28 2007 inscribed:
> On Sun, 7 Oct 2007 13:20:26 +0100, Anders Karlsson <anders at trudheim.co.uk> wrote:
> 
> > I've been trying to get UMTS working through the Sierra chip in my
> > Thinkpad X60s and for some reason, the USB subsystem in F8 TestN and
> > Rawhide clocks that I have the Sierra chip, configures it (udev
> > creates /dev/ttyUSB[0-2]) and then immediately disconnects the device,
> > meaning I no longer see it in lsusb output etc. This was not the case
> > in F7.
> 
> > Oct  7 12:44:02 iota kernel: sierra 3-1:1.0: Sierra USB modem (3 port) converter detected
> > Oct  7 12:44:02 iota kernel: usb 3-1: USB disconnect, address 2
> 
> Linux never disconnects anything by itself, but something we do makes
> your device to roll over and play dead.

As far as I can see, on the latest kernel compiled with USB debug
enabled, the device is noticed by uhci_hcd (messages in log) and once
the swap is enabled the device is disconnected and I can no longer see
it.

> Please send me a usbmon trace
> (see /usr/share/doc/kernel-doc-2.6.22/Documentation/usb/usbmon.txt).

I'll have to instrument something to run early enough in rc.sysinit or
from the initrd so that this can be captured. The point in time where
the device is disconnected is just to early.

Would an initrd generated without usb support allow me to load the
modules one at a time to get this set up so I can use usbmon you
think?

> Also, I'd like to see /proc/bus/usb/devices (please disable sierra
> driver by renaming or blacklisting it temporarily so it does not
> kill the device before you can capture the devices file). I'll poke
> the upstream about it we can put together an error case.

sierra and usbserial is blacklisted, and the device still get
disconnected. 

Thanks!

-- 
Anders Karlsson <anders at trudheim.co.uk>
All-Round Linux Tinkerer & RHCE



From harald at redhat.com  Tue Oct  9 10:08:36 2007
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 09 Oct 2007 12:08:36 +0200
Subject: [SOLVED] F8t3 k3b and sound problems
In-Reply-To: <20071008093351.1592a8e5@redhat.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>	<4705FA4B.4010503@redhat.com>	<1191579585.12607.1.camel@scrappy.miketc.com>	<4709E0EC.8010902@redhat.com>	<1191849744.2204.1.camel@scrappy.miketc.com>
	<20071008093351.1592a8e5@redhat.com>
Message-ID: <470B5324.6030906@redhat.com>

Jesse Keating wrote:
> On Mon, 08 Oct 2007 08:22:24 -0500
> Mike Chambers <mike at miketc.com> wrote:
> 
>> Welp, turning on Consolekit and a quick reboot and BOTH k3b and my
>> sound now seem to work.  So this *has* to be on for those type devices
>> (removable and so on?) to work?
> 
> ConsoleKit and PolicyKit work together to assign ACLs to the devices
> for the active console user.  If it isn't running, the ACLs won't be
> applied and you won't have access to use them.
> 
> 

Think of them as the pam_console replacement.



From buildsys at redhat.com  Tue Oct  9 10:11:51 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 9 Oct 2007 06:11:51 -0400
Subject: rawhide report: 20071009 changes
Message-ID: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>

New package astromenace
	Hardcore 3D space shooter with spaceship upgrade possibilities

New package astromenace-data
	Hardcore 3D space shooter with spaceship upgrade possibilities

New package avarice
	Program for interfacing the Atmel JTAG ICE to GDB

New package rpmrebuild
	A tool to build rpm file from rpm database

New package uisp
	Universal In-System Programmer for Atmel AVR and 8051


Removed package digikamimageplugins-doc

Removed package digikamimageplugins

Updated Packages:

TeXmacs-1.0.6.11-3.fc8
----------------------
* Mon Oct 08 2007 Gerard Milmeister <gemi at bluewin.ch> - 1.0.6.11-2
- patch for maxima 5.13.0

TurboGears-1.0.3.2-5.fc8
------------------------
* Mon Oct 08 2007 Toshio Kuratomi <a.badger at gmail.com> 1.0.3.2-5
- Update patch so that quickstart template pulls in the proper sqlalchemy
  when tg-admin quickstart -s is run.

anaconda-11.3.0.37-1
--------------------
* Mon Oct 08 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.37-1
- Use nodocs when building stage2 images (Orion Poplawski)
- Add extra headers to ks.cfg request for arch and release (#315601)
- Fix a traceback in partition sanity checking (#316551, #318841, #300721) 
- Hack to not ignore the ssb driver for wireless (#311421)
- Set repo cost so we pull things from the DVD instead of network (#245696)
- Make boot partitions 200 megs
- Write reboot commands into generated anaconda-ks.cfg (clumens)
- Don't reload the UI if we don't have to (clumens, #290781)
- Use newer version of device command (clumens)

bootparamd-0.17-26.fc8
----------------------
* Mon Oct 08 2007 Ondrej Dvoracek <odvorace at redhat.com> - 0.17-26
- added LSB header in the initscript
- corrected issues from merge review (#225623)

chess-1.0-10.fc8
----------------
* Mon Oct 08 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0-10
- Rebuild for new ogre

claws-mail-plugins-3.0.1-1.fc8
------------------------------
* Mon Oct 08 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.0.1-1
- version upgrade

dhcp-12:3.0.6-8.fc8
-------------------
* Mon Oct 08 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-8
- Init script fixes (#320761)
- Removed linux.dbus-example script since we aren't using dhcdbd now
- Remove dhcdbd leftovers from dhclient-script (#306381)

* Wed Sep 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-7
- In dhcp.conf.5, explain that if no next-server statement applies to the
  requesting client, the address 0.0.0.0 is used (#184484).

* Wed Sep 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-6
- Init script fixes for dhcpd and dhcrelay (#278601)

dssi-0.9.1-11.fc8
-----------------
* Sun Oct 07 2007 Anthony Green <green at redhat.com> 0.9.1-11
- Rebuild for new lash.

emerald-0.5.2-2.fc8
-------------------
* Mon Oct 08 2007 Jarod Wilson <jwilson at redhat.com> 0.5.2-2
- Disable ppc64 build (no compiz-devel.ppc64)

* Mon Oct 08 2007 Jarod Wilson <jwilson at redhat.com> 0.5.2-1
- New upstream release
- Should work with latest compiz bits in Fedora

* Mon Jun 11 2007 Jarod Wilson <jwilson at redhat.com> 0.2.1-2
- Fix up build against latest libwnck

emerald-themes-0.5.2-1.fc8
--------------------------
* Mon Oct 08 2007 Jarod Wilson <jwilson at redhat.com> 0.5.2-1
- New upstream release
- Should work with latest compiz bits in Fedora

fluidsynth-1.0.7-9.a.fc8
------------------------
* Mon Oct 08 2007 Anthony Green <green at redhat.com> 1.0.7-9.a
- Rebuilt for new lash.

fluxbox-1.0.0-1.fc8
-------------------
* Mon Oct 08 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
1.0.0-1
- version upgrade

gnome-keyring-2.20-5.fc8
------------------------
* Mon Oct 08 2007 Alexander Larsson <alexl at redhat.com> - 2.20-5
- Fixed minor issue with pam-selinux issue pointed out by stef

* Thu Oct 04 2007 Alexander Larsson <alexl at redhat.com> - 2.20-4
- Have the pam module tell the daemon to init the login keyring 
  without using the socket as selinux limits access to that

* Thu Oct 04 2007 Alexander Larsson <alexl at redhat.com> - 2.20-3
- Add NO_MATCH error patch from svn. Will fix apps that
  can't handle empty list matches

gpodder-0.10.0-1.fc8
--------------------
* Sun Oct 07 2007 Jef Spaleta <jspaleta at gmail.com> 0.10.0-1
- New Upstream version

groff-1.18.1.4-10.fc8
---------------------
* Mon Oct 08 2007 Marcela Maslanova <mmaslano at redhat.com> - 1.18.1.4-10
- path for groffer wasn't set correctly #89210

gstreamer-plugins-good-0.10.6-6.fc8
-----------------------------------
* Mon Oct 08 2007 - Bastien Nocera <bnocera at redhat.com> - 0.10.6-6
- Kill esound output, as we don't have esound installed anymore, just
  Pulseaudio (#323061)

hunspell-1.1.12.2-2.fc8
-----------------------
* Mon Oct 08 2007 Caolan McNamara <caolanm at redhat.com> - 1.1.12.2-2
- lang fix for man pages from Ville Skytt??
hwbrowser-0.38-1.fc8
--------------------
* Mon Oct 08 2007 Nils Philippsen <nphilipp at redhat.com> - 0.38-1
- add "make diff" ("dif") and "make shortdiff" ("sdif")
- pull in updated translations

initscripts-8.59-1
------------------
* Mon Oct 08 2007 Bill Nottingham <notting at redhat.com> - 8.59-1
- rc.sysinit: fix rhgb check
- prefdm: add wdm section (#248087)
- init.d/functions, halt: clean up some extraneous delays (#219816)
- ifup-wireless: set mode before bringing link up (#254046, <linville at redhat.com>)
- translation updates: pt_BR, hr

irssi-0.8.12-1.fc8
------------------
* Mon Oct 08 2007 Marek Mahut <mmahut fedoraproject.org> - 0.8.12-1
- New release
- Fixes bug from BZ#239511, dropping patch

kazehakase-0.4.9-2.fc8
----------------------
* Mon Oct 08 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2
- Readd accidentally deleted obsolete_plugin_ver macro

kernel-2.6.23-0.224.rc9.git6.fc8
--------------------------------
* Mon Oct 08 2007 Dave Jones <davej at redhat.com>
- Add a bunch of modules to the 586 kernel for the livecd.

* Mon Oct 08 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git6

* Sat Oct 06 2007 Dave Jones <davej at redhat.com>
- 2.6.23-rc9-git4

kismet-0.0.2007.10.R1-0.fc8
---------------------------
* Mon Oct 08 2007 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.0.2007.10.R1-1
- updated to 2007-10-R1
- dropped/rediffed patches
- added BR on dbus-devel

lash-0.5.3-3.fc8
----------------
* Mon Oct 08 2007 Anthony Green <green at redhat.com> 0.5.3-3
- Disable pylash until we can figure out how to install it properly.

* Mon Oct 08 2007 Anthony Green <green at redhat.com> 0.5.3-2
- Fixed python installation for 64-bit systems.

* Sun Oct 07 2007 Anthony Green <green at redhat.com> 0.5.3-1
- Upgrade sources.
- Don't install info files (no longer built).
- Add python package.

ltrace-0.5-9.45svn.fc8
----------------------
* Wed Sep 12 2007 Petr Machata <pmachata at redhat.com> - 0.5-9.45svn
- Cleanup spec.
- Fix parallel make bug in Makefile.
- resolves: #226109

* Thu Aug 16 2007 Petr Machata <pmachata at redhat.com> - 0.5-8.45svn
- Fix licensing tag.

lyx-1.5.2-1.fc8
---------------
* Mon Oct 08 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5.2-1
- lyx-1.5.2

ogre-1.4.5-1.fc8
----------------
* Mon Oct 08 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.4.5-1
- New upstream release 1.4.5

oprofile-0.9.3-6.fc8
--------------------
* Mon Oct 08 2007 Will Cohen <wcohen at redhat.com> - 0.9.3-5
- Should be popt-devel to BuildRequires.

* Mon Oct 08 2007 Will Cohen <wcohen at redhat.com> - 0.9.3-5
- Add popt to BuildRequires.

* Mon Oct 08 2007 Will Cohen <wcohen at redhat.com> - 0.9.3-4
- Allow short forms of --list-events (-l)  and --dump (-d).
  Resolves: rhbz#234003.

php-pecl-phar-1.2.2-1.fc8
-------------------------
* Mon Oct 08 2007 Remi Collet <Fedora at FamilleCollet.com> 1.2.2-1
- update to 1.2.1
pidgin-2.2.1-2.fc8
------------------
* Sun Oct 07 2007 Michel Salim <michel.sylvan at gmail.com> - 2.2.1-2
- BR on avahi-glib-devel to supply complete set of Avahi headers

* Mon Oct 01 2007 Warren Togami <wtogami at redhat.com> - 2.2.1-1
- 2.2.1 with many bug fixes and CVE-2007-4996 DOS fix

* Sat Sep 29 2007 Michel Salim <michel.sylvan at gmail.com> - 2.2.0-3
- Build against avahi proper instead of its HOWL compatibility layer

policycoreutils-2.0.29-1.fc8
----------------------------
* Sun Oct 07 2007 Dan Walsh <dwalsh at redhat.com> 2.0.29-1
- Update to upstream
	* Add genhomedircon script to invoke semodule -Bn from Dan Walsh.
- Add deleteall for ports and fcontext

redhat-artwork-7.0.0-14.fc8
---------------------------
* Mon Oct 08 2007 Matthias Clasen <mclasen at redhat.com> - 7.0.0-14
- Make the defaul theme not show up as "Custom"

rpy-1.0-0.3.RC3.fc8
-------------------
* Mon Oct 08 2007 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.0-0.3.RC3
- Rebuild for R 2.6.0 (really).

samba-0:3.0.26a-3.fc8
---------------------
* Sat Oct 06 2007 Simo Sorce <ssorce at redhat.com> 3.0.26a-3.fc8
- Fix bug 245506

sbcl-1.0.10-1.fc8
-----------------
* Mon Oct 08 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.10-1
- sbcl-1.0.10

shadow-utils-2:4.0.18.1-18.fc8
------------------------------
* Mon Oct 08 2007 Peter Vrabec <pvrabec at redhat.com> 2:4.0.18.1-18
- mark localized man pages with %lang

straw-0.27-10.fc8
-----------------
* Sat Oct 06 2007 Subhodip Biswas <440volt.tux at gmail.com> - 0.27-10
- Excluded ppc64 dur to dependency problem related to 
- gnome-python2-extras

system-config-network-1.4.2-1.fc8
---------------------------------
* Mon Oct 08 2007 Harald Hoyer <harald at redhat.com> - 1.4.2
- speedup genClass
- restorecon selinux context

system-config-samba-1.2.54-1.fc8
--------------------------------
* Mon Oct 08 2007 Nils Philippsen <nphilipp at redhat.com>
- add "make diff" ("dif") and "make shortdiff" ("sdif")
- pull in updated translations

system-config-services-0.9.12-1.fc8
-----------------------------------
* Mon Oct 08 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.12
- add "make diff" ("dif") and "make shortdiff" ("sdif")
- pull in updated translations

vkeybd-0.1.17a-5.fc8
--------------------
* Sun Oct 07 2007 Anthony Green <green at redhat.com> 0.1.17a-5
- Add -no-OSS patch.

* Sun Oct 07 2007 Anthony Green <green at redhat.com> 0.1.17a-4
- Rebuild for new lash.

wine-0.9.46-1.fc8
-----------------
* Sun Oct 07 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

* Sun Sep 16 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.45-1
- version upgrade

wine-docs-0.9.46-1.fc8
----------------------
* Mon Oct 08 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

xmlto-0.0.18-16
---------------
* Mon Oct 08 2007 Ondrej Vasik <ovasik at redhat.com> - 0.0.18-16
- fixed warning message from find in usage() display(#322121)

yum-3.2.6-2.fc8
---------------
* Mon Oct 08 2007 Seth Vidal <skvidal at fedoraproject.org> 3.2.6-2
- fixes pre-3.2.7

* Fri Oct 05 2007 Seth Vidal <skvidal at fedoraproject.org> 3.2.6-1
- 3.2.6 
- remove all old patches

* Tue Sep 25 2007 Jeremy Katz <katzj at redhat.com> - 3.2.5-4
- pull in fixes from upstream for media handling, pkgid (#291471), and 
  a potential depsolving bug

Broken deps for i386
----------------------------------------------------------
	fluidsynth - 1.0.7-9.a.fc8.i386 requires liblash.so.2
	fluidsynth-libs - 1.0.7-9.a.fc8.i386 requires liblash.so.2
	ghc-gtk2hs - 0.9.12-2.fc8.i386 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.i386 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	maxima-runtime-sbcl - 5.13.0-6.fc8.i386 requires sbcl = 0:1.0.9
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	seq24 - 0.8.7-6.fc6.i386 requires liblash.so.2
	zynaddsubfx - 2.2.1-14.fc7.i386 requires liblash.so.2



Broken deps for x86_64
----------------------------------------------------------
	fluidsynth - 1.0.7-9.a.fc8.x86_64 requires liblash.so.2()(64bit)
	fluidsynth-libs - 1.0.7-9.a.fc8.i386 requires liblash.so.2
	fluidsynth-libs - 1.0.7-9.a.fc8.x86_64 requires liblash.so.2()(64bit)
	ghc-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.x86_64 requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	maxima-runtime-sbcl - 5.13.0-6.fc8.x86_64 requires sbcl = 0:1.0.9
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	seq24 - 0.8.7-6.fc6.x86_64 requires liblash.so.2()(64bit)
	zynaddsubfx - 2.2.1-14.fc7.x86_64 requires liblash.so.2()(64bit)



Broken deps for ppc
----------------------------------------------------------
	fluidsynth - 1.0.7-9.a.fc8.ppc requires liblash.so.2
	fluidsynth-libs - 1.0.7-9.a.fc8.ppc requires liblash.so.2
	fluidsynth-libs - 1.0.7-9.a.fc8.ppc64 requires liblash.so.2()(64bit)
	ghc-gtk2hs - 0.9.12-2.fc8.ppc requires ghc = 0:6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires /usr/bin/ghc-pkg-6.6.1
	ghc661-gtk2hs - 0.9.12-2.fc8.ppc requires ghc661
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	maxima-runtime-sbcl - 5.13.0-6.fc8.ppc requires sbcl = 0:1.0.9
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	seq24 - 0.8.7-6.fc6.ppc requires liblash.so.2
	zynaddsubfx - 2.2.1-14.fc7.ppc requires liblash.so.2



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	fluidsynth - 1.0.7-9.a.fc8.ppc64 requires liblash.so.2()(64bit)
	fluidsynth-libs - 1.0.7-9.a.fc8.ppc64 requires liblash.so.2()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics
	zynaddsubfx - 2.2.1-14.fc7.ppc64 requires liblash.so.2()(64bit)





From green at redhat.com  Tue Oct  9 10:17:03 2007
From: green at redhat.com (Anthony Green)
Date: Tue, 09 Oct 2007 03:17:03 -0700
Subject: rawhide report: 20071009 changes
In-Reply-To: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
References: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
Message-ID: <470B551F.1000907@redhat.com>

The rawhide report says:
> Broken deps for i386
> ----------------------------------------------------------
> 	fluidsynth - 1.0.7-9.a.fc8.i386 requires liblash.so.2
> 	fluidsynth-libs - 1.0.7-9.a.fc8.i386 requires liblash.so.2
> 	seq24 - 0.8.7-6.fc6.i386 requires liblash.so.2
> 	zynaddsubfx - 2.2.1-14.fc7.i386 requires liblash.so.2

I've fixed these ones (for all archs).

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/6b6ad2de/attachment.vcf>

From sundaram at fedoraproject.org  Tue Oct  9 10:20:29 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Oct 2007 15:50:29 +0530
Subject: rawhide report: 20071009 changes
In-Reply-To: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
References: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
Message-ID: <470B55ED.2070309@fedoraproject.org>

Build System wrote:

> kernel-2.6.23-0.224.rc9.git6.fc8
> --------------------------------
> * Mon Oct 08 2007 Dave Jones <davej at redhat.com>
> - Add a bunch of modules to the 586 kernel for the livecd.

Do live images support the i586 arch?

Rahul



From mike.cohler at gmail.com  Tue Oct  9 11:02:06 2007
From: mike.cohler at gmail.com (Mike C)
Date: Tue, 9 Oct 2007 11:02:06 +0000 (UTC)
Subject: yum-updatesd in F8?
Message-ID: <loom.20071009T110055-482@post.gmane.org>

Can someone say if yum-updatesd will be in F8 final - and if so whether it
really works or not?  It never did for me in F7.



From dcbw at redhat.com  Tue Oct  9 11:10:53 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 09 Oct 2007 07:10:53 -0400
Subject: Test NetworkManager-openvpn?
In-Reply-To: <20071009112324.42606788@python3.es.egwn.lan>
References: <4705BCF4.2070207@redhat.com> <20071005074413.07744715@redhat.com>
	<20071005181805.4a85545d@localhost.localdomain>
	<20071009112324.42606788@python3.es.egwn.lan>
Message-ID: <1191928253.599.0.camel@localhost.localdomain>

On Tue, 2007-10-09 at 11:23 +0200, Matthias Saou wrote:
> Thomas Canniot wrote :
> 
> > Le Fri, 5 Oct 2007 07:44:13 -0400,
> > Jesse Keating <jkeating at redhat.com> a ?crit :
> > 
> > > On Fri, 05 Oct 2007 00:26:28 -0400
> > > Warren Togami <wtogami at redhat.com> wrote:
> > > 
> > > > Can someone test the equivalent for NetworkManager-openvpn with
> > > > Selinux enforcing enabled?  Please test it in both "service
> > > > NetworkManager start" and "NetworkManager --no-daemon" mode to be
> > > > sure both are functioning properly.
> > > 
> > > That's a little difficult when NM-openvpn hasn't yet been ported to
> > > NM-0.7 infrastructure.
> > > 
> > 
> > On FC7, I had absolutely no problem using it... in fact, it is the
> > light at the end of the tunnel for me. It works so great and out of the
> > box (certificate and login / pwd identification on a wpa network). I
> > can now connect very easily in my university.
> 
> WPA? Then you probably mean Wireless, not VPN :-)
> 
> I use NM with OpenVPN on F-7, and although it "mostly works" (I use
> certificates with login/pass), it gets things completely wrong
> regarding network routes. I still have some open bug reports about this
> upstream...

Tambet committed bits yesterday to port the openvpn plugin to the new
VPN plugin API; we need testing on it though.  I suppose that means
packaging up what's in SVN so people can report the issues.

Dan

> Matthias
> 
> -- 
> Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
> Fedora release 7 (Moonshine) - Linux kernel 2.6.22.6-81.fc7
> Load : 0.27 0.37 0.36
> 



From ian at stams.strath.ac.uk  Tue Oct  9 11:42:03 2007
From: ian at stams.strath.ac.uk (Ian Thurlbeck)
Date: Tue, 09 Oct 2007 12:42:03 +0100
Subject: FC8t3 issues
Message-ID: <470B690B.80900@stams.strath.ac.uk>


Dear All

here is a grab bag of things I noticed trying out FC8 test 3 + current updates.

Please advise if I should bugzilla any of them:

1) installer: cosmetic redraw bugs on custom partition editor page
    82915/GV/... graphics

2) installer: checking "Additional Fedora Software" when behind a proxy
    hangs anaconda "retrieving mirrorlist" (may timeout?)

3) gdm: cannot log in when using NIS authentication

    pam_unix(gdm:auth): check pass; user unknown

    Old bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=134393

    Fix to set USENIS=yes in /etc/sysconfig/authconfig works - why doesn't it
    just use the rules in /etc/nsswitch.conf ?

    workaround: setting DISPLAYMANAGER="KDE" in /etc/sysconfig/desktop to run kdm

4) xmms KDE_Window_Open.wav

    ** WARNING **: Failed to open font: "-adobe-helvetica-bold-r-*-*-10-*"

    requires xorg-x11-fonts-75dpi.noarch to quieten this.

5) hald runs as uid 68 but this has no entry in /etc/passwd ?

6) lpstat -t lists printers in long format, even if you
    set BrowseShortNames Yes option:

    device for col at dunnet: ipp://dunnet:631/printers/col

    when it should be:

    device for col: ipp://dunnet:631/printers/col

    compiling a fresh cups from 1.3.3 cups.org source lists short names printers.

That's all so far!

Many thanks

Ian
-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



From snecklifter at gmail.com  Tue Oct  9 11:49:00 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Tue, 9 Oct 2007 12:49:00 +0100
Subject: yum-updatesd in F8?
In-Reply-To: <loom.20071009T110055-482@post.gmane.org>
References: <loom.20071009T110055-482@post.gmane.org>
Message-ID: <364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>

On 09/10/2007, Mike C <mike.cohler at gmail.com> wrote:
>
> Can someone say if yum-updatesd will be in F8 final


Yes.

- and if so whether it
> really works or not?


Yes. It really WORKSFORME.

 It never did for me in F7.


Sorry to hear it. I have also found it flaky in F7 but there is always
bugzilla and rawhide to test from if you can.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/b504ae42/attachment.htm>

From sundaram at fedoraproject.org  Tue Oct  9 12:03:32 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Oct 2007 17:33:32 +0530
Subject: FC8t3 issues
In-Reply-To: <470B690B.80900@stams.strath.ac.uk>
References: <470B690B.80900@stams.strath.ac.uk>
Message-ID: <470B6E14.8090508@fedoraproject.org>

Ian Thurlbeck wrote:
> 
> Dear All
> 
> here is a grab bag of things I noticed trying out FC8 test 3 + current 
> updates.
> 
> Please advise if I should bugzilla any of them:

Thanks for the feedback. Please check and file bug reports for all of them.

Rahul



From mschwendt.tmp0701.nospam at arcor.de  Tue Oct  9 12:10:22 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 9 Oct 2007 14:10:22 +0200
Subject: rpms/liblrdf/FC-6 liblrdf.spec,1.6,1.7
In-Reply-To: <200710091122.l99BMXqs029700@cvs-int.fedora.redhat.com>
References: <200710091122.l99BMXqs029700@cvs-int.fedora.redhat.com>
Message-ID: <20071009141022.277f7326.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 9 Oct 2007 07:22:33 -0400, Anthony Green (green) wrote:

> Author: green
> 
> Update of /cvs/extras/rpms/liblrdf/FC-6

> -%exclude %{_datadir}/ladspa/rdf/ladspa.rdfs
> +%{_datadir}/ladspa/rdf/ladspa.rdfs

What's the full story here?
https://bugzilla.redhat.com/show_bug.cgi?id=189313#c6
What has changed?



From katzj at redhat.com  Tue Oct  9 12:11:01 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 08:11:01 -0400
Subject: rawhide report: 20071009 changes
In-Reply-To: <470B55ED.2070309@fedoraproject.org>
References: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
	<470B55ED.2070309@fedoraproject.org>
Message-ID: <1191931861.28263.74.camel@localhost.localdomain>

On Tue, 2007-10-09 at 15:50 +0530, Rahul Sundaram wrote:
> Build System wrote:
> > kernel-2.6.23-0.224.rc9.git6.fc8
> > --------------------------------
> > * Mon Oct 08 2007 Dave Jones <davej at redhat.com>
> > - Add a bunch of modules to the 586 kernel for the livecd.
> 
> Do live images support the i586 arch?

No; the live images are built with the i686 kernel

Jeremy



From green at redhat.com  Tue Oct  9 12:41:25 2007
From: green at redhat.com (Anthony Green)
Date: Tue, 09 Oct 2007 05:41:25 -0700
Subject: rpms/liblrdf/FC-6 liblrdf.spec,1.6,1.7
In-Reply-To: <20071009141022.277f7326.mschwendt.tmp0701.nospam@arcor.de>
References: <200710091122.l99BMXqs029700@cvs-int.fedora.redhat.com>
	<20071009141022.277f7326.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <470B76F5.1020501@redhat.com>

Michael Schwendt wrote:
> On Tue, 9 Oct 2007 07:22:33 -0400, Anthony Green (green) wrote:
> 
>> Author: green
>>
>> Update of /cvs/extras/rpms/liblrdf/FC-6
> 
>> -%exclude %{_datadir}/ladspa/rdf/ladspa.rdfs
>> +%{_datadir}/ladspa/rdf/ladspa.rdfs
> 
> What's the full story here?
> https://bugzilla.redhat.com/show_bug.cgi?id=189313#c6
> What has changed?

nando (on copy now) filed the following bug...
https://bugzilla.redhat.com/show_bug.cgi?id=277361

AG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/984104b6/attachment.vcf>

From pertusus at free.fr  Tue Oct  9 12:48:24 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Oct 2007 14:48:24 +0200
Subject: FC8t3 issues
In-Reply-To: <470B690B.80900@stams.strath.ac.uk>
References: <470B690B.80900@stams.strath.ac.uk>
Message-ID: <20071009124824.GB2622@free.fr>

On Tue, Oct 09, 2007 at 12:42:03PM +0100, Ian Thurlbeck wrote:
>
> 5) hald runs as uid 68 but this has no entry in /etc/passwd ?

That's not related with hal, but it is for all the username with length
greater than 8. Don't you have an entry like:
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin

--
Pat



From ian at stams.strath.ac.uk  Tue Oct  9 13:10:16 2007
From: ian at stams.strath.ac.uk (Ian Thurlbeck)
Date: Tue, 09 Oct 2007 14:10:16 +0100
Subject: FC8t3 issues
In-Reply-To: <470B690B.80900@stams.strath.ac.uk>
References: <470B690B.80900@stams.strath.ac.uk>
Message-ID: <470B7DB8.5030701@stams.strath.ac.uk>

Ian Thurlbeck wrote:
> 
> Dear All
> 
> here is a grab bag of things I noticed trying out FC8 test 3 + current 
> updates.
> 
> Please advise if I should bugzilla any of them:
> 
> 1) installer: cosmetic redraw bugs on custom partition editor page
>    82915/GV/... graphics
> 

Existing bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=289281

> 2) installer: checking "Additional Fedora Software" when behind a proxy
>    hangs anaconda "retrieving mirrorlist" (may timeout?)

Making anaconda proxy aware is raised here: 
https://bugzilla.redhat.com/show_bug.cgi?id=141988

And RFE here: https://bugzilla.redhat.com/show_bug.cgi?id=125917

My filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=324801

> 3) gdm: cannot log in when using NIS authentication
> 
>    pam_unix(gdm:auth): check pass; user unknown
> 
>    Old bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=134393
> 
>    Fix to set USENIS=yes in /etc/sysconfig/authconfig works - why 
> doesn't it
>    just use the rules in /etc/nsswitch.conf ?
> 
>    workaround: setting DISPLAYMANAGER="KDE" in /etc/sysconfig/desktop to 
> run kdm

My filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=324811

> 4) xmms KDE_Window_Open.wav
> 
>    ** WARNING **: Failed to open font: "-adobe-helvetica-bold-r-*-*-10-*"
> 
>    requires xorg-x11-fonts-75dpi.noarch to quieten this.

My filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=324821

> 5) hald runs as uid 68 but this has no entry in /etc/passwd ?

Whoops, actually it has "haldaemon".  ps -ef does not list the username
for usernames > 8 chars, so it's defined behaviour, see:

http://procps.sourceforge.net/faq.html

> 6) lpstat -t lists printers in long format, even if you
>    set BrowseShortNames Yes option:
> 
>    device for col at dunnet: ipp://dunnet:631/printers/col
> 
>    when it should be:
> 
>    device for col: ipp://dunnet:631/printers/col
> 
>    compiling a fresh cups from 1.3.3 cups.org source lists short names 
> printers.

This has had a previous incarnation:

https://bugzilla.redhat.com/show_bug.cgi?id=201800

which was fixed, apparently. Removing /var/cache/cups/remote.cache as
suggested does indeed fix the problem. However, under some circumstances
the issue still occurs, so:

My filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=324851

> That's all so far!
> 
> Many thanks
> 
> Ian


-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



From ssorce at redhat.com  Tue Oct  9 13:32:58 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 09:32:58 -0400
Subject: samba license change
In-Reply-To: <1191911966.7000.4.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
	<1191911966.7000.4.camel@localhost.localdomain>
Message-ID: <1191936778.8880.5.camel@localhost.localdomain>

On Tue, 2007-10-09 at 08:39 +0200, Lubomir Kundrak wrote:
> On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> > Simo Sorce wrote:
> > 
> > > Is this because of the QT license?
> > > If so it seem that QT has a lot of exceptions:
> > > http://trolltech.com/products/qt/gplexception
> > > I wonder why GPLv3 is not on the list yet.
> > > 
> > > Does anyone have more details?
> > 
> > Last I heard TrollTech was still evaluating this option.
> > 
> > http://chani.wordpress.com/2007/07/18/uhoh/#comment-1932
> > 
> > Essentially unless the entire dependency chain for Samba is GPLv3 
> > compatible, a new samba version under GPLv3 or later would be impossible 
> > to pull as incompatible licensing is a liability for the distribution 
> > and not necessarily for the individual components.
> 
> This also applies to the patches from the samba upstream. Simo: do you
> have an idea wheter it would be possible to convince the samba upstream
> to release at least security fixes for samba under GPLv2?

Security Fixes for 3.0.x Series are guaranteed for 1 year after 3.2.0
will be released and of course they will be GPLv2. We are responsible
people guys, no worries.

Simo.



From ssorce at redhat.com  Tue Oct  9 13:34:05 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 09:34:05 -0400
Subject: samba license change
In-Reply-To: <470B1F20.1010905@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
Message-ID: <1191936845.8880.8.camel@localhost.localdomain>

On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> Essentially unless the entire dependency chain for Samba is GPLv3 
> compatible, a new samba version under GPLv3 or later would be
> impossible 
> to pull as incompatible licensing is a liability for the distribution 
> and not necessarily for the individual components. 

It's the other way around, it is KDE (Konqueror uses libsmbclient) that
depends on Samba, Samba has no dependency problems at all.

Simo.



From tjb at unh.edu  Tue Oct  9 13:34:28 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Tue, 09 Oct 2007 09:34:28 -0400
Subject: Gnome Logout Hangs?
Message-ID: <1191936868.4913.2.camel@raptor.sr.unh.edu>


I saw a while back (if I'm recalling correctly) Jesse acknowledging the
gnome logout hang bug as known and should be fixed by a forthcoming X11
update but that was several weeks ago and it still happens for me. Is it
something I'm running or is it still happening for everyone?

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From notting at redhat.com  Tue Oct  9 13:07:52 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Oct 2007 09:07:52 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <470B0E6D.3000606@gmail.com>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
Message-ID: <20071009130752.GA18900@nostromo.devel.redhat.com>

Toshio Kuratomi (a.badger at gmail.com) said: 
> Pick one as the default (Probably totem-gstreamer since the rest of our 
> infrastructure is based around gstreamer.)  The other one can either be 
> invoked by using totem-xine or a shell script can be used to select which 
> one to run (based on what's installed, an environment variable, and the 
> default.)

Surely you just want to have the engines selected by a user pref?

Bill



From sundaram at fedoraproject.org  Tue Oct  9 13:36:29 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Oct 2007 19:06:29 +0530
Subject: samba license change
In-Reply-To: <1191936845.8880.8.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>	<1191882314.2199.7.camel@localhost.localdomain>	<470B1F20.1010905@fedoraproject.org>
	<1191936845.8880.8.camel@localhost.localdomain>
Message-ID: <470B83DD.8090909@fedoraproject.org>

Simo Sorce wrote:
> On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
>> Essentially unless the entire dependency chain for Samba is GPLv3 
>> compatible, a new samba version under GPLv3 or later would be
>> impossible 
>> to pull as incompatible licensing is a liability for the distribution 
>> and not necessarily for the individual components. 
> 
> It's the other way around, it is KDE (Konqueror uses libsmbclient) that
> depends on Samba, Samba has no dependency problems at all.

Right but then Fedora would end up with a license violation if you push 
the GPLv3 samba into the distribution. Whatever packages depends on 
samba needs to be GPLv3 compatible before we do the push.

Rahul



From rdieter at math.unl.edu  Tue Oct  9 13:33:13 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 09 Oct 2007 08:33:13 -0500
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
Message-ID: <fefvuq$ak4$1@sea.gmane.org>

Ville Skytt? wrote:

> On 10/3/07, Simo Sorce <ssorce at redhat.com> wrote:
>> Samba has changed it's license from GPLv2+ to GPLv3+
>> The license change affects version 3.2.0 (still a pre-release now).
>> In F-8 we will still have 3.0.X so the change affects F-9
> 
> Looks like KDE may suffer from this, both kdebase and kdebase4 are
> labeled GPLv2 (no "+").

Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will have
to be dropped, at least temporarily.

(1) qt is GPLv2, trolltech is evaluating GPLv2+ or GPLv3, but that's all
behind closed doors with no visible movement.  There is a proposal within
kde to move to (L)GPLv2+.  All of this is slow, tedious work, often
blocking on lawyers, and we all know how fast they are.

-- Rex



From mclasen at redhat.com  Tue Oct  9 13:39:15 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 09 Oct 2007 09:39:15 -0400
Subject: samba license change
In-Reply-To: <1191936845.8880.8.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
	<1191936845.8880.8.camel@localhost.localdomain>
Message-ID: <1191937155.2598.2.camel@localhost.localdomain>


On Tue, 2007-10-09 at 09:34 -0400, Simo Sorce wrote:
> On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> > Essentially unless the entire dependency chain for Samba is GPLv3 
> > compatible, a new samba version under GPLv3 or later would be
> > impossible 
> > to pull as incompatible licensing is a liability for the distribution 
> > and not necessarily for the individual components. 
> 
> It's the other way around, it is KDE (Konqueror uses libsmbclient) that
> depends on Samba, Samba has no dependency problems at all.

Yeah, samba just ignores the problems that it causes for its
dependencies...



From lmacken at redhat.com  Tue Oct  9 13:40:29 2007
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 9 Oct 2007 09:40:29 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
Message-ID: <20071009134029.GA12588@crow.myhome.westell.com>

On Tue, Oct 09, 2007 at 12:49:00PM +0100, Christopher Brown wrote:
> On 09/10/2007, Mike C <mike.cohler at gmail.com> wrote:
> > Can someone say if yum-updatesd will be in F8 final
> 
> Yes.
> 
> - and if so whether it
> > really works or not?
> 
> Yes. It really WORKSFORME.
> 
> >  It never did for me in F7.
> 
> Sorry to hear it. I have also found it flaky in F7 but there is always
> bugzilla and rawhide to test from if you can.

yum-updatesd has seen *significant* improvements since F7,
especially with memory usage.

     Private  +   Shared  =  RAM used       Program 
      6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd


luke



From rdieter at math.unl.edu  Tue Oct  9 13:36:37 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 09 Oct 2007 08:36:37 -0500
Subject: Another readahead issue
References: <1191889707.25531.49.camel@vincent52.localdomain>
Message-ID: <feg055$ak4$2@sea.gmane.org>

Matthew Saltzman wrote:

> Not sure if I should have started a new thread, but...
> 
> If you *are* going to keep or eventually revive readahead, it would be
> nice to deal with the fact that all the firefox entries in default.later
> are /usr/lib/firefox-2.0.0.3/, but the current firefox is
> firefox-2.0.0.5.

imo, avoid the mess, firefox could use an unversioned folder,
say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
else the firefox packagin/maintainer would be doing this already, right? :)

-- Rex



From berrange at redhat.com  Tue Oct  9 13:43:21 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 9 Oct 2007 14:43:21 +0100
Subject: samba license change
In-Reply-To: <fefvuq$ak4$1@sea.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<fefvuq$ak4$1@sea.gmane.org>
Message-ID: <20071009134321.GA4031@redhat.com>

On Tue, Oct 09, 2007 at 08:33:13AM -0500, Rex Dieter wrote:
> Ville Skytt? wrote:
> 
> > On 10/3/07, Simo Sorce <ssorce at redhat.com> wrote:
> >> Samba has changed it's license from GPLv2+ to GPLv3+
> >> The license change affects version 3.2.0 (still a pre-release now).
> >> In F-8 we will still have 3.0.X so the change affects F-9
> > 
> > Looks like KDE may suffer from this, both kdebase and kdebase4 are
> > labeled GPLv2 (no "+").
> 
> Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will have
> to be dropped, at least temporarily.

Or keep around the GPLv2'd 3.0.x version as compat-libsmbclient  for 
KDE & others in the same position to link against, while the rest of 
the apps which can use the GPLv3 newer libs. Or bundle the older release
libsmbclient.so inside the KDE  package in a private lib directory

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From james.antill at redhat.com  Tue Oct  9 13:43:39 2007
From: james.antill at redhat.com (James Antill)
Date: Tue, 09 Oct 2007 09:43:39 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <loom.20071009T110055-482@post.gmane.org>
References: <loom.20071009T110055-482@post.gmane.org>
Message-ID: <1191937419.19193.11.camel@code.and.org>

On Tue, 2007-10-09 at 11:02 +0000, Mike C wrote:
> Can someone say if yum-updatesd will be in F8 final - and if so whether it
> really works or not?  It never did for me in F7.

 There is a package in F8 called yum-updatesd, however that package is
completely different to the one in F7 and should have fixed a lot (if
not all) of the problems.
 In fact you can even do:

yum install yum-updatesd --enablerepo=development

...if you want to install that version on your F7 machines. Also if you 

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- 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/20071009/e237d40c/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct  9 13:46:46 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 09 Oct 2007 19:16:46 +0530
Subject: yum-updatesd in F8?
In-Reply-To: <1191937419.19193.11.camel@code.and.org>
References: <loom.20071009T110055-482@post.gmane.org>
	<1191937419.19193.11.camel@code.and.org>
Message-ID: <470B8646.9040000@fedoraproject.org>

James Antill wrote:
> On Tue, 2007-10-09 at 11:02 +0000, Mike C wrote:
>> Can someone say if yum-updatesd will be in F8 final - and if so whether it
>> really works or not?  It never did for me in F7.
> 
>  There is a package in F8 called yum-updatesd, however that package is
> completely different to the one in F7 and should have fixed a lot (if
> not all) of the problems.
>  In fact you can even do:
> 
> yum install yum-updatesd --enablerepo=development

Any chance this is going to be pushed as an update to Fedora 7?

Rahul



From katzj at redhat.com  Tue Oct  9 13:57:55 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 09:57:55 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <470B8646.9040000@fedoraproject.org>
References: <loom.20071009T110055-482@post.gmane.org>
	<1191937419.19193.11.camel@code.and.org>
	<470B8646.9040000@fedoraproject.org>
Message-ID: <1191938275.5449.0.camel@localhost.localdomain>

On Tue, 2007-10-09 at 19:16 +0530, Rahul Sundaram wrote:
> James Antill wrote:
> > On Tue, 2007-10-09 at 11:02 +0000, Mike C wrote:
> >> Can someone say if yum-updatesd will be in F8 final - and if so whether it
> >> really works or not?  It never did for me in F7.
> > 
> >  There is a package in F8 called yum-updatesd, however that package is
> > completely different to the one in F7 and should have fixed a lot (if
> > not all) of the problems.
> >  In fact you can even do:
> > 
> > yum install yum-updatesd --enablerepo=development
> 
> Any chance this is going to be pushed as an update to Fedora 7?

It comes up as a question from time to time...  it's probably worth
doing, there just aren't enough hours in the day :-/

Jeremy



From bnocera at redhat.com  Tue Oct  9 13:59:59 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 9 Oct 2007 13:59:59 +0000 (UTC)
Subject: Merging totem and totem-xine
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
Message-ID: <loom.20071009T134853-933@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
<snip>
> Toshio Kuratomi (a.badger <at> gmail.com) said: 
> > Pick one as the default (Probably totem-gstreamer since the rest of our 
> > infrastructure is based around gstreamer.)  The other one can either be 
> > invoked by using totem-xine or a shell script can be used to select which 
> > one to run (based on what's installed, an environment variable, and the 
> > default.)
> 
> Surely you just want to have the engines selected by a user pref?

I'd go for a shell script (probably the same one symlinked). Something like:

#!/bin/sh

if [ -f ~/.local/etc/sysconfig/totem ] ; then
      . ~/.local/etc/sysconfig/totem
else if [ -f /etc/sysconfig/totem ] ; then
      . /etc/sysconfig/totem
fi

# Default to GStreamer if there's no config
if [ -z $TOTEM_BACKEND ] ; then
      TOTEM_BACKEND=gstreamer
fi
# Default to GStreamer if the backend is invalid
if [ $TOTEM_BACKEND != "xine" -a $TOTEM_BACKEND != "gstreamer" ] ; then
      TOTEM_BACKEND=gstreamer
fi

BIN=$0
shift

exec $BIN-$TOTEM_BACKEND $*

Obviously, not tested, but this would allow to switch between backends. This
would also need some checking whether or not the backend is there.

I'm not interested in users being able to select one backend for each of the 4
binaries, it would just create more confusion.

Cheers



From notting at redhat.com  Tue Oct  9 14:06:39 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Oct 2007 10:06:39 -0400
Subject: Another readahead issue
In-Reply-To: <feg055$ak4$2@sea.gmane.org>
References: <1191889707.25531.49.camel@vincent52.localdomain>
	<feg055$ak4$2@sea.gmane.org>
Message-ID: <20071009140639.GC3939@nostromo.devel.redhat.com>

Rex Dieter (rdieter at math.unl.edu) said: 
> imo, avoid the mess, firefox could use an unversioned folder,
> say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
> else the firefox packagin/maintainer would be doing this already, right? :)

It doesn't have a consistent ABI, so using a single location would lead
to apps breaking when the ABI changes - at least with a different folder
they break in a predictable way.

Bill



From katzj at redhat.com  Tue Oct  9 14:08:34 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 10:08:34 -0400
Subject: FC8t3 issues
In-Reply-To: <470B690B.80900@stams.strath.ac.uk>
References: <470B690B.80900@stams.strath.ac.uk>
Message-ID: <1191938914.5449.5.camel@localhost.localdomain>

On Tue, 2007-10-09 at 12:42 +0100, Ian Thurlbeck wrote:
> 1) installer: cosmetic redraw bugs on custom partition editor page
>     82915/GV/... graphics

This is bug 289281

> 2) installer: checking "Additional Fedora Software" when behind a proxy
>     hangs anaconda "retrieving mirrorlist" (may timeout?)

Yes, the installer doesn't really have any proxy support currently.
This is something we're hoping to resolve for Fedora 9.  It should
timeout, though.

> 4) xmms KDE_Window_Open.wav
> 
>     ** WARNING **: Failed to open font: "-adobe-helvetica-bold-r-*-*-10-*"
> 
>     requires xorg-x11-fonts-75dpi.noarch to quieten this.

Looks like xmms is missing a requires; probably worth filing.

Jeremy



From mjs at CLEMSON.EDU  Tue Oct  9 14:14:00 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Tue, 09 Oct 2007 10:14:00 -0400
Subject: Another readahead issue
In-Reply-To: <feg055$ak4$2@sea.gmane.org>
References: <1191889707.25531.49.camel@vincent52.localdomain>
	<feg055$ak4$2@sea.gmane.org>
Message-ID: <1191939240.32242.45.camel@vincent52.localdomain>

On Tue, 2007-10-09 at 08:36 -0500, Rex Dieter wrote:
> Matthew Saltzman wrote:
> 
> > Not sure if I should have started a new thread, but...
> > 
> > If you *are* going to keep or eventually revive readahead, it would be
> > nice to deal with the fact that all the firefox entries in default.later
> > are /usr/lib/firefox-2.0.0.3/, but the current firefox is
> > firefox-2.0.0.5.
> 
> imo, avoid the mess, firefox could use an unversioned folder,
> say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
> else the firefox packagin/maintainer would be doing this already, right? :)

I thought of that (and had the same question).  Also thought
of /etc/readahead.d/readahead.early.d/, etc. and having packages include
their own readahead files.

I don't pretend to know enough to have a preference or if there's a
better mechanism than either of those.

> 
> -- Rex
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From rdieter at math.unl.edu  Tue Oct  9 14:17:21 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 09 Oct 2007 09:17:21 -0500
Subject: Another readahead issue
References: <1191889707.25531.49.camel@vincent52.localdomain>
	<feg055$ak4$2@sea.gmane.org>
	<20071009140639.GC3939@nostromo.devel.redhat.com>
Message-ID: <feg2hh$jse$1@sea.gmane.org>

Bill Nottingham wrote:

> Rex Dieter (rdieter at math.unl.edu) said:
>> imo, avoid the mess, firefox could use an unversioned folder,
>> say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
>> else the firefox packagin/maintainer would be doing this already, right?
>> :)
> 
> It doesn't have a consistent ABI, so using a single location would lead
> to apps breaking when the ABI changes - at least with a different folder
> they break in a predictable way.

I was afraid of that excuse.  Imo, Not a good one, bad packaging practice.

Dependent pkgs already (or should!) include (something like).
Requires: firefox = <some_version>

-- Rex



From bnocera at redhat.com  Tue Oct  9 14:18:37 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 09 Oct 2007 15:18:37 +0100
Subject: Merging totem and totem-xine
In-Reply-To: <loom.20071009T134853-933@post.gmane.org>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
Message-ID: <1191939517.3626.90.camel@cookie.hadess.net>

On Tue, 2007-10-09 at 13:59 +0000, Bastien Nocera wrote:
<snip>
> I'd go for a shell script (probably the same one symlinked). Something like:
> 
> #!/bin/sh
> 
> if [ -f ~/.local/etc/sysconfig/totem ] ; then
>       . ~/.local/etc/sysconfig/totem
> else if [ -f /etc/sysconfig/totem ] ; then
>       . /etc/sysconfig/totem
> fi

As Bill mentioned to me on IRC, getting the value from GConf would work
just as well, allowing admins to select the default one and enforce it,
or users to change theirs without affecting other users.



From seandarcy2 at gmail.com  Tue Oct  9 14:22:59 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Tue, 09 Oct 2007 10:22:59 -0400
Subject: f8t3 live: no networking on presario 700 (Broadcom)
In-Reply-To: <1191887833.28263.41.camel@localhost.localdomain>
References: <febsul$oim$1@sea.gmane.org>	<1191804935.28263.38.camel@localhost.localdomain>	<fec24n$3fu$1@sea.gmane.org>
	<1191887833.28263.41.camel@localhost.localdomain>
Message-ID: <feg2s5$lts$1@sea.gmane.org>

Jeremy Katz wrote:
> On Sun, 2007-10-07 at 21:45 -0400, sean darcy wrote:
>> Jeremy Katz wrote:
>>> On Sun, 2007-10-07 at 20:17 -0400, sean darcy wrote:
>>>> I have compaq presario 714n notebook, Intel G965 chipset. wireless is 
>>>> Broadcom BCM94311MCG mini-pci, which shows up in lspci.
>>> Broadcom does not make firmware for their wireless cards available in a
>>> freely redistributable form, so Fedora cannot distribute this firmware.
>>> Thus, it cannot work out of the box.  You can generate a firmware file
>>> using the b43-fwcutter utility, but this doesn't help much for the live
>>> environment.  Feel free to request that Broadcom provide freely
>>> redistributable firmware for their wireless products!
>>>
>> Well, would this work:
>>
>> I'm using live to install on a 20gig partition that already has windows 
>> installed.
>>
>> Can I install f8 ( from dvd or livecd ), download the fw43-cutter rpm 
>> under windows, use ntfs-utils to copy to the linux partition, install 
>> it, and Voila! ??
> 
> Yes.
> 
>> Is fw43-cutter on the dvd?
> 
> Not as of test3.  I just adjusted comps so that it will be on the DVD
> and the live images for the final release to help making this hardware a
> little easier
> 

Installed b43-fwcutter and followed the instructions at 
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware

Got http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2

untarred that file and ran
b43-fwcutter -w /lib/firmare broadcom-wl-4.80.53.0/kmod/wl_apsta.o

that seemed to work, and populated /lib/firmware/b43/ with a bunch of 
*.fw files.

Then rmmod b43; modprobe -vv b43. No errors. Nothing in syslog.

Also loaded cfg80211 and mac80211.

Shouldn't I have seen the firmware being loaded in dmesg, or syslog?

Made sure NetworkManager was working. I can see the icon. No connection.

Now what? I've never tried to use Fedora with wireless, so I may be 
missing something obvious.

sean




From chris.stone at gmail.com  Tue Oct  9 15:03:36 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 9 Oct 2007 08:03:36 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071008201103.2d814b5a@redhat.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
	<470A8327.1020204@gmail.com> <20071008201103.2d814b5a@redhat.com>
Message-ID: <d9c612bf0710090803r1138979pa51747d73ef7dc65@mail.gmail.com>

On 10/8/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Mon, 08 Oct 2007 12:21:11 -0700
> Toshio Kuratomi <a.badger at gmail.com> wrote:
>
> > If koji keeps track of dependencies it would be easier to implement
> > this there than in the packagedb at the moment.  The packagedb
> > doesn't currently track dependencies because the other tools do
> > that.  We could change that, but we probably need to sit down and
> > talk about what tools we want storing which information in the dbs.
>
>
> Actually in the koji db there are listed rpm requirements.
>
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=228266 is an example of srpm Requires which are the same as BuildRequires in the spec.  The problem is that many times these requires are somewhat generic and can be serviced by multiple packages and/or rely on indirect BuildRequires that are pulled in from the direct BuildRequires or the minimal buildroot.
>
> It is really quite difficult to get an accurate map of exactly which
> packages will ultimately need your package to build.

The notification system that is currently available might be the best
way to go then.  Perhaps we can enhance the notification system to be
easier to use.  For example, it could suggest packages you should
subscribe to for notifications.  In addition, there should be
notification levels like there are syslog levels.  So the most
important pushes which would require a rebuild would be set at the
highest notification level and then I can just filter out the
notifications I really care about this way.



From ville.skytta at iki.fi  Tue Oct  9 15:47:36 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 9 Oct 2007 18:47:36 +0300
Subject: [SOLVED] F8t3 k3b and sound problems
In-Reply-To: <470B5324.6030906@redhat.com>
References: <1191543150.11601.4.camel@scrappy.miketc.com>
	<20071008093351.1592a8e5@redhat.com> <470B5324.6030906@redhat.com>
Message-ID: <200710091847.36432.ville.skytta@iki.fi>

On Tuesday 09 October 2007, Harald Hoyer wrote:
> Jesse Keating wrote:
> > On Mon, 08 Oct 2007 08:22:24 -0500
> >
> > Mike Chambers <mike at miketc.com> wrote:
> >> Welp, turning on Consolekit and a quick reboot and BOTH k3b and my
> >> sound now seem to work.  So this *has* to be on for those type devices
> >> (removable and so on?) to work?
> >
> > ConsoleKit and PolicyKit work together to assign ACLs to the devices
> > for the active console user.  If it isn't running, the ACLs won't be
> > applied and you won't have access to use them.
>
> Think of them as the pam_console replacement.

Is there a in-a-nutshell guide somewhere how to migrate existing packages 
using pam_console to CK+PK?



From pknirsch at redhat.com  Tue Oct  9 15:59:28 2007
From: pknirsch at redhat.com (Phil Knirsch)
Date: Tue, 09 Oct 2007 17:59:28 +0200
Subject: rpm and post script install/run order question (texlive) [2]
In-Reply-To: <20071009080528.GC2616@free.fr>
References: <20071009080528.GC2616@free.fr>
Message-ID: <470BA560.4040702@redhat.com>

Patrice Dumas wrote:
> Hello,
> 
> My previous mail had errors, sorry. Resending.
> 
> I have some questions regarding rpm installation and script run order.
> It is for texlive, and I use letters that corresponds with:
> 
> A texlive
> B texlive-texmf
> C kpathsea
> D texlive-fonts
> E texlive-fonts-texmf
> 
> sA1 updmap-sys
> sA2 texconfig-sys
> 
> 
> We have:
> 
> A
> Requires: B C D
> Requires(post): sA2
> 
> B
> Requires(post): sA1 sA2
> 
> C doesn't requires anything, but has a post script (ldconfig) that must
>   be run before it can be used by programs in A or D.
> 
> D
> Requires: E C
> Requires(post): sA2
> 
> E
> Requires(post): sA1 sA2
> 
> The script sA1 is in A, but to be succesfull, it has to be run with A, B,
> C and D installed. If run multiple time, only the last run must be
> succesfull, but it should be run with all the packages that Requires it
> installed (B E), it is not a problem if previous runs are done wrong.
> sA2 is in A, but only requires A to be present to be successfull.
> 
> Unless I am wrong, in that kind of setup all the packages will be
> installed in the same batch (except maybe for C, but no user will
> ever install C directly).
> 
> I am not sure, however, what would be the order of installation of those
> packages, nor when would sA be called. For example, since C doesn't have
> any Requires(post) on A would it be possible to have an install order
> with C in the end, and the post scripts run before C is installed?
> Maybe there are other subtle possible failures? Also is the installation
> and post script run order dependent on which package is selected for,
> say a yum install, that is will:
> 
> yum install A
> yum install E
> yum install B
> 
> and so on and so forth give the same installation and post script run
> order?
> 
> My question may be a bit confused, so don't hesitate to ask for more
> info. Also I couldn't find a place where such issues are explained in
> depth. In the usual rpm manuals there are some explanations, but not
> precise enough. Is there some doc I could have missed?
> 
> The example is a bit simplified, since additionnally there is a
> dependency cycle between texlive-dvips and texlive-fonts, and also there
> is texlive-latex, but the issues faced shouldn't be different than for
> the example above, unless I missed something.
> 
> --
> Pat
> 

Well, from looking at the dependencies you listed here the dependency 
tree would look like this:




updmap-sys    texconfig-sys    C
   /|\             /|\
    |               |
            E       B
           /|\
            |
            D
           /|\
            |
            A


So effectively this means that on the 1st level of the tree updmap-sys, 
texconfig-sys and C can be ordered in any way as well as on the 2nd 
level E and B as they have no cross and/or chained dependencies.

So to answer your questions:

1) Can C be installed prior to sA being called: No, as the dependency 
chain clearly require B, C and D and therefore those will be installed 
prior to A.

2) Will the various yum install [A|E|B] give the same script run orders? 
Thats not 100% guaranteed as the installation order of E and B as well 
as the installation of updmap-sys, texconfig-sys and C are not fixed by 
any requires, so using a subset of packages to install first (e.g. only 
updmap-sys, texconfig-sys and C) might result in a different order for 
those packages than using a "full" install with A.

There might be some code inside rpm that could possibly have updmap-sys, 
texconfig-sys and C be installed in the same order despite having not 
dependencies between each other, but from an algorithmical point of view 
you can't and shouldn't rely on it.

Or to put it differently: If you need those packages to be installed in 
a specific order then just use Requires.

On the other hand, if those are "soft" requires then things get tricky , 
e.g. IF updmap-sys, texconfig-sys and C get installed then C needs to be 
installed after updmap-sys and/or texconfig-sys. I remember vaguely that 
such "soft" requires (which don't pull in packages automatically but 
which will be honored in case it is already in the transaction) were 
either planed or even already put into rpm, but Panu/JBJ can probably 
tell you a lot more in detail about that.

Read ya, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From skasal at redhat.com  Tue Oct  9 16:10:53 2007
From: skasal at redhat.com (Stepan Kasal)
Date: Tue, 9 Oct 2007 18:10:53 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <200710080956.38846.aportal@univ-montp2.fr>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<200710052120.05292.alain.portal@free.fr>
	<20071006111626.e927f0cc.mschwendt.tmp0701.nospam@arcor.de>
	<200710080956.38846.aportal@univ-montp2.fr>
Message-ID: <20071009161053.GA24990@camelia.ucw.cz>

Hello,

On Mon, Oct 08, 2007 at 09:56:38AM +0200, Alain PORTAL wrote:
> Previously, I "BuildRequires: automake", but it seems I made a mistake and I 
> removed it...

but you should understand that this would break if automake were
upgraded to 1.10.  I do not think this is a real possibility in FC-6,
so your solution is adequate here.

But for general development, let me remind that there are only two
safe options:

1) either you rely on the autotools-generated files packed in the
tarball, in which case you do not need to BuildRequire anything.

2) Or you do refresh the autotools generated stuff fully, so you need
at least:

BuildRequire: autoconf automake
%build
aclocal
autoconf
automake

The aclocal collects various *.m4 files so you often need
	aclocal -I m4
for *.m4 files in the m4/ subdir of the tarball, and you often need
to BuildRequire libfoo-devel, if libfoo is used by your package and
if it contains a /usr/share/aclocal/foo.m4


As you see, the second option can get a bit complicated, so if the
only problem is a time stamp mistake in the upstream tarball, it
might be a better idea to make the upstream to realease a fixed
tarball, or find the bug and patch it by a "touch -r".

Happy hacking,
	Stepan



From mschwendt.tmp0701.nospam at arcor.de  Tue Oct  9 16:41:02 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 9 Oct 2007 18:41:02 +0200
Subject: rpms/liblrdf/FC-6 liblrdf.spec,1.6,1.7
In-Reply-To: <470B76F5.1020501@redhat.com>
References: <200710091122.l99BMXqs029700@cvs-int.fedora.redhat.com>
	<20071009141022.277f7326.mschwendt.tmp0701.nospam@arcor.de>
	<470B76F5.1020501@redhat.com>
Message-ID: <20071009184102.d99d65d1.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 09 Oct 2007 05:41:25 -0700, Anthony Green wrote:

> Michael Schwendt wrote:
> > On Tue, 9 Oct 2007 07:22:33 -0400, Anthony Green (green) wrote:
> > 
> >> Author: green
> >>
> >> Update of /cvs/extras/rpms/liblrdf/FC-6
> > 
> >> -%exclude %{_datadir}/ladspa/rdf/ladspa.rdfs
> >> +%{_datadir}/ladspa/rdf/ladspa.rdfs
> > 
> > What's the full story here?
> > https://bugzilla.redhat.com/show_bug.cgi?id=189313#c6
> > What has changed?
> 
> nando (on copy now) filed the following bug...
> https://bugzilla.redhat.com/show_bug.cgi?id=277361

So, what happens is that Hydrogen still displays lots of empty
categories even for the core ladspa plugins. liblrdf still doesn't
care about the ladspa.rdfs file.

But when the ladspa.rdfs file is installed (although it is installed
from within an "examples" directory), only then any ladspa plugins
which come with an .rdf file are classified inside Hydrogen. *urks*



From gilboad at gmail.com  Tue Oct  9 16:45:53 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Tue, 09 Oct 2007 18:45:53 +0200
Subject: Another readahead issue
In-Reply-To: <feg2hh$jse$1@sea.gmane.org>
References: <1191889707.25531.49.camel@vincent52.localdomain>
	<feg055$ak4$2@sea.gmane.org>
	<20071009140639.GC3939@nostromo.devel.redhat.com>
	<feg2hh$jse$1@sea.gmane.org>
Message-ID: <1191948353.23373.32.camel@gilboa-work-dev.localdomain>

On Tue, 2007-10-09 at 09:17 -0500, Rex Dieter wrote:
> Bill Nottingham wrote:
> 
> > Rex Dieter (rdieter at math.unl.edu) said:
> >> imo, avoid the mess, firefox could use an unversioned folder,
> >> say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
> >> else the firefox packagin/maintainer would be doing this already, right?
> >> :)
> > 
> > It doesn't have a consistent ABI, so using a single location would lead
> > to apps breaking when the ABI changes - at least with a different folder
> > they break in a predictable way.
> 
> I was afraid of that excuse.  Imo, Not a good one, bad packaging practice.
> 
> Dependent pkgs already (or should!) include (something like).
> Requires: firefox = <some_version>
> 
> -- Rex
> 

Let alone the fact that, AFAIK, firefox is not parallel installable.

- Gilboa 



From ssorce at redhat.com  Tue Oct  9 16:49:58 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 12:49:58 -0400
Subject: samba license change
In-Reply-To: <1191936845.8880.8.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
	<1191936845.8880.8.camel@localhost.localdomain>
Message-ID: <1191948598.8880.24.camel@localhost.localdomain>

On Tue, 2007-10-09 at 09:34 -0400, Simo Sorce wrote:
> On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> > Essentially unless the entire dependency chain for Samba is GPLv3 
> > compatible, a new samba version under GPLv3 or later would be
> > impossible 
> > to pull as incompatible licensing is a liability for the distribution 
> > and not necessarily for the individual components. 
> 
> It's the other way around, it is KDE (Konqueror uses libsmbclient) that
> depends on Samba, Samba has no dependency problems at all.

Ah and btw if someone can check what is the GNOME status wrt this it
would be nice. Nautilus uses libsmbclient as well.

Simo.



From ssorce at redhat.com  Tue Oct  9 16:51:39 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 12:51:39 -0400
Subject: samba license change
In-Reply-To: <1191937155.2598.2.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<1191882314.2199.7.camel@localhost.localdomain>
	<470B1F20.1010905@fedoraproject.org>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191937155.2598.2.camel@localhost.localdomain>
Message-ID: <1191948699.8880.26.camel@localhost.localdomain>

On Tue, 2007-10-09 at 09:39 -0400, Matthias Clasen wrote:
> On Tue, 2007-10-09 at 09:34 -0400, Simo Sorce wrote:
> > On Tue, 2007-10-09 at 11:56 +0530, Rahul Sundaram wrote:
> > > Essentially unless the entire dependency chain for Samba is GPLv3 
> > > compatible, a new samba version under GPLv3 or later would be
> > > impossible 
> > > to pull as incompatible licensing is a liability for the distribution 
> > > and not necessarily for the individual components. 
> > 
> > It's the other way around, it is KDE (Konqueror uses libsmbclient) that
> > depends on Samba, Samba has no dependency problems at all.
> 
> Yeah, samba just ignores the problems that it causes for its
> dependencies...

Excuse me ?

Simo.



From mcepl at redhat.com  Tue Oct  9 16:52:09 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 09 Oct 2007 18:52:09 +0200
Subject: gnome-keyring issue, workaround
References: <1191423273.22332.50.camel@localhost.localdomain>
Message-ID: <slrnfgncdp.78r.mcepl@hubmaier.ceplovi.cz>

On 2007-10-03, 14:54 GMT, Alexander Larsson wrote:
> I fixed a gnome-keyring issue today where it would unset the default
> keyring on logout. However, people running test versions could already
> have had this happen to them.
>
> If you have gnome-keyring problems, check the file
> ~/.gnome2/keyrings/default. It should contain the name of the default
> keyring, which is typically "default". If it has size 0 you problably
> ran into this bug. You can fix it by doing:
>
>  echo -n default > ~/.gnome2/keyrings/default

I haven't this file at all (on Rawhide), but this trick doesn't 
help (should I restart something?) with (pretty nasty) bug 
https://bugzilla.redhat.com/show_bug.cgi?id=324961

Mat?j



From ville.skytta at iki.fi  Tue Oct  9 17:18:21 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Tue, 9 Oct 2007 20:18:21 +0300
Subject: samba license change
In-Reply-To: <1191948598.8880.24.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
Message-ID: <200710092018.21899.ville.skytta@iki.fi>

On Tuesday 09 October 2007, Simo Sorce wrote:
>
> Ah and btw if someone can check what is the GNOME status wrt this it
> would be nice. Nautilus uses libsmbclient as well.

I'm no expert on GNOME stuff but I thought it does so through gnome-vfs.

gnome-vfs2.spec has:
License: LGPLv2 and LGPL+ and GPL+
# the daemon and the library are LGPLv2
# the modules are LGPL+ and GPL+

libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
(Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)

I also checked xine-lib, it is GPLv2+ so should be no problem.



From wwoods at redhat.com  Tue Oct  9 17:24:56 2007
From: wwoods at redhat.com (Will Woods)
Date: Tue, 09 Oct 2007 13:24:56 -0400
Subject: f8t3 live: no networking on presario 700 (Broadcom)
In-Reply-To: <feg2s5$lts$1@sea.gmane.org>
References: <febsul$oim$1@sea.gmane.org>
	<1191804935.28263.38.camel@localhost.localdomain>
	<fec24n$3fu$1@sea.gmane.org>
	<1191887833.28263.41.camel@localhost.localdomain>
	<feg2s5$lts$1@sea.gmane.org>
Message-ID: <1191950696.14083.7.camel@metroid.rdu.redhat.com>

On Tue, 2007-10-09 at 10:22 -0400, sean darcy wrote:

> Installed b43-fwcutter and followed the instructions at 
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware
> 
> Got http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2
> 
> untarred that file and ran
> b43-fwcutter -w /lib/firmare broadcom-wl-4.80.53.0/kmod/wl_apsta.o

Just to be sure, what made you choose version 4 firmware for your
device? I had messages in dmesg directing me to get the version 3
firmware (for my BCM4306 card). I'm not sure what firmware/driver the
4311 would use, but it would probably tell you in the logs..

> Shouldn't I have seen the firmware being loaded in dmesg, or syslog?

Not necessarily? I don't think it bothers loading the firmware until you
actually try to bring up the device. Of course, NetworkManager usually
does that pretty quickly, so you might see a message like this one:

b43legacy-phy0 debug: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)

But then again, maybe not - I'm not sure how b43 and b43legacy differ in
their log messages.

> Made sure NetworkManager was working. I can see the icon. No connection.

You don't see any wireless networks listed if you click on the icon?
Have you restarted NetworkManager?

> Now what? I've never tried to use Fedora with wireless, so I may be 
> missing something obvious.

Nope, you've got pretty much everything right (except, possibly, the
firmware - thanks for making this harder than it needs to be, Broadcom.)

-w
-------------- 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/20071009/2c93af21/attachment.sig>

From laurent.rineau__fedora at normalesup.org  Tue Oct  9 17:25:01 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Tue, 9 Oct 2007 19:25:01 +0200
Subject: samba license change
In-Reply-To: <20071009134321.GA4031@redhat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
Message-ID: <200710091925.01313@rineau.tsetse>

On Tuesday 09 October 2007 15:43:21 Daniel P. Berrange wrote:
> > Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will
> > have to be dropped, at least temporarily.

Please, no.

> Or keep around the GPLv2'd 3.0.x version as compat-libsmbclient  for
> KDE & others in the same position to link against, while the rest of
> the apps which can use the GPLv3 newer libs. Or bundle the older release
> libsmbclient.so inside the KDE  package in a private lib directory

We might have a problem if the SONAME of libsmbclient has not changed when the 
license has.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From ssorce at redhat.com  Tue Oct  9 17:30:27 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 13:30:27 -0400
Subject: samba license change
In-Reply-To: <200710091925.01313@rineau.tsetse>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
Message-ID: <1191951027.8880.34.camel@localhost.localdomain>

On Tue, 2007-10-09 at 19:25 +0200, Laurent Rineau wrote:
> On Tuesday 09 October 2007 15:43:21 Daniel P. Berrange wrote:
> > > Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will
> > > have to be dropped, at least temporarily.
> 
> Please, no.
> 
> > Or keep around the GPLv2'd 3.0.x version as compat-libsmbclient  for
> > KDE & others in the same position to link against, while the rest of
> > the apps which can use the GPLv3 newer libs. Or bundle the older release
> > libsmbclient.so inside the KDE  package in a private lib directory
> 
> We might have a problem if the SONAME of libsmbclient has not changed when the 
> license has.

There is no plan to change the soname, I see no reason for it to change
as it is almost the same code and most applications are perfectly fine.

Simo.



From seg at haxxed.com  Tue Oct  9 17:51:08 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 09 Oct 2007 12:51:08 -0500
Subject: f8t3 live: no networking on presario 700 (Broadcom)
In-Reply-To: <1191950696.14083.7.camel@metroid.rdu.redhat.com>
References: <febsul$oim$1@sea.gmane.org>
	<1191804935.28263.38.camel@localhost.localdomain>
	<fec24n$3fu$1@sea.gmane.org>
	<1191887833.28263.41.camel@localhost.localdomain>
	<feg2s5$lts$1@sea.gmane.org>
	<1191950696.14083.7.camel@metroid.rdu.redhat.com>
Message-ID: <1191952268.29582.88.camel@localhost>

On Tue, 2007-10-09 at 13:24 -0400, Will Woods wrote:
> Just to be sure, what made you choose version 4 firmware for your
> device? I had messages in dmesg directing me to get the version 3
> firmware (for my BCM4306 card). I'm not sure what firmware/driver the
> 4311 would use, but it would probably tell you in the logs..

As of F7 it demands v4. Which nicely complicated the hell out upgrading
to F7, as finding v4 drivers to cut the firmware from was next to
impossible upon release.
-------------- 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/20071009/e0cd5fc8/attachment.sig>

From cmadams at hiwaay.net  Tue Oct  9 17:56:37 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 9 Oct 2007 12:56:37 -0500
Subject: samba license change
In-Reply-To: <1191951027.8880.34.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
Message-ID: <20071009175637.GF1500118@hiwaay.net>

Once upon a time, Simo Sorce <ssorce at redhat.com> said:
> On Tue, 2007-10-09 at 19:25 +0200, Laurent Rineau wrote:
> > We might have a problem if the SONAME of libsmbclient has not changed when the 
> > license has.
> 
> There is no plan to change the soname, I see no reason for it to change
> as it is almost the same code and most applications are perfectly fine.

The soname should change for any incompatible change, and while it isn't
a technical change, the license change is incompatible.
-- 
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 jspaleta at gmail.com  Tue Oct  9 18:07:59 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Oct 2007 10:07:59 -0800
Subject: samba license change
In-Reply-To: <20071009175637.GF1500118@hiwaay.net>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
Message-ID: <604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>

On 10/9/07, Chris Adams <cmadams at hiwaay.net> wrote:
> The soname should change for any incompatible change, and while it isn't
> a technical change, the license change is incompatible.


I'd have to agree.  A licensing change on a library, that we know
causing an incompatibility with other packages that we include, is a
big enough deal that we really need a demarcation to make it easier to
avoid licensing violations.  If the soname doesn't change in the
package that we ship, then I think we as a project are not acting in
good faith to help prevent licensing violations by the people using
our packages.  I think this sets a bad precedent for licensing changes
in general.

In my mind, it comes down to this question. As a project as a whole,
and as individual contributors to this project, do we want to make
inadvertent licensing violations less likely or more likely?

Samba as a project has every right to re-license its codebase as it
sees fit. But at the same time, don't we as a distributor have some
responsibility to make sure we introduce that change in such a way to
minimize potential licensing violations? I think we do.

-jef



From notting at redhat.com  Tue Oct  9 18:06:58 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 9 Oct 2007 14:06:58 -0400
Subject: samba license change
In-Reply-To: <604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
Message-ID: <20071009180658.GA12157@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> Samba as a project has every right to re-license its codebase as it
> sees fit. But at the same time, don't we as a distributor have some
> responsibility to make sure we introduce that change in such a way to
> minimize potential licensing violations? I think we do.

However, changing the license differently from upstream doesn't really
help anybody.

Bill



From drago01 at gmail.com  Tue Oct  9 18:14:00 2007
From: drago01 at gmail.com (dragoran)
Date: Tue, 9 Oct 2007 20:14:00 +0200
Subject: samba license change
In-Reply-To: <20071009180658.GA12157@nostromo.devel.redhat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<20071009180658.GA12157@nostromo.devel.redhat.com>
Message-ID: <f6ca9fed0710091114jec98c0j2aad6d38c4b201@mail.gmail.com>

On 10/9/07, Bill Nottingham <notting at redhat.com> wrote:
> Jeff Spaleta (jspaleta at gmail.com) said:
> > Samba as a project has every right to re-license its codebase as it
> > sees fit. But at the same time, don't we as a distributor have some
> > responsibility to make sure we introduce that change in such a way to
> > minimize potential licensing violations? I think we do.
>
> However, changing the license differently from upstream doesn't really
> help anybody.

s/license/soname/ correct? ;)

yes I agree here we should convince upstream to do so..



From pertusus at free.fr  Tue Oct  9 18:27:25 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 9 Oct 2007 20:27:25 +0200
Subject: samba license change
In-Reply-To: <20071009175637.GF1500118@hiwaay.net>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
Message-ID: <20071009182725.GD2659@free.fr>

On Tue, Oct 09, 2007 at 12:56:37PM -0500, Chris Adams wrote:
> 
> The soname should change for any incompatible change, and while it isn't
> a technical change, the license change is incompatible.

The soname doesn't change for any incompatible change. It changes for
ABI changes. I don't think this should be also used for license
compatibility. Some libraries that link against samba libs may already
have a compatible license, a rebuild is unnecessary -- while for ABI
change a rebuild is necessary.

--
Pat



From ssorce at redhat.com  Tue Oct  9 18:30:05 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 09 Oct 2007 14:30:05 -0400
Subject: samba license change
In-Reply-To: <f6ca9fed0710091114jec98c0j2aad6d38c4b201@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<20071009180658.GA12157@nostromo.devel.redhat.com>
	<f6ca9fed0710091114jec98c0j2aad6d38c4b201@mail.gmail.com>
Message-ID: <1191954605.11753.7.camel@localhost.localdomain>

On Tue, 2007-10-09 at 20:14 +0200, dragoran wrote:
> On 10/9/07, Bill Nottingham <notting at redhat.com> wrote:
> > Jeff Spaleta (jspaleta at gmail.com) said:
> > > Samba as a project has every right to re-license its codebase as it
> > > sees fit. But at the same time, don't we as a distributor have some
> > > responsibility to make sure we introduce that change in such a way to
> > > minimize potential licensing violations? I think we do.
> >
> > However, changing the license differently from upstream doesn't really
> > help anybody.
> 
> s/license/soname/ correct? ;)
> 
> yes I agree here we should convince upstream to do so..

This means we break binary compatibility with all packages that uses
libsmbclient happily and have no license problems. A simple upgrade from
3.0.x to 3.2.x would be difficult without recompiling packages that
depends on libsmbclient and ultimately I know this will end up with
people requesting a compat- package.

A compat- package in turn would be bad because it will:
a) not motivate people to switch to the new one
b) not benefit from the bug-fixes we will have in the new one
c) Yet another package to maintain

Honestly,
I would rather see packages that depend on libsmbclient to do the hard
work if they don't like or can't get compatible with the new license.

Changing the soname for non-technical reasons seem just a way to conceal
the problem.

Simo.

Simo.



From mzerqung at 0pointer.de  Tue Oct  9 18:42:04 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 9 Oct 2007 20:42:04 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
Message-ID: <20071009184204.GA23965@tango.0pointer.de>

On Tue, 09.10.07 17:37, Hikaru Amano (kagesenshi.87 at gmail.com) wrote:

Hi!

> if the pulseaudio daemon crashed, it doesnt restart itself .. and it
> need to be manually restarted ... It would be nice to have it restarts
> after crash because normal users wont know how to restart it ..

Hmm, but why did PA crash in the first place? I hope you already filed
a bug?

PA is right now started trhough a compatibility script called "esd"
form gnome-session. So, while gnome-session thinks it starts esd it
actually starts PulseAudio. And gnome-session doesn't restart esd by
default. It's more a bug in esd then in PA.

> plus .. if the folder /tmp/pulse-username exist, pulseaudio refuses to
> start and returns
> 
> E: pid.c: Daemon already running.
> E: main.c: pa_pid_file_create() failed.

If that directory has the proper access modes PA will reuse it and
shouldn't fail restarting.

Is it possible you have some kind of permission problem here?

> but the daemon is not running so I had to delete the folder manually ..
> 
> btw.. where does the autostart script pulseaudio daemon located?? I
> couldnt find it .. (I wanted to add a simple while loop hack for
> restarting the daemon for my own use) ..

Check gnome-session, look for the esd startup code (as mentioned above).

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From habig at neutrino.d.umn.edu  Tue Oct  9 18:42:30 2007
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Tue, 9 Oct 2007 13:42:30 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <20071009134029.GA12588@crow.myhome.westell.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
Message-ID: <20071009184230.GA24144@neutrino.d.umn.edu>

Luke Macken writes:
> yum-updatesd has seen *significant* improvements since F7,
> especially with memory usage.
> 
>      Private  +   Shared  =  RAM used       Program 
>       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd

Also, if you're of the camp that thinks even this level of resource
commitment is excessive, the old cron-script based method is now
available as a package on its own, "yum-cron".  Handier for non-desktop
or multi-user systems, but you lose the blinky gnome button.

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/
-------------- 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/20071009/5f30b144/attachment.sig>

From ericsbinaryworld at gmail.com  Tue Oct  9 19:05:02 2007
From: ericsbinaryworld at gmail.com (Eric Mesa)
Date: Tue, 9 Oct 2007 15:05:02 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1191936868.4913.2.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
Message-ID: <582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>

Still happens to me.  I happen to be running Compiz - you?

On 10/9/07, Thomas J. Baker <tjb at unh.edu> wrote:
>
>
> I saw a while back (if I'm recalling correctly) Jesse acknowledging the
> gnome logout hang bug as known and should be fixed by a forthcoming X11
> update but that was several weeks ago and it still happens for me. Is it
> something I'm running or is it still happening for everyone?
>
> Thanks,
>
> tjb
> --
> =======================================================================
> | Thomas Baker                                  email: tjb at unh.edu    |
> | Systems Programmer                                                  |
> | Research Computing Center                     voice: (603) 862-4490 |
> | University of New Hampshire                     fax: (603) 862-1761 |
> | 332 Morse Hall                                                      |
> | Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
> =======================================================================
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Eric Mesa
http://www.ericsbinaryworld.com
http://server.ericsbinaryworld.com
"Do not worry about those things that are outside of your circle of
influence.  For since they are outside of your power to control them it is
simply a waste of time and energy to dwell on them.  Instead, turn your
attention to those things that you can control and grow your influence in
those areas and you will see the effects begin to trickle out to those items
that were previously out of your power to influence." ? Eric Mesa inspired
by Covey's 7 Habits of Highly Effective People
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/cce0210f/attachment.htm>

From tjb at unh.edu  Tue Oct  9 19:10:19 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Tue, 09 Oct 2007 15:10:19 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
Message-ID: <1191957019.4913.15.camel@raptor.sr.unh.edu>


On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
> Still happens to me.  I happen to be running Compiz - you?
> 

Yes I am.

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From seg at haxxed.com  Tue Oct  9 19:28:40 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 09 Oct 2007 14:28:40 -0500
Subject: Pulseaudio not restarting after crash
In-Reply-To: <20071009184204.GA23965@tango.0pointer.de>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<20071009184204.GA23965@tango.0pointer.de>
Message-ID: <1191958120.29582.90.camel@localhost>

On Tue, 2007-10-09 at 20:42 +0200, Lennart Poettering wrote:
> PA is right now started trhough a compatibility script called "esd"
> form gnome-session. So, while gnome-session thinks it starts esd it
> actually starts PulseAudio. And gnome-session doesn't restart esd by
> default. It's more a bug in esd then in PA.

Yeah but the ESD libs like to start up esd if its not already running.
Should PA do the same? If the PA libs autostarted the daemon on demand,
would you even need to start it with the session?
-------------- 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/20071009/3ce1ec30/attachment.sig>

From katzj at redhat.com  Tue Oct  9 20:05:31 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 16:05:31 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <20071009184230.GA24144@neutrino.d.umn.edu>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<20071009184230.GA24144@neutrino.d.umn.edu>
Message-ID: <1191960331.4334.6.camel@localhost.localdomain>

On Tue, 2007-10-09 at 13:42 -0500, Alec T. Habig wrote:
> Luke Macken writes:
> > yum-updatesd has seen *significant* improvements since F7,
> > especially with memory usage.
> > 
> >      Private  +   Shared  =  RAM used       Program 
> >       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd
> 
> Also, if you're of the camp that thinks even this level of resource
> commitment is excessive, the old cron-script based method is now
> available as a package on its own, "yum-cron".  Handier for non-desktop
> or multi-user systems, but you lose the blinky gnome button.

Ultimately, I'd love to have yum-updatesd just activated via dbus system
activation, but periodic activation is still relatively important.  This
could be via cron, but cron is somewhat problematic for machines that
aren't always on :-/

Jeremy



From nicolas.mailhot at laposte.net  Tue Oct  9 20:16:08 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 09 Oct 2007 22:16:08 +0200
Subject: yum-updatesd in F8?
In-Reply-To: <1191960331.4334.6.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<20071009184230.GA24144@neutrino.d.umn.edu>
	<1191960331.4334.6.camel@localhost.localdomain>
Message-ID: <1191960968.4756.0.camel@rousalka.dyndns.org>


Le mardi 09 octobre 2007 ? 16:05 -0400, Jeremy Katz a ?crit :
> On Tue, 2007-10-09 at 13:42 -0500, Alec T. Habig wrote:
> > Luke Macken writes:
> > > yum-updatesd has seen *significant* improvements since F7,
> > > especially with memory usage.
> > > 
> > >      Private  +   Shared  =  RAM used       Program 
> > >       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd
> > 
> > Also, if you're of the camp that thinks even this level of resource
> > commitment is excessive, the old cron-script based method is now
> > available as a package on its own, "yum-cron".  Handier for non-desktop
> > or multi-user systems, but you lose the blinky gnome button.
> 
> Ultimately, I'd love to have yum-updatesd just activated via dbus system
> activation, but periodic activation is still relatively important.  This
> could be via cron, but cron is somewhat problematic for machines that
> aren't always on :-/

I thought anacron fixed that

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

From katzj at redhat.com  Tue Oct  9 20:22:48 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 16:22:48 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <1191960968.4756.0.camel@rousalka.dyndns.org>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<20071009184230.GA24144@neutrino.d.umn.edu>
	<1191960331.4334.6.camel@localhost.localdomain>
	<1191960968.4756.0.camel@rousalka.dyndns.org>
Message-ID: <1191961368.4334.12.camel@localhost.localdomain>

On Tue, 2007-10-09 at 22:16 +0200, Nicolas Mailhot wrote:
> Le mardi 09 octobre 2007 ? 16:05 -0400, Jeremy Katz a ?crit :
> > On Tue, 2007-10-09 at 13:42 -0500, Alec T. Habig wrote:
> > > Luke Macken writes:
> > > > yum-updatesd has seen *significant* improvements since F7,
> > > > especially with memory usage.
> > > > 
> > > >      Private  +   Shared  =  RAM used       Program 
> > > >       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd
> > > 
> > > Also, if you're of the camp that thinks even this level of resource
> > > commitment is excessive, the old cron-script based method is now
> > > available as a package on its own, "yum-cron".  Handier for non-desktop
> > > or multi-user systems, but you lose the blinky gnome button.
> > 
> > Ultimately, I'd love to have yum-updatesd just activated via dbus system
> > activation, but periodic activation is still relatively important.  This
> > could be via cron, but cron is somewhat problematic for machines that
> > aren't always on :-/
> 
> I thought anacron fixed that

I've actually found that anacron makes things worse...  boot laptop,
watch it become completely unusable as anacron kicks off cron jobs that
would have happened when "idle".

Not to mention that it's starting another init.d service (two, if you
count starting crond) which is going to end up offsetting the boot speed
difference of not running yum-updatesd as an init.d service

Jeremy



From jwilson at redhat.com  Tue Oct  9 20:34:02 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Tue, 09 Oct 2007 16:34:02 -0400
Subject: rpms/emerald/devel emerald.spec,1.13,1.14
In-Reply-To: <1191895166.14135.1.camel@localhost.localdomain>
References: <200710081535.l98FZv86006715@cvs-int.fedora.redhat.com>
	<1191895166.14135.1.camel@localhost.localdomain>
Message-ID: <470BE5BA.2090504@redhat.com>

Peter Gordon wrote:
> On Mon, 2007-10-08 at 11:35 -0400, Jarod Wilson wrote:
>> Log Message:
>> Disable ppc64 build (no compiz-devel.ppc64 available)
> 
> When you ExcludeArch PPC64, please remember to file a bug against your
> package which blocks the FE-ExcludeArch-ppc64 tracker (bug 238953) if
> you have not already done so.

Thank you for the reminder. Was on my todo list, but not very high. Just
got to it a few seconds ago.

https://bugzilla.redhat.com/show_bug.cgi?id=325551

-- 
Jarod Wilson
jwilson at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/aa4b5d75/attachment.sig>

From mzerqung at 0pointer.de  Tue Oct  9 20:45:12 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 9 Oct 2007 22:45:12 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <1191958120.29582.90.camel@localhost>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<20071009184204.GA23965@tango.0pointer.de>
	<1191958120.29582.90.camel@localhost>
Message-ID: <20071009204512.GA29408@tango.0pointer.de>

On Tue, 09.10.07 14:28, Callum Lerwick (seg at haxxed.com) wrote:

> On Tue, 2007-10-09 at 20:42 +0200, Lennart Poettering wrote:
> > PA is right now started trhough a compatibility script called "esd"
> > form gnome-session. So, while gnome-session thinks it starts esd it
> > actually starts PulseAudio. And gnome-session doesn't restart esd by
> > default. It's more a bug in esd then in PA.
> 
> Yeah but the ESD libs like to start up esd if its not already running.
> Should PA do the same? If the PA libs autostarted the daemon on demand,
> would you even need to start it with the session?

libesd should be able to autostart PA if required, thinking that it
starts up esd. The esd compatibility script should behave perfectly
like the real esd in this aspect.

However, I beleive that autostarting PA is a really bad idea, which is
why on Fedora PA is by default started by gnome-session. PA nowadays
closes the audio devices as soon as 1s after they become idle. So
basically there's no reason to not keep PA around all the time anymore.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From ville.skytta at iki.fi  Tue Oct  9 20:46:24 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Tue, 9 Oct 2007 23:46:24 +0300
Subject: yum-updatesd in F8?
In-Reply-To: <20071009184230.GA24144@neutrino.d.umn.edu>
References: <loom.20071009T110055-482@post.gmane.org>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<20071009184230.GA24144@neutrino.d.umn.edu>
Message-ID: <200710092346.24965.ville.skytta@iki.fi>

On Tuesday 09 October 2007, Alec T. Habig wrote:
> Luke Macken writes:
> > yum-updatesd has seen *significant* improvements since F7,
> > especially with memory usage.
> >
> >      Private  +   Shared  =  RAM used       Program
> >       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd
>
> Also, if you're of the camp that thinks even this level of resource
> commitment is excessive, the old cron-script based method is now
> available as a package on its own, "yum-cron".  Handier for non-desktop
> or multi-user systems, but you lose the blinky gnome button.

Can yum-cron do download+notify only?  That's the mode I'd prefer for most 
setups.



From pemboa at gmail.com  Tue Oct  9 20:52:57 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 9 Oct 2007 15:52:57 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <20071009134029.GA12588@crow.myhome.westell.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
Message-ID: <16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>

On 10/9/07, Luke Macken <lmacken at redhat.com> wrote:
> On Tue, Oct 09, 2007 at 12:49:00PM +0100, Christopher Brown wrote:
> > On 09/10/2007, Mike C <mike.cohler at gmail.com> wrote:
> > > Can someone say if yum-updatesd will be in F8 final
> >
> > Yes.
> >
> > - and if so whether it
> > > really works or not?
> >
> > Yes. It really WORKSFORME.
> >
> > >  It never did for me in F7.
> >
> > Sorry to hear it. I have also found it flaky in F7 but there is always
> > bugzilla and rawhide to test from if you can.
>
> yum-updatesd has seen *significant* improvements since F7,
> especially with memory usage.
>
>      Private  +   Shared  =  RAM used       Program
>       6.6 MiB +   2.0 MiB =   8.6 MiB       yum-updatesd

1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.

2) Does the GUI (pup?) work in KDE?

3) Is there a silent download, interactive install mode?

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From katzj at redhat.com  Tue Oct  9 21:01:45 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 17:01:45 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
Message-ID: <1191963705.4334.16.camel@localhost.localdomain>

On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.

You can't have multiple things doing transactions at the same time.  It
just _can't_ be guaranteed to work.  Both yum and pirut should now let
you easily retry (or exit out).  Also, the main reason things were
getting blocked was deadlocking of yum-updatesd in threading land.  This
can't really happen now.

> 2) Does the GUI (pup?) work in KDE?

pup has always worked in KDE...   the applet should work in KDE now if I
remember the bug correctly[1].  If not, please file something.

> 3) Is there a silent download, interactive install mode?

Yep, just like always.  But should be more reliable now.

Jeremy

[1] A GtkStatusIcon that started out hidden would never show up in the
KDE panel when you made the GtkStatusIcon visible.



From lkundrak at redhat.com  Tue Oct  9 21:07:28 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 09 Oct 2007 23:07:28 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
Message-ID: <1191964048.7000.16.camel@localhost.localdomain>


On Tue, 2007-10-09 at 17:37 +0800, Hikaru Amano wrote:
> if the pulseaudio daemon crashed, it doesnt restart itself .. and it
> need to be manually restarted ... It would be nice to have it restarts
> after crash because normal users wont know how to restart it ..

It's not a bug that it doesn't restart. Many services don't do so.
Respawning a dying daemon is not a good idea, because in case of
exploitation of a security issues, it would effectively defeat
randomization giving the attacker more tries, etc. etc.

The real problem is the crash. Do you have a core dump? Or at least
relevant lines from the log file? Are you able to reproduce the problem?
Please do file a bug in case you do/are.

> plus .. if the folder /tmp/pulse-username exist, pulseaudio refuses to
> start and returns
> 
> E: pid.c: Daemon already running.
> E: main.c: pa_pid_file_create() failed.
> 
> but the daemon is not running so I had to delete the folder manually ..

This is the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=299131
I somehow had to delete that directory manually also, though I don't
remember the actual setting anymore. Probably it is derived from $USER
rather than from the effective id and gets created when you start the
daemon as another user or whatever. It is also a (though pretty low
severity) denial of service condition.
> 
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From s.adam at diffingo.com  Tue Oct  9 21:08:26 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 09 Oct 2007 17:08:26 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <1191939517.3626.90.camel@cookie.hadess.net>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
Message-ID: <1191964106.23786.9.camel@Diffingo.localdomain>

On Tue, 2007-10-09 at 15:18 +0100, Bastien Nocera wrote:
> On Tue, 2007-10-09 at 13:59 +0000, Bastien Nocera wrote:
> <snip>
> > I'd go for a shell script (probably the same one symlinked). Something like:
> > 
> > #!/bin/sh
> > 
> > if [ -f ~/.local/etc/sysconfig/totem ] ; then
> >       . ~/.local/etc/sysconfig/totem
> > else if [ -f /etc/sysconfig/totem ] ; then
> >       . /etc/sysconfig/totem
> > fi
> 
> As Bill mentioned to me on IRC, getting the value from GConf would work
> just as well, allowing admins to select the default one and enforce it,
> or users to change theirs without affecting other users.
Good idea, this would also make it very easy to switch via a simple
application that can be placed in System > Preferences > Personal.

Stewart



From habig at neutrino.d.umn.edu  Tue Oct  9 21:18:51 2007
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Tue, 9 Oct 2007 16:18:51 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <200710092346.24965.ville.skytta@iki.fi>
References: <loom.20071009T110055-482@post.gmane.org>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<20071009184230.GA24144@neutrino.d.umn.edu>
	<200710092346.24965.ville.skytta@iki.fi>
Message-ID: <20071009211851.GD24144@neutrino.d.umn.edu>

Ville Skytt? writes:
> Can yum-cron do download+notify only?  That's the mode I'd prefer for
> most setups.

Yes.  In /etc/sysconfig/yum-cron, set 

  CHECK_ONLY=yes

In another development, Bug 325531 suggests having yum-cron call
yum-updatesd in run-once mode, so as to take advantage of the plethora
of notification options available to yum-updatesd without having to
waste daemon space on it.  I'll play with this and see how it works.

      Alec

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/
-------------- 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/20071009/e6deb93f/attachment.sig>

From pemboa at gmail.com  Tue Oct  9 21:20:53 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 9 Oct 2007 16:20:53 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <1191963705.4334.16.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
Message-ID: <16de708d0710091420s9d4d643t79964b311a89b0a5@mail.gmail.com>

On 10/9/07, Jeremy Katz <katzj at redhat.com> wrote:
> On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> > 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
>
> You can't have multiple things doing transactions at the same time.  It
> just _can't_ be guaranteed to work.  Both yum and pirut should now let
> you easily retry (or exit out).  Also, the main reason things were
> getting blocked was deadlocking of yum-updatesd in threading land.  This
> can't really happen now.

Forgive my ignorance, but is it not possible to have yum work in
essentially a read-only mode which would allow checking for updates...
but would _not_ block other applications>

> > 2) Does the GUI (pup?) work in KDE?
>
> pup has always worked in KDE...   the applet should work in KDE now if I
> remember the bug correctly[1].  If not, please file something.

Thanks... I got to try pup in Gnome on CentOS5... it was quite nice..
hadn't used Gnome for years.

> > 3) Is there a silent download, interactive install mode?
>
> Yep, just like always.  But should be more reliable now.

Cool. I take it RFEs on the interface are welcome?

> Jeremy
>
> [1] A GtkStatusIcon that started out hidden would never show up in the
> KDE panel when you made the GtkStatusIcon visible.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From lkundrak at redhat.com  Tue Oct  9 21:21:44 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 09 Oct 2007 23:21:44 +0200
Subject: yum-updatesd in F8?
In-Reply-To: <1191963705.4334.16.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
Message-ID: <1191964904.7000.22.camel@localhost.localdomain>


On Tue, 2007-10-09 at 17:01 -0400, Jeremy Katz wrote:
> On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> > 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
> 
> You can't have multiple things doing transactions at the same time.  It
> just _can't_ be guaranteed to work.  Both yum and pirut should now let
> you easily retry (or exit out).  Also, the main reason things were
> getting blocked was deadlocking of yum-updatesd in threading land.  This
> can't really happen now.

First experience of every new Fedora user ever after clean installation
is pop-up message about that the packages are available, and then
response that "software information" is blocked when he selects to view
the updates. Awful.

Maybe pirut should be able to tell updatesd that he's going to handle
things himself and he should unlock stuff or whatever. Or updatesd
himself should do all the job of installing the packages, getting the
list, etc., pirut just being the frontend for telling it what to do and
getting and displaying status.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From pemboa at gmail.com  Tue Oct  9 21:24:43 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 9 Oct 2007 16:24:43 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <1191964904.7000.22.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
	<1191964904.7000.22.camel@localhost.localdomain>
Message-ID: <16de708d0710091424i5cc86b1bg271d440603660222@mail.gmail.com>

On 10/9/07, Lubomir Kundrak <lkundrak at redhat.com> wrote:
>
> On Tue, 2007-10-09 at 17:01 -0400, Jeremy Katz wrote:
> > On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> > > 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
> >
> > You can't have multiple things doing transactions at the same time.  It
> > just _can't_ be guaranteed to work.  Both yum and pirut should now let
> > you easily retry (or exit out).  Also, the main reason things were
> > getting blocked was deadlocking of yum-updatesd in threading land.  This
> > can't really happen now.
>
> First experience of every new Fedora user ever after clean installation
> is pop-up message about that the packages are available, and then
> response that "software information" is blocked when he selects to view
> the updates. Awful.

I faced the little popup onCentos5/Gnome for my first time.. I didn't
run into a blocking scenario when I clicked on it.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From bnocera at redhat.com  Tue Oct  9 21:29:42 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 09 Oct 2007 22:29:42 +0100
Subject: Merging totem and totem-xine
In-Reply-To: <1191964106.23786.9.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
Message-ID: <1191965382.3626.108.camel@cookie.hadess.net>

On Tue, 2007-10-09 at 17:08 -0400, Stewart Adam wrote:
> On Tue, 2007-10-09 at 15:18 +0100, Bastien Nocera wrote:
> > On Tue, 2007-10-09 at 13:59 +0000, Bastien Nocera wrote:
> > <snip>
> > > I'd go for a shell script (probably the same one symlinked). Something like:
> > > 
> > > #!/bin/sh
> > > 
> > > if [ -f ~/.local/etc/sysconfig/totem ] ; then
> > >       . ~/.local/etc/sysconfig/totem
> > > else if [ -f /etc/sysconfig/totem ] ; then
> > >       . /etc/sysconfig/totem
> > > fi
> > 
> > As Bill mentioned to me on IRC, getting the value from GConf would work
> > just as well, allowing admins to select the default one and enforce it,
> > or users to change theirs without affecting other users.
> Good idea, this would also make it very easy to switch via a simple
> application that can be placed in System > Preferences > Personal.

I don't intend to have this feature visible at all, but it would be
possible if somebody wants to cook up a TweakUI for GNOME...



From s.adam at diffingo.com  Tue Oct  9 21:32:12 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 09 Oct 2007 17:32:12 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <1191965382.3626.108.camel@cookie.hadess.net>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
Message-ID: <1191965532.23786.18.camel@Diffingo.localdomain>

On Tue, 2007-10-09 at 22:29 +0100, Bastien Nocera wrote:
> I don't intend to have this feature visible at all, but it would be
> possible if somebody wants to cook up a TweakUI for GNOME...
What do you think of a simple dialog box like this?

|-------------------------- Totem engine --------------------------|
| Please select the engine you would like to use for totem below:  |
|                                                                  |
|           |^ gstreamer                                           |
|           |  xine                                                |
|                                                                  |
|                                        [ OK ]   [ Cancel ]       |
|__________________________________________________________________|

Stewart



From katzj at redhat.com  Tue Oct  9 21:36:43 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 17:36:43 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710091420s9d4d643t79964b311a89b0a5@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
	<16de708d0710091420s9d4d643t79964b311a89b0a5@mail.gmail.com>
Message-ID: <1191965803.4334.27.camel@localhost.localdomain>

On Tue, 2007-10-09 at 16:20 -0500, Arthur Pemberton wrote:
> On 10/9/07, Jeremy Katz <katzj at redhat.com> wrote:
> > On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> > > 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
> >
> > You can't have multiple things doing transactions at the same time.  It
> > just _can't_ be guaranteed to work.  Both yum and pirut should now let
> > you easily retry (or exit out).  Also, the main reason things were
> > getting blocked was deadlocking of yum-updatesd in threading land.  This
> > can't really happen now.
> 
> Forgive my ignorance, but is it not possible to have yum work in
> essentially a read-only mode which would allow checking for updates...
> but would _not_ block other applications>

No, because we change out repodata in place.  Which would mean that you
could get a very inconsistent view if you didn't listen to the lock.

> > > 3) Is there a silent download, interactive install mode?
> >
> > Yep, just like always.  But should be more reliable now.
> 
> Cool. I take it RFEs on the interface are welcome?

Yep!  Bugzilla against yum-updatesd for the daemon side, pirut for the
UI

Jeremy



From katzj at redhat.com  Tue Oct  9 21:37:42 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 09 Oct 2007 17:37:42 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <1191964904.7000.22.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
	<1191964904.7000.22.camel@localhost.localdomain>
Message-ID: <1191965862.4334.30.camel@localhost.localdomain>

On Tue, 2007-10-09 at 23:21 +0200, Lubomir Kundrak wrote:
> On Tue, 2007-10-09 at 17:01 -0400, Jeremy Katz wrote:
> > On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
> > > 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
> > 
> > You can't have multiple things doing transactions at the same time.  It
> > just _can't_ be guaranteed to work.  Both yum and pirut should now let
> > you easily retry (or exit out).  Also, the main reason things were
> > getting blocked was deadlocking of yum-updatesd in threading land.  This
> > can't really happen now.
> 
> First experience of every new Fedora user ever after clean installation
> is pop-up message about that the packages are available, and then
> response that "software information" is blocked when he selects to view
> the updates. Awful.

You definitely get teh "there's stuff available" popup, but if you then
click "View updates", I haven't ever seen that things are blocked.  Can
you please file something in bugzilla with more complete details.

Jeremy



From lmacken at redhat.com  Tue Oct  9 21:41:40 2007
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 9 Oct 2007 17:41:40 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1191936868.4913.2.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
Message-ID: <20071009214119.GA8058@crow.redhat.com>

On Tue, Oct 09, 2007 at 09:34:28AM -0400, Thomas J. Baker wrote:
> I saw a while back (if I'm recalling correctly) Jesse acknowledging the
> gnome logout hang bug as known and should be fixed by a forthcoming X11
> update but that was several weeks ago and it still happens for me. Is it
> something I'm running or is it still happening for everyone?

This could be pulseaudio related.  I hit a similar bug that prevented me
from shutting down because pulse had crashed.

luke



From hughsient at gmail.com  Tue Oct  9 22:01:23 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 09 Oct 2007 23:01:23 +0100
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710091420s9d4d643t79964b311a89b0a5@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<1191963705.4334.16.camel@localhost.localdomain>
	<16de708d0710091420s9d4d643t79964b311a89b0a5@mail.gmail.com>
Message-ID: <1191967283.5275.5.camel@hughsie-laptop>

On Tue, 2007-10-09 at 16:20 -0500, Arthur Pemberton wrote:
> Forgive my ignorance, but is it not possible to have yum work in
> essentially a read-only mode which would allow checking for updates...
> but would _not_ block other applications>

PackageKit can do this. Checkout http://hughsient.livejournal.com/ for
progress. There's also a git repo if you want to try this out on
rawhide.

Richard.




From kagesenshi.87 at gmail.com  Tue Oct  9 22:18:12 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Wed, 10 Oct 2007 06:18:12 +0800
Subject: Pulseaudio not restarting after crash
In-Reply-To: <1191964048.7000.16.camel@localhost.localdomain>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<1191964048.7000.16.camel@localhost.localdomain>
Message-ID: <c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>

On 10/10/07, Lubomir Kundrak <lkundrak at redhat.com> wrote:
> It's not a bug that it doesn't restart. Many services don't do so.
> Respawning a dying daemon is not a good idea, because in case of
> exploitation of a security issues, it would effectively defeat
> randomization giving the attacker more tries, etc. etc.

it would be nice if theres something that would notify the user that
pulseaudio terminated (and maybe ask permission to restart it) ...
rather than silently quit and left the users wondering what happened
to their pc sound and started blaming Fedora doesnt work ...

>
> The real problem is the crash. Do you have a core dump? Or at least
> relevant lines from the log file? Are you able to reproduce the problem?
> Please do file a bug in case you do/are.

( I think i should use the term stopped rather than crashed )

I couldnt find the cause of pulseaudio stopping yet .. pulseaudio
suddenly quits on random ..

the last time it terminated, pulseaudio gived out this error

[kagesenshi at Hikari ~]$ while true;do pulseaudio ;echo "DIED";done
Soft CPU time limit exhausted, terminating.
E: module-volume-restore.c: failed to open file '(null)': No such file
or directory
DIED

>
> > but the daemon is not running so I had to delete the folder manually ..
>
> This is the following bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=299131
> I somehow had to delete that directory manually also, though I don't
> remember the actual setting anymore. Probably it is derived from $USER
> rather than from the effective id and gets created when you start the
> daemon as another user or whatever. It is also a (though pretty low
> severity) denial of service condition.




-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From buildsys at fedoraproject.org  Tue Oct  9 22:25:18 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue,  9 Oct 2007 18:25:18 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-09
Message-ID: <20071009222518.EC05B15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 17

NEW avarice-2.6-1.fc6 : Program for interfacing the Atmel JTAG ICE to GDB
NEW centerim-20071003-1.fc6 : Text mode menu- and window-driven IM
    cowsay-3.03-4.fc6
    em8300-kmod-0.16.3-1.2.6.22.9_61.fc6
    gnome-theme-clearlooks-bigpack-0.6-6.fc6
NEW hydrogen-0.9.3-9.fc6 : Advanced drum machine for GNU/Linux
    kazehakase-0.4.9-2.fc6
    liblrdf-0.4.0-12.fc6
    lyx-1.5.2-1.fc6
    osgcal-0.1.46-1.fc6
    php-pecl-memcache-2.2.0-1.fc6
    pikloops-0.2.4-4.fc6
    polyester-1.0.2-1.fc6
NEW roxterm-1.7.4-4.fc6 : A fast terminal emulator
NEW uisp-20050207-1.fc6 : Universal In-System Programmer for Atmel AVR and 8051
    wine-docs-0.9.46-1.fc6
    xdg-utils-1.0.2-2.fc6


Changes in Fedora Extras 6: 


avarice-2.6-1.fc6
-----------------
* Mon Mar 12 2007 Trond Danielsen <trond.danielsen at fedoraproject.org> - 2.6-1
- Initial version.

centerim-20071003-1.fc6
-----------------------
* Mon Oct 08 2007 Lubomir Kundrak <lkundrak at redhat.com> - 20071003-2
- Fixed BuildRoot
- Removed redundant BuildReq
- Rebased to more current upstream tarball

* Tue Oct 02 2007 Lubomir Kundrak <lkundrak at redhat.com> - 20070625-1
- fork centerim from centericq

cowsay-3.03-4.fc6
-----------------
* Tue Oct 09 2007 Micha? Bentkowski <mr.ecik at gmail.com> - 3.03-4
- Fix mech-and-cow file (#250844)

* Mon Sep 17 2007 Lubomir Kundrak <lkundrak at redhat.com> - 3.03-3
- Make --help be a bit more sane (#293061)

em8300-kmod-0.16.3-1.2.6.22.9_61.fc6
------------------------------------
* Mon Oct 08 2007 Ville Skytt? <ville.skytta at iki.fi>
- Rebuild for kernel 2.6.22.9-61.fc6.

gnome-theme-clearlooks-bigpack-0.6-6.fc6
----------------------------------------
* Sun Oct 07 2007 Peter Gordon <peter at thecodergeek.com> - 0.6-6
- Add some sed invocations at build-time to remove unused menuitemstyle,
  listviewitemstyle, progressbarstyle, and sunkenmenu configuration options.
- Resolves: bug 242031 (Clearlooks bigpack warnings)
- Clarify License version (GPL+) for compliance with new Licensing guidelines.

hydrogen-0.9.3-9.fc6
--------------------
* Tue Oct 09 2007 Lubomir Kundrak <lkundrak at redhat.com> 0.9.3-9
- Incorporate fixes from #190040, thanks to Hans de Goede
- Removed useless LIBDIR introduced in previous revision
- Fixed desktop file installation
- Call gtk-update-icon-cache only if it is present

* Sun Oct 07 2007 Lubomir Kundrak <lkundrak at redhat.com> 0.9.3-8
- Remove -j from make to fix concurrency problems
- Handle libdir on 64bit platforms correctly
- Rename patches

* Sat Oct 06 2007 Lubomir Kundrak <lkundrak at redhat.com> 0.9.3-7.1
- Fix desktop file
- Fix compatibility with new FLAC
- Fix linking for Build ID use

kazehakase-0.4.9-2.fc6
----------------------
* Mon Oct 08 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2
- Readd accidentally deleted obsolete_plugin_ver macro

liblrdf-0.4.0-12.fc6
--------------------
* Mon Oct 08 2007 Anthony Green <green at redhat.com> 0.4.0-12
- Don't %exclude %{_datadir}/ladspa/rdf/ladspa.rdfs
- Require ladspa to get directory ownerships right.

* Fri Jul 20 2007 Callum Lerwick <seg at haxxed.com> 0.4.0-11
- Bump to build on ppc64, bug #247583.

lyx-1.5.2-1.fc6
---------------
* Mon Oct 08 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5.2-1
- lyx-1.5.2

* Sat Aug 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5.1-2
- respin (BuildID)

osgcal-0.1.46-1.fc6
-------------------
* Mon Oct 08 2007 Christopher Stone <chris.stone at gmail.com> 0.1.46-1
- Upstream sync
- Remove no longer needed 64bit patch
- Fix License and Source
- Fix encoding on ChangeLog

* Mon Oct 08 2007 Christopher Stone <chris.stone at gmail.com> 0.1.44-5
- ExcludeArch ppc64 since OSG-devel is not build for this arch

php-pecl-memcache-2.2.0-1.fc6
-----------------------------
* Sat Sep 22 2007 Remi Collet <Fedora at FamilleCollet.com> 2.2.0-1
- new version
- add new INI directives (hash_strategy + hash_function) to config
- add BR on php-devel >= 4.3.11

pikloops-0.2.4-4.fc6
--------------------
* Mon Oct 08 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.4-4
- Don't ExcludeArch ppc...

* Mon Oct 08 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.4-3
- Don't ExcludeArch ppc and BR automake...

* Sat Oct 06 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.4-2
- ExcludeArch ppc because automake isn't found... No comment...

* Fri Sep 28 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.4-1
- New upstream version

* Sun Sep 02 2007 Chitlesh Goorah <chitlesh[AT]fedoraproject[DOT]org> - 0.2.3-3
- Fix desktop file

* Tue Aug 21 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.3-2
- Licence tag clarification

polyester-1.0.2-1.fc6
---------------------
* Tue Aug 21 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.0.2-1
- new upstream version: 1.0.2

* Thu Aug 16 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.0.1-2
- Change License to LGPLv2

roxterm-1.7.4-4.fc6
-------------------
* Wed Sep 19 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.7.4-4
- correct %doc in spec

* Wed Sep 19 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.7.4-3
- own directories
- set %{_docdir} to %{name}-%{version}

* Tue Sep 18 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.7.4-2
- use gtk-update-icon-cache in %post and %postun

* Tue Sep 18 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.7.4-1
- new upstream version: 1.7.4
- correct url

* Tue Sep 11 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.7.1-1
- new upstream version
- change license to GPLv2+
- BR: dbus-devel

uisp-20050207-1.fc6
-------------------
* Mon Mar 12 2007 Trond Danielsen <trond.danielsen at fedoraproject.org> - 20050207-1
- Initial version.
- Summary and description taken from spec file included in uisp.

wine-docs-0.9.46-1.fc6
----------------------
* Mon Oct 08 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

* Sat Aug 25 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.44-2
- disable debuginfo

* Sat Aug 25 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.44-1
- version upgrade

* Sat Aug 18 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.43-1
- version upgrade
- fix license

* Sat Jul 28 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.42-1
- version upgrade

* Mon Jul 16 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.41-1
- version upgrade

* Sun Jun 17 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
0.9.39-1
- version upgrade

* Sun Jun 03 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
0.9.38-1
- version upgrade

xdg-utils-1.0.2-2.fc6
---------------------
* Wed Oct 03 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.2-2
- Requires: which (#312601)

* Sun Jun 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.2-1
- xdg-utils-1.0.2

* Mon Apr 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.1-3
- add htmlview,links to browser fallbacks

* Tue Dec 19 2006 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.1-2
- fix typo in xdg-icon-resource manpage



From ville.skytta at iki.fi  Tue Oct  9 22:32:34 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 10 Oct 2007 01:32:34 +0300
Subject: yum-updatesd in F8?
In-Reply-To: <20071009211851.GD24144@neutrino.d.umn.edu>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710092346.24965.ville.skytta@iki.fi>
	<20071009211851.GD24144@neutrino.d.umn.edu>
Message-ID: <200710100132.35256.ville.skytta@iki.fi>

On Wednesday 10 October 2007, Alec T. Habig wrote:
> Ville Skytt? writes:
> > Can yum-cron do download+notify only?  That's the mode I'd prefer for
> > most setups.
>
> Yes.  In /etc/sysconfig/yum-cron, set
>
>   CHECK_ONLY=yes

That seems to result in it running "yum check-update" which AFAIK does not 
actually download the _packages_.

(Yep, I know yum-updatesd should be able to do that, but the last time I tried 
quite a while back, I couldn't get it to work.)



From lkundrak at redhat.com  Tue Oct  9 22:46:22 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 10 Oct 2007 00:46:22 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<1191964048.7000.16.camel@localhost.localdomain>
	<c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>
Message-ID: <1191969982.7000.37.camel@localhost.localdomain>


On Wed, 2007-10-10 at 06:18 +0800, Hikaru Amano wrote:
> On 10/10/07, Lubomir Kundrak <lkundrak at redhat.com> wrote:
> > It's not a bug that it doesn't restart. Many services don't do so.
> > Respawning a dying daemon is not a good idea, because in case of
> > exploitation of a security issues, it would effectively defeat
> > randomization giving the attacker more tries, etc. etc.
> 
> it would be nice if theres something that would notify the user that
> pulseaudio terminated (and maybe ask permission to restart it) ...
> rather than silently quit and left the users wondering what happened
> to their pc sound and started blaming Fedora doesnt work ...

It would be a just blame. Pulseaudio should _not_ crash. Imagine if we
did thing such as this (the respawn) for about every thing that is
expected to run and can crash -- not a real solution.

> > The real problem is the crash. Do you have a core dump? Or at least
> > relevant lines from the log file? Are you able to reproduce the problem?
> > Please do file a bug in case you do/are.
> 
> ( I think i should use the term stopped rather than crashed )
> 
> I couldnt find the cause of pulseaudio stopping yet .. pulseaudio
> suddenly quits on random ..
> 
> the last time it terminated, pulseaudio gived out this error
> 
> [kagesenshi at Hikari ~]$ while true;do pulseaudio ;echo "DIED";done
> Soft CPU time limit exhausted, terminating.
> E: module-volume-restore.c: failed to open file '(null)': No such file
> or directory
> DIED

I had exactly the same problem.
https://bugzilla.redhat.com/show_bug.cgi?id=322481
After I decided to hunt down the problem and compiled pulseaudio with
profiling data, I noticed, that I forgot respawining esd that was now
causing two instances of pulseaudio to run. No idea how does it relate,
but removing one kind of solved this problem for me. I'll return to it
once I have more time.

Please use that bug report to trace every piece of information you get about that.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From ericsbinaryworld at gmail.com  Tue Oct  9 22:55:40 2007
From: ericsbinaryworld at gmail.com (Eric Mesa)
Date: Tue, 09 Oct 2007 18:55:40 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1191957019.4913.15.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>	
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
	<1191957019.4913.15.camel@raptor.sr.unh.edu>
Message-ID: <470C06EC.2060207@gmail.com>

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

Thomas J. Baker wrote:
> On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
>> Still happens to me.  I happen to be running Compiz - you?
>>
>
> Yes I am.
>
> Thanks,
>
> tjb
Yeah, that's why I never filed a bug report because running compiz
means you're running Nvidia or ATI drivers which means they can't
help.  At least that's the impression I get.

- --
Eric Mesa
ericsbinaryworld at gmail.com
http://www.ericsbinaryworld.com
Note:  All emails from this address should have a GPG signature.  If
you have the proper setup you can use this to confirm my identity and
that the email was not changed in transit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHDAbsPvU+8ApmWXIRAjgzAJ9S/aXKUe4zJdvu3JWwAhLX9MYHTwCfUCTN
h0vDdMMlQviTl0FG0z2Ils0=
=/b0l
-----END PGP SIGNATURE-----



From dr.diesel at gmail.com  Tue Oct  9 22:59:06 2007
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Tue, 9 Oct 2007 18:59:06 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <470C06EC.2060207@gmail.com>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
	<1191957019.4913.15.camel@raptor.sr.unh.edu>
	<470C06EC.2060207@gmail.com>
Message-ID: <2a28d2ab0710091559n87ab3afh6be6125ad56bf929@mail.gmail.com>

On 10/9/07, Eric Mesa <ericsbinaryworld at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas J. Baker wrote:
> > On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
> >> Still happens to me.  I happen to be running Compiz - you?
> >>
> >
> > Yes I am.
> >
> > Thanks,
> >
> > tjb
> Yeah, that's why I never filed a bug report because running compiz
> means you're running Nvidia or ATI drivers which means they can't
> help.  At least that's the impression I get.
>

Compiz runs fine on Intel/i910.



From abartlet at samba.org  Tue Oct  9 23:00:21 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 09:00:21 +1000
Subject: samba license change
In-Reply-To: <604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
Message-ID: <1191970821.8865.28.camel@dragonlady>

On Tue, 2007-10-09 at 10:07 -0800, Jeff Spaleta wrote:

> Samba as a project has every right to re-license its codebase as it
> sees fit. But at the same time, don't we as a distributor have some
> responsibility to make sure we introduce that change in such a way to
> minimize potential licensing violations? I think we do.

Isn't this an argument for the Licence tags on RPMs, and for someone to
run a depsolver over the packages, ensuring the packages do not rely on
services with incompatible licences?

Bumping the soname just makes people recompile code, with no further
indication as to what is incompatible.  Unlike and ABI change, the
problem doesn't go away with a rebuild. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.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/20071010/289cfdd0/attachment.sig>

From fletchal at cs.wisc.edu  Tue Oct  9 23:13:51 2007
From: fletchal at cs.wisc.edu (Jason Fletchall)
Date: Tue, 09 Oct 2007 18:13:51 -0500
Subject: Behavior Trends in Nautilus and other Desktop Apps
Message-ID: <470C0B2F.2030200@cs.wisc.edu>

Dear Developers,

The Cooperative Bug Isolation Project has made some interesting 
discoveries about the behavior (and misbehavior) of Nautilus and several 
other GNOME applications running under Fedora.  For those who have not 
heard of CBI, we instrument applications for users to download.  These 
instrumented binaries send us opt-in feedback data about branch 
coverage, exit status, etc.  For more information, check out the main 
CBI site here: <http://www.cs.wisc.edu/cbi/>.

For example, we have found that Nautilus 2.14 releases for Fedora 5 were 
buggy, with almost one run in ten crashing!  Subsequent releases of 
Nautilus 2.16 (Fedora 6) and Nautilus 2.18 (Fedora 7) have been much 
more stable.

Our CBI Early Findings pages, <http://www.cs.wisc.edu/cbi/findings/>, 
give more information about trends we have seen in Nautilus and other 
applications, including snapshots of the very latest CBI crash data.

These pages are just a small sample of what we could discover in the 
data, so we are eager to hear back from all of you.  If you have 
suggestions or requests for things we could look into, or if you have 
any questions or comments, contact us: 
<http://www.cs.wisc.edu/cbi/contact/>.  We instrument lots of program 
actions, not just crashes, so we can also answer questions about feature 
use, code coverage, branch behavior, etc.

Also, the more users we have, the more accurate our findings!  If you 
want to become a part of the CBI community, simply download these 
packages: <http://www.cs.wisc.edu/cbi/downloads/>.

Jason Fletchall
University of Wisconsin-Madison



From tjb at unh.edu  Tue Oct  9 23:16:39 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Tue, 09 Oct 2007 19:16:39 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <470C06EC.2060207@gmail.com>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
	<1191957019.4913.15.camel@raptor.sr.unh.edu>
	<470C06EC.2060207@gmail.com>
Message-ID: <1191971799.26962.8.camel@neuromancer>

On Tue, 2007-10-09 at 18:55 -0400, Eric Mesa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thomas J. Baker wrote:
> > On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
> >> Still happens to me.  I happen to be running Compiz - you?
> >>
> >
> > Yes I am.
> >
> > Thanks,
> >
> > tjb
> Yeah, that's why I never filed a bug report because running compiz
> means you're running Nvidia or ATI drivers which means they can't
> help.  At least that's the impression I get.
> 

I have the same problem on my Intel laptop so I don't think it's related
to the NVIDIA driver on my desktop. It's some type of hang because if I
just C-A-Backspace, gdm comes back up fine. Something is not letting X
reset.

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From jkeating at redhat.com  Tue Oct  9 23:15:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 9 Oct 2007 19:15:53 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <d9c612bf0710090803r1138979pa51747d73ef7dc65@mail.gmail.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
	<470A8327.1020204@gmail.com> <20071008201103.2d814b5a@redhat.com>
	<d9c612bf0710090803r1138979pa51747d73ef7dc65@mail.gmail.com>
Message-ID: <20071009191553.6d4c2a60@redhat.com>

On Tue, 9 Oct 2007 08:03:36 -0700
"Christopher Stone" <chris.stone at gmail.com> wrote:

> The notification system that is currently available might be the best
> way to go then.  Perhaps we can enhance the notification system to be
> easier to use.  For example, it could suggest packages you should
> subscribe to for notifications.  In addition, there should be
> notification levels like there are syslog levels.  So the most
> important pushes which would require a rebuild would be set at the
> highest notification level and then I can just filter out the
> notifications I really care about this way.


RFEs are best collected in the project upstream tracker (:

(I'm not saying that this is a bad suggestion, just that it may get
lost in a mailing list)

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/546368f7/attachment.sig>

From jkeating at redhat.com  Tue Oct  9 23:16:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 9 Oct 2007 19:16:45 -0400
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
 stable release
In-Reply-To: <1191891016.3395.491.camel@mccallum.corsepiu.local>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<20071008183932.ebaa3a57.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<1191878740.3395.467.camel@mccallum.corsepiu.local>
	<20071008201231.156c7027@redhat.com>
	<1191891016.3395.491.camel@mccallum.corsepiu.local>
Message-ID: <20071009191645.19981784@redhat.com>

On Tue, 09 Oct 2007 02:50:16 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> Well, then I can't avoid to ask why the results of this built had not
> been communicated to the maintainers, esp. for the ppc64, where
> several packages must have failed building - not necessarily nice.

I'm almost certain there was repeated listings of what wasn't built.
Bill Nottingham did almost all the build/import work.  If there wasn't,
I apologize, things were a bit crazy around that time and notification
may have not made it past IRC chatter.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/d39008b5/attachment.sig>

From fedora at marcbradshaw.co.uk  Tue Oct  9 23:21:01 2007
From: fedora at marcbradshaw.co.uk (Marc Bradshaw)
Date: Wed, 10 Oct 2007 09:21:01 +1000
Subject: Help requested re build errors on x86_64-devel
Message-ID: <470C0CDD.7070901@marcbradshaw.co.uk>

Hi,

Are there any c++ gurus on the list who could shed some light on a
problem we are having building a package for x86_64-devel.
The package builds in i386-devel and x86_64-f7 but fails on x86_64-devel
with lots of "template with C linkage"errors.

Bugzilla and buildlog links follow.

https://bugzilla.redhat.com/show_bug.cgi?id=310641

http://dribble.org.uk/buildlogs/GREYCstoration-2.5.2-4/8/x86_64/

Thanks,
-Marc



From jkeating at redhat.com  Tue Oct  9 23:18:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 9 Oct 2007 19:18:53 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <1191965532.23786.18.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
Message-ID: <20071009191853.3c023603@redhat.com>

On Tue, 09 Oct 2007 17:32:12 -0400
Stewart Adam <s.adam at diffingo.com> wrote:

> What do you think of a simple dialog box like this?
> 
> |-------------------------- Totem engine --------------------------|
> | Please select the engine you would like to use for totem below:  |
> |                                                                  |
> |           |^ gstreamer                                           |
> |           |  xine                                                |
> |                                                                  |
> |                                        [ OK ]   [ Cancel ]       |
> |__________________________________________________________________|

What does that actually mean to a user?  How do you explain what
"gstreamer" is vs "xine"?  When do you propose you through this
mysterious question at the user?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071009/2cd53e41/attachment.sig>

From a.badger at gmail.com  Tue Oct  9 23:22:17 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 09 Oct 2007 16:22:17 -0700
Subject: samba license change
In-Reply-To: <1191970821.8865.28.camel@dragonlady>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
Message-ID: <470C0D29.4050101@gmail.com>

Andrew Bartlett wrote:
> On Tue, 2007-10-09 at 10:07 -0800, Jeff Spaleta wrote:
> 
>> Samba as a project has every right to re-license its codebase as it
>> sees fit. But at the same time, don't we as a distributor have some
>> responsibility to make sure we introduce that change in such a way to
>> minimize potential licensing violations? I think we do.
> 
> Isn't this an argument for the Licence tags on RPMs, and for someone to
> run a depsolver over the packages, ensuring the packages do not rely on
> services with incompatible licences?
> 
> Bumping the soname just makes people recompile code, with no further
> indication as to what is incompatible.  Unlike and ABI change, the
> problem doesn't go away with a rebuild. 
> 

I think the problem people are trying to address is how to allow the 
packages which can only link to libsmbclient-GPLv2+ to do so while 
providing samba-GPLv3+ for everything else.  If we have an SONAME bump, 
then we can have a package for the programs which need GPLv2 and a 
package for the packages which are free to move on.

Without the SONAME bump we'd have to do one of the following:

* static library or private directory for libsmb-GPLv2+ and have the 
affected programs set up to find the library there.
* Rename the libsmbclient-GPLv2+ library so it has a different SONAME by 
virtue of its name.

The problem you bring up is also worthwhile but it is a separate issue 
(detecting of problems rather than how to address the problems once they 
are brought to light.)

-Toshio



From kevin.kofler at chello.at  Tue Oct  9 23:56:46 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 9 Oct 2007 23:56:46 +0000 (UTC)
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<fefvuq$ak4$1@sea.gmane.org>
Message-ID: <loom.20071009T235442-798@post.gmane.org>

Rex Dieter <rdieter <at> math.unl.edu> writes:
> (1) qt is GPLv2, trolltech is evaluating GPLv2+ or GPLv3, but that's all
> behind closed doors with no visible movement.  There is a proposal within
> kde to move to (L)GPLv2+.

Note that the LGPLv2 is compatible with all GPLv2+ because the LGPLv2->GPL 
conversion clause explicitly allows any later version of the GPL. It's the 
GPLv2 code (Qt, some application code) which is the problem.

        Kevin Kofler



From s.adam at diffingo.com  Wed Oct 10 01:00:10 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 09 Oct 2007 21:00:10 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <20071009191853.3c023603@redhat.com>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
Message-ID: <1191978010.7325.4.camel@Diffingo.localdomain>

On Tue, 2007-10-09 at 19:18 -0400, Jesse Keating wrote:
> On Tue, 09 Oct 2007 17:32:12 -0400
> Stewart Adam <s.adam at diffingo.com> wrote:
> 
> > What do you think of a simple dialog box like this?
> > 
> > |-------------------------- Totem engine --------------------------|
> > | Please select the engine you would like to use for totem below:  |
> > |                                                                  |
> > |           |^ gstreamer                                           |
> > |           |  xine                                                |
> > |                                                                  |
> > |                                        [ OK ]   [ Cancel ]       |
> > |__________________________________________________________________|
> 
> What does that actually mean to a user?  How do you explain what
> "gstreamer" is vs "xine"?  When do you propose you through this
> mysterious question at the user?
This is what I was thinking of adding "Totem Backend" to Preferences,
that dialog would be it. If we need a quick description, that can be
done too underneath the current selection:

"The gstreamer backend is the Fedora default and uses gstreamer codecs
to play multimedia files."

"The xine backend uses the xine codecs to play multimedia files. The
xine backend, among other things, support DVD menus."

Stewart



From davej at redhat.com  Wed Oct 10 01:25:05 2007
From: davej at redhat.com (Dave Jones)
Date: Tue, 9 Oct 2007 21:25:05 -0400
Subject: rawhide report: 20071009 changes
In-Reply-To: <1191931861.28263.74.camel@localhost.localdomain>
References: <200710091011.l99ABpOZ013976@porkchop.devel.redhat.com>
	<470B55ED.2070309@fedoraproject.org>
	<1191931861.28263.74.camel@localhost.localdomain>
Message-ID: <20071010012505.GB22848@redhat.com>

On Tue, Oct 09, 2007 at 08:11:01AM -0400, Jeremy Katz wrote:
 > On Tue, 2007-10-09 at 15:50 +0530, Rahul Sundaram wrote:
 > > Build System wrote:
 > > > kernel-2.6.23-0.224.rc9.git6.fc8
 > > > --------------------------------
 > > > * Mon Oct 08 2007 Dave Jones <davej at redhat.com>
 > > > - Add a bunch of modules to the 586 kernel for the livecd.
 > > 
 > > Do live images support the i586 arch?
 > 
 > No; the live images are built with the i686 kernel

Oh well, no real harm (other than a few seconds extra build time).

	Dave

-- 
http://www.codemonkey.org.uk



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Oct 10 01:34:54 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 10 Oct 2007 10:34:54 +0900
Subject: Help requested re build errors on x86_64-devel
In-Reply-To: <470C0CDD.7070901@marcbradshaw.co.uk>
References: <470C0CDD.7070901@marcbradshaw.co.uk>
Message-ID: <470C2C3E.5010701@ioa.s.u-tokyo.ac.jp>

Marc Bradshaw wrote, at 10/10/2007 08:21 AM +9:00:
> Hi,
> 
> Are there any c++ gurus on the list who could shed some light on a
> problem we are having building a package for x86_64-devel.
> The package builds in i386-devel and x86_64-f7 but fails on x86_64-devel
> with lots of "template with C linkage"errors.
> 
> Bugzilla and buildlog links follow.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=310641
> 
> http://dribble.org.uk/buildlogs/GREYCstoration-2.5.2-4/8/x86_64/
> 

This srpm can be rebuilt on all arch, dist-f8.
http://koji.fedoraproject.org/koji/taskinfo?taskID=189122

I guess the build failure you saw is because your build used
gimp 2.4.0 rc1. Update gimp to 2.4.0 rc3. (current rawhide Fedora's
gimp is gimp-2.4.0-0.rc3.1.fc8).
Similar discussion is found on
https://bugzilla.redhat.com/show_bug.cgi?id=250210#c9

Regards,
Mamoru



From abartlet at samba.org  Wed Oct 10 03:38:10 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 13:38:10 +1000
Subject: samba license change
In-Reply-To: <470C0D29.4050101@gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>  <470C0D29.4050101@gmail.com>
Message-ID: <1191987490.10594.1.camel@naomi>

On Tue, 2007-10-09 at 16:22 -0700, Toshio Kuratomi wrote:
> Andrew Bartlett wrote:
> > On Tue, 2007-10-09 at 10:07 -0800, Jeff Spaleta wrote:
> > 
> >> Samba as a project has every right to re-license its codebase as it
> >> sees fit. But at the same time, don't we as a distributor have some
> >> responsibility to make sure we introduce that change in such a way to
> >> minimize potential licensing violations? I think we do.
> > 
> > Isn't this an argument for the Licence tags on RPMs, and for someone to
> > run a depsolver over the packages, ensuring the packages do not rely on
> > services with incompatible licences?
> > 
> > Bumping the soname just makes people recompile code, with no further
> > indication as to what is incompatible.  Unlike and ABI change, the
> > problem doesn't go away with a rebuild. 
> > 
> 
> I think the problem people are trying to address is how to allow the 
> packages which can only link to libsmbclient-GPLv2+ to do so while 
> providing samba-GPLv3+ for everything else.  If we have an SONAME bump, 
> then we can have a package for the programs which need GPLv2 and a 
> package for the packages which are free to move on.

The problem is, there is no long-term will to maintain such a -compat
package.  How long would such a package last - forever if other packages
don't move?  Who would maintain it?

The bit that bothers me is that not only was Samba for the longest time
mentioned in most GPLv3 news articles, we asked if anybody had a reason
not to change our licence, and nobody gave a compelling reason.

We have time yet before Samba 3.2.0 for other packages to either allow a
compatible licence, or decide that they no longer need the services
Samba's library provides.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.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/20071010/05c00560/attachment.sig>

From sundaram at fedoraproject.org  Wed Oct 10 03:49:13 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 10 Oct 2007 09:19:13 +0530
Subject: samba license change
In-Reply-To: <1191987490.10594.1.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
Message-ID: <470C4BB9.5060905@fedoraproject.org>

Andrew Bartlett wrote:

> 
> The problem is, there is no long-term will to maintain such a -compat
> package.  How long would such a package last - forever if other packages
> don't move?  Who would maintain it?

I assume whoever is dependent on Samba but can't make the move to a 
compatible license would be interesting in maintaining it. I don't think 
it is feasible for us to have a new release of Fedora where something as 
major as GNOME or KDE does not have any Samba support. Do you?

> The bit that bothers me is that not only was Samba for the longest time
> mentioned in most GPLv3 news articles, we asked if anybody had a reason
> not to change our licence, and nobody gave a compelling reason.

Things are not working a vacuum. You know the major players in Free 
dependent on Samba which includes GNOME and KDE. The license 
incompatibility that would occur as a result of this move was very plain 
  to everyone involved. Such a transition can take several months if we 
have to introduce it into the distribution. I don't see any way out of a 
  maintaining a GPLv2 version of Samba for a while unless everyone 
involved moves to GPLv3 or compatible licenses for their own software 
quickly if they are dependent on Samba.

Rahul



From jspaleta at gmail.com  Wed Oct 10 03:56:04 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Oct 2007 19:56:04 -0800
Subject: samba license change
In-Reply-To: <470C4BB9.5060905@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009134321.GA4031@redhat.com> <200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
Message-ID: <604aa7910710092056o3893871et8bb11d73ce84ef52@mail.gmail.com>

On 10/9/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> I don't see any way out of a
> maintaining a GPLv2 version of Samba for a while unless everyone
> involved moves to GPLv3 or compatible licenses for their own software
> quickly if they are dependent on Samba.

is kdebase/kdebase4 the only problem package(s) currently in fedora proper?

-jef



From rc040203 at freenet.de  Wed Oct 10 04:06:34 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 06:06:34 +0200
Subject: samba license change
In-Reply-To: <1191987490.10594.1.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>  <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
Message-ID: <1191989194.3395.628.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 13:38 +1000, Andrew Bartlett wrote:

> The bit that bothers me is that not only was Samba for the longest time
> mentioned in most GPLv3 news articles, we asked if anybody had a reason
> not to change our licence, and nobody gave a compelling reason.
The rationales for projects not wanting to switch to GPLv3 are quite
simple:
- GPLv2 has a long tradition. How to apply it is well understood, its
implications on works is well understood.
- GPLv2 had been challenged at courts. Its leaks/wholes and its
validity/applicability are well understood.

With GPLv3 these points do not apply anymore. It's all "brand new".

I.e. on one hand you have the FSF claiming GPLv3 to be "great progress"
and to close "leaks" GPLv2 has/was accused to have, on the other hand
you have fear und uncertainty due to lack of understanding the GPLv3 and
lack of facts to support the FSF's claims (e.g. challenges at courts).

Ralf




From ssorce at redhat.com  Wed Oct 10 04:20:02 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 00:20:02 -0400
Subject: samba license change
In-Reply-To: <470C4BB9.5060905@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
Message-ID: <1191990002.13627.35.camel@localhost.localdomain>

On Wed, 2007-10-10 at 09:19 +0530, Rahul Sundaram wrote:
> Andrew Bartlett wrote:
> 
> > 
> > The problem is, there is no long-term will to maintain such a -compat
> > package.  How long would such a package last - forever if other packages
> > don't move?  Who would maintain it?

I agree with Andrew and you actually give me a chance to explain why.

> I assume whoever is dependent on Samba but can't make the move to a 
> compatible license would be interesting in maintaining it. I don't think 
> it is feasible for us to have a new release of Fedora where something as 
> major as GNOME or KDE does not have any Samba support. Do you?

Well there are 2 possible situations:
A) The projects that depend on samba are willing to address the
licensing problem
B) They are not

If A we have time, we are talking about F9, plenty of time.

If B then they have 2 choices:
B.1) Drop functionality
B.2) Implement/maintain/whatever their own SMB/CIFS support

In both cases I think they should provide the solution. A SONAME bump is
just going to break existing application that do not have any licensing
problem, it is not going to fix the licensing problem for these
projects, a problem they need to solve one way or another anyway.

If they choose B.1 a SONAME bump was useless, broke applications, wasted
time.
If they choose B.2 a SONAME bump was useless, broke applications, wasted
time as they are going to provide their own solution anyway in their
packages (or through a fork, or whatever).

> > The bit that bothers me is that not only was Samba for the longest time
> > mentioned in most GPLv3 news articles, we asked if anybody had a reason
> > not to change our licence, and nobody gave a compelling reason.
> 
> Things are not working a vacuum.

Oh this is exactly right, things do not happen in a vacuum, the license
change of Samba was *largely* anticipated and announced some time ago.
Plenty of time to act. And remember we are not forcing anybody on a
solution, these projects are completely free to choose their own.

> You know the major players in Free 
> dependent on Samba which includes GNOME and KDE. The license 
> incompatibility that would occur as a result of this move was very plain 
>   to everyone involved.

Yes, it was clear, but let me rant a bit:
People started warning about the problems of GPLv2 only licensing
*years* ago, when the GPLv3 work was not started yet but was expected to
start at some point.
Now projects that choose GPLv2 only, choose *consciously* the route of
incompatibility with an upgrade.
now as these projects made that decision, I think it is only fair they
move quickly to fix the problem, they have been given a lot of time to
think, the 3.0.x version will still be maintained (security fixes and
very serious bugs only) for an year after the GPLv3ed 3.2.0 is out.

> Such a transition can take several months if we 
> have to introduce it into the distribution. I don't see any way out of a 
>   maintaining a GPLv2 version of Samba for a while unless everyone 
> involved moves to GPLv3 or compatible licenses for their own software 
> quickly if they are dependent on Samba.

See above, there is still some time, I am holding 3.2.0 (we are still
pre1 anyway) releases for now, they will not hit rawhide until the
matter is solved for Fedora.
But this is a general issue, I urge the people that work with GNOME and
KDE to ask these projects to decide what they are willing to do in the
future without further delaying an inevitable decision.

I sent notice to fedora-devel in advance exactly to start kicking the
whole machine, as I said we have time, but not the whole eternity, and I
haven't seen much around the topic since we made our announcement from
the interested parties.

Nor when we asked for comments *before* changing the license, nor
*after* we announced it. I believe it is time to hear something from our
friends :)

Simo.



From ssorce at redhat.com  Wed Oct 10 04:22:03 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 00:22:03 -0400
Subject: samba license change
In-Reply-To: <604aa7910710092056o3893871et8bb11d73ce84ef52@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009134321.GA4031@redhat.com> <200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<604aa7910710092056o3893871et8bb11d73ce84ef52@mail.gmail.com>
Message-ID: <1191990123.13627.37.camel@localhost.localdomain>

On Tue, 2007-10-09 at 19:56 -0800, Jeff Spaleta wrote:
> On 10/9/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> > I don't see any way out of a
> > maintaining a GPLv2 version of Samba for a while unless everyone
> > involved moves to GPLv3 or compatible licenses for their own software
> > quickly if they are dependent on Samba.
> 
> is kdebase/kdebase4 the only problem package(s) currently in fedora proper?

I think most of GNOME should be ok as it is LGPL or GPLv2+, the only app
I know that is v2 'only' seem to be Evolution, but I have no idea if
Evolution uses libsmbclient for anything, it seem unlikely, but it would
be nice to get some confirmation about that.

Simo.



From ssorce at redhat.com  Wed Oct 10 04:26:21 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 00:26:21 -0400
Subject: samba license change
In-Reply-To: <1191989194.3395.628.camel@mccallum.corsepiu.local>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>  <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
Message-ID: <1191990381.13627.42.camel@localhost.localdomain>

On Wed, 2007-10-10 at 06:06 +0200, Ralf Corsepius wrote:
> On Wed, 2007-10-10 at 13:38 +1000, Andrew Bartlett wrote:
> 
> > The bit that bothers me is that not only was Samba for the longest time
> > mentioned in most GPLv3 news articles, we asked if anybody had a reason
> > not to change our licence, and nobody gave a compelling reason.
> The rationales for projects not wanting to switch to GPLv3 are quite
> simple:
> - GPLv2 has a long tradition. How to apply it is well understood, its
> implications on works is well understood.
> - GPLv2 had been challenged at courts. Its leaks/wholes and its
> validity/applicability are well understood.
> 
> With GPLv3 these points do not apply anymore. It's all "brand new".
> 
> I.e. on one hand you have the FSF claiming GPLv3 to be "great progress"
> and to close "leaks" GPLv2 has/was accused to have, on the other hand
> you have fear und uncertainty due to lack of understanding the GPLv3 and
> lack of facts to support the FSF's claims (e.g. challenges at courts).

If we had to wait for court approval on licenses Free software and Open
Source would not exist at all, that has never stopped anybody in the
past nor in the present, it is just a marginal consideration.

In any case this is completely irrelevant, we are not asking anybody to
go GPLv3, but to come out with a decision on what they want to do. Once
that is clear we will know how to handle the situation.

Simo.



From cjdahlin at ncsu.edu  Wed Oct 10 04:29:47 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Wed, 10 Oct 2007 00:29:47 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <1191964904.7000.22.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>	<364d303b0710090449w1b05ca72o74a0ba2b81a25573@mail.gmail.com>	<20071009134029.GA12588@crow.myhome.westell.com>	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>	<1191963705.4334.16.camel@localhost.localdomain>
	<1191964904.7000.22.camel@localhost.localdomain>
Message-ID: <470C553B.8000000@ncsu.edu>

Lubomir Kundrak wrote:
> On Tue, 2007-10-09 at 17:01 -0400, Jeremy Katz wrote:
>   
>> On Tue, 2007-10-09 at 15:52 -0500, Arthur Pemberton wrote:
>>     
>>> 1) Does yum-updatesd still block yum and piruit? Causes newbies some headaches.
>>>       
>> You can't have multiple things doing transactions at the same time.  It
>> just _can't_ be guaranteed to work.  Both yum and pirut should now let
>> you easily retry (or exit out).  Also, the main reason things were
>> getting blocked was deadlocking of yum-updatesd in threading land.  This
>> can't really happen now.
>>     
>
> First experience of every new Fedora user ever after clean installation
> is pop-up message about that the packages are available, and then
> response that "software information" is blocked when he selects to view
> the updates. Awful.
>
>   
Speaking of which, what are thoughts on adding a yum update step to 
firstboot? The images are fairly out of date for most of the release 
cycle, and encouraging users to update right away could be a benefit.
> Maybe pirut should be able to tell updatesd that he's going to handle
> things himself and he should unlock stuff or whatever. Or updatesd
> himself should do all the job of installing the packages, getting the
> list, etc., pirut just being the frontend for telling it what to do and
> getting and displaying status.
>
>   



From sundaram at fedoraproject.org  Wed Oct 10 05:09:51 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 10 Oct 2007 10:39:51 +0530
Subject: samba license change
In-Reply-To: <1191990002.13627.35.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
Message-ID: <470C5E9F.1050506@fedoraproject.org>

Simo Sorce wrote:

> Well there are 2 possible situations:
> A) The projects that depend on samba are willing to address the
> licensing problem
> B) They are not

C) They are willing to consider a move but they need more time.

> If A we have time, we are talking about F9, plenty of time.
> 
> If B then they have 2 choices:
> B.1) Drop functionality
> B.2) Implement/maintain/whatever their own SMB/CIFS support

3) Introduce a compatibility package and maintain it for a while before 
sorting out the licensing details. Samba developers have claimed before 
they will still provide security and bug fixes for the older codebase 
for a while so this option is feasible.

Rahul



From rc040203 at freenet.de  Wed Oct 10 05:10:55 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 07:10:55 +0200
Subject: samba license change
In-Reply-To: <1191990381.13627.42.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>  <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
Message-ID: <1191993055.3395.643.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 00:26 -0400, Simo Sorce wrote:
> On Wed, 2007-10-10 at 06:06 +0200, Ralf Corsepius wrote:
> > On Wed, 2007-10-10 at 13:38 +1000, Andrew Bartlett wrote:
> > 
> > > The bit that bothers me is that not only was Samba for the longest time
> > > mentioned in most GPLv3 news articles, we asked if anybody had a reason
> > > not to change our licence, and nobody gave a compelling reason.
> > The rationales for projects not wanting to switch to GPLv3 are quite
> > simple:
> > - GPLv2 has a long tradition. How to apply it is well understood, its
> > implications on works is well understood.
> > - GPLv2 had been challenged at courts. Its leaks/wholes and its
> > validity/applicability are well understood.
> > 
> > With GPLv3 these points do not apply anymore. It's all "brand new".
> > 
> > I.e. on one hand you have the FSF claiming GPLv3 to be "great progress"
> > and to close "leaks" GPLv2 has/was accused to have, on the other hand
> > you have fear und uncertainty due to lack of understanding the GPLv3 and
> > lack of facts to support the FSF's claims (e.g. challenges at courts).
> 
> If we had to wait for court approval on licenses Free software and Open
> Source would not exist at all, that has never stopped anybody in the
> past nor in the present, it is just a marginal consideration.
Well, it matters very much to individuals if they want to endanger
themselves by the uncertainties of a "brand new" license a political
organization with controversial (some say "fundamentalist zealotic")
attitude (the FSF) tries to enforce.

> In any case this is completely irrelevant, we are not asking anybody to
> go GPLv3, but to come out with a decision on what they want to do. Once
> that is clear we will know how to handle the situation.
Though I am strongly convinced about OpenSource and am usually
supporting it, for my own works, I have decided not to apply GPLv3 (at
least for now), because there are details inside I consider
counterproductive[1] and ... because I prefer not to expose myself to
the risks of this license :)

Ralf

[1] E.g. the FSF now considering dynamic linkage as "combined works".
This topic is not as clear as the FSF wants it to appear. It is
controversial and collides with "provided by the OS".






From debarshi.ray at gmail.com  Wed Oct 10 05:21:41 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 10 Oct 2007 10:51:41 +0530
Subject: Non-orphans treated as orphans
Message-ID: <3170f42f0710092221i487ac8b0j7dd904254d16672e@mail.gmail.com>

https://admin.fedoraproject.org/pkgdb/users/packages/orphan

A number of packages (like libedit and nget) which were orphaned
sometime back and then taken over, are still listed as orphans in the
above URL. These packages have an owner for all the current branches
-- FC-6, F-7 and devel, but not for the EOL'ed branches.

Is this how it is supposed to be, or should I file a bug/ticket, or is
this already a known issue?

Cheerio,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jspaleta at gmail.com  Wed Oct 10 05:30:53 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Oct 2007 21:30:53 -0800
Subject: samba license change
In-Reply-To: <1191990002.13627.35.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
Message-ID: <604aa7910710092230o7e935bd9g7bbb2cfa740dd65c@mail.gmail.com>

On 10/9/07, Simo Sorce <ssorce at redhat.com> wrote:
> Well there are 2 possible situations:
> A) The projects that depend on samba are willing to address the
> licensing problem
> B) They are not
>
> If A we have time, we are talking about F9, plenty of time.
>
> If B then they have 2 choices:
> B.1) Drop functionality
> B.2) Implement/maintain/whatever their own SMB/CIFS support

no matter which case... in the meantime... as a distribution we have a
serious problem with kdebase. Even if trolltech/kde are in the
optimistic scenario A... we as a distribution can't actually build the
currently available kdebase against the the gplv3 libsmbclient in our
buildsystem or else we are violating the license by rebuilding our
kdebase against our libsmbclient. So while we are in the limbo of
scenario A resolution everything associated with kde package
maintainence STOPS in fedora development leading up to F9.  As a
distribution can we really afford to do that?

-jef



From abartlet at samba.org  Wed Oct 10 06:05:06 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 16:05:06 +1000
Subject: samba license change
In-Reply-To: <470C5E9F.1050506@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C5E9F.1050506@fedoraproject.org>
Message-ID: <1191996306.10594.38.camel@naomi>

On Wed, 2007-10-10 at 10:39 +0530, Rahul Sundaram wrote:
> Simo Sorce wrote:
> 
> > Well there are 2 possible situations:
> > A) The projects that depend on samba are willing to address the
> > licensing problem
> > B) They are not
> 
> C) They are willing to consider a move but they need more time.

I'm increasingly sceptical about this possibility.  This is not a new
issue, or an unexpected turn of events.  If we try and sweep it under
the carpet with a 'compatibility' fork of Samba, then we burden
ourselves with this situation forever. 

> > If A we have time, we are talking about F9, plenty of time.
> > 
> > If B then they have 2 choices:
> > B.1) Drop functionality
> > B.2) Implement/maintain/whatever their own SMB/CIFS support
> 
> 3) Introduce a compatibility package and maintain it for a while before 
> sorting out the licensing details. Samba developers have claimed before 
> they will still provide security and bug fixes for the older codebase 
> for a while so this option is feasible.

If there any real expectation that issues not resolved now (while there
is significant movement in this issue) will magically be resolved later.
Is that expectation worth the complete packaging mess that this would
create?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071010/c63f368e/attachment.sig>

From abartlet at samba.org  Wed Oct 10 06:05:17 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 16:05:17 +1000
Subject: samba license change
In-Reply-To: <1191993055.3395.643.camel@mccallum.corsepiu.local>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>  <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
Message-ID: <1191996317.10594.39.camel@naomi>

On Wed, 2007-10-10 at 07:10 +0200, Ralf Corsepius wrote:

> > In any case this is completely irrelevant, we are not asking anybody to
> > go GPLv3, but to come out with a decision on what they want to do. Once
> > that is clear we will know how to handle the situation.
> Though I am strongly convinced about OpenSource and am usually
> supporting it, for my own works, I have decided not to apply GPLv3 (at
> least for now), because there are details inside I consider
> counterproductive[1] and ... because I prefer not to expose myself to
> the risks of this license :)

And we choose not to provide you with our software, except on the terms
that we find best protect it.  We are very serious in this business, and
have had more to do with the threats, protections and realities around
GPL'ed software than many other projects.  We choose this licence for
good reason, and after wide consultation. 

If others cannot come to licence their software under the GPL version 2
or later (at your option), a long and respected option for free software
licencing, then we respect their choice, and kindly ask that they
respect ours. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071010/f3d88e95/attachment.sig>

From abartlet at samba.org  Wed Oct 10 06:07:19 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 16:07:19 +1000
Subject: samba license change
In-Reply-To: <604aa7910710092230o7e935bd9g7bbb2cfa740dd65c@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<604aa7910710092230o7e935bd9g7bbb2cfa740dd65c@mail.gmail.com>
Message-ID: <1191996439.10594.41.camel@naomi>

On Tue, 2007-10-09 at 21:30 -0800, Jeff Spaleta wrote:
> On 10/9/07, Simo Sorce <ssorce at redhat.com> wrote:
> > Well there are 2 possible situations:
> > A) The projects that depend on samba are willing to address the
> > licensing problem
> > B) They are not
> >
> > If A we have time, we are talking about F9, plenty of time.
> >
> > If B then they have 2 choices:
> > B.1) Drop functionality
> > B.2) Implement/maintain/whatever their own SMB/CIFS support
> 
> no matter which case... in the meantime... as a distribution we have a
> serious problem with kdebase. Even if trolltech/kde are in the
> optimistic scenario A... we as a distribution can't actually build the
> currently available kdebase against the the gplv3 libsmbclient in our
> buildsystem or else we are violating the license by rebuilding our
> kdebase against our libsmbclient. So while we are in the limbo of
> scenario A resolution everything associated with kde package
> maintainence STOPS in fedora development leading up to F9. 

No, you could just stop building the optional support for libsmbclient
in the meantime. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071010/0f6b0a62/attachment.sig>

From sundaram at fedoraproject.org  Wed Oct 10 06:09:08 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 10 Oct 2007 11:39:08 +0530
Subject: samba license change
In-Reply-To: <1191996306.10594.38.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C5E9F.1050506@fedoraproject.org>
	<1191996306.10594.38.camel@naomi>
Message-ID: <470C6C84.3020802@fedoraproject.org>

Andrew Bartlett wrote:

> If there any real expectation that issues not resolved now (while there
> is significant movement in this issue) will magically be resolved later.
> Is that expectation worth the complete packaging mess that this would
> create?

What is your suggested alternative? That we release Fedora 9 with no 
support for Samba in KDE ? Step outside the narrow perspective of just 
Samba and think about the distributions which are the gateway to your 
end users.

Rahul



From peter at thecodergeek.com  Wed Oct 10 06:14:21 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 09 Oct 2007 23:14:21 -0700
Subject: Merging totem and totem-xine
In-Reply-To: <1191978010.7325.4.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
	<1191978010.7325.4.camel@Diffingo.localdomain>
Message-ID: <1191996861.4028.8.camel@localhost.localdomain>

On Tue, 2007-10-09 at 21:00 -0400, Stewart Adam wrote:
> "The gstreamer backend is the Fedora default and uses gstreamer codecs
> to play multimedia files."
> 
> "The xine backend uses the xine codecs to play multimedia files. The
> xine backend, among other things, support DVD menus."
> 

While I think your idea about these descriptions is good, it seems
entirely infeasible, mainly because Xine as shipped in Fedora does _not_
support DVD menus. Though you can install non-Free codecs from wThat
Other Repository(TM) which grant this ability to Xine-using
applications, the fact remains that if we say something about features
that a program supports, we want it to be true "out of the box" or with
as little configuration necessary to achieve the goal. 

Again, I don't believe it is right to say it supports DVD menus when it
does not as-is in Fedora; however, I like your idea of contrasting
features in the description.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071009/9e3ecb89/attachment.sig>

From peter at thecodergeek.com  Wed Oct 10 06:16:14 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 09 Oct 2007 23:16:14 -0700
Subject: Merging totem and totem-xine
In-Reply-To: <1191996861.4028.8.camel@localhost.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
	<1191978010.7325.4.camel@Diffingo.localdomain>
	<1191996861.4028.8.camel@localhost.localdomain>
Message-ID: <1191996974.4028.11.camel@localhost.localdomain>

On Tue, 2007-10-09 at 23:14 -0700, Peter Gordon wrote:
> While I think your idea about these descriptions is good, it seems
> entirely infeasible, [...]

Rereading my message, I should clarify this: It's not entirely
infeasible as a concept; but as you had worded it (Stewart), it would
have been so.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071009/1e181864/attachment.sig>

From jspaleta at gmail.com  Wed Oct 10 06:22:24 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 9 Oct 2007 22:22:24 -0800
Subject: samba license change
In-Reply-To: <1191996439.10594.41.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<604aa7910710092230o7e935bd9g7bbb2cfa740dd65c@mail.gmail.com>
	<1191996439.10594.41.camel@naomi>
Message-ID: <604aa7910710092322x659d6be4ne17f54902eda3ff6@mail.gmail.com>

On 10/9/07, Andrew Bartlett <abartlet at samba.org> wrote:
> No, you could just stop building the optional support for libsmbclient
> in the meantime.

Sorry, I totally missed that obvious option. I'll have to see what the
kde maintainers think about that in the short term.

-jef



From lesmikesell at gmail.com  Wed Oct 10 06:26:58 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Oct 2007 01:26:58 -0500
Subject: samba license change
In-Reply-To: <1191996317.10594.39.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<1191989194.3395.628.camel@mccallum.corsepiu.local>	<1191990381.13627.42.camel@localhost.localdomain>	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<1191996317.10594.39.camel@naomi>
Message-ID: <470C70B2.4030407@gmail.com>

Andrew Bartlett wrote:
> On Wed, 2007-10-10 at 07:10 +0200, Ralf Corsepius wrote:
> 
>>> In any case this is completely irrelevant, we are not asking anybody to
>>> go GPLv3, but to come out with a decision on what they want to do. Once
>>> that is clear we will know how to handle the situation.
>> Though I am strongly convinced about OpenSource and am usually
>> supporting it, for my own works, I have decided not to apply GPLv3 (at
>> least for now), because there are details inside I consider
>> counterproductive[1] and ... because I prefer not to expose myself to
>> the risks of this license :)
> 
> And we choose not to provide you with our software, except on the terms
> that we find best protect it.  We are very serious in this business, and
> have had more to do with the threats, protections and realities around
> GPL'ed software than many other projects.   We choose this licence for
> good reason, and after wide consultation. 

Did you mean to imply that the people using, say, the Apache license 
aren't serious?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mk at crc.dk  Wed Oct 10 06:53:02 2007
From: mk at crc.dk (Mogens Kjaer)
Date: Wed, 10 Oct 2007 08:53:02 +0200
Subject: Another readahead issue
In-Reply-To: <feg055$ak4$2@sea.gmane.org>
References: <1191889707.25531.49.camel@vincent52.localdomain>
	<feg055$ak4$2@sea.gmane.org>
Message-ID: <470C76CE.8060204@crc.dk>

Rex Dieter wrote:
...
> imo, avoid the mess, firefox could use an unversioned folder,
> say, /usr/lib/firefox.  I assume there's good reasons not to do this tho,
> else the firefox packagin/maintainer would be doing this already, right? :)

I've installed a 32bit firefox on a x86_64 F7, and the default.later has
references to /usr/lib64/firefox-<wrong version> so just using
/usr/lib64/firefox in default.later would be wrong.

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 abartlet at samba.org  Wed Oct 10 07:03:39 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 10 Oct 2007 17:03:39 +1000
Subject: samba license change
In-Reply-To: <470C70B2.4030407@gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<1191996317.10594.39.camel@naomi>  <470C70B2.4030407@gmail.com>
Message-ID: <1191999819.10594.48.camel@naomi>

On Wed, 2007-10-10 at 01:26 -0500, Les Mikesell wrote:
> Andrew Bartlett wrote:
> > On Wed, 2007-10-10 at 07:10 +0200, Ralf Corsepius wrote:
> > 
> >>> In any case this is completely irrelevant, we are not asking anybody to
> >>> go GPLv3, but to come out with a decision on what they want to do. Once
> >>> that is clear we will know how to handle the situation.
> >> Though I am strongly convinced about OpenSource and am usually
> >> supporting it, for my own works, I have decided not to apply GPLv3 (at
> >> least for now), because there are details inside I consider
> >> counterproductive[1] and ... because I prefer not to expose myself to
> >> the risks of this license :)
> > 
> > And we choose not to provide you with our software, except on the terms
> > that we find best protect it.  We are very serious in this business, and
> > have had more to do with the threats, protections and realities around
> > GPL'ed software than many other projects.   We choose this licence for
> > good reason, and after wide consultation. 
> 
> Did you mean to imply that the people using, say, the Apache license 
> aren't serious?

No, and with GPLv3 we are very glad to be able to link Samba with Apache
Licenced software.  It is one of the many reasons we moved to GPLv3.  

I simply mean to say that we as the Samba Team did not take this
decision lightly, nor do we consider it a risky option, but a choice
made for the good of our project.  

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071010/39e6aa8d/attachment.sig>

From jamatos at fc.up.pt  Tue Oct  9 21:08:38 2007
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Tue, 9 Oct 2007 22:08:38 +0100
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
Message-ID: <200710092208.38706.jamatos@fc.up.pt>

On Tuesday 09 October 2007 21:52:57 Arthur Pemberton wrote:
> 1) Does yum-updatesd still block yum and piruit? Causes newbies some
> headaches.

  It works for me.

> 2) Does the GUI (pup?) work in KDE?

  puplet works for me on KDE.

-- 
Jos? Ab?lio



From alexl at redhat.com  Wed Oct 10 07:15:28 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Wed, 10 Oct 2007 09:15:28 +0200
Subject: samba license change
In-Reply-To: <200710092018.21899.ville.skytta@iki.fi>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
	<200710092018.21899.ville.skytta@iki.fi>
Message-ID: <1192000528.13539.61.camel@localhost.localdomain>

On Tue, 2007-10-09 at 20:18 +0300, Ville Skytt? wrote:
> On Tuesday 09 October 2007, Simo Sorce wrote:
> >
> > Ah and btw if someone can check what is the GNOME status wrt this it
> > would be nice. Nautilus uses libsmbclient as well.
> 
> I'm no expert on GNOME stuff but I thought it does so through gnome-vfs.
> 
> gnome-vfs2.spec has:
> License: LGPLv2 and LGPL+ and GPL+
> # the daemon and the library are LGPLv2
> # the modules are LGPL+ and GPL+
> 
> libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
> (Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)

Furthermore, the smb module is run in the daemon, so the license of it
doesn't affect applications linking to gnome-vfs.




From tsmetana at redhat.com  Wed Oct 10 07:42:34 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Wed, 10 Oct 2007 09:42:34 +0200
Subject: Non-orphans treated as orphans
In-Reply-To: <3170f42f0710092221i487ac8b0j7dd904254d16672e@mail.gmail.com>
References: <3170f42f0710092221i487ac8b0j7dd904254d16672e@mail.gmail.com>
Message-ID: <20071010094234.a7fa0212.tsmetana@redhat.com>

On Wed, 10 Oct 2007 10:51:41 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> https://admin.fedoraproject.org/pkgdb/users/packages/orphan
> 
> A number of packages (like libedit and nget) which were orphaned
> sometime back and then taken over, are still listed as orphans in the
> above URL. These packages have an owner for all the current branches
> -- FC-6, F-7 and devel, but not for the EOL'ed branches.
> 
> Is this how it is supposed to be, or should I file a bug/ticket, or is
> this already a known issue?

It's a known problem and it seems it's been taken care of already:
https://hosted.fedoraproject.org/projects/packagedb/ticket/55

Regards.

-- 
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From andy at warmcat.com  Wed Oct 10 07:44:18 2007
From: andy at warmcat.com (Andy Green)
Date: Wed, 10 Oct 2007 08:44:18 +0100
Subject: The gstreamer third way
In-Reply-To: <1191990002.13627.35.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
Message-ID: <470C82D2.2010107@warmcat.com>

Somebody in the thread at some point said:

> Well there are 2 possible situations:
> A) The projects that depend on samba are willing to address the
> licensing problem
> B) They are not
> 
> If A we have time, we are talking about F9, plenty of time.
> 
> If B then they have 2 choices:
> B.1) Drop functionality
> B.2) Implement/maintain/whatever their own SMB/CIFS support

Can this not ultimately be framed and resolved in the same way as
gstreamer-plugins-good/bad/ugly? If it is still only a matter of
distribution (I didn't really understand the whole of the GPL3 yet), the
combination can occur at the end-user.

In that scenario until there is a better resolution Fedora ships an
increasingly dusty GPL2 Samba and it's up to the user if they replace it
with a same soname GPL3 packaged one from elsewhere (it's always up to
them anyway, let's face it).

-Andy



From lkundrak at redhat.com  Wed Oct 10 08:40:35 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 10 Oct 2007 10:40:35 +0200
Subject: samba license change
In-Reply-To: <fefvuq$ak4$1@sea.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<8718ff870710081434h35f7f0c2w7dc6be9718aa7b7b@mail.gmail.com>
	<fefvuq$ak4$1@sea.gmane.org>
Message-ID: <1192005635.6890.2.camel@localhost.localdomain>


On Tue, 2007-10-09 at 08:33 -0500, Rex Dieter wrote:
> Ville Skytt? wrote:
> 
> > On 10/3/07, Simo Sorce <ssorce at redhat.com> wrote:
> >> Samba has changed it's license from GPLv2+ to GPLv3+
> >> The license change affects version 3.2.0 (still a pre-release now).
> >> In F-8 we will still have 3.0.X so the change affects F-9
> > 
> > Looks like KDE may suffer from this, both kdebase and kdebase4 are
> > labeled GPLv2 (no "+").
> 
> Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will have
> to be dropped, at least temporarily.

Would it be a problem for Samba team to make an exception from the
license for KDE? At least for 3.2.0? It might be unlikely that it would
hapen, and me, as non-lawyer, know nothing about the legal implications,
but that might be one of ways to ensure availability of quality free
software.

> (1) qt is GPLv2, trolltech is evaluating GPLv2+ or GPLv3, but that's all
> behind closed doors with no visible movement.  There is a proposal within
> kde to move to (L)GPLv2+.  All of this is slow, tedious work, often
> blocking on lawyers, and we all know how fast they are.
> 
> -- Rex
> 
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From mcepl at redhat.com  Wed Oct 10 08:55:25 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 10 Oct 2007 10:55:25 +0200
Subject: Gnome Logout Hangs?
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
	<1191957019.4913.15.camel@raptor.sr.unh.edu>
	<470C06EC.2060207@gmail.com>
Message-ID: <slrnfgp4rt.eid.mcepl@hubmaier.ceplovi.cz>

On 2007-10-09, 22:55 GMT, Eric Mesa wrote:
> Yeah, that's why I never filed a bug report because running 
> compiz
> means you're running Nvidia or ATI drivers which means they can't
> help.  At least that's the impression I get.

You can have some level of compiz with open source ati driver -- 
it is buggy, but it exists. And of course, at least theoretically 
compiz should work with intel driver as well.

Matej



From lkundrak at redhat.com  Wed Oct 10 09:07:23 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 10 Oct 2007 11:07:23 +0200
Subject: Gnome Logout Hangs?
In-Reply-To: <1191971799.26962.8.camel@neuromancer>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>
	<1191957019.4913.15.camel@raptor.sr.unh.edu>
	<470C06EC.2060207@gmail.com> <1191971799.26962.8.camel@neuromancer>
Message-ID: <1192007243.6890.7.camel@localhost.localdomain>


On Tue, 2007-10-09 at 19:16 -0400, Thomas J. Baker wrote:
> On Tue, 2007-10-09 at 18:55 -0400, Eric Mesa wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Thomas J. Baker wrote:
> > > On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
> > >> Still happens to me.  I happen to be running Compiz - you?
> > >>
> > >
> > > Yes I am.
> > >
> > > Thanks,
> > >
> > > tjb
> > Yeah, that's why I never filed a bug report because running compiz
> > means you're running Nvidia or ATI drivers which means they can't
> > help.  At least that's the impression I get.
> > 
> 
> I have the same problem on my Intel laptop so I don't think it's related
> to the NVIDIA driver on my desktop. It's some type of hang because if I
> just C-A-Backspace, gdm comes back up fine. Something is not letting X
> reset.

Could you please try to check what is still connected to the X server?
Maybe with xwininfo, or look into /proc/*/fd to see what process has an
open socket to the X server, or whatver. And please file a bug.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicu_fedora at nicubunu.ro  Wed Oct 10 09:08:17 2007
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Wed, 10 Oct 2007 12:08:17 +0300
Subject: The gstreamer third way
In-Reply-To: <470C82D2.2010107@warmcat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com>
Message-ID: <470C9681.9050905@nicubunu.ro>

Andy Green wrote:
>> Well there are 2 possible situations:
>> A) The projects that depend on samba are willing to address the
>> licensing problem
>> B) They are not
>>
>> If A we have time, we are talking about F9, plenty of time.
>>
>> If B then they have 2 choices:
>> B.1) Drop functionality
>> B.2) Implement/maintain/whatever their own SMB/CIFS support
> 
> Can this not ultimately be framed and resolved in the same way as
> gstreamer-plugins-good/bad/ugly? If it is still only a matter of
> distribution (I didn't really understand the whole of the GPL3 yet), the
> combination can occur at the end-user.

No. The ugly gstreamer plugins don't have a license problem, but a 
patents problem and this problem apply only on certain parts of the 
world, there are other parts where they are perfectly fine from any 
point of view.

Using the same way for Samba would be knowingly breaking the GPL, 
something I don't think anybody want to do.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From nicolas.mailhot at laposte.net  Wed Oct 10 09:42:36 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Oct 2007 11:42:36 +0200 (CEST)
Subject: samba license change
In-Reply-To: <470C6C84.3020802@fedoraproject.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi> <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C5E9F.1050506@fedoraproject.org> <1191996306.10594.38.camel@naomi>
	<470C6C84.3020802@fedoraproject.org>
Message-ID: <9280.192.54.193.51.1192009356.squirrel@rousalka.dyndns.org>


Le Mer 10 octobre 2007 08:09, Rahul Sundaram a ?crit :
> Andrew Bartlett wrote:
>
>> If there any real expectation that issues not resolved now (while
>> there
>> is significant movement in this issue) will magically be resolved
>> later.
>> Is that expectation worth the complete packaging mess that this
>> would
>> create?
>
> What is your suggested alternative? That we release Fedora 9 with no
> support for Samba in KDE ? Step outside the narrow perspective of just
> Samba and think about the distributions which are the gateway to your
> end users.

Rahul : past history proved samba users have been very keen on new
Samba releases, because current samba is never "good enough". MS works
full-time pushing users to situations where samba is useless and then
samba plays catch-up.

Freezing samba while KDE moves is not the distro-friendly solution.
Users will yell your frozen GPLv2 samba has not the fixes and
improvements of GPLv3 samba. You want to complain to someone for
putting distributions in a hard place, complain to the KDE project not
the Samba guys. Samba has been crystal-clear on its roadmap for a long
time.

The situation is not different from out-of-tree drivers and upstream
vanilla kernel. When you depend on a large piece of complex code it's
your responsibility to make sure you take into account announced code
or licensing changes on this code. And itt's no use begging for
indefinite postponement of those changes when they happen. (if they've
been announced for a reasonable time, as is the case there)

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Oct 10 09:47:52 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Oct 2007 11:47:52 +0200 (CEST)
Subject: samba license change
In-Reply-To: <1191989194.3395.628.camel@mccallum.corsepiu.local>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
Message-ID: <41776.192.54.193.51.1192009672.squirrel@rousalka.dyndns.org>


Le Mer 10 octobre 2007 06:06, Ralf Corsepius a ?crit :
> On Wed, 2007-10-10 at 13:38 +1000, Andrew Bartlett wrote:
>
>> The bit that bothers me is that not only was Samba for the longest
>> time
>> mentioned in most GPLv3 news articles, we asked if anybody had a
>> reason
>> not to change our licence, and nobody gave a compelling reason.
> The rationales for projects not wanting to switch to GPLv3 are quite
> simple

And they don't matter in this case.

Simply put, you can choose your own license as you wish, but you also
have to respect the licenses of stuff you depend on (it's your choice
to depend on external projects, and your burden to bear).

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Oct 10 09:51:38 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Oct 2007 11:51:38 +0200 (CEST)
Subject: samba license change
In-Reply-To: <1191993055.3395.643.camel@mccallum.corsepiu.local>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
Message-ID: <63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>


Le Mer 10 octobre 2007 07:10, Ralf Corsepius a ?crit :

> Well, it matters very much to individuals if they want to endanger
> themselves by the uncertainties of a "brand new" license a political
> organization with controversial (some say "fundamentalist zealotic")
> attitude (the FSF) tries to enforce.

Then don't link to GPLv3 code. Simple. Easy.

Don't ask for the freedom to make licensing choices then deny it to
other projects because they happen to make a different choice than
yours (and incidentally they've been involved in actual trials which
are likely to be more relevant to them than your anti-FSF parano?a)

-- 
Nicolas Mailhot



From andy at warmcat.com  Wed Oct 10 09:58:06 2007
From: andy at warmcat.com (Andy Green)
Date: Wed, 10 Oct 2007 10:58:06 +0100
Subject: The gstreamer third way
In-Reply-To: <470C9681.9050905@nicubunu.ro>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C82D2.2010107@warmcat.com>
	<470C9681.9050905@nicubunu.ro>
Message-ID: <470CA22E.6050207@warmcat.com>

Somebody in the thread at some point said:

>> gstreamer-plugins-good/bad/ugly? If it is still only a matter of
>> distribution (I didn't really understand the whole of the GPL3 yet), the
>> combination can occur at the end-user.

> Using the same way for Samba would be knowingly breaking the GPL,
> something I don't think anybody want to do.

Which part of which GPL do you think would be violated here?

-Andy



From rc040203 at freenet.de  Wed Oct 10 10:20:14 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 12:20:14 +0200
Subject: samba license change
In-Reply-To: <63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
Message-ID: <1192011614.3395.721.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 11:51 +0200, Nicolas Mailhot wrote:
> Le Mer 10 octobre 2007 07:10, Ralf Corsepius a ?crit :
> 
> > Well, it matters very much to individuals if they want to endanger
> > themselves by the uncertainties of a "brand new" license a political
> > organization with controversial (some say "fundamentalist zealotic")
> > attitude (the FSF) tries to enforce.
> 
> Then don't link to GPLv3 code. Simple. Easy.
False - This is not easy. 

> Don't ask for the freedom to make licensing choices then deny it to
> other projects because they happen to make a different choice than
> yours (and incidentally they've been involved in actual trials which
> are likely to be more relevant to them than your anti-FSF parano?a)
I prefer to rely on existing precedences which had been approved by
courts, and not a political party's wishful thinking.

Ralf





From pertusus at free.fr  Wed Oct 10 10:31:15 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 10 Oct 2007 12:31:15 +0200
Subject: samba license change
In-Reply-To: <1192011614.3395.721.camel@mccallum.corsepiu.local>
References: <20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
Message-ID: <20071010103114.GB16044@free.fr>

On Wed, Oct 10, 2007 at 12:20:14PM +0200, Ralf Corsepius wrote:
> I prefer to rely on existing precedences which had been approved by
> courts, and not a political party's wishful thinking.

Then you never change licenses? Somebody have to take the risk to
release software under the new license in order to have it challenged in
court. It is logical that those who need the new features of the license
(the samba team) takes the risk. Those who don't want to take the risk
have to rewrite the software under whatever license they prefer. They
have to be solidary because they use the work of those who want the new
license.

--
Pat



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 10 10:50:40 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 10 Oct 2007 12:50:40 +0200
Subject: FC6: Metadata file does not match checksum
Message-ID: <20071010125040.ae078446.mschwendt.tmp0701.nospam@arcor.de>

Revisiting the annoying "Metadata file does not match checksum" problem,
since it just came back here like this:

$ ll /var/cache/yum/updates-released/
total 488
-rw-r--r-- 1 root root      0 Oct 10 12:28 cachecookie
drwxr-xr-x 2 root root   4096 Oct 10 12:28 headers
drwxr-xr-x 2 root root   4096 Oct 10 12:28 packages
-rw-r--r-- 1 root root 461224 Oct 10 12:33 primary.xml.gz
-rw-r--r-- 1 root root   1197 Sep 19 00:47 repomd.xml

The cached repomd.xml file is out-of-date from September 19th, and all
the mirrors offer much newer repodata from Oct 8th. The mirrors are
not to blame here, since Yum does not consider downloading a fresh copy.
Instead, it seems it tries to fetch metadata files which match the old
repomd index:

http://ftp.rhd.ru/pub/fedora/linux/core/updates/6/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
primary.xml.gz            100% |=========================| 450 kB    00:01     
http://mirrors.kernel.org/fedora/core/updates/6/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
primary.xml.gz                                                  450 kB 00:00 
ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/6/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
primary.xml.gz            100% |=========================| 450 kB    00:04     
ftp://thales.memphis.edu/fedora/linux/core/updates/6/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
[...]

Is this observation right?



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 10 10:56:57 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 10 Oct 2007 12:56:57 +0200
Subject: FC6 mirrorlists not found
Message-ID: <20071010125657.6e7fd6d3.mschwendt.tmp0701.nospam@arcor.de>

Sometimes this works and is redirected to rhold.fedoraproject.org,
sometimes it doesn't and fails like this:

Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Could not retrieve mirrorlist http://fedora.redhat.com/download/mirrors/updates-released-fc6 error was
[Errno 14] HTTP Error 404: Date: Wed, 10 Oct 2007 10:52:18 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Length: 324
Content-Type: text/html; charset=iso-8859-1

Error: Cannot find a valid baseurl for repo: updates-released


$ grep mirror /etc/yum.repos.d/fedora-updates.repo 
mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever



Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
http://less.cogeco.net/pub/fedora/linux/core/updates/6/i386/repodata/repomd.xml: [Errno 12] Timeout: <urlopen error timed out>
Trying other mirror.
updates-released          100% |=========================| 1.2 kB    00:00     
Could not retrieve mirrorlist http://fedora.redhat.com/download/mirrors/fedora-extras-6 error was
[Errno 14] HTTP Error 404: Date: Wed, 10 Oct 2007 10:55:27 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Length: 319
Content-Type: text/html; charset=iso-8859-1

Error: Cannot find a valid baseurl for repo: extras



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 10 11:01:38 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 10 Oct 2007 13:01:38 +0200
Subject: FC6 mirrorlists not found
In-Reply-To: <20071010125657.6e7fd6d3.mschwendt.tmp0701.nospam@arcor.de>
References: <20071010125657.6e7fd6d3.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071010130138.a2cce2fa.mschwendt.tmp0701.nospam@arcor.de>

$ wget http://fedora.redhat.com/download/mirrors/updates-released-fc6
--12:59:14--  http://fedora.redhat.com/download/mirrors/updates-released-fc6
Resolving fedora.redhat.com... 209.132.176.120
Connecting to fedora.redhat.com|209.132.176.120|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://rhold.fedoraproject.org/Download/mirrors/updates-released-fc6 [following]
--12:59:15--  http://rhold.fedoraproject.org/Download/mirrors/updates-released-fc6
Resolving rhold.fedoraproject.org... 209.132.176.120
Reusing existing connection to fedora.redhat.com:80.
HTTP request sent, awaiting response... 404 Not Found
12:59:15 ERROR 404: Not Found.

Proxy errors? Sometimes it gives 404, the next time it works again,
then fails again.

$ wget http://fedora.redhat.com/download/mirrors/updates-released-fc6
--13:00:09--  http://fedora.redhat.com/download/mirrors/updates-released-fc6
Resolving fedora.redhat.com... 209.132.176.120
Connecting to fedora.redhat.com|209.132.176.120|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://rhold.fedoraproject.org/Download/mirrors/updates-released-fc6 [following]
--13:00:10--  http://rhold.fedoraproject.org/Download/mirrors/updates-released-fc6
Resolving rhold.fedoraproject.org... 209.132.176.120
Reusing existing connection to fedora.redhat.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 4488 (4.4K) [text/plain]
Saving to: `updates-released-fc6'

100%[=======================================>] 4,488       21.3K/s   in 0.2s   

13:00:10 (21.3 KB/s) - `updates-released-fc6.2' saved [4488/4488]



From drago01 at gmail.com  Wed Oct 10 11:06:24 2007
From: drago01 at gmail.com (dragoran)
Date: Wed, 10 Oct 2007 13:06:24 +0200
Subject: Gnome Logout Hangs?
In-Reply-To: <1191971799.26962.8.camel@neuromancer>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>	<582715960710091205w4b0f822ete5b7b3568fe6bf40@mail.gmail.com>	<1191957019.4913.15.camel@raptor.sr.unh.edu>	<470C06EC.2060207@gmail.com>
	<1191971799.26962.8.camel@neuromancer>
Message-ID: <470CB230.7090305@gmail.com>

Thomas J. Baker wrote:
> On Tue, 2007-10-09 at 18:55 -0400, Eric Mesa wrote:
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Thomas J. Baker wrote:
>>     
>>> On Tue, 2007-10-09 at 15:05 -0400, Eric Mesa wrote:
>>>       
>>>> Still happens to me.  I happen to be running Compiz - you?
>>>>
>>>>         
>>> Yes I am.
>>>
>>> Thanks,
>>>
>>> tjb
>>>       
>> Yeah, that's why I never filed a bug report because running compiz
>> means you're running Nvidia or ATI drivers which means they can't
>> help.  At least that's the impression I get.
>>
>>     
>
> I have the same problem on my Intel laptop so I don't think it's related
> to the NVIDIA driver on my desktop. It's some type of hang because if I
> just C-A-Backspace, gdm comes back up fine. Something is not letting X
> reset.
>   
well there is a known bug with the nvidia drivers when using compiz with 
indirect rendering that causes this... but there lastest driver fixes 
it. And also thats the first time I hear this happening on Intel.... a 
bug needs to be filled ;)



From kevin.kofler at chello.at  Wed Oct 10 11:30:48 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 11:30:48 +0000 (UTC)
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
Message-ID: <loom.20071010T112610-389@post.gmane.org>

Andrew Bartlett <abartlet <at> samba.org> writes:
> The bit that bothers me is that not only was Samba for the longest time
> mentioned in most GPLv3 news articles, we asked if anybody had a reason
> not to change our licence, and nobody gave a compelling reason.

There definitely have been complaints from the KDE camp, both on public news 
sites like Slashdot and on KDE developer blogs.

See, the KDE project can't just move to GPLv3, most of their code is actually 
LGPL (which allows converting to any GPLv2+) or GPLv2+ already, but Qt is GPLv2 
only. So KDE can't do anything without Trolltech, and Trolltech is still in 
the "evaluating their options" phase.

Also be aware that if the problem gets solved, it will be solved only for KDE 
4, KDE 3 relies on Qt 3 which is not supported by Trolltech anymore, so the 
chances for that to change its license are essentially nil.

        Kevin Kofler



From j.w.r.degoede at hhs.nl  Wed Oct 10 11:25:17 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 10 Oct 2007 13:25:17 +0200
Subject: samba license change
In-Reply-To: <loom.20071010T112610-389@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
Message-ID: <470CB69D.304@hhs.nl>

Kevin Kofler wrote:
> Andrew Bartlett <abartlet <at> samba.org> writes:
>> The bit that bothers me is that not only was Samba for the longest time
>> mentioned in most GPLv3 news articles, we asked if anybody had a reason
>> not to change our licence, and nobody gave a compelling reason.
> 
> There definitely have been complaints from the KDE camp, both on public news 
> sites like Slashdot and on KDE developer blogs.
> 
> See, the KDE project can't just move to GPLv3, most of their code is actually 
> LGPL (which allows converting to any GPLv2+) or GPLv2+ already, but Qt is GPLv2 
> only. So KDE can't do anything without Trolltech, and Trolltech is still in 
> the "evaluating their options" phase.
> 
> Also be aware that if the problem gets solved, it will be solved only for KDE 
> 4, KDE 3 relies on Qt 3 which is not supported by Trolltech anymore, so the 
> chances for that to change its license are essentially nil.
> 

I must say I'm sorry to step into this flamefest, but weren't the QT licensing 
issues the reasons why we have gnome in the first place? So all in all it turns 
out that despite all trolltech's promises, they don't follow through?

Its really simple to me, TrollTech has the power to fix this, and they should, 
so instead of endless discussions here, maybe those that care should focus 
their efforts on TrollTech instead?

Regards,

hans



From opensource at till.name  Wed Oct 10 12:02:19 2007
From: opensource at till.name (Till Maas)
Date: Wed, 10 Oct 2007 14:02:19 +0200
Subject: FC6: Metadata file does not match checksum
In-Reply-To: <20071010125040.ae078446.mschwendt.tmp0701.nospam@arcor.de>
References: <20071010125040.ae078446.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200710101402.19959.opensource@till.name>

On Mi Oktober 10 2007, Michael Schwendt wrote:
> Revisiting the annoying "Metadata file does not match checksum" problem,

> since it just came back here like this:
> The cached repomd.xml file is out-of-date from September 19th, and all
> the mirrors offer much newer repodata from Oct 8th. The mirrors are
> not to blame here, since Yum does not consider downloading a fresh copy.
> Instead, it seems it tries to fetch metadata files which match the old
> repomd index:

> Is this observation right?

I always experienced this with any Fedora Release I used (4-7) and imho your 
observation is right. For me setting the metadata_expire high or just do 
a "yum clean all" when this happens. 

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/6f99464e/attachment.sig>

From kevin.kofler at chello.at  Wed Oct 10 12:04:49 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 12:04:49 +0000 (UTC)
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
Message-ID: <loom.20071010T115730-875@post.gmane.org>

Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
> Its really simple to me, TrollTech has the power to fix this, and they
> should, so instead of endless discussions here, maybe those that care should
> focus their efforts on TrollTech instead?

Actually, depending on what exactly gets linked with libsmbclient (which in 
turn depends on your definition of "linking", is the external kio_smb process 
the only thing considered "linked" with libsmbclient? ldd seems to think so 
(the kio_*.so libs are actually started up as separate processes by kdeinit, 
and only kio_smb.so shows up as linked to libsmbclient), but is ldd the correct 
definition of "linking" here?), some other KDE contributors may have to 
relicense their code too. But what's sure is that without Trolltech, KDE can't 
do anything.

        Kevin Kofler



From aportal at univ-montp2.fr  Wed Oct 10 12:06:50 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Wed, 10 Oct 2007 14:06:50 +0200
Subject: FC-6: automake-1.9 on ppc
In-Reply-To: <20071009161053.GA24990@camelia.ucw.cz>
References: <200710021129.47993.aportal@univ-montp2.fr>
	<200710080956.38846.aportal@univ-montp2.fr>
	<20071009161053.GA24990@camelia.ucw.cz>
Message-ID: <200710101406.51048.aportal@univ-montp2.fr>

Le Tuesday 09 October 2007 18:10:53 Stepan Kasal, vous avez ?crit?:
> Hello,
>
> On Mon, Oct 08, 2007 at 09:56:38AM +0200, Alain PORTAL wrote:
> > Previously, I "BuildRequires: automake", but it seems I made a mistake
> > and I removed it...
>
> but you should understand that this would break if automake were
> upgraded to 1.10.

I don't think.
I think if automake is upgraded, it will be search for the upgrade.

> I do not think this is a real possibility in FC-6, 
> so your solution is adequate here.
>
> But for general development, let me remind that there are only two
> safe options:
>
> 1) either you rely on the autotools-generated files packed in the
> tarball, in which case you do not need to BuildRequire anything.

It seems I can't rely on these files because when I run ./configure && make, 
make rerun ./configure

> 2) Or you do refresh the autotools generated stuff fully, so you need
> at least:
>
> BuildRequire: autoconf automake
> %build
> aclocal
> autoconf
> automake
>
> The aclocal collects various *.m4 files so you often need
> 	aclocal -I m4
> for *.m4 files in the m4/ subdir of the tarball, and you often need
> to BuildRequire libfoo-devel, if libfoo is used by your package and
> if it contains a /usr/share/aclocal/foo.m4
>
>
> As you see, the second option can get a bit complicated, so if the
> only problem is a time stamp mistake in the upstream tarball, it
> might be a better idea to make the upstream to realease a fixed
> tarball, or find the bug and patch it by a "touch -r".

I'm not sure this is a time stamp problem. Project is manage with Kdevelop and 
this is Kdevelop which generate the files.
The real problem is that I'm the new upstream and I don't know how to fix...

Regards,
Alain
-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From limb at jcomserv.net  Wed Oct 10 12:12:09 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 10 Oct 2007 07:12:09 -0500 (CDT)
Subject: samba license change
In-Reply-To: <loom.20071010T115730-875@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<loom.20071010T115730-875@post.gmane.org>
Message-ID: <39534.63.85.68.164.1192018329.squirrel@mail.jcomserv.net>


> Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
>> Its really simple to me, TrollTech has the power to fix this, and they
>> should, so instead of endless discussions here, maybe those that care
>> should
>> focus their efforts on TrollTech instead?
>
> Actually, depending on what exactly gets linked with libsmbclient (which
> in
> turn depends on your definition of "linking", is the external kio_smb
> process
> the only thing considered "linked" with libsmbclient? ldd seems to think
> so
> (the kio_*.so libs are actually started up as separate processes by
> kdeinit,
> and only kio_smb.so shows up as linked to libsmbclient), but is ldd the
> correct
> definition of "linking" here?), some other KDE contributors may have to
> relicense their code too. But what's sure is that without Trolltech, KDE
> can't
> do anything.

I'm not the person with the expertise to accomplish this, but would it be
possible to have the rpm build process check the license tag of the
current spec, query the license tags of BuildRequires, and die with an
error if a license violation occurs?  If would really help keep people on
their toes WRT license tags.  I could see it getting hairy with multiple
tags, though.

Just my $0.02.

>         Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From ssorce at redhat.com  Wed Oct 10 12:30:05 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 08:30:05 -0400
Subject: samba license change
In-Reply-To: <1192011614.3395.721.camel@mccallum.corsepiu.local>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
Message-ID: <1192019405.13627.57.camel@localhost.localdomain>

On Wed, 2007-10-10 at 12:20 +0200, Ralf Corsepius wrote:
> On Wed, 2007-10-10 at 11:51 +0200, Nicolas Mailhot wrote:
> > Le Mer 10 octobre 2007 07:10, Ralf Corsepius a ?crit :
> > 
> > > Well, it matters very much to individuals if they want to endanger
> > > themselves by the uncertainties of a "brand new" license a political
> > > organization with controversial (some say "fundamentalist zealotic")
> > > attitude (the FSF) tries to enforce.
> > 
> > Then don't link to GPLv3 code. Simple. Easy.
> False - This is not easy. 
> 
> > Don't ask for the freedom to make licensing choices then deny it to
> > other projects because they happen to make a different choice than
> > yours (and incidentally they've been involved in actual trials which
> > are likely to be more relevant to them than your anti-FSF parano?a)
> I prefer to rely on existing precedences which had been approved by
> courts, and not a political party's wishful thinking.

Simply put, can you stop trolling?

This is not an anti-GPLv3 trollfest, we have real things to discuss.
You are just distracting with irrelevant trolling arguments.

Did I say trolling? :-)

Simo.



From alan at redhat.com  Wed Oct 10 12:33:13 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 10 Oct 2007 08:33:13 -0400
Subject: samba license change
In-Reply-To: <loom.20071010T112610-389@post.gmane.org>
References: <fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
Message-ID: <20071010123313.GB13559@devserv.devel.redhat.com>

On Wed, Oct 10, 2007 at 11:30:48AM +0000, Kevin Kofler wrote:
> only. So KDE can't do anything without Trolltech, and Trolltech is still in 
> the "evaluating their options" phase.

Well I'm sure the added urgency will help them prioritise

> Also be aware that if the problem gets solved, it will be solved only for KDE 
> 4, KDE 3 relies on Qt 3 which is not supported by Trolltech anymore, so the 
> chances for that to change its license are essentially nil.

Thats a curious claim. If anything its easier to grant an extra licence 
consent on a product you no longer support and market under other parallel
proprietary licences than one you do.

Alan



From ssorce at redhat.com  Wed Oct 10 12:39:06 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 08:39:06 -0400
Subject: samba license change
In-Reply-To: <loom.20071010T112610-389@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
Message-ID: <1192019946.13627.65.camel@localhost.localdomain>

On Wed, 2007-10-10 at 11:30 +0000, Kevin Kofler wrote:
> Andrew Bartlett <abartlet <at> samba.org> writes:
> > The bit that bothers me is that not only was Samba for the longest time
> > mentioned in most GPLv3 news articles, we asked if anybody had a reason
> > not to change our licence, and nobody gave a compelling reason.
> 
> There definitely have been complaints from the KDE camp, both on public news 
> sites like Slashdot and on KDE developer blogs.

Slashdot ? On Slashdot anybody can say anything and the contrary, I
wonder why people is so shy to talk directly with other developers when
they need to...

> See, the KDE project can't just move to GPLv3, most of their code is actually 
> LGPL (which allows converting to any GPLv2+) or GPLv2+ already, but Qt is GPLv2 
> only. So KDE can't do anything without Trolltech, and Trolltech is still in 
> the "evaluating their options" phase.

Maybe with a bit of pressure because of a real problem they will be
faster ?

> Also be aware that if the problem gets solved, it will be solved only for KDE 
> 4, KDE 3 relies on Qt 3 which is not supported by Trolltech anymore, so the 
> chances for that to change its license are essentially nil.

If Qt3 is obsolete I can't understand why Trolltech can't add an
exception there, it should be actually much more easier for older
unsupported software, after all who cares for that? It's going to slowly
disappear from the scene anyway and GPLv2 vs GPLv2+/exception for v3
does not make any difference in that case.

In any case I was under the impression that F9 was going to use
KDE4/QT4, have plans changed ?

Simo.



From ssorce at redhat.com  Wed Oct 10 12:41:08 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 08:41:08 -0400
Subject: samba license change
In-Reply-To: <1192000528.13539.61.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
	<200710092018.21899.ville.skytta@iki.fi>
	<1192000528.13539.61.camel@localhost.localdomain>
Message-ID: <1192020068.13627.68.camel@localhost.localdomain>

On Wed, 2007-10-10 at 09:15 +0200, Alexander Larsson wrote:
> On Tue, 2007-10-09 at 20:18 +0300, Ville Skytt? wrote:
> > On Tuesday 09 October 2007, Simo Sorce wrote:
> > >
> > > Ah and btw if someone can check what is the GNOME status wrt this it
> > > would be nice. Nautilus uses libsmbclient as well.
> > 
> > I'm no expert on GNOME stuff but I thought it does so through gnome-vfs.
> > 
> > gnome-vfs2.spec has:
> > License: LGPLv2 and LGPL+ and GPL+
> > # the daemon and the library are LGPLv2
> > # the modules are LGPL+ and GPL+
> > 
> > libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
> > (Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)
> 
> Furthermore, the smb module is run in the daemon, so the license of it
> doesn't affect applications linking to gnome-vfs.

This is interesting, to be sure we should evaluate though if there is
intimate communication and sharing of data structures between the daemon
and the client, but things looks much better in the GNOME camp.

Thanks for the info.
Simo.



From lesmikesell at gmail.com  Wed Oct 10 12:51:20 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Oct 2007 07:51:20 -0500
Subject: samba license change
In-Reply-To: <20071010123313.GB13559@devserv.devel.redhat.com>
References: <fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<loom.20071010T112610-389@post.gmane.org>
	<20071010123313.GB13559@devserv.devel.redhat.com>
Message-ID: <470CCAC8.2020209@gmail.com>

Alan Cox wrote:
> On Wed, Oct 10, 2007 at 11:30:48AM +0000, Kevin Kofler wrote:
>> only. So KDE can't do anything without Trolltech, and Trolltech is still in 
>> the "evaluating their options" phase.
> 
> Well I'm sure the added urgency will help them prioritise
> 
>> Also be aware that if the problem gets solved, it will be solved only for KDE 
>> 4, KDE 3 relies on Qt 3 which is not supported by Trolltech anymore, so the 
>> chances for that to change its license are essentially nil.
> 
> Thats a curious claim. If anything its easier to grant an extra licence 
> consent on a product you no longer support and market under other parallel
> proprietary licences than one you do.

Doesn't everyone who has ever contributed code have to agree to a change 
unless it had the "gplv2 or newer" clause to begin with - unless they 
also turned over ownership of the copyright to someone else?

-- 
   Les Mikesell
     lesmikesell at gmail.com



From zprikryl at redhat.com  Wed Oct 10 13:16:19 2007
From: zprikryl at redhat.com (Zdenek Prikryl)
Date: Wed, 10 Oct 2007 15:16:19 +0200
Subject: acpid and logging
Message-ID: <470CD0A3.2030204@redhat.com>

Hello,
since version 1.0.6, acpid does not use separate file for logging. It uses
openlog() and vsyslog() instead of own implementation of logging. So everything
go to /var/log/messages. But it could be dangerous. According to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=294391, it could lead to unreadable
/var/log/messages.

So there are two options:
1. Get back to old style logging (but upstream does not want to)
2. In /etc/rsyslog.conf append a filter for acpid, so rsyslog will be logging
messages form acpid in separate file.

Question is, what is better solution :-)

Thanks

Zdenek



From notting at redhat.com  Wed Oct 10 13:21:12 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 10 Oct 2007 09:21:12 -0400
Subject: samba license change
In-Reply-To: <1192000528.13539.61.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
	<200710092018.21899.ville.skytta@iki.fi>
	<1192000528.13539.61.camel@localhost.localdomain>
Message-ID: <20071010132112.GA23240@nostromo.devel.redhat.com>

Alexander Larsson (alexl at redhat.com) said: 
> > gnome-vfs2.spec has:
> > License: LGPLv2 and LGPL+ and GPL+
> > # the daemon and the library are LGPLv2
> > # the modules are LGPL+ and GPL+
> > 
> > libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
> > (Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)
> 
> Furthermore, the smb module is run in the daemon, so the license of it
> doesn't affect applications linking to gnome-vfs.

But if it's run *in the daemon*, and the daemon is LGPLv2 (only)....

Bill



From j.w.r.degoede at hhs.nl  Wed Oct 10 13:09:24 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 10 Oct 2007 15:09:24 +0200
Subject: samba license change
In-Reply-To: <20071010132112.GA23240@nostromo.devel.redhat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>	<1191936845.8880.8.camel@localhost.localdomain>	<1191948598.8880.24.camel@localhost.localdomain>	<200710092018.21899.ville.skytta@iki.fi>	<1192000528.13539.61.camel@localhost.localdomain>
	<20071010132112.GA23240@nostromo.devel.redhat.com>
Message-ID: <470CCF04.9090604@hhs.nl>

Bill Nottingham wrote:
> Alexander Larsson (alexl at redhat.com) said: 
>>> gnome-vfs2.spec has:
>>> License: LGPLv2 and LGPL+ and GPL+
>>> # the daemon and the library are LGPLv2
>>> # the modules are LGPL+ and GPL+
>>>
>>> libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
>>> (Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)
>> Furthermore, the smb module is run in the daemon, so the license of it
>> doesn't affect applications linking to gnome-vfs.
> 
> But if it's run *in the daemon*, and the daemon is LGPLv2 (only)....
> 

Not a problem then as LGPLv2 may be converted to GPLv2+, and thus is GPLv3 
compatible.

Regards,

Hans



From cmadams at hiwaay.net  Wed Oct 10 13:27:16 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 10 Oct 2007 08:27:16 -0500
Subject: samba license change
In-Reply-To: <1191996306.10594.38.camel@naomi>
References: <1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C5E9F.1050506@fedoraproject.org>
	<1191996306.10594.38.camel@naomi>
Message-ID: <20071010132716.GA1226232@hiwaay.net>

Once upon a time, Andrew Bartlett <abartlet at samba.org> said:
> If there any real expectation that issues not resolved now (while there
> is significant movement in this issue) will magically be resolved later.
> Is that expectation worth the complete packaging mess that this would
> create?

There is precedent; see the old MySQL client library licensing issues.
For a few releases, there was a compatibility library under the old
license until the issues were cleared up, and then the compat library
went away.

However, there was a SONAME difference there that made it easy to track.
-- 
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 dominik at greysector.net  Wed Oct 10 12:12:15 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 10 Oct 2007 14:12:15 +0200
Subject: Help requested re build errors on x86_64-devel
In-Reply-To: <470C0CDD.7070901@marcbradshaw.co.uk>
References: <470C0CDD.7070901@marcbradshaw.co.uk>
Message-ID: <20071010121215.GA7296@ryvius.pekin.waw.pl>

On Wednesday, 10 October 2007 at 01:21, Marc Bradshaw wrote:
> Hi,
> 
> Are there any c++ gurus on the list who could shed some light on a
> problem we are having building a package for x86_64-devel.
> The package builds in i386-devel and x86_64-f7 but fails on x86_64-devel
> with lots of "template with C linkage"errors.

In case of trouble with x86_64, why not ask some of the x86-64 SIG
folks? http://fedoraproject.org/wiki/SIGs/x86-64

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From laurent.rineau__fedora at normalesup.org  Wed Oct 10 13:31:54 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Wed, 10 Oct 2007 15:31:54 +0200
Subject: samba license change
In-Reply-To: <39534.63.85.68.164.1192018329.squirrel@mail.jcomserv.net>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<loom.20071010T115730-875@post.gmane.org>
	<39534.63.85.68.164.1192018329.squirrel@mail.jcomserv.net>
Message-ID: <200710101531.54463@rineau.tsetse>

On Wednesday 10 October 2007 14:12:09 Jon Ciesla wrote:
> I'm not the person with the expertise to accomplish this, but would it be
> possible to have the rpm build process check the license tag of the
> current spec, query the license tags of BuildRequires, and die with an
> error if a license violation occurs?

It would not solve the current problem (namely Samba relicensing): as 
libsmbclient does not change its soname, a simple upgrade of Samba can make 
KDE modules be linked with GPLv3 code.

That procedure that you described needs also to check license of packages that 
BuildRequires (rescursively) the package that is being rebuild.

Maybe the repo construction step could check licensing. That does not seem 
easy at all, though.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From sgrubb at redhat.com  Wed Oct 10 13:33:50 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 10 Oct 2007 09:33:50 -0400
Subject: acpid and logging
In-Reply-To: <470CD0A3.2030204@redhat.com>
References: <470CD0A3.2030204@redhat.com>
Message-ID: <200710100933.50936.sgrubb@redhat.com>

On Wednesday 10 October 2007 09:16:19 Zdenek Prikryl wrote:
> since version 1.0.6, acpid does not use separate file for logging. It uses
> openlog() and vsyslog() instead of own implementation of logging. So
> everything go to /var/log/messages. 

Yes, I have been chatting with upstream since I'm getting about 6-8 events a 
second. He claims I'm the only person on the planet that is getting this rate 
of events and my BIOS is broken. It makes syslog hard to use for researching 
problems, but not unreadable.

> But it could be dangerous. According to this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=294391, it could lead 
> to unreadable /var/log/messages.

I do not see anything in that bug that tells how it damages or makes syslog 
unusable. I find that it floods syslog, but its not unreadable.

> So there are two options:
> 1. Get back to old style logging (but upstream does not want to)
> 2. In /etc/rsyslog.conf append a filter for acpid, so rsyslog will be
> logging messages form acpid in separate file.

There's a third option, which I've asked upstream about, make some of these 
messages DEBUG and only log abnormal messages at the higher syslog 
priorities. IOW, not all messages are of the same importance. Seriously, my 
battery being full of power or me connecting to AC power is not a syslog 
worthy or any log worthy event unless I'm debugging a problem. 

Upstream is of the opinion that I'm the only person seeing a high rate of 
events and doesn't really want to fix it unless others report similar 
problems. Am I the only one?

Thanks,
-Steve



From pemboa at gmail.com  Wed Oct 10 13:44:35 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Oct 2007 08:44:35 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <200710092208.38706.jamatos@fc.up.pt>
References: <loom.20071009T110055-482@post.gmane.org>
	<20071009134029.GA12588@crow.myhome.westell.com>
	<16de708d0710091352u2d5b1467nc772180fc1c13d9e@mail.gmail.com>
	<200710092208.38706.jamatos@fc.up.pt>
Message-ID: <16de708d0710100644t69b9af37ha18f912f1c82b62a@mail.gmail.com>

On 10/9/07, Jos? Matos <jamatos at fc.up.pt> wrote:
> On Tuesday 09 October 2007 21:52:57 Arthur Pemberton wrote:
> > 1) Does yum-updatesd still block yum and piruit? Causes newbies some
> > headaches.
>
>   It works for me.

So you're saying that you can run both yum-updatesd and piruit?



From rc040203 at freenet.de  Wed Oct 10 13:46:13 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 15:46:13 +0200
Subject: samba license change
In-Reply-To: <20071010103114.GB16044@free.fr>
References: <20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
	<20071010103114.GB16044@free.fr>
Message-ID: <1192023973.3395.743.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 12:31 +0200, Patrice Dumas wrote:
> On Wed, Oct 10, 2007 at 12:20:14PM +0200, Ralf Corsepius wrote:
> > I prefer to rely on existing precedences which had been approved by
> > courts, and not a political party's wishful thinking.
> 
> Then you never change licenses?
As upstream? Yes, almost never, because this is almost never possible.

>  Somebody have to take the risk to
> release software under the new license in order to have it challenged in
> court. It is logical that those who need the new features of the license
> (the samba team) takes the risk.
The problem is the infectious nature of switching to GPLv3 and the
unclarities attached to it.

One detail: The "GPLv2 or any later version" clause is inacceptable to
several project and probably is incompatible and/or void in some legal
systems (In Germany, it is controversial). 

Did somebody consider something along these lines might be the cause for
TrollTech having used GPLv2 only?

Ralf




From laurent.rineau__fedora at normalesup.org  Wed Oct 10 13:49:07 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Wed, 10 Oct 2007 15:49:07 +0200
Subject: acpid and logging
In-Reply-To: <200710100933.50936.sgrubb@redhat.com>
References: <470CD0A3.2030204@redhat.com>
	<200710100933.50936.sgrubb@redhat.com>
Message-ID: <200710101549.07982@rineau.tsetse>

On Wednesday 10 October 2007 15:33:50 Steve Grubb wrote:
> On Wednesday 10 October 2007 09:16:19 Zdenek Prikryl wrote:
> > since version 1.0.6, acpid does not use separate file for logging. It
> > uses openlog() and vsyslog() instead of own implementation of logging. So
> > everything go to /var/log/messages.
>
> Yes, I have been chatting with upstream since I'm getting about 6-8 events
> a second. He claims I'm the only person on the planet that is getting this
> rate of events and my BIOS is broken. It makes syslog hard to use for
> researching problems, but not unreadable.

I have that kind of problem, with an Asus K6m, two years ago. I had eventually 
managed to patch my BIOS, and made ACPI be happier.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From rc040203 at freenet.de  Wed Oct 10 13:52:19 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 15:52:19 +0200
Subject: samba license change
In-Reply-To: <1192019405.13627.57.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
	<1192019405.13627.57.camel@localhost.localdomain>
Message-ID: <1192024339.3395.752.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 08:30 -0400, Simo Sorce wrote:
> On Wed, 2007-10-10 at 12:20 +0200, Ralf Corsepius wrote:
> > On Wed, 2007-10-10 at 11:51 +0200, Nicolas Mailhot wrote:
> > > Le Mer 10 octobre 2007 07:10, Ralf Corsepius a ?crit :
> > > 
> > > > Well, it matters very much to individuals if they want to endanger
> > > > themselves by the uncertainties of a "brand new" license a political
> > > > organization with controversial (some say "fundamentalist zealotic")
> > > > attitude (the FSF) tries to enforce.
> > > 
> > > Then don't link to GPLv3 code. Simple. Easy.
> > False - This is not easy. 
> > 
> > > Don't ask for the freedom to make licensing choices then deny it to
> > > other projects because they happen to make a different choice than
> > > yours (and incidentally they've been involved in actual trials which
> > > are likely to be more relevant to them than your anti-FSF parano?a)
> > I prefer to rely on existing precedences which had been approved by
> > courts, and not a political party's wishful thinking.
> 
> Simply put, can you stop trolling?
Welcome, several 100s of pages explaing to GPLv2's role in the light of
German laws written by German lawyers are sufficient reasons for me not
to consider GPLv3 at the moment

> This is not an anti-GPLv3 trollfest, we have real things to discuss.
> You are just distracting with irrelevant trolling arguments.
Thanks. May each project chose that license they want for whatever
reasons they want.






From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 10 13:53:08 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 10 Oct 2007 15:53:08 +0200
Subject: FC6: Metadata file does not match checksum
In-Reply-To: <200710101402.19959.opensource@till.name>
References: <20071010125040.ae078446.mschwendt.tmp0701.nospam@arcor.de>
	<200710101402.19959.opensource@till.name>
Message-ID: <20071010155308.d523e2d2.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 10 Oct 2007 14:02:19 +0200, Till Maas wrote:

> On Mi Oktober 10 2007, Michael Schwendt wrote:
> > Revisiting the annoying "Metadata file does not match checksum" problem,
> 
> > since it just came back here like this:
> > The cached repomd.xml file is out-of-date from September 19th, and all
> > the mirrors offer much newer repodata from Oct 8th. The mirrors are
> > not to blame here, since Yum does not consider downloading a fresh copy.
> > Instead, it seems it tries to fetch metadata files which match the old
> > repomd index:
> 
> > Is this observation right?
> 
> I always experienced this with any Fedora Release I used (4-7) and imho your 
> observation is right. For me setting the metadata_expire high or just do 
> a "yum clean all" when this happens. 

$ grep meta /etc/yum.conf 
metadata_expire=1800

That's half an hour. The default I assume. Still, with mirrorlist enabled,
it leads to this ugly situation, where Yum somehow relied on a repomd.xml file
that was older than what 99% (?) of the mirrors offered.

Without skimming over the source code, it smells much like if the
cachecookie is recent enough, Yum will not retry loading the tiny
repomd.xml and won't recover from the metadata checksum mismatch deadlock
automatically. And 1800 seconds later it can run into the same problem
again.



From chris.stone at gmail.com  Wed Oct 10 13:54:46 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 10 Oct 2007 06:54:46 -0700
Subject: OpenSceneGraph-devel woes on F-7/FC-6 ExcludeArch change in
	stable release
In-Reply-To: <20071009191553.6d4c2a60@redhat.com>
References: <d9c612bf0710080919i3fecdcdbs825121bd7ea5f3d5@mail.gmail.com>
	<d9c612bf0710080955s6d55fb1w3559c848adce4b4b@mail.gmail.com>
	<20071008190951.d9457c71.mschwendt.tmp0701.nospam@arcor.de>
	<d9c612bf0710081016w15200484ta5250b9519fc0bed@mail.gmail.com>
	<20071008172617.GE32528@psilocybe.teonanacatl.org>
	<d9c612bf0710081056t13f31b9au51651d1362ebc4dc@mail.gmail.com>
	<470A8327.1020204@gmail.com> <20071008201103.2d814b5a@redhat.com>
	<d9c612bf0710090803r1138979pa51747d73ef7dc65@mail.gmail.com>
	<20071009191553.6d4c2a60@redhat.com>
Message-ID: <d9c612bf0710100654w5edaa9a7x69e6450902f39474@mail.gmail.com>

On 10/9/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Tue, 9 Oct 2007 08:03:36 -0700
> "Christopher Stone" <chris.stone at gmail.com> wrote:
>
> > The notification system that is currently available might be the best
> > way to go then.  Perhaps we can enhance the notification system to be
> > easier to use.  For example, it could suggest packages you should
> > subscribe to for notifications.  In addition, there should be
> > notification levels like there are syslog levels.  So the most
> > important pushes which would require a rebuild would be set at the
> > highest notification level and then I can just filter out the
> > notifications I really care about this way.
>
>
> RFEs are best collected in the project upstream tracker (:
>
> (I'm not saying that this is a bad suggestion, just that it may get
> lost in a mailing list)

Okay, I added a request for notification levels. I think it is a good
idea, so people can filter out only the notifications they really care
about.

https://hosted.fedoraproject.org/projects/koji/ticket/50#preview



From limb at jcomserv.net  Wed Oct 10 14:01:11 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 10 Oct 2007 09:01:11 -0500 (CDT)
Subject: samba license change
In-Reply-To: <200710101531.54463@rineau.tsetse>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<loom.20071010T115730-875@post.gmane.org>
	<39534.63.85.68.164.1192018329.squirrel@mail.jcomserv.net>
	<200710101531.54463@rineau.tsetse>
Message-ID: <59136.63.85.68.164.1192024871.squirrel@mail.jcomserv.net>


> On Wednesday 10 October 2007 14:12:09 Jon Ciesla wrote:
>> I'm not the person with the expertise to accomplish this, but would it
>> be
>> possible to have the rpm build process check the license tag of the
>> current spec, query the license tags of BuildRequires, and die with an
>> error if a license violation occurs?
>
> It would not solve the current problem (namely Samba relicensing): as
> libsmbclient does not change its soname, a simple upgrade of Samba can
> make
> KDE modules be linked with GPLv3 code.
>
> That procedure that you described needs also to check license of packages
> that
> BuildRequires (rescursively) the package that is being rebuild.

Exactly.

> Maybe the repo construction step could check licensing. That does not seem
> easy at all, though.

Agreed.  If it was easy, I'd have submitted a patch. :)

> --
> Laurent Rineau
> http://fedoraproject.org/wiki/LaurentRineau
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From jamatos at fc.up.pt  Wed Oct 10 14:09:57 2007
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Wed, 10 Oct 2007 15:09:57 +0100
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710100644t69b9af37ha18f912f1c82b62a@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710092208.38706.jamatos@fc.up.pt>
	<16de708d0710100644t69b9af37ha18f912f1c82b62a@mail.gmail.com>
Message-ID: <200710101509.57799.jamatos@fc.up.pt>

On Wednesday 10 October 2007 14:44:35 Arthur Pemberton wrote:
> > ? It works for me.
>
> So you're saying that you can run both yum-updatesd and piruit?

Well I use yum shell but the idea is the same.

When I enter the yum shell, sometimes yum has to retry several times before 
giving me the prompt saying that other program is locking yum.lock. This 
takes several seconds and is done by yum (not me).

Conversely I forget sometimes the yum shell open and only when closing do I 
see the applet claiming that there are new packages. I do not expect pirut to 
behave in a different way. :-)

-- 
Jos? Ab?lio



From alan at redhat.com  Wed Oct 10 14:23:08 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 10 Oct 2007 10:23:08 -0400
Subject: samba license change
In-Reply-To: <1192023973.3395.743.camel@mccallum.corsepiu.local>
References: <1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
	<20071010103114.GB16044@free.fr>
	<1192023973.3395.743.camel@mccallum.corsepiu.local>
Message-ID: <20071010142308.GA18784@devserv.devel.redhat.com>

On Wed, Oct 10, 2007 at 03:46:13PM +0200, Ralf Corsepius wrote:
> One detail: The "GPLv2 or any later version" clause is inacceptable to
> several project and probably is incompatible and/or void in some legal
> systems (In Germany, it is controversial). 

I'm not aware of any issues there. Its very different from the usual
"and we may change the licence on you" clauses  - which have been found
unreasonable in assorted jurisdictions because you the end user make the
choice, not the supplier.

Alan

--
	"Where small clearances exist, controls are required to
	 prevent these clearances becoming negative"
		- How a rail standards body describes "not hitting a wall"



From pemboa at gmail.com  Wed Oct 10 14:28:26 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Oct 2007 09:28:26 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <200710101509.57799.jamatos@fc.up.pt>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710092208.38706.jamatos@fc.up.pt>
	<16de708d0710100644t69b9af37ha18f912f1c82b62a@mail.gmail.com>
	<200710101509.57799.jamatos@fc.up.pt>
Message-ID: <16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>

On 10/10/07, Jos? Matos <jamatos at fc.up.pt> wrote:
> On Wednesday 10 October 2007 14:44:35 Arthur Pemberton wrote:
> > > It works for me.
> >
> > So you're saying that you can run both yum-updatesd and piruit?
>
> Well I use yum shell but the idea is the same.
>
> When I enter the yum shell, sometimes yum has to retry several times before
> giving me the prompt saying that other program is locking yum.lock. This
> takes several seconds and is done by yum (not me).
>
> Conversely I forget sometimes the yum shell open and only when closing do I
> see the applet claiming that there are new packages. I do not expect pirut to
> behave in a different way. :-)


And you don't consider that to be blocking?


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From adrian at lisas.de  Wed Oct 10 14:37:58 2007
From: adrian at lisas.de (Adrian Reber)
Date: Wed, 10 Oct 2007 16:37:58 +0200
Subject: wordpress 2.3
Message-ID: <20071010143758.GA4478@lisas.de>


I am about to update wordpress to 2.3. One of the "great" features of
wordpress 2.3 is that it supports auto-update notification.

I am thinking about to disable this feature in the Fedora rpm because
the update is anyway supposed to be updated via yum/rpm and not by
downloading it directly from wordpress. Just like it is the case for
firefox.

		Adrian



From zprikryl at redhat.com  Wed Oct 10 14:42:11 2007
From: zprikryl at redhat.com (Zdenek Prikryl)
Date: Wed, 10 Oct 2007 16:42:11 +0200
Subject: acpid and logging
In-Reply-To: <200710100933.50936.sgrubb@redhat.com>
References: <470CD0A3.2030204@redhat.com>
	<200710100933.50936.sgrubb@redhat.com>
Message-ID: <470CE4C3.5040904@redhat.com>

Steve Grubb napsal(a):
> I do not see anything in that bug that tells how it damages or makes syslog 
> unusable. I find that it floods syslog, but its not unreadable.

By unreadable I meant, that /var/log/messages is full of acpid messages. And it
is hard to find relevant information if you have any other problem.

>> So there are two options:
>> 1. Get back to old style logging (but upstream does not want to)
>> 2. In /etc/rsyslog.conf append a filter for acpid, so rsyslog will be
>> logging messages form acpid in separate file.
> 
> There's a third option, which I've asked upstream about, make some of these 
> messages DEBUG and only log abnormal messages at the higher syslog 
> priorities. IOW, not all messages are of the same importance. Seriously, my 
> battery being full of power or me connecting to AC power is not a syslog 
> worthy or any log worthy event unless I'm debugging a problem. 

That could be a solution too.

> Upstream is of the opinion that I'm the only person seeing a high rate of 
> events and doesn't really want to fix it unless others report similar 
> problems. Am I the only one?

Definitely, you are not only one with this problem. So I'll write an email to
upstream and I'll suggest them a solution based on priorities too.

Zdenek



From mattdm at mattdm.org  Wed Oct 10 14:44:49 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 10 Oct 2007 10:44:49 -0400
Subject: wordpress 2.3
In-Reply-To: <20071010143758.GA4478@lisas.de>
References: <20071010143758.GA4478@lisas.de>
Message-ID: <20071010144449.GA2878@jadzia.bu.edu>

On Wed, Oct 10, 2007 at 04:37:58PM +0200, Adrian Reber wrote:
> I am thinking about to disable this feature in the Fedora rpm because
> the update is anyway supposed to be updated via yum/rpm and not by
> downloading it directly from wordpress. Just like it is the case for
> firefox.

+1

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jamatos at fc.up.pt  Wed Oct 10 14:46:54 2007
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Wed, 10 Oct 2007 15:46:54 +0100
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
Message-ID: <200710101546.54277.jamatos@fc.up.pt>

On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
> And you don't consider that to be blocking?

Cann't you wait less than 10 seconds (the worst wait time I had)? You are 
really a busy person. ;-)

-- 
Jos? Ab?lio



From lkundrak at redhat.com  Wed Oct 10 14:55:16 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 10 Oct 2007 16:55:16 +0200
Subject: yum-updatesd in F8?
In-Reply-To: <200710101546.54277.jamatos@fc.up.pt>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
Message-ID: <1192028116.6890.37.camel@localhost.localdomain>


On Wed, 2007-10-10 at 15:46 +0100, Jos? Matos wrote:
> On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
> > And you don't consider that to be blocking?
> 
> Cann't you wait less than 10 seconds (the worst wait time I had)? You are 
> really a busy person. ;-)

Now do a reasonable F-7 desktop installation, and then see if it would
be less than 10 seconds even if you have a moderately fast internet
connection. And imaging that you are a newbie and have no idea what
blocks what and how long would it take, and whether it will ever
unblock.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From wwoods at redhat.com  Wed Oct 10 14:58:21 2007
From: wwoods at redhat.com (Will Woods)
Date: Wed, 10 Oct 2007 10:58:21 -0400
Subject: QA Meeting, *Thursday* Oct 11, 1500UTC
Message-ID: <1192028301.9864.28.camel@localhost.localdomain>

Hi folks, 

With F8 Final rapidly approaching I thought it'd be a good time to
discuss the state of Test3 and what we need to do to get things ready.

We'll have a QA Meeting in the usual place at 1500UTC (11AM EDT). See
this wiki page for details*:
http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel

The agenda's pretty simple:
Hit the highlights from the bugzilla Blocker and Target lists:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F8Blocker&hide_resolved=1
https://bugzilla.redhat.com/showdependencytree.cgi?id=F8Target&hide_resolved=1
and discuss which bugs are either missing from the lists or need to have
their priority raised/lowered. 

If you can't make it to the meeting, I urge you to go through those bug
lists and email fedora-test-list about stuff that you think is missing
or needs to change.

Keep in mind that a Blocker is supposed to be determined by the Release
Criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria

Unless a bug meets one of those criteria, it is *not* a release blocker.
If you think the criteria are in error, we'd be interested to hear your
opinions.

Hope to see you there tomorrow!

-w

* Yes, QA meetings are normally supposed to be on Wednesdays, but I've
had a bit of bad news this week and I've been dealing with that.
-------------- 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/20071010/516eaf1e/attachment.sig>

From skvidal at fedoraproject.org  Wed Oct 10 14:59:08 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 10 Oct 2007 10:59:08 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <1192028116.6890.37.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
Message-ID: <1192028348.6741.271.camel@cutter>


On Wed, 2007-10-10 at 16:55 +0200, Lubomir Kundrak wrote:
> On Wed, 2007-10-10 at 15:46 +0100, Jos? Matos wrote:
> > On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
> > > And you don't consider that to be blocking?
> > 
> > Cann't you wait less than 10 seconds (the worst wait time I had)? You are 
> > really a busy person. ;-)
> 
> Now do a reasonable F-7 desktop installation, and then see if it would
> be less than 10 seconds even if you have a moderately fast internet
> connection. And imaging that you are a newbie and have no idea what
> blocks what and how long would it take, and whether it will ever
> unblock.
> 

If the transaction is being performed what alternative do you have?

reading from the rpmdb while a transaction is occurring is possible you
just won't be able to rely on the results as 'correct'

Now, if you're talking about grabbing a new copy of the metadata then
what we've put on the 'future' todo list is downloading he metadata to a
tmpdir, checking it out and putting it in place once its correct,
however, that's a bit racy b/c you end up with the potential for 2 or
more processes to want to write to the same location with, potentially
different data.

-sv




From galibert at pobox.com  Wed Oct 10 15:00:36 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 10 Oct 2007 17:00:36 +0200
Subject: samba license change
In-Reply-To: <470CB69D.304@hhs.nl>
References: <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
Message-ID: <20071010150036.GA44167@dspnet.fr.eu.org>

On Wed, Oct 10, 2007 at 01:25:17PM +0200, Hans de Goede wrote:
> I must say I'm sorry to step into this flamefest, but weren't the QT 
> licensing issues the reasons why we have gnome in the first place?

That was the #1 reason, when Qt's license was not DFSG-compliant.  I
suspect #2 and #3 were "me no likee C++" and "RedHat needs to have
something different vs. what Suse does".  Without #2 and #3 the
solution would not have been gnome but simply reimplementing a
reasonably compatible but better version of Qt.  The standard GNU
method in other words.


> So all in all it turns out that despite all trolltech's promises,
> they don't follow through?

They put the library under GPLv2, how is that not following through?
There wasn't the GPLv3 nightmare at the time, and given their presence
in the embedded market I can understand they can be hesitant when it
comes to being pulled into it.

  OG.



From lkundrak at redhat.com  Wed Oct 10 15:10:41 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 10 Oct 2007 17:10:41 +0200
Subject: yum-updatesd in F8?
In-Reply-To: <1192028348.6741.271.camel@cutter>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
Message-ID: <1192029041.6890.45.camel@localhost.localdomain>

On Wed, 2007-10-10 at 10:59 -0400, seth vidal wrote:
> > Now do a reasonable F-7 desktop installation, and then see if it would
> > be less than 10 seconds even if you have a moderately fast internet
> > connection. And imaging that you are a newbie and have no idea what
> > blocks what and how long would it take, and whether it will ever
> > unblock.
> > 
> 
> If the transaction is being performed what alternative do you have?

Maybe move all the logic to updatesd and let it organize thing in
non-conflicting way? If a transaction is in progress while user clicks
on update icon, terminate the transaction and let pirut do its business,
and restart the transaction when pirut no longer needs access to
database? And if user selects to update packages, or list updates or
whatever, let updatesd enqueue that and do that after restarting the
former transaction, and while it is being done, inform about the
progress via dbus?

In fact I do not know, I'd rather not pretend that I understand that.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From skvidal at fedoraproject.org  Wed Oct 10 15:13:54 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 10 Oct 2007 11:13:54 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <1192029041.6890.45.camel@localhost.localdomain>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
	<1192029041.6890.45.camel@localhost.localdomain>
Message-ID: <1192029234.6741.281.camel@cutter>


On Wed, 2007-10-10 at 17:10 +0200, Lubomir Kundrak wrote:
> On Wed, 2007-10-10 at 10:59 -0400, seth vidal wrote:
> > > Now do a reasonable F-7 desktop installation, and then see if it would
> > > be less than 10 seconds even if you have a moderately fast internet
> > > connection. And imaging that you are a newbie and have no idea what
> > > blocks what and how long would it take, and whether it will ever
> > > unblock.
> > > 
> > 
> > If the transaction is being performed what alternative do you have?
> 
> Maybe move all the logic to updatesd and let it organize thing in
> non-conflicting way? If a transaction is in progress while user clicks
> on update icon, terminate the transaction and let pirut do its business,
> and restart the transaction when pirut no longer needs access to
> database?

So you want to exit a transaction in mid-swing and what? Hope that the
rpmdb is in a quasi-workable state? It's not like a db commit, we're
putting new data on disk, there's no nice and good way to just pause and
do something else.

>  And if user selects to update packages, or list updates or
> whatever, let updatesd enqueue that and do that after restarting the
> former transaction, and while it is being done, inform about the
> progress via dbus?

but the rpmdb is in an inconsistent state at this point - who knows what
results we'll end up with. Not just within updating packages but also
within actually executing programs.

-sv




From tjb at unh.edu  Wed Oct 10 15:20:36 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Wed, 10 Oct 2007 11:20:36 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1191936868.4913.2.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
Message-ID: <1192029636.26943.20.camel@raptor.sr.unh.edu>


On Tue, 2007-10-09 at 09:34 -0400, Thomas J. Baker wrote:
> I saw a while back (if I'm recalling correctly) Jesse acknowledging the
> gnome logout hang bug as known and should be fixed by a forthcoming X11
> update but that was several weeks ago and it still happens for me. Is it
> something I'm running or is it still happening for everyone?
> 
> Thanks,
> 
> tjb

I tracked this down more and it happens with metacity too on my intel
graphics laptop. After logging out, if I go to a text console and kill
just gnome-session, the logout finishes and gdm comes back up.

Does this "fix" work for anyone else having the problem? It seems that
since this apparently is not happening for everyone, it must be
something I'm running that causes gnome-session to hang. I checked and
pulseaudio is not running so I'm don't think it is the culprit. 

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From pemboa at gmail.com  Wed Oct 10 15:23:40 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 10 Oct 2007 10:23:40 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <1192028348.6741.271.camel@cutter>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
Message-ID: <16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>

---------- Forwarded message ----------
From: seth vidal <skvidal at fedoraproject.org>
Date: Oct 10, 2007 9:59 AM
Subject: Re: yum-updatesd in F8?
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>



On Wed, 2007-10-10 at 16:55 +0200, Lubomir Kundrak wrote:
> On Wed, 2007-10-10 at 15:46 +0100, Jos? Matos wrote:
> > On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
> > > And you don't consider that to be blocking?
> >
> > Cann't you wait less than 10 seconds (the worst wait time I had)? You are
> > really a busy person. ;-)
>
> Now do a reasonable F-7 desktop installation, and then see if it would
> be less than 10 seconds even if you have a moderately fast internet
> connection. And imaging that you are a newbie and have no idea what
> blocks what and how long would it take, and whether it will ever
> unblock.
>

If the transaction is being performed what alternative do you have?

reading from the rpmdb while a transaction is occurring is possible you
just won't be able to rely on the results as 'correct'

Now, if you're talking about grabbing a new copy of the metadata then
what we've put on the 'future' todo list is downloading he metadata to a
tmpdir, checking it out and putting it in place once its correct,
however, that's a bit racy b/c you end up with the potential for 2 or
more processes to want to write to the same location with, potentially
different data.

-sv


Here's my somewhat similar proposal.

1) have yum-updatesd copy all the data it needs, put a watch on the
working dataset for changes

2) have yum-updates first download all the data it needs to do the update

3) check the working dataset for changes, if there have been changes
(more than simply updating the local copy of the meta data) end the
process here

4) otherwise put the working dataset into a readonly mode (other UIs
would be able to read this, and provide the user with feedback
accordingly without simply blocking)

5) do updates with the updated dataset copy

6) then copyover/sync the working dataset with the updated one and
release the readonly mode (any UIs would be obligated to refresh
themselves once the readonly mode has been removed

worse case scenario is that user opens a UI seconds after yum-updatesd
begins downloading packages, and does a full update themselves... in
which case the data would be downloaded twice - I believe that problem
too could be mitigated

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From tjb at unh.edu  Wed Oct 10 15:34:23 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Wed, 10 Oct 2007 11:34:23 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1192029636.26943.20.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<1192029636.26943.20.camel@raptor.sr.unh.edu>
Message-ID: <1192030463.26943.22.camel@raptor.sr.unh.edu>


On Wed, 2007-10-10 at 11:20 -0400, Thomas J. Baker wrote:
> On Tue, 2007-10-09 at 09:34 -0400, Thomas J. Baker wrote:
> > I saw a while back (if I'm recalling correctly) Jesse acknowledging the
> > gnome logout hang bug as known and should be fixed by a forthcoming X11
> > update but that was several weeks ago and it still happens for me. Is it
> > something I'm running or is it still happening for everyone?
> > 
> > Thanks,
> > 
> > tjb
> 
> I tracked this down more and it happens with metacity too on my intel
> graphics laptop. After logging out, if I go to a text console and kill
> just gnome-session, the logout finishes and gdm comes back up.
> 
> Does this "fix" work for anyone else having the problem? It seems that
> since this apparently is not happening for everyone, it must be
> something I'm running that causes gnome-session to hang. I checked and
> pulseaudio is not running so I'm don't think it is the culprit. 
> 
> Thanks,
> 
> tjb
> -- 


https://bugzilla.redhat.com/show_bug.cgi?id=326461

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From peter at thecodergeek.com  Wed Oct 10 15:34:33 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 10 Oct 2007 08:34:33 -0700 (PDT)
Subject: wordpress 2.3
In-Reply-To: <20071010143758.GA4478@lisas.de>
References: <20071010143758.GA4478@lisas.de>
Message-ID: <1380.207.233.85.165.1192030473.squirrel@webmail.thecodergeek.com>

Adrian Reber wrote:
> I am thinking about to disable this feature in the Fedora rpm because
> the update is anyway supposed to be updated via yum/rpm and not by
> downloading it directly from wordpress. Just like it is the case for
> firefox.
>

+1; I did that for Deluge, too.

For Deluge it was far simpler to patch the installed GConf schema to
set the key for that preference to False to default rather than True.
I've not delved much into the WordPress codebase, but whether it will
be simpler to remove the feature entirely or merely have it disabled
by default is a choice left to you, its maintainer. :)
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From alan at redhat.com  Wed Oct 10 15:55:19 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 10 Oct 2007 11:55:19 -0400
Subject: samba license change
In-Reply-To: <20071010150036.GA44167@dspnet.fr.eu.org>
References: <200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<20071010150036.GA44167@dspnet.fr.eu.org>
Message-ID: <20071010155519.GA22618@devserv.devel.redhat.com>

On Wed, Oct 10, 2007 at 05:00:36PM +0200, Olivier Galibert wrote:
> > I must say I'm sorry to step into this flamefest, but weren't the QT 
> > licensing issues the reasons why we have gnome in the first place?
> 
> That was the #1 reason, when Qt's license was not DFSG-compliant.  I
> suspect #2 and #3 were "me no likee C++" and "RedHat needs to have
> something different vs. what Suse does".  Without #2 and #3 the

There were several reasons I can remember
	- Qt was non free, so KDE was non free  (long fixed)
	- A desktop built on a "pay to play" licence would strange 
	  future uptake (as Motif did for Unix)
	- Gnome was doing lots of cool stuff even by the point we got
	  properly involved.
	- There were patents around Qt and troll tech strongly implied they
	  attack the Qt cloning work if it ever succeeded.

Since then Troll Tech have refined the Qt licence somewhat, allowed GPL use
of it clearly, set up the foundation to protect its future if bad things
occur, and done lots of cool stuff with it. Still has issues for non-free
software that Gnome does not - that however is by design 8)

Alan



From fedora at leemhuis.info  Wed Oct 10 16:02:13 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 10 Oct 2007 18:02:13 +0200
Subject: EPEL report week 40 2007
Message-ID: <470CF785.40907@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week40

(sorry, report late again, but as you can see -- you didn't miss
anything ;-) )
----

= Weekly EPEL Summary =

Week 40/2007

== Most important happenings ==

 * Nothing major

== EPEL SIG Meeting ==

Canceled.

== Stats ==

=== General ===

Number of EPEL Contributors 1

We welcome 1 new contributors: afsilva

=== EPEL 5 ===

Number of source packages: 682

Number of binary packages:  1314

There are 12 new Packages:

 * aget | Console download accelerator
 * cvsweb | Web interface for CVS repositories
 * ejabberd | A distributed, fault-tolerant Jabber/XMPP server
 * flashrom | Simple program for reading/writing BIOS chips content
 * kile | (La)TeX source editor and TeX shell
 * python-basemap | Plots data on map projections (with continental and
political boundaries)
 * quilt | Scripts for working with series of patches
 * qwt-doc | Documentation of qwt
 * qwt | Qt Widgets for Technical Applications
 * rpmrebuild | A tool to build rpm file from rpm database
 * smbldap-tools | User and group administration tools for Samba/OpenLDAP
 * superiotool | Simple program for detecting Super I/O on your mainboard

=== EPEL 4 ===

Number of source packages: 429

Number of binary packages:  868

There are 8 new Packages:

 * aget | Console download accelerator
 * cvsweb | Web interface for CVS repositories
 * erlang | General-purpose programming language and runtime environment
 * flashrom | Simple program for reading/writing BIOS chips content
 * python-simplejson | Simple, fast, extensible JSON encoder/decoder for
Python
 * quilt | Scripts for working with series of patches
 * smbldap-tools | User and group administration tools for Samba/OpenLDAP
 * superiotool | Simple program for detecting Super I/O on your mainboard

----
["CategoryEPELReports"]



From lesmikesell at gmail.com  Wed Oct 10 16:24:33 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 10 Oct 2007 11:24:33 -0500
Subject: samba license change
In-Reply-To: <20071010155519.GA22618@devserv.devel.redhat.com>
References: <200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<loom.20071010T112610-389@post.gmane.org>
	<470CB69D.304@hhs.nl>	<20071010150036.GA44167@dspnet.fr.eu.org>
	<20071010155519.GA22618@devserv.devel.redhat.com>
Message-ID: <470CFCC1.30804@gmail.com>

Alan Cox wrote:

> Since then Troll Tech have refined the Qt licence somewhat, allowed GPL use
> of it clearly, set up the foundation to protect its future if bad things
> occur, and done lots of cool stuff with it. Still has issues for non-free
> software that Gnome does not - that however is by design 8)

Can you give an example of how Gnome can be used with non-free 
components where Qt couldn't?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From drago01 at gmail.com  Wed Oct 10 16:26:58 2007
From: drago01 at gmail.com (dragoran)
Date: Wed, 10 Oct 2007 18:26:58 +0200
Subject: samba license change
In-Reply-To: <470CFCC1.30804@gmail.com>
References: <200710091925.01313@rineau.tsetse>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<20071010150036.GA44167@dspnet.fr.eu.org>
	<20071010155519.GA22618@devserv.devel.redhat.com>
	<470CFCC1.30804@gmail.com>
Message-ID: <f6ca9fed0710100926yef787dcreaee41b9a542878e@mail.gmail.com>

On 10/10/07, Les Mikesell <lesmikesell at gmail.com> wrote:
> Alan Cox wrote:
>
> > Since then Troll Tech have refined the Qt licence somewhat, allowed GPL use
> > of it clearly, set up the foundation to protect its future if bad things
> > occur, and done lots of cool stuff with it. Still has issues for non-free
> > software that Gnome does not - that however is by design 8)
>
> Can you give an example of how Gnome can be used with non-free
> components where Qt couldn't?

you can link a non-free app to gnome libs while you (legally) can't do
this with kdelibs.



From a.badger at gmail.com  Wed Oct 10 16:40:56 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 10 Oct 2007 09:40:56 -0700
Subject: Non-orphans treated as orphans
In-Reply-To: <20071010094234.a7fa0212.tsmetana@redhat.com>
References: <3170f42f0710092221i487ac8b0j7dd904254d16672e@mail.gmail.com>
	<20071010094234.a7fa0212.tsmetana@redhat.com>
Message-ID: <470D0098.9010703@gmail.com>

Tom?? Smetana wrote:
> On Wed, 10 Oct 2007 10:51:41 +0530
> "Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:
> 
>> https://admin.fedoraproject.org/pkgdb/users/packages/orphan
>>
>> A number of packages (like libedit and nget) which were orphaned
>> sometime back and then taken over, are still listed as orphans in the
>> above URL. These packages have an owner for all the current branches
>> -- FC-6, F-7 and devel, but not for the EOL'ed branches.
>>
>> Is this how it is supposed to be, or should I file a bug/ticket, or is
>> this already a known issue?
> 
> It's a known problem and it seems it's been taken care of already:
> https://hosted.fedoraproject.org/projects/packagedb/ticket/55
> 
Yep.  I committed a fix yesterday.  The fix will be pushed to the 
production instance the next time I sync from devel. ~ 1 week.

-Toshio



From dstewart at atl.lmco.com  Wed Oct 10 16:45:15 2007
From: dstewart at atl.lmco.com (Douglas Stewart)
Date: Wed, 10 Oct 2007 12:45:15 -0400
Subject: wordpress 2.3
In-Reply-To: <1380.207.233.85.165.1192030473.squirrel@webmail.thecodergeek.com>
References: <20071010143758.GA4478@lisas.de>
	<1380.207.233.85.165.1192030473.squirrel@webmail.thecodergeek.com>
Message-ID: <470D019B.10002@atl.lmco.com>

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

Peter Gordon wrote:
> Adrian Reber wrote:
>> I am thinking about to disable this feature in the Fedora rpm because
>> the update is anyway supposed to be updated via yum/rpm and not by
>> downloading it directly from wordpress. Just like it is the case for
>> firefox.
>>
> 
> +1; I did that for Deluge, too.
> 
> For Deluge it was far simpler to patch the installed GConf schema to
> set the key for that preference to False to default rather than True.
> I've not delved much into the WordPress codebase, but whether it will
> be simpler to remove the feature entirely or merely have it disabled
> by default is a choice left to you, its maintainer. :)

You can disable it via a plugin:
http://wordpress.org/extend/plugins/disable-wordpress-core-update/

Stripping the code revision after revision may not be the best notion,
from a support standpoint.

Also, if you feel like it, there's a plugin to disable plugin update
checking as well:

http://wordpress.org/extend/plugins/disable-wordpress-plugin-updates/


- --
- ----------
Doug Stewart
Senior Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDQGbN50Q8DVvcvkRAuCgAJ4hOCEeMpLXqnoubnnNnXXbmz9WqACfb/Uh
m0/8tXQu62Ah1FjhEO1Hz3c=
=GUki
-----END PGP SIGNATURE-----



From peter at thecodergeek.com  Wed Oct 10 16:53:30 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 10 Oct 2007 09:53:30 -0700 (PDT)
Subject: wordpress 2.3
In-Reply-To: <470D019B.10002@atl.lmco.com>
References: <20071010143758.GA4478@lisas.de>
	<1380.207.233.85.165.1192030473.squirrel@webmail.thecodergeek.com>
	<470D019B.10002@atl.lmco.com>
Message-ID: <2677.207.233.85.165.1192035210.squirrel@webmail.thecodergeek.com>

Douglas Stewart wrote:
> You can disable it via a plugin:
> http://wordpress.org/extend/plugins/disable-wordpress-core-update/
>
> Stripping the code revision after revision may not be the best notion,
> from a support standpoint.
>
> Also, if you feel like it, there's a plugin to disable plugin update
> checking as well:
>
> http://wordpress.org/extend/plugins/disable-wordpress-plugin-updates/

Good to know; thanks!
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From debarshi.ray at gmail.com  Wed Oct 10 17:02:26 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 10 Oct 2007 22:32:26 +0530
Subject: Non-orphans treated as orphans
In-Reply-To: <470D0098.9010703@gmail.com>
References: <3170f42f0710092221i487ac8b0j7dd904254d16672e@mail.gmail.com>
	<20071010094234.a7fa0212.tsmetana@redhat.com>
	<470D0098.9010703@gmail.com>
Message-ID: <3170f42f0710101002m185aeb53h2839c545fcaeaaa6@mail.gmail.com>

>> It's a known problem and it seems it's been taken care of already:
>> https://hosted.fedoraproject.org/projects/packagedb/ticket/55

> Yep.  I committed a fix yesterday.  The fix will be pushed to the
> production instance the next time I sync from devel. ~ 1 week.

That is nice.

On hindsight I should have searched the tickets before posting here.
Sorry for the noise.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From peter at thecodergeek.com  Wed Oct 10 17:12:11 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 10 Oct 2007 10:12:11 -0700 (PDT)
Subject: fedora-release fedora-development.repo, 1.14,
 1.14.2.1 fedora-release.spec, 1.54, 1.54.2.1
In-Reply-To: <200710101708.l9AH8Z01003554@cvs-int.fedora.redhat.com>
References: <200710101708.l9AH8Z01003554@cvs-int.fedora.redhat.com>
Message-ID: <3209.207.233.85.165.1192036331.squirrel@webmail.thecodergeek.com>

Jesse Keating wrote:
> Modified Files:
>       Tag: F-7
> 	fedora-development.repo fedora-release.spec
> Log Message:
> Add gpg info to devel repo

Just to qualm my anxious curiosity - does this mean that we are finally
getting GPG-signed Development packages too? That would be *awesome*. :D
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From adrian at lisas.de  Wed Oct 10 17:16:02 2007
From: adrian at lisas.de (Adrian Reber)
Date: Wed, 10 Oct 2007 19:16:02 +0200
Subject: wordpress 2.3
In-Reply-To: <470D019B.10002@atl.lmco.com>
References: <20071010143758.GA4478@lisas.de>
	<1380.207.233.85.165.1192030473.squirrel@webmail.thecodergeek.com>
	<470D019B.10002@atl.lmco.com>
Message-ID: <20071010171602.GA15613@lisas.de>

On Wed, Oct 10, 2007 at 12:45:15PM -0400, Douglas Stewart wrote:
> Peter Gordon wrote:
> > Adrian Reber wrote:
> >> I am thinking about to disable this feature in the Fedora rpm because
> >> the update is anyway supposed to be updated via yum/rpm and not by
> >> downloading it directly from wordpress. Just like it is the case for
> >> firefox.
> >>
> > 
> > +1; I did that for Deluge, too.
> > 
> > For Deluge it was far simpler to patch the installed GConf schema to
> > set the key for that preference to False to default rather than True.
> > I've not delved much into the WordPress codebase, but whether it will
> > be simpler to remove the feature entirely or merely have it disabled
> > by default is a choice left to you, its maintainer. :)
> 
> You can disable it via a plugin:
> http://wordpress.org/extend/plugins/disable-wordpress-core-update/
> 
> Stripping the code revision after revision may not be the best notion,
> from a support standpoint.
> 
> Also, if you feel like it, there's a plugin to disable plugin update
> checking as well:
> 
> http://wordpress.org/extend/plugins/disable-wordpress-plugin-updates/

The problem with those plugins is that they have to be enabled by the
users as far as I understand it. I would like have a way to disable it
by default and only let the user enable it if he really wants it.

		Adrian



From rc040203 at freenet.de  Wed Oct 10 17:18:20 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 10 Oct 2007 19:18:20 +0200
Subject: samba license change
In-Reply-To: <20071010142308.GA18784@devserv.devel.redhat.com>
References: <1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<1191989194.3395.628.camel@mccallum.corsepiu.local>
	<1191990381.13627.42.camel@localhost.localdomain>
	<1191993055.3395.643.camel@mccallum.corsepiu.local>
	<63956.192.54.193.51.1192009898.squirrel@rousalka.dyndns.org>
	<1192011614.3395.721.camel@mccallum.corsepiu.local>
	<20071010103114.GB16044@free.fr>
	<1192023973.3395.743.camel@mccallum.corsepiu.local>
	<20071010142308.GA18784@devserv.devel.redhat.com>
Message-ID: <1192036700.3395.849.camel@mccallum.corsepiu.local>

On Wed, 2007-10-10 at 10:23 -0400, Alan Cox wrote:
> On Wed, Oct 10, 2007 at 03:46:13PM +0200, Ralf Corsepius wrote:
> > One detail: The "GPLv2 or any later version" clause is inacceptable to
> > several project and probably is incompatible and/or void in some legal
> > systems (In Germany, it is controversial). 
> 
> I'm not aware of any issues there.
Well, some projects consider the "any later" clause to be giving away
control over their works, which they consider to endanger their works
and therefore prefer not to apply the "any later" clause.

[Consider the FSF had added something to the GPL which would be
inapplicable/void under some <country>'s law. In worst case, a court
could consider the whole license void.]


>  Its very different from the usual
> "and we may change the licence on you" clauses  - which have been found
> unreasonable in assorted jurisdictions because you the end user make the
> choice, not the supplier.

Well, German lawyers use a different argumentation, which can be found
in detail in different documents under http://www.ifross.de

(run by FSF-benvolent lawyers being specialized in OpenSource legal).
Unfortunately translating their "legalize"-argumentation exceeds my
capabilities and would exceed email.

A more or less readable version can be found on page 10, of 
http://www.ifross.de/ifross_html/Druckfassung/Die_GPL_kommentiert_und_erklaert.pdf
(IMO, this book is a must-read for German developers).

A more detailed wording (in "heavy German legalize") of the same
argumentation can be found in section 3.c) of:
http://www.ifross.de/ifross_html/art1.html

Very abbreviated and roughly translated from the link above, they say: 
"Copyright-law related concerns arise from ?9 GPL ... "any later
version" .... Concerns against this regulation arise from aspects of 
?31 Abs. 4 UrHG [German copyright law], because the GPL presumes
granting of entire rights to everybody, when it permits copying,
modification and distribution on any media." 


In brief: Lawyers say, the "any later" clause bears legal risks, if
German law is applicable. In other words, they construct a case where
the concerns in my sentence on the top could hit.

Ralf






From alan at redhat.com  Wed Oct 10 17:21:45 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 10 Oct 2007 13:21:45 -0400
Subject: samba license change
In-Reply-To: <470CFCC1.30804@gmail.com>
References: <20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<20071010150036.GA44167@dspnet.fr.eu.org>
	<20071010155519.GA22618@devserv.devel.redhat.com>
	<470CFCC1.30804@gmail.com>
Message-ID: <20071010172145.GC24071@devserv.devel.redhat.com>

On Wed, Oct 10, 2007 at 11:24:33AM -0500, Les Mikesell wrote:
> >occur, and done lots of cool stuff with it. Still has issues for non-free
> >software that Gnome does not - that however is by design 8)
> 
> Can you give an example of how Gnome can be used with non-free 
> components where Qt couldn't?

The Gnome developers have a policy that the core GNOME libraries are
LGPL or similar.



From jkeating at redhat.com  Wed Oct 10 17:24:56 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 10 Oct 2007 13:24:56 -0400
Subject: fedora-release fedora-development.repo, 1.14, 1.14.2.1
 fedora-release.spec, 1.54, 1.54.2.1
In-Reply-To: <3209.207.233.85.165.1192036331.squirrel@webmail.thecodergeek.com>
References: <200710101708.l9AH8Z01003554@cvs-int.fedora.redhat.com>
	<3209.207.233.85.165.1192036331.squirrel@webmail.thecodergeek.com>
Message-ID: <20071010132456.5fb8fdf1@redhat.com>

On Wed, 10 Oct 2007 10:12:11 -0700 (PDT)
"Peter Gordon" <peter at thecodergeek.com> wrote:

> > Modified Files:
> >       Tag: F-7
> > 	fedora-development.repo fedora-release.spec
> > Log Message:
> > Add gpg info to devel repo  
> 
> Just to qualm my anxious curiosity - does this mean that we are
> finally getting GPG-signed Development packages too? That would be
> *awesome*. :D

We've gotten them as a byproduct of test releases throughout this
development cycle.  Every package was signed at each test point.  It's
the builds between those releases that still aren't signed, and will
continue to not be signed for the near future.

Oh and the Tag was a mistake above, that should have been "F-8" (:
I've already fixed that.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/a218f4e9/attachment.sig>

From kevin.kofler at chello.at  Wed Oct 10 16:27:06 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 16:27:06 +0000 (UTC)
Subject: samba license change
References: <fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<loom.20071010T112610-389@post.gmane.org>
	<20071010123313.GB13559@devserv.devel.redhat.com>
	<470CCAC8.2020209@gmail.com>
Message-ID: <loom.20071010T162359-639@post.gmane.org>

Les Mikesell <lesmikesell <at> gmail.com> writes:
> Doesn't everyone who has ever contributed code have to agree to a change 
> unless it had the "gplv2 or newer" clause to begin with - unless they 
> also turned over ownership of the copyright to someone else?

Trolltech makes sure all contributions are under terms which allow them to 
grant any license, their dual license model wouldn't work otherwise. So as far 
as Qt is concerned, it all depends on Trolltech and only Trolltech.

The subset of KDE apps which is also using the GPLv2 is another story, but 
similarly to how GNOME's gnome-vfs works, kio_smb is also a separate process as 
far as I can tell, so it's probably not necessary to get every single KDE app 
relicensed to avoid a mess. But IANAL.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 10 16:40:43 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 16:40:43 +0000 (UTC)
Subject: samba license change
References: <200710091925.01313@rineau.tsetse>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<20071010150036.GA44167@dspnet.fr.eu.org>
	<20071010155519.GA22618@devserv.devel.redhat.com>
	<470CFCC1.30804@gmail.com>
	<f6ca9fed0710100926yef787dcreaee41b9a542878e@mail.gmail.com>
Message-ID: <loom.20071010T163958-26@post.gmane.org>

dragoran <drago01 <at> gmail.com> writes:
> you can link a non-free app to gnome libs while you (legally) can't do
> this with kdelibs.

Only if you're too cheap to buy a commercial license for Qt. The kdelibs are 
LGPL exactly for that reason, and Qt is dual-licensed.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 10 16:54:15 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 16:54:15 +0000 (UTC)
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>
	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<loom.20071010T115730-875@post.gmane.org>
Message-ID: <loom.20071010T164410-608@post.gmane.org>

I wrote:
> Actually, depending on what exactly gets linked with libsmbclient (which in 
> turn depends on your definition of "linking", is the external kio_smb process 
> the only thing considered "linked" with libsmbclient? ldd seems to think so 
> (the kio_*.so libs are actually started up as separate processes by kdeinit, 
> and only kio_smb.so shows up as linked to libsmbclient), but is ldd the
> correct definition of "linking" here?), some other KDE contributors may have
> to relicense their code too. But what's sure is that without Trolltech, KDE
> can't do anything.

Looking into it:
* yes, kio_smb is a separate process,
* all the code in kio_smb itself is GPLv2+ or LGPLv2+ (There was apparently 
some improper LGPL->GPL conversion done there though, because there's no such 
version as the "GPL 2.1" which is referred to. :-/)
* the kdelibs code which is of course linked in should all be LGPL, thus no 
problem,
so yes, Qt is the one problem here, we can start linking kio_smb to GPLv3 or 
LGPLv3 libraries if and only if and when Trolltech allows the GPLv3 for Qt.

As for exceptions, you'd also have to consider the GPLv2+ code in kio_smb, 
which so happens to be "Copyright (c) 2000  Caldera Systems, Inc.", good luck 
getting these folks to agree to any sort of exception. And without exceptions, 
I guess the GPLv2+ has to be interpreted as "pick any one version of the GPL", 
not a mix of both.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 10 16:38:25 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 10 Oct 2007 16:38:25 +0000 (UTC)
Subject: samba license change
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>
	<470C0D29.4050101@gmail.com> <1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
Message-ID: <loom.20071010T162828-161@post.gmane.org>

Simo Sorce <ssorce <at> redhat.com> writes:
> Slashdot ? On Slashdot anybody can say anything and the contrary, I
> wonder why people is so shy to talk directly with other developers when
> they need to...

There were also some developer blogs. There may have been some lack of 
communication. But do you expect them to follow every single thread on your 
mailing list? You don't follow every single thread on kde-core-devel, or even 
every single thread related to licensing there, either, do you?

> If Qt3 is obsolete I can't understand why Trolltech can't add an
> exception there, it should be actually much more easier for older
> unsupported software, after all who cares for that? It's going to slowly
> disappear from the scene anyway and GPLv2 vs GPLv2+/exception for v3
> does not make any difference in that case.

Historically, Trolltech has always done license changes only for the new 
versions, I think they want to use that as leverage to force people to use the 
new version, which is annoying in the context of KDE where KDE is generally not 
ready for said new version yet when they do the change.

As for GPLv2+exception: is the affected Samba code GPLv3+ or LGPLv3+? If it's 
LGPLv3+, an exception in Qt might work (but we'd still need Trolltech to grant 
it!), if it's GPLv3+, we need an exception from BOTH sides.

> In any case I was under the impression that F9 was going to use
> KDE4/QT4, have plans changed ?

That's the plan. But this mess will essentially force us to move (leaving us 
with no fallback plan), and that's only if Trolltech updates the Qt 4 license, 
if they don't, we're stuck. Well, we can ship a KDE without SMB support, but is 
that really what you want in the Samba project?

Don't get me wrong, I agree Trolltech's use of GPL v2 only and not doing 
anything about the GPLv3 (at least not fast enough) is bad, but Samba 
essentially knowingly sabotaging what's probably their biggest user isn't a 
solution to that problem either.

        Kevin Kofler



From drago01 at gmail.com  Wed Oct 10 17:59:16 2007
From: drago01 at gmail.com (dragoran)
Date: Wed, 10 Oct 2007 19:59:16 +0200
Subject: samba license change
In-Reply-To: <loom.20071010T163958-26@post.gmane.org>
References: <200710091925.01313@rineau.tsetse> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org> <470CB69D.304@hhs.nl>
	<20071010150036.GA44167@dspnet.fr.eu.org>
	<20071010155519.GA22618@devserv.devel.redhat.com>
	<470CFCC1.30804@gmail.com>
	<f6ca9fed0710100926yef787dcreaee41b9a542878e@mail.gmail.com>
	<loom.20071010T163958-26@post.gmane.org>
Message-ID: <f6ca9fed0710101059t620a9aabq10bbda7767b6597a@mail.gmail.com>

On 10/10/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
> dragoran <drago01 <at> gmail.com> writes:
> > you can link a non-free app to gnome libs while you (legally) can't do
> > this with kdelibs.
>
> Only if you're too cheap to buy a commercial license for Qt. The kdelibs are
> LGPL exactly for that reason, and Qt is dual-licensed.

sorry I missed this option, you are correct here. ;)



From ssorce at redhat.com  Wed Oct 10 18:10:51 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 14:10:51 -0400
Subject: samba license change
In-Reply-To: <loom.20071010T164410-608@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<470CB69D.304@hhs.nl> <loom.20071010T115730-875@post.gmane.org>
	<loom.20071010T164410-608@post.gmane.org>
Message-ID: <1192039851.26017.13.camel@localhost.localdomain>

On Wed, 2007-10-10 at 16:54 +0000, Kevin Kofler wrote:

> Looking into it:
> * yes, kio_smb is a separate process,
> * all the code in kio_smb itself is GPLv2+ or LGPLv2+ (There was apparently 
> some improper LGPL->GPL conversion done there though, because there's no such 
> version as the "GPL 2.1" which is referred to. :-/)
> * the kdelibs code which is of course linked in should all be LGPL, thus no 
> problem,
> so yes, Qt is the one problem here, we can start linking kio_smb to GPLv3 or 
> LGPLv3 libraries if and only if and when Trolltech allows the GPLv3 for Qt.

It seem the same sort of situation as for gnome-vfs, it is interesting
to understand how kio_smb communicate and share data with upper layers,
under stricter GPL interpretations what matters is intimate data
structure sharing to define "linking" and therefore derivation, but
IANAL, I guess we need some legal advice on this matter, maybe the
various projects can all agree and ask SFLC to study the situation and
come out with recommendations?

> As for exceptions, you'd also have to consider the GPLv2+ code in kio_smb, 
> which so happens to be "Copyright (c) 2000  Caldera Systems, Inc.", good luck 
> getting these folks to agree to any sort of exception. And without exceptions, 
> I guess the GPLv2+ has to be interpreted as "pick any one version of the GPL", 
> not a mix of both.

GPLv2+ or GPLv3+ or ... means that you are forward compatible, ie, the
work as a whole is redistributed under the uppermost license number.
Individual components keep the license they want when they are on their
own.

Simo.



From ssorce at redhat.com  Wed Oct 10 18:23:43 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 14:23:43 -0400
Subject: samba license change
In-Reply-To: <loom.20071010T162828-161@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org> <20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
Message-ID: <1192040623.26017.24.camel@localhost.localdomain>

On Wed, 2007-10-10 at 16:38 +0000, Kevin Kofler wrote:
> Simo Sorce <ssorce <at> redhat.com> writes:
> > Slashdot ? On Slashdot anybody can say anything and the contrary, I
> > wonder why people is so shy to talk directly with other developers when
> > they need to...
> 
> There were also some developer blogs. There may have been some lack of 
> communication. But do you expect them to follow every single thread on your 
> mailing list? You don't follow every single thread on kde-core-devel, or even 
> every single thread related to licensing there, either, do you?

No but we were on the headlines both during the GPLv3 process and when
we announced the license change so we made our part to get visible and
inform others. I follow each announcement of license change for the code
we depend on  and make sure we have no problem for it, if we have we
contact the devs of the other project promptly and discuss the
situation.

> > If Qt3 is obsolete I can't understand why Trolltech can't add an
> > exception there, it should be actually much more easier for older
> > unsupported software, after all who cares for that? It's going to slowly
> > disappear from the scene anyway and GPLv2 vs GPLv2+/exception for v3
> > does not make any difference in that case.
> 
> Historically, Trolltech has always done license changes only for the new 
> versions, I think they want to use that as leverage to force people to use the 
> new version, which is annoying in the context of KDE where KDE is generally not 
> ready for said new version yet when they do the change.

I undertand that but I guess Trolltech can be asked at least to say a
word or two, so far I know only Trolltech is 'thinking' about it. Can
someone that know them please get in touch with Trolltech and get us
some facts to discuss on? Speculation is annoying.

> As for GPLv2+exception: is the affected Samba code GPLv3+ or LGPLv3+? If it's 
> LGPLv3+, an exception in Qt might work (but we'd still need Trolltech to grant 
> it!), if it's GPLv3+, we need an exception from BOTH sides.

I don't understand this. It is GPLv2 only that is incompatible, once
Trolltech makes it v2+ or dual license it under v3/v3+ we have no
problems.

> > In any case I was under the impression that F9 was going to use
> > KDE4/QT4, have plans changed ?
> 
> That's the plan. But this mess will essentially force us to move (leaving us 
> with no fallback plan), and that's only if Trolltech updates the Qt 4 license, 
> if they don't, we're stuck. Well, we can ship a KDE without SMB support, but is 
> that really what you want in the Samba project?

We don't like the situation but what is our option? We strongly believe
the GPLv3 is the right license for Samba.

> Don't get me wrong, I agree Trolltech's use of GPL v2 only and not doing 
> anything about the GPLv3 (at least not fast enough) is bad, but Samba 
> essentially knowingly sabotaging what's probably their biggest user isn't a 
> solution to that problem either.

Sorry, our biggest users are Windows clients and linux clients via
smbfs/cifs kernel modules.
KDE is only one of the many clients like GNOME on one of the platforms.
Nonetheless we are concerned about that and that's why we are sending
signals to people in *advance*.
But you don't expect us to do the work for these projects, do you?

Simo.



From jspaleta at gmail.com  Wed Oct 10 18:55:22 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Oct 2007 10:55:22 -0800
Subject: samba license change
In-Reply-To: <1192040623.26017.24.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
Message-ID: <604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>

On 10/10/07, Simo Sorce <ssorce at redhat.com> wrote:
> But you don't expect us to do the work for these projects, do you?

I think in the short term inside Fedora I think there is going to be a
need to handle the license change like how it was previously done for
the mysql client library. Someone is going to have to take the gplv2+
libsmbclient  codebase build it with a new name for packages to link
against until the licensing mess is resolved.  I take it that as a
Fedora Contributor you would be unwilling to submit and maintain such
a package?

What I don't want to see happen in the meantime is accidental building
against the libsmbclient by any component that isn't gplv3 compatible
in Fedora space, putting Fedora in violation of the licensing.  Even
scratch builds are a problem.  Unfortunately I don't know of any
mechanism in our build system which we can use to prevent such
inadvertent linking in the Fedora build system and development trees.
Regardless of decision of upstream Samba's licensing change, the
decision to introduce the gplv3 code in place of gplv2+ code into the
Fedora buildsystem puts Fedora into a situation where we could easily
be in violation just by rebuilding existing packages. This is not a
good situation to be in as a distribution project.

Thank god we don't actually have sophisticated features in our
buildsystem like automated bootstrapping or mass rebuilding processes
in rawhide, which would trigger a violation without human
intervention. The introduction of relicensed code,especially library
code into the distribution is a pain in the ass.  I think we're gonna
have to handle this sort of thing in a more controlled way as more
library codebases move forward. Fesco?

If I had my preferences, I would build a whitelist of components
allowed to link against samba/smbclient and start with an empty
whitelist, and going through one component at a time and figuring out
if its safe to let them build against libsmbclient or not.  But I
don't think we have the ability to do that sort of thing currently.

-jef



From ndbecker2 at gmail.com  Wed Oct 10 19:18:02 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 10 Oct 2007 15:18:02 -0400
Subject: better install experience
Message-ID: <fej8ij$v89$1@sea.gmane.org>

Some time back, IIRC I posted that it would improve the user experience if
fedora installer would include a few tools.  I am (once again) getting a
new machine, and (once again) it's coming with windoze pre-installed.  I
need to do ntfsresize.  Last time, I had to grab a live-cd that had an
ntfsresize, before I could do fedora install.  Has this situation improved?

If we want to improve the user experience, it would be great if anaconda
offered to do the resize.  Even for an experienced user, who wants to d/l +
burn >1 cd/dvd?



From ssorce at redhat.com  Wed Oct 10 19:37:39 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 15:37:39 -0400
Subject: samba license change
In-Reply-To: <604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
Message-ID: <1192045059.26017.39.camel@localhost.localdomain>

On Wed, 2007-10-10 at 10:55 -0800, Jeff Spaleta wrote:
> On 10/10/07, Simo Sorce <ssorce at redhat.com> wrote:
> > But you don't expect us to do the work for these projects, do you?
> 
> I think in the short term inside Fedora I think there is going to be a
> need to handle the license change like how it was previously done for
> the mysql client library. Someone is going to have to take the gplv2+
> libsmbclient  codebase build it with a new name for packages to link
> against until the licensing mess is resolved.  I take it that as a
> Fedora Contributor you would be unwilling to submit and maintain such
> a package?

It depends on the amount of work involved, but it is not the top of my
priorities, I could be a co-maintainer though if someone more involved
with the projects needing this package can take up the ball and do it
themselves.

In any case I would rather see upstream take action and solve this
problem for all their users including Fedora.

> What I don't want to see happen in the meantime is accidental building
> against the libsmbclient by any component that isn't gplv3 compatible
> in Fedora space, putting Fedora in violation of the licensing.  Even
> scratch builds are a problem.  Unfortunately I don't know of any
> mechanism in our build system which we can use to prevent such
> inadvertent linking in the Fedora build system and development trees.
> Regardless of decision of upstream Samba's licensing change, the
> decision to introduce the gplv3 code in place of gplv2+ code into the
> Fedora buildsystem puts Fedora into a situation where we could easily
> be in violation just by rebuilding existing packages. This is not a
> good situation to be in as a distribution project.

That's why I removed the only package I built in rawhide and I said I
will hold any other 3.2.0 package until the matter is clear.

> Thank god we don't actually have sophisticated features in our
> buildsystem like automated bootstrapping or mass rebuilding processes
> in rawhide, which would trigger a violation without human
> intervention. The introduction of relicensed code,especially library
> code into the distribution is a pain in the ass.  I think we're gonna
> have to handle this sort of thing in a more controlled way as more
> library codebases move forward. Fesco?
> 
> If I had my preferences, I would build a whitelist of components
> allowed to link against samba/smbclient and start with an empty
> whitelist, and going through one component at a time and figuring out
> if its safe to let them build against libsmbclient or not.  But I
> don't think we have the ability to do that sort of thing currently.

Better we start thinking of it, Samba is not the only project that
switched to the v3. On a side note however I think we shouldn't see this
a special case, any license change in any package may have the same
consequences, we just need to be diligent and warn people, and people
need to be diligent and check if they are affect as we always should do.

Simo.

> -jef
> 



From tcallawa at redhat.com  Wed Oct 10 19:38:41 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 15:38:41 -0400
Subject: better install experience
In-Reply-To: <fej8ij$v89$1@sea.gmane.org>
References: <fej8ij$v89$1@sea.gmane.org>
Message-ID: <1192045121.3261.82.camel@localhost.localdomain>


On Wed, 2007-10-10 at 15:18 -0400, Neal Becker wrote:
> Some time back, IIRC I posted that it would improve the user experience if
> fedora installer would include a few tools.  I am (once again) getting a
> new machine, and (once again) it's coming with windoze pre-installed.  I
> need to do ntfsresize.  Last time, I had to grab a live-cd that had an
> ntfsresize, before I could do fedora install.  Has this situation improved?
> 
> If we want to improve the user experience, it would be great if anaconda
> offered to do the resize.  Even for an experienced user, who wants to d/l +
> burn >1 cd/dvd?

Anaconda doesn't have any ntfs support yet. We're looking at that for
F9.

The F-8 live-cd might have the ntfsutils, but I don't know.

~spot



From nicolas.mailhot at laposte.net  Wed Oct 10 19:47:56 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 10 Oct 2007 21:47:56 +0200
Subject: samba license change
In-Reply-To: <604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
Message-ID: <1192045676.23415.1.camel@rousalka.dyndns.org>


Le mercredi 10 octobre 2007 ? 10:55 -0800, Jeff Spaleta a ?crit :

> Thank god we don't actually have sophisticated features in our
> buildsystem like automated bootstrapping or mass rebuilding processes
> in rawhide, which would trigger a violation without human
> intervention. 

??? Even if you build against gplv2 samba, as soon as the result is
distributed with gpl3 samba and links against it on user systems, you're
in the wrong.

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

From paul at xelerance.com  Wed Oct 10 19:53:12 2007
From: paul at xelerance.com (Paul Wouters)
Date: Wed, 10 Oct 2007 15:53:12 -0400 (EDT)
Subject: better install experience
In-Reply-To: <1192045121.3261.82.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>

On Wed, 10 Oct 2007, Tom "spot" Callaway wrote:

> > If we want to improve the user experience, it would be great if anaconda
> > offered to do the resize.  Even for an experienced user, who wants to d/l +
> > burn >1 cd/dvd?
>
> Anaconda doesn't have any ntfs support yet. We're looking at that for
> F9.
>
> The F-8 live-cd might have the ntfsutils, but I don't know.

Wasn't NTFS a patent issue? Though I do not see it anymore on
http://fedoraproject.org/wiki/ForbiddenItems

Paul



From katzj at redhat.com  Wed Oct 10 19:52:15 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 10 Oct 2007 15:52:15 -0400
Subject: better install experience
In-Reply-To: <fej8ij$v89$1@sea.gmane.org>
References: <fej8ij$v89$1@sea.gmane.org>
Message-ID: <1192045935.26533.2.camel@localhost.localdomain>

On Wed, 2007-10-10 at 15:18 -0400, Neal Becker wrote:
> Some time back, IIRC I posted that it would improve the user experience if
> fedora installer would include a few tools.  I am (once again) getting a
> new machine, and (once again) it's coming with windoze pre-installed.  I
> need to do ntfsresize.  Last time, I had to grab a live-cd that had an
> ntfsresize, before I could do fedora install.  Has this situation improved?
> 
> If we want to improve the user experience, it would be great if anaconda
> offered to do the resize.  Even for an experienced user, who wants to d/l +
> burn >1 cd/dvd?

Are you offering to help by contributing code?  Because honestly, it's
not like we don't want to do it.  But there's only a finite number of
people working on anaconda and a finite amount of time available for
working on what's realisticially a pretty big project[1].  Having some
people interested stepping up and helping to work on code would go a
long way towards getting this done for Fedora 9.

But with the Fedora 8 (and the Fedora 7 even) live CDs, gparted is there
and you can use it for resizing ntfs.  It just doesn't provide a
well-integrated experience

Jeremy

[1] As it currently stands, the partitioning workflow can't really work
within the constraints needed for resizing.  And so some that's also an
area that's going to need changes



From tcallawa at redhat.com  Wed Oct 10 19:53:51 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 15:53:51 -0400
Subject: better install experience
In-Reply-To: <Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
Message-ID: <1192046031.3261.85.camel@localhost.localdomain>


On Wed, 2007-10-10 at 15:53 -0400, Paul Wouters wrote:
> On Wed, 10 Oct 2007, Tom "spot" Callaway wrote:
> 
> > > If we want to improve the user experience, it would be great if anaconda
> > > offered to do the resize.  Even for an experienced user, who wants to d/l +
> > > burn >1 cd/dvd?
> >
> > Anaconda doesn't have any ntfs support yet. We're looking at that for
> > F9.
> >
> > The F-8 live-cd might have the ntfsutils, but I don't know.
> 
> Wasn't NTFS a patent issue? Though I do not see it anymore on
> http://fedoraproject.org/wiki/ForbiddenItems

Short answer: No.

Long answer: If something (anything) in Fedora infringes a patent that
you hold, please let me know the specifics (which patent, which
software, etc), and we will address it.

~spot



From ssorce at redhat.com  Wed Oct 10 20:01:23 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 20:01:23 +0000
Subject: samba license change
In-Reply-To: <1192045676.23415.1.camel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
Message-ID: <1192046483.26017.41.camel@localhost.localdomain>

On Wed, 2007-10-10 at 21:47 +0200, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 10:55 -0800, Jeff Spaleta a ?crit :
> 
> > Thank god we don't actually have sophisticated features in our
> > buildsystem like automated bootstrapping or mass rebuilding processes
> > in rawhide, which would trigger a violation without human
> > intervention. 
> 
> ??? Even if you build against gplv2 samba, as soon as the result is
> distributed with gpl3 samba and links against it on user systems, you're
> in the wrong.

This is debatable, but better safe then sorry they say.

Simo.



From fedora at leemhuis.info  Wed Oct 10 20:08:59 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 10 Oct 2007 22:08:59 +0200
Subject: better install experience
In-Reply-To: <1192046031.3261.85.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
Message-ID: <470D315B.3070604@leemhuis.info>


On 10.10.2007 21:53, Tom "spot" Callaway wrote:
> On Wed, 2007-10-10 at 15:53 -0400, Paul Wouters wrote:
>> On Wed, 10 Oct 2007, Tom "spot" Callaway wrote:
>>>> If we want to improve the user experience, it would be great if anaconda
>>>> offered to do the resize.  Even for an experienced user, who wants to d/l +
>>>> burn >1 cd/dvd?
>>> Anaconda doesn't have any ntfs support yet. We're looking at that for
>>> F9.
>>> The F-8 live-cd might have the ntfsutils, but I don't know.
>> Wasn't NTFS a patent issue? Though I do not see it anymore on
>> http://fedoraproject.org/wiki/ForbiddenItems
> Short answer: No.
> Long answer: If something (anything) in Fedora infringes a patent that
> you hold, please let me know the specifics (which patent, which
> software, etc), and we will address it.

Is there a middle-sized answer maybe that might explain why
https://bugzilla.redhat.com/show_bug.cgi?id=65749
still wasn't fixed? The bug is about this fact:

$ grep NTFS /boot/config-2.6.23-0.217.rc9.git1.fc8
# CONFIG_NTFS_FS is not set

Sure, ntfs-3g is around -- but some people still prefer the in-kernel
driver and it still gets downloaded from a well know 3rd party repo as
kmod a lot.

Cu
knurd



From tcallawa at redhat.com  Wed Oct 10 20:23:15 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 16:23:15 -0400
Subject: better install experience
In-Reply-To: <470D315B.3070604@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
Message-ID: <1192047795.3261.88.camel@localhost.localdomain>


On Wed, 2007-10-10 at 22:08 +0200, Thorsten Leemhuis wrote:
> On 10.10.2007 21:53, Tom "spot" Callaway wrote:
> > On Wed, 2007-10-10 at 15:53 -0400, Paul Wouters wrote:
> >> On Wed, 10 Oct 2007, Tom "spot" Callaway wrote:
> >>>> If we want to improve the user experience, it would be great if anaconda
> >>>> offered to do the resize.  Even for an experienced user, who wants to d/l +
> >>>> burn >1 cd/dvd?
> >>> Anaconda doesn't have any ntfs support yet. We're looking at that for
> >>> F9.
> >>> The F-8 live-cd might have the ntfsutils, but I don't know.
> >> Wasn't NTFS a patent issue? Though I do not see it anymore on
> >> http://fedoraproject.org/wiki/ForbiddenItems
> > Short answer: No.
> > Long answer: If something (anything) in Fedora infringes a patent that
> > you hold, please let me know the specifics (which patent, which
> > software, etc), and we will address it.
> 
> Is there a middle-sized answer maybe that might explain why
> https://bugzilla.redhat.com/show_bug.cgi?id=65749
> still wasn't fixed? The bug is about this fact:
> 
> $ grep NTFS /boot/config-2.6.23-0.217.rc9.git1.fc8
> # CONFIG_NTFS_FS is not set
> 
> Sure, ntfs-3g is around -- but some people still prefer the in-kernel
> driver and it still gets downloaded from a well know 3rd party repo as
> kmod a lot.

I asked DaveJ not to enable the ntfs kmod.

1. It doesn't work as well as ntfs-3g.
1A. It doesn't have RW support.
2. It is unmaintained upstream.
3. mount.ntfs points to ntfs-3g in Fedora. So, even if someone gets the
ntfs.ko in place, they're still probably using ntfs-3g.

~spot



From bpepple at fedoraproject.org  Wed Oct 10 18:23:03 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 10 Oct 2007 14:23:03 -0400
Subject: Plan for tomorrows (20071011) FESCO meeting
Message-ID: <1192040583.6641.2.camel@kennedy>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic FESCo meeting -- Free discussion around Fedora

There's nothing on the schedule for tomorrow so if you want something
to be discussed, send a note to the list in reply to this mail and I'll
add it to the schedule.  You can also propose topics in the meeting
while it is in the "Free discussion around Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071010/8e1be162/attachment.sig>

From jspaleta at gmail.com  Wed Oct 10 20:44:48 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Oct 2007 12:44:48 -0800
Subject: samba license change
In-Reply-To: <1192045676.23415.1.camel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
Message-ID: <604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>

On 10/10/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> ??? Even if you build against gplv2 samba, as soon as the result is
> distributed with gpl3 samba and links against it on user systems, you're
> in the wrong.

who is the 'you' in that sentence? if a user takes a re-licensed
rawhide package and uses it on an F7 system, is Fedora liable? We
can't really police what people do on their systems, but we certaintly
need to police what we do on the build system.

-jef



From tmraz at redhat.com  Wed Oct 10 20:55:42 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 10 Oct 2007 22:55:42 +0200
Subject: samba license change
In-Reply-To: <604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191970821.8865.28.camel@dragonlady> <470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
Message-ID: <1192049742.3065.101.camel@vespa.kabelta.loc>


On Wed, 2007-10-10 at 12:44 -0800, Jeff Spaleta wrote:
> On 10/10/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> > ??? Even if you build against gplv2 samba, as soon as the result is
> > distributed with gpl3 samba and links against it on user systems, you're
> > in the wrong.
> 
> who is the 'you' in that sentence? if a user takes a re-licensed
> rawhide package and uses it on an F7 system, is Fedora liable? We
> can't really police what people do on their systems, but we certaintly
> need to police what we do on the build system.

Actually in case of rawhide we probably cannot build the new samba there
before all packages linking to it which have incompatible license are
either changed to not link to samba or to link to the proposed compat
libsmbclient package.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From mike at miketc.com  Wed Oct 10 20:56:00 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 10 Oct 2007 15:56:00 -0500
Subject: better install experience
In-Reply-To: <fej8ij$v89$1@sea.gmane.org>
References: <fej8ij$v89$1@sea.gmane.org>
Message-ID: <1192049760.7383.4.camel@scrappy.miketc.com>

On Wed, 2007-10-10 at 15:18 -0400, Neal Becker wrote:
> Some time back, IIRC I posted that it would improve the user experience if
> fedora installer would include a few tools.  I am (once again) getting a
> new machine, and (once again) it's coming with windoze pre-installed.  I
> need to do ntfsresize.  Last time, I had to grab a live-cd that had an
> ntfsresize, before I could do fedora install.  Has this situation improved?

I know you would rather not do this, so you get the support in case you
need it (but don't think it would matter since you are
resizing/reconfiguring the machine anyway to fit linux), but you could
just repartition it yourself and reinstall windows so you at least have
both and can reinstall either one without having to resize any longer.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From fedora at leemhuis.info  Wed Oct 10 21:02:31 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 10 Oct 2007 23:02:31 +0200
Subject: better install experience
In-Reply-To: <1192047795.3261.88.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>	<1192046031.3261.85.camel@localhost.localdomain>	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
Message-ID: <470D3DE7.90401@leemhuis.info>

On 10.10.2007 22:23, Tom "spot" Callaway wrote:
> [...]
> I asked DaveJ not to enable the ntfs kmod.

..and you two never cared to at least update the informations in the
bug? The last comment is from 2007-05-28 and people IMHO deserve at
least a answer.

> 1. It doesn't work as well as ntfs-3g.

Arguable -- some people have more trust in the kernel stuff where
kernel-developers keep a close eye on.

> 1A. It doesn't have RW support.

True; but on the other hand:

1B: ntfs from the kernel doesn't need fuse and thus you don't have to
add yourself to the fuse group.

> 2. It is unmaintained upstream.

Okay, there is not much work being done...
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=fs/ntfs;hb=HEAD
...but I would not call it unmaintained.

Further from
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS;h=9a91d9e3f1f25c2e0aaded950fae19e4d6fa7e08;hb=HEAD

NTFS FILESYSTEM
[...]
S:      Maintained

> 3. mount.ntfs points to ntfs-3g in Fedora. So, even if someone gets the
> ntfs.ko in place, they're still probably using ntfs-3g.

Nope:

$ /sbin/modinfo ntfs
filename:       /lib/modules/2.6.23-0.202.rc8.fc8/extra/ntfs/ntfs.ko
$ LC_ALL=C rpm -q ntfs-3g
package ntfs-3g is not installed
$ LC_ALL=C ls {/usr,}/{s,}bin/mount*ntfs
ls: cannot access /usr/sbin/mount*ntfs: No such file or directory
ls: cannot access /usr/bin/mount*ntfs: No such file or directory
ls: cannot access /sbin/mount*ntfs: No such file or directory
ls: cannot access /bin/mount*ntfs: No such file or directory
$ sudo mount /dev/sda3 /mnt/misc/
$ mount | grep /dev/sda3
/dev/sda3 on /mnt/misc type ntfs (rw)

----

/me will keep away from this thread now -- this won't lead to anything
anyway; I'll tag it in the growing categories "Fedora knows better then
me want I want" and "why Fedora never will become a true community
distribution"

Cu
knurd



From opensource at till.name  Wed Oct 10 21:10:58 2007
From: opensource at till.name (Till Maas)
Date: Wed, 10 Oct 2007 23:10:58 +0200
Subject: better install experience
In-Reply-To: <470D3DE7.90401@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
Message-ID: <200710102310.59264.opensource@till.name>

On Mi Oktober 10 2007, Thorsten Leemhuis wrote:

> 1B: ntfs from the kernel doesn't need fuse and thus you don't have to
> add yourself to the fuse group.

With kernel support one needs to be root to mount or adjust /etc/fstab. Imho 
the fuse solution is more userfriendly here. :-)

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/eebe7e35/attachment.sig>

From tcallawa at redhat.com  Wed Oct 10 21:17:46 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 17:17:46 -0400
Subject: better install experience
In-Reply-To: <470D3DE7.90401@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
Message-ID: <1192051066.3261.103.camel@localhost.localdomain>


On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> /me will keep away from this thread now -- this won't lead to anything
> anyway; I'll tag it in the growing categories "Fedora knows better
> then
> me want I want" and "why Fedora never will become a true community
> distribution"

DaveJ doesn't want the bugreports. Are you volunteering to take them?

There are two ntfs implementations. One is old, crufted, and poorly
maintained. The other one is actively maintained, with lots of new
releases, bugfixes, and performance improvements.

Which one should Fedora put forward for users, who don't know better?
Both?

Dave asked me for my opinion, and I said that we shouldn't ship
something that's not recommended by one of its authors, and has no real
maintenance upstream:

http://ntfs-3g.org/about.html

IMHO, this the same reason we don't enable every possible module in the
kernel. Feel free to plead your case to Dave Jones if you'd like.

~spot



From choeger at cs.tu-berlin.de  Wed Oct 10 21:20:58 2007
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 10 Oct 2007 23:20:58 +0200
Subject: better install experience
In-Reply-To: <fej8ij$v89$1@sea.gmane.org>
References: <fej8ij$v89$1@sea.gmane.org>
Message-ID: <1192051258.3749.4.camel@choeger4>

Hi guys,

I thought about it and want to put my two pence in the ring:
If you use linux for the first time you will probably get a live cd/dvd
first. This means there should be a simple way to install from such a cd
(is it? I just don't know).
If this way exists it seems that this is the place where to put the
ntfsresize option. So we could add the resize step to the live cd and
leave the default anaconda untouched, as normal users of the standard
dvd will probably resize their partitions before they even finish the
download.

what do you think?

Am Mittwoch, den 10.10.2007, 15:18 -0400 schrieb Neal Becker:
> Some time back, IIRC I posted that it would improve the user experience if
> fedora installer would include a few tools.  I am (once again) getting a
> new machine, and (once again) it's coming with windoze pre-installed.  I
> need to do ntfsresize.  Last time, I had to grab a live-cd that had an
> ntfsresize, before I could do fedora install.  Has this situation improved?
> 
> If we want to improve the user experience, it would be great if anaconda
> offered to do the resize.  Even for an experienced user, who wants to d/l +
> burn >1 cd/dvd?
> 
-- 
Christoph H?ger <choeger at cs.tu-berlin.de>
-------------- 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/20071010/f0de357a/attachment.sig>

From jspaleta at gmail.com  Wed Oct 10 21:21:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Oct 2007 13:21:58 -0800
Subject: samba license change
In-Reply-To: <1192049742.3065.101.camel@vespa.kabelta.loc>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
Message-ID: <604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>

On 10/10/07, Tomas Mraz <tmraz at redhat.com> wrote:
> Actually in case of rawhide we probably cannot build the new samba there
> before all packages linking to it which have incompatible license are
> either changed to not link to samba or to link to the proposed compat
> libsmbclient package.

Or we had a whitelist mechanism in the buildsystem to enforce
metarules concerning what can build against new libsmbclient/samba.

But Nicolas has stated my murkier concern. If we just drop re-licensed
libsmbclient into place with no enforced technical break like a soname
change or a library renaming, are we acting negligently with regard to
protecting our own users who consume pieces of rawhide to suppliment
F7 or soon to be F8? If the re-licensed code can just drop into place,
are we encouraging users to violate the license at runtime by making
it too easy to use the re-licensing binary in situations where its
inappropriate?

-jef



From ssorce at redhat.com  Wed Oct 10 21:31:16 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 17:31:16 -0400
Subject: samba license change
In-Reply-To: <604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191987490.10594.1.camel@naomi>
	<loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
Message-ID: <1192051876.26017.45.camel@localhost.localdomain>

On Wed, 2007-10-10 at 13:21 -0800, Jeff Spaleta wrote:
> On 10/10/07, Tomas Mraz <tmraz at redhat.com> wrote:
> > Actually in case of rawhide we probably cannot build the new samba there
> > before all packages linking to it which have incompatible license are
> > either changed to not link to samba or to link to the proposed compat
> > libsmbclient package.
> 
> Or we had a whitelist mechanism in the buildsystem to enforce
> metarules concerning what can build against new libsmbclient/samba.
> 
> But Nicolas has stated my murkier concern. If we just drop re-licensed
> libsmbclient into place with no enforced technical break like a soname
> change or a library renaming, are we acting negligently with regard to
> protecting our own users who consume pieces of rawhide to suppliment
> F7 or soon to be F8? If the re-licensed code can just drop into place,
> are we encouraging users to violate the license at runtime by making
> it too easy to use the re-licensing binary in situations where its
> inappropriate?

Short answer: no

Simo.



From snecklifter at gmail.com  Wed Oct 10 21:33:02 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 10 Oct 2007 22:33:02 +0100
Subject: better install experience
In-Reply-To: <1192047795.3261.88.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
Message-ID: <364d303b0710101433w3a0f9975u80d5fa981e2a8fb4@mail.gmail.com>

On 10/10/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
>
>
> On Wed, 2007-10-10 at 22:08 +0200, Thorsten Leemhuis wrote:
> > On 10.10.2007 21:53, Tom "spot" Callaway wrote:
> > > On Wed, 2007-10-10 at 15:53 -0400, Paul Wouters wrote:
> > >> On Wed, 10 Oct 2007, Tom "spot" Callaway wrote:
> > >>>> If we want to improve the user experience, it would be great if
> anaconda
> > >>>> offered to do the resize.  Even for an experienced user, who wants
> to d/l +
> > >>>> burn >1 cd/dvd?
> > >>> Anaconda doesn't have any ntfs support yet. We're looking at that
> for
> > >>> F9.
> > >>> The F-8 live-cd might have the ntfsutils, but I don't know.
> > >> Wasn't NTFS a patent issue? Though I do not see it anymore on
> > >> http://fedoraproject.org/wiki/ForbiddenItems
> > > Short answer: No.
> > > Long answer: If something (anything) in Fedora infringes a patent that
> > > you hold, please let me know the specifics (which patent, which
> > > software, etc), and we will address it.
> >
> > Is there a middle-sized answer maybe that might explain why
> > https://bugzilla.redhat.com/show_bug.cgi?id=65749
> > still wasn't fixed? The bug is about this fact:
> >
> > $ grep NTFS /boot/config-2.6.23-0.217.rc9.git1.fc8
> > # CONFIG_NTFS_FS is not set
> >
> > Sure, ntfs-3g is around -- but some people still prefer the in-kernel
> > driver and it still gets downloaded from a well know 3rd party repo as
> > kmod a lot.
>
> I asked DaveJ not to enable the ntfs kmod.


I'd prefer it if it was enabled.

1. It doesn't work as well as ntfs-3g.


This is debatable. It doesn't have full write support (has some albeit
limited) but that doesn't mean it doesn't work well. If you have a partition
that you only need read access for it actually works better (qv. faster)
than ntfs-3g.

1A. It doesn't have RW support.


You can do some. http://linux-ntfs.org/doku.php?id=status

2. It is unmaintained upstream.


Not true. Anton is implementing a full read/write driver for OS X and under
the terms of his contract he cannot release the code until something like a
year after completion.

http://sourceforge.net/mailarchive/forum.php?thread_id=7767017&forum_id=2697

3. mount.ntfs points to ntfs-3g in Fedora. So, even if someone gets the
> ntfs.ko in place, they're still probably using ntfs-3g.


I think that is wrong and a little short-sighted. It really should be
mount.ntfs-3g - the kernel driver was implemented first - it is still under
development and may well be released around the time of F9+1. Speed issues
alone will support the use of kernel filesystems over userspace ones and
this will simply prompt a return to this debate. Please can this be changed.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/f651500c/attachment.htm>

From opensource at till.name  Wed Oct 10 21:32:18 2007
From: opensource at till.name (Till Maas)
Date: Wed, 10 Oct 2007 23:32:18 +0200
Subject: samba license change
In-Reply-To: <1192045676.23415.1.camel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
Message-ID: <200710102332.46708.opensource@till.name>

On Mi Oktober 10 2007, Nicolas Mailhot wrote:

> ??? Even if you build against gplv2 samba, as soon as the result is
> distributed with gpl3 samba and links against it on user systems, you're
> in the wrong.

Is this really the case? Afaik the GPL only defines rules for distributing the 
software and rights for receiving GPL software. E.g. from GPLv3:

| 9. Acceptance Not Required for Having Copies.
| 
| You are not required to accept this License in order to receive or run a
| copy of the Program. 

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/189add22/attachment.sig>

From tcallawa at redhat.com  Wed Oct 10 21:40:43 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 17:40:43 -0400
Subject: better install experience
In-Reply-To: <364d303b0710101433w3a0f9975u80d5fa981e2a8fb4@mail.gmail.com>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<364d303b0710101433w3a0f9975u80d5fa981e2a8fb4@mail.gmail.com>
Message-ID: <1192052443.3261.106.camel@localhost.localdomain>


On Wed, 2007-10-10 at 22:33 +0100, Christopher Brown wrote:


> I think that is wrong and a little short-sighted. It really should be
> mount.ntfs-3g - the kernel driver was implemented first - it is still
> under development and may well be released around the time of F9+1.
> Speed issues alone will support the use of kernel filesystems over
> userspace ones and this will simply prompt a return to this debate.
> Please can this be changed. 

Anton's been promising that driver for two+ years now. If it ever
emerges, I'd be willing to revisit my opinion on this matter.

As to performance, can you back up your assertions with statistics?

Something like:
http://ntfs-3g.org/performance.html

~spot




From snecklifter at gmail.com  Wed Oct 10 21:51:25 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 10 Oct 2007 22:51:25 +0100
Subject: better install experience
In-Reply-To: <1192051066.3261.103.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
	<1192051066.3261.103.camel@localhost.localdomain>
Message-ID: <364d303b0710101451s10ffb932gb8c15715533d9468@mail.gmail.com>

On 10/10/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
>
>
> On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> > /me will keep away from this thread now -- this won't lead to anything
> > anyway; I'll tag it in the growing categories "Fedora knows better
> > then
> > me want I want" and "why Fedora never will become a true community
> > distribution"
>
> DaveJ doesn't want the bugreports. Are you volunteering to take them?


These aren't bug reports.

There are two ntfs implementations. One is old, crufted, and poorly
> maintained.


Sorry but that is bullshit. Old and crufted aren't very good technical
arguments and poorly maintained is simply untrue. If this boils down to "It
doesn't have write support, bwaaaaaaaah" then "poorly maintained" isn't much
of one either. The reason there have been so few git commits is because it
works fine in the state that its in and as I explained, the core developer
is focused mainly on the new driver which, license debates aside, will be
released in about a year.

The other one is actively maintained, with lots of new
> releases, bugfixes, and performance improvements.


No argument here.

Which one should Fedora put forward for users, who don't know better?


No, they run ShuttleworthLinux.

Both?


Yes, remember choice? mount.ntfs for kernel driver, mount.ntfs-3g for
userspace

Dave asked me for my opinion, and I said that we shouldn't ship
> something that's not recommended by one of its authors, and has no real
> maintenance upstream:
>
> http://ntfs-3g.org/about.html


You're taking that from Szaka's mouth who spat the dummy and went off and
created ntfs-3g when he could have merged it with ntfsprogs. It actually has
nothing to do with the kernel driver.

IMHO, this the same reason we don't enable every possible module in the
> kernel.


No, we don't enable every module because some conflict with each other, some
are experimental, and some simply don't work (cough bcm43xx cough)

Feel free to plead your case to Dave Jones if you'd like.


Since you're the one who made the decision, it really should be you who is
answering the critics. I don't think "I made the decision, now go talk to
Dave" is aligned with "DaveJ doesn't want the bugreports."

Cheers
Chris


-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/3be29e76/attachment.htm>

From snecklifter at gmail.com  Wed Oct 10 22:04:04 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 10 Oct 2007 23:04:04 +0100
Subject: better install experience
In-Reply-To: <1192052443.3261.106.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<364d303b0710101433w3a0f9975u80d5fa981e2a8fb4@mail.gmail.com>
	<1192052443.3261.106.camel@localhost.localdomain>
Message-ID: <364d303b0710101504w28859cf0hdc8683d3f5979f60@mail.gmail.com>

On 10/10/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
>
>
> On Wed, 2007-10-10 at 22:33 +0100, Christopher Brown wrote:
>
>
> > I think that is wrong and a little short-sighted. It really should be
> > mount.ntfs-3g - the kernel driver was implemented first - it is still
> > under development and may well be released around the time of F9+1.
> > Speed issues alone will support the use of kernel filesystems over
> > userspace ones and this will simply prompt a return to this debate.
> > Please can this be changed.
>
> Anton's been promising that driver for two+ years now. If it ever
> emerges, I'd be willing to revisit my opinion on this matter.
>
> As to performance, can you back up your assertions with statistics?


Love to.

http://linuxhelp.150m.com/resources/fs-benchmarks.htm

Something like:
> http://ntfs-3g.org/performance.html


..which doesn't compare the ntfs kernel driver strangely enough (even if it
did, taking data from one of the project sites is difficult to justify on
impartiality grounds).

Nice detraction from the main thrust of the argument btw. So what happens if
the kernel r/w driver gets released? There will be fireworks with
mount.ntfsthen...

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/02421925/attachment.htm>

From s.adam at diffingo.com  Wed Oct 10 22:00:45 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Wed, 10 Oct 2007 18:00:45 -0400
Subject: Merging totem and totem-xine
In-Reply-To: <1191996974.4028.11.camel@localhost.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
	<1191978010.7325.4.camel@Diffingo.localdomain>
	<1191996861.4028.8.camel@localhost.localdomain>
	<1191996974.4028.11.camel@localhost.localdomain>
Message-ID: <1192053645.19184.2.camel@Diffingo.localdomain>

On Tue, 2007-10-09 at 23:16 -0700, Peter Gordon wrote:
> On Tue, 2007-10-09 at 23:14 -0700, Peter Gordon wrote:
> > While I think your idea about these descriptions is good, it seems
> > entirely infeasible, [...]
> 
> Rereading my message, I should clarify this: It's not entirely
> infeasible as a concept; but as you had worded it (Stewart), it would
> have been so.
That's true, I forgot about that. How does this sound:

"Totem's backend specifies which set of codecs Totem should use to play
multimedia files. Selecting Gstreamer will use all installed gstreamer
codecs, while selecting Xine will use all available Xine codecs." 

Stewart

PS. Doesn't xine-lib itself support DVD menus, just not (css-)encrypted
ones?



From ssorce at redhat.com  Wed Oct 10 22:07:44 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 18:07:44 -0400
Subject: rsync license change
Message-ID: <1192054064.27891.1.camel@localhost.localdomain>

Rsync has changed it's license from GPLv2+ to GPLv3+
The license change affects version 3.0.0 (still a pre-release now).
In F-8 we will still have 2.6.9 so the change affects F-9

Simo.




From jspaleta at gmail.com  Wed Oct 10 22:13:50 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 10 Oct 2007 14:13:50 -0800
Subject: better install experience
In-Reply-To: <364d303b0710101504w28859cf0hdc8683d3f5979f60@mail.gmail.com>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<364d303b0710101433w3a0f9975u80d5fa981e2a8fb4@mail.gmail.com>
	<1192052443.3261.106.camel@localhost.localdomain>
	<364d303b0710101504w28859cf0hdc8683d3f5979f60@mail.gmail.com>
Message-ID: <604aa7910710101513t620d123fqe265d6988d54fc6d@mail.gmail.com>

On 10/10/07, Christopher Brown <snecklifter at gmail.com> wrote:
> Love to.
>
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm

Correct me if I'm reading it wrong... but the information on that
benchmark page
seems to indicate that the NTFS listings are made using the native
Windows NTFS driver running under Windows XP.

Quoting:
"For NTFS the native 32-bit Windows XP-SP2 driver was used."
...
"The NTFS filesystem and driver, performed very poorly, especially
when copying from one NTFS partition to another. It is possible the
problem is not filesystem related, but due to the SATA driver that
shipped with the motherboard (or Windows XP). Or, it might be a
problem related to running a 32-bit operating system on a 64-bit
machine. Who knows?"
...
"Interestingly enough, the NTFS/fuse project is most probably another
effort designed to have NTFS preform poorly under Linux. By design,
NTFS/fuse is a user space driver, and thus will never compete
favorably with Microsoft's kernel drivers. The Linux NTFS kernel
driver was knocked on the head some years ago, after claims, probably
false, of how dangerous it was to use. Anyway, instead of fixing the
supposed problems, the work to that point was just thrown away and the
NTFS/fuse project started."

End of qoutes from the url listed.

-jef



From ssorce at redhat.com  Wed Oct 10 22:27:38 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 18:27:38 -0400
Subject: rsync license change
In-Reply-To: <1192054064.27891.1.camel@localhost.localdomain>
References: <1192054064.27891.1.camel@localhost.localdomain>
Message-ID: <1192055258.27891.4.camel@localhost.localdomain>

On Wed, 2007-10-10 at 18:07 -0400, Simo Sorce wrote:
> Rsync has changed it's license from GPLv2+ to GPLv3+
> The license change affects version 3.0.0 (still a pre-release now).
> In F-8 we will still have 2.6.9 so the change affects F-9

Btw,
the rsync package provides just one binary and no libraries so there is
no license dependency problem.
Also the package itself uses just 2 system libraries (libacl, libpopot)
so no licensing problem here either.

Simo.



From peter at thecodergeek.com  Wed Oct 10 22:31:22 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 10 Oct 2007 15:31:22 -0700
Subject: fedora-release fedora-development.repo, 1.14, 1.14.2.1
	fedora-release.spec, 1.54, 1.54.2.1
In-Reply-To: <20071010132456.5fb8fdf1@redhat.com>
References: <200710101708.l9AH8Z01003554@cvs-int.fedora.redhat.com>
	<3209.207.233.85.165.1192036331.squirrel@webmail.thecodergeek.com>
	<20071010132456.5fb8fdf1@redhat.com>
Message-ID: <1192055482.4028.15.camel@localhost.localdomain>

On Wed, 2007-10-10 at 13:24 -0400, Jesse Keating wrote:
> We've gotten them as a byproduct of test releases throughout this
> development cycle.  Every package was signed at each test point.  It's
> the builds between those releases that still aren't signed, and will
> continue to not be signed for the near future.

Aww. :P

Thanks for explaining that to me. It's appreciated.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071010/4bb8ba77/attachment.sig>

From mcepl at redhat.com  Wed Oct 10 22:33:19 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 11 Oct 2007 00:33:19 +0200
Subject: better install experience
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
	<1192051066.3261.103.camel@localhost.localdomain>
	<364d303b0710101451s10ffb932gb8c15715533d9468@mail.gmail.com>
Message-ID: <slrnfgqkpf.9on.mcepl@hubmaier.ceplovi.cz>

On 2007-10-10, 21:51 GMT, Christopher Brown wrote:
> > There are two ntfs implementations. One is old, crufted, and 
> > poorly maintained.
>
> Sorry but that is bullshit. Old and crufted aren't very good 
> technical arguments and poorly maintained is simply untrue.

Just wanted to write something similar. One could easily write 
?one is well-tested known, accepted upstream, running in kernel 
space, and apparently built by somebody who cares a lot about 
safety of users data, the other is <opposite>.? Moreover, 
although I understand absolutely nothing, just by chance I got 
close to the discussion on 
https://bugzilla.redhat.com/show_bug.cgi?id=243594 and my feeling 
from reading that conclusion is that there is a lot of 
self-report about quality of ntfs-3g by Szaba, but a lot of 
doubts on side of person whom I trust to be very careful and 
knowledgeable.

Just my 0.02 CZK

Mat?j



From bnocera at redhat.com  Wed Oct 10 22:51:59 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 10 Oct 2007 23:51:59 +0100
Subject: Merging totem and totem-xine
In-Reply-To: <1192053645.19184.2.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
	<1191978010.7325.4.camel@Diffingo.localdomain>
	<1191996861.4028.8.camel@localhost.localdomain>
	<1191996974.4028.11.camel@localhost.localdomain>
	<1192053645.19184.2.camel@Diffingo.localdomain>
Message-ID: <1192056719.3626.145.camel@cookie.hadess.net>

On Wed, 2007-10-10 at 18:00 -0400, Stewart Adam wrote:
> On Tue, 2007-10-09 at 23:16 -0700, Peter Gordon wrote:
> > On Tue, 2007-10-09 at 23:14 -0700, Peter Gordon wrote:
> > > While I think your idea about these descriptions is good, it seems
> > > entirely infeasible, [...]
> > 
> > Rereading my message, I should clarify this: It's not entirely
> > infeasible as a concept; but as you had worded it (Stewart), it would
> > have been so.
> That's true, I forgot about that. How does this sound:
> 
> "Totem's backend specifies which set of codecs Totem should use to play
> multimedia files. Selecting Gstreamer will use all installed gstreamer
> codecs, while selecting Xine will use all available Xine codecs." 

That wouldn't really help, would it? What are xine-lib and GStreamer,
what do they play? The xine-lib backend is fine for power-users to
choose (or their admins make the choice for them), but it's not
something you'd want to present to users.

I'll mention it once again: I don't want to see this sort of dialogue in
Totem, or in the default installation. After that, feel free to discuss
implementation and wording for addition in another add-on application.

> PS. Doesn't xine-lib itself support DVD menus, just not (css-)encrypted
> ones?

No, as there's no MPEG-2 video decoder in Fedora's xine-lib (and if
there is, it shouldn't be there).



From sandeen at redhat.com  Wed Oct 10 23:14:56 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 10 Oct 2007 18:14:56 -0500
Subject: boot-time / readahead investigations
Message-ID: <470D5CF0.20204@redhat.com>

I found some problems with our (F8) readahead as it is.  I did some
testing w/ blktrace & seekwatcher during boot to see what the io
patterns look like.

First, the default/shipped readahead lists seem pretty incomplete, I saw
lots of fresh IO happening after the readahead is done.  How are the
default lists maintained?

I tried generating my own lists with init=/sbin/readahead-collector, but:

Bugzilla Bug 326891: readahead-collector doesn't collect binaries

I fixed that up, and generated nice long custom lists, but:

Bugzilla Bug 327041: readahead --sort generates file with "(null)"
instead of filename

so after the cron.daily goes off, those nice custom lists (or the
default lists) get nuked in the sort procedure.  (I think this bug only
hits on 32-bit platforms)

Ok, fixed that up, and did a bit of other tweaking:

1) moved readahead_early to S01 per davej's suggestion, and made the
readahead call *not* background itself.  This seems to help.

2) also played with "readahead_later" at S02, reading ahead in the
background.  This saved a little time, but it requires jumping through
hoops to make the lists properly.

3) tried adding a superearly readahead list for all the IO rc.sysinit
does, it helped a little but not a whole lot.

So, with the above bugfixes and 1) above, using (fixed) readahead *does*
speed up the boot process.  Testing w/o selinux so far,

with stock readahead (0:59):
http://sandeen.net/fedora_boot/bootchart-stockreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-stockreadahead-noselinux.png

without readahead (0:49):
http://sandeen.net/fedora_boot/bootchart-noreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-noreadahead-noselinux.png

with tweaked readahead (0:44):
(only tweak 1) above, with updated/sorted lists)
http://sandeen.net/fedora_boot/bootchart-fixedreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-fixedreadahead-noselinux.png

On the seekwatcher graphs, nice linear accesses should be faster, and if
all files are unfragmented and read-ahead in block order, we shouldn't
be doing a lot of seeking around.

I was able to get down to about 0:41 a few times with enough fiddling...

Also, some way to keep the readahead lists uptodate would be a help, I
think.

Selinux still does have a lot of overhead, haven't started looking
too closely at that case yet (for one, readahead probably doesn't pull
in the selinux xattrs)

Also, Chris Mason told me that the SuSE glibc has a patch which calls
fadvise(POSIX_FADV_WILLNEED) on any shared library that is opened; this
causes the kernel to launch its own readahead on it.  I have the patch
and will do some testing, sounds like an interesting approach.

I'll keep looking at this...

-Eric



From tcallawa at redhat.com  Wed Oct 10 23:41:51 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 10 Oct 2007 19:41:51 -0400
Subject: better install experience
In-Reply-To: <364d303b0710101451s10ffb932gb8c15715533d9468@mail.gmail.com>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
	<1192051066.3261.103.camel@localhost.localdomain>
	<364d303b0710101451s10ffb932gb8c15715533d9468@mail.gmail.com>
Message-ID: <1192059711.3261.110.camel@localhost.localdomain>


On Wed, 2007-10-10 at 22:51 +0100, Christopher Brown wrote:
> Since you're the one who made the decision, it really should be you
> who is answering the critics. I don't think "I made the decision, now
> go talk to Dave" is aligned with "DaveJ doesn't want the bugreports."

No, I didn't make the decision. DaveJ did. He asked me for my opinion,
and I gave it to him.

~spot



From cmadams at hiwaay.net  Wed Oct 10 23:57:54 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 10 Oct 2007 18:57:54 -0500
Subject: samba license change
In-Reply-To: <1192051876.26017.45.camel@localhost.localdomain>
References: <loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
	<1192051876.26017.45.camel@localhost.localdomain>
Message-ID: <20071010235754.GA1083997@hiwaay.net>

Once upon a time, Simo Sorce <ssorce at redhat.com> said:
> On Wed, 2007-10-10 at 13:21 -0800, Jeff Spaleta wrote:
> > But Nicolas has stated my murkier concern. If we just drop re-licensed
> > libsmbclient into place with no enforced technical break like a soname
> > change or a library renaming, are we acting negligently with regard to
> > protecting our own users who consume pieces of rawhide to suppliment
> > F7 or soon to be F8? If the re-licensed code can just drop into place,
> > are we encouraging users to violate the license at runtime by making
> > it too easy to use the re-licensing binary in situations where its
> > inappropriate?
> 
> Short answer: no

So what if KDE used a private copy of libsmclient.so.0 (from 3.0 so
GPLv2) during build but didn't ship it?  As long as the newer version is
ABI compatible (even if the license isn't), is there a violation?  I'm
sure some would say it is a violation of the spirit, but is there a
technical violation?

If so, where is the violation?  Where does it physically occur?

I haven't read GPLv3 closely, but "linking" doesn't appear anywhere in
GPLv2 except in a single note in the appendix (not in the license terms
itself).  Everything else in GPLv2 talks about derivative works.
Arguably, KDE's use of libsmbclient is a derivative work of a GPLv2
product.  As long as the interface to that product doesn't change (so
KDE's use of the product doesn't change), KDE could claim to be a
derivative work of the GPLv2 product.  Samba is NOT changing the ABI, so
any derivative works (that are derivative by action of using the
libsmbclient.so.0 interface) can still claim to be derivatives of only
the GPLv2 library.

I'm really curious about this (not just trying to still the flames): if
a GPLv2-only program is linked against a GPLv2 (or 2+) library and the
library switches to GPLv3 (or 3+), who is violating the license?  Use
(e.g. an end-user actually loading the KDE binary that dynamically links
against libsmbclient.so.0) is not covered by the GPLv2, so the end-user
is not violating it (because they aren't distributing).  A distributor
could be building against a GPLv2 version of the library but only
distributing the GPLv3 version; is that a violation (why)?

-- 
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 ndbecker2 at gmail.com  Thu Oct 11 00:22:18 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 10 Oct 2007 20:22:18 -0400
Subject: better install experience
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045935.26533.2.camel@localhost.localdomain>
Message-ID: <fejqd3$p2r$1@sea.gmane.org>

Jeremy Katz wrote:

> On Wed, 2007-10-10 at 15:18 -0400, Neal Becker wrote:
>> Some time back, IIRC I posted that it would improve the user experience
>> if
>> fedora installer would include a few tools.  I am (once again) getting a
>> new machine, and (once again) it's coming with windoze pre-installed.  I
>> need to do ntfsresize.  Last time, I had to grab a live-cd that had an
>> ntfsresize, before I could do fedora install.  Has this situation
>> improved?
>> 
>> If we want to improve the user experience, it would be great if anaconda
>> offered to do the resize.  Even for an experienced user, who wants to d/l
>> + burn >1 cd/dvd?
> 
> Are you offering to help by contributing code?  Because honestly, it's
> not like we don't want to do it. 
[...]

No, I have no plan to implement this any time soon.  But an important part
of progress on a large project is to generate good ideas, and to make sure
good ideas are organized into a plan.  So, I'd like to make 2 points:

1) Contributing good ideas is an important contribution, even if the
originator lacks the time or expertise to implement it.

2) Does fedora have a good way to organize suggestions and develop them into
goals?  I guess I'm not really aware of anything, other than posting on
this list - and with this method good ideas might easily be forgotten.



From fedora at marcbradshaw.co.uk  Thu Oct 11 00:47:35 2007
From: fedora at marcbradshaw.co.uk (Marc Bradshaw)
Date: Thu, 11 Oct 2007 10:47:35 +1000
Subject: Help requested re build errors on x86_64-devel
In-Reply-To: <470C2C3E.5010701@ioa.s.u-tokyo.ac.jp>
References: <470C0CDD.7070901@marcbradshaw.co.uk>
	<470C2C3E.5010701@ioa.s.u-tokyo.ac.jp>
Message-ID: <470D72A7.10003@marcbradshaw.co.uk>

Mamoru Tasaka wrote:
> This srpm can be rebuilt on all arch, dist-f8.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=189122
>
> I guess the build failure you saw is because your build used
> gimp 2.4.0 rc1. Update gimp to 2.4.0 rc3. (current rawhide Fedora's
> gimp is gimp-2.4.0-0.rc3.1.fc8).
> Similar discussion is found on
> https://bugzilla.redhat.com/show_bug.cgi?id=250210#c9
Thanks Mamoru, that did indeed appear to be the problem here too.

-Marc



From mmcgrath at redhat.com  Thu Oct 11 01:51:55 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 10 Oct 2007 20:51:55 -0500
Subject: CDs DVDs or netboot.  Oh my!
Message-ID: <470D81BB.2070404@redhat.com>

History: Up until Fedora 7 all RH family products had an install CD that 
people could download, stick in their drive and install a minimal set of 
packages or at least specify a method to install from.

Problem: As of Fedora 7 (and soon with Fedora 8) they cannot do this.  
The installable live cd can install but not in the traditional sense of 
what people are used to.  It has no package selection and cannot upgrade.

Opinion: I believe, in part, this has contributed to the dip in numbers 
we saw between FC6 and F7.

Future problem: as of F8 for an individual arch a user could download 
boot.iso, live cd, installable DVD, and a few respins.  Respins are 
going to get linked to a spins site, the torrents and public mirrors 
site will be linked to as well.  So the real question is what do we 
'suggest' our default install be?

1) Live CD: Can't upgrade, do package selection or specify install method.
2) DVD: isn't live (duh :)  but requires DVD burner and drive to do 
installs.
3) boot.iso: a little too advanced for causal users, etc.

So which one do we link to directly from get-fedora?  The public mirror 
list will be there as it was in the past.

    -Mike



From skvidal at fedoraproject.org  Thu Oct 11 02:23:40 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 10 Oct 2007 22:23:40 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D81BB.2070404@redhat.com>
References: <470D81BB.2070404@redhat.com>
Message-ID: <1192069420.19308.15.camel@cutter>


On Wed, 2007-10-10 at 20:51 -0500, Mike McGrath wrote:
> History: Up until Fedora 7 all RH family products had an install CD that 
> people could download, stick in their drive and install a minimal set of 
> packages or at least specify a method to install from.
> 
> Problem: As of Fedora 7 (and soon with Fedora 8) they cannot do this.  
> The installable live cd can install but not in the traditional sense of 
> what people are used to.  It has no package selection and cannot upgrade.
> 
> Opinion: I believe, in part, this has contributed to the dip in numbers 
> we saw between FC6 and F7.
> 
> Future problem: as of F8 for an individual arch a user could download 
> boot.iso, live cd, installable DVD, and a few respins.  Respins are 
> going to get linked to a spins site, the torrents and public mirrors 
> site will be linked to as well.  So the real question is what do we 
> 'suggest' our default install be?
> 
> 1) Live CD: Can't upgrade, do package selection or specify install method.
> 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do 
> installs.
> 3) boot.iso: a little too advanced for causal users, etc.
> 
> So which one do we link to directly from get-fedora?  The public mirror 
> list will be there as it was in the past.

livecd - you can do pkg selection after you're installed and it lets you
'try before you buy'

-sv




From mastahnke at gmail.com  Thu Oct 11 02:36:09 2007
From: mastahnke at gmail.com (Michael Stahnke)
Date: Wed, 10 Oct 2007 21:36:09 -0500
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <1192069420.19308.15.camel@cutter>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
Message-ID: <7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>

I really think an upgrade path for the casual user is required.  Live
CDs require the user to start over. Boo.  The DVD is huge.  A minimal
upgrade, like editing the repo files and yum update would be nice.
Especially if everything worked correctly.  (I am not saying it
doesn't currently, but in the past, it sure didn't).   Or, could there
be a package group like "start here for upgrades" or something? Again,
for the more casual linux user, not the system admins.


stahnma



From jreiser at BitWagon.com  Thu Oct 11 02:47:52 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Wed, 10 Oct 2007 19:47:52 -0700
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D81BB.2070404@redhat.com>
References: <470D81BB.2070404@redhat.com>
Message-ID: <470D8ED8.9010509@BitWagon.com>

> So the real question is what do we 'suggest' our default install be?
> 
> 1) Live CD: Can't upgrade, do package selection or specify install method.

Why can't a system that is installed from the Live CD be upgraded?
What would it take to make such an installation upgradeable?
I believe it is reasonable if the upgrade is possible, even if it
requires a separate step after initial installation from Live CD.
[Specifying install method and package selection is a natural for the
Rescue CD; see #3 below.]

> 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do
> installs.

In the "first world" a DVD burner is $50 or less and a DVD reader is
$30 or less.  In other places (or if those prices are a serious barrier)
then share through a user group or a buddy, or postal mail, etc.  Seriously.
The isolated boxes with no DVD also tend to have anemic network connectivity.
Five CD images take a *week* at dialup speeds (I know, I created F7 CDs
and spoon fed them to somebody at 33.6Kbaud.)

I would like to see a step-by-step method with explanation for doing
an install from a DVD.iso on a separate partition on the same machine,
and over NFS from another machine that has DVD.iso (unpacking the .iso
beforehand is not allowed.)  I believe that the current directions
for these cases are too glib.

> 3) boot.iso: a little too advanced for causal users, etc.

For the suggested default, I favor network install booted from the Rescue CD.
Please make the Rescue CD available separately, at least for official Release.
In the test series for Fedora 8, particularly the torrents, the Rescue CD
was "bundled" with the DVD.  This bundling defeats the size advantage (120MB
vs 3GB.)

-- 



From notting at redhat.com  Thu Oct 11 02:46:11 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 10 Oct 2007 22:46:11 -0400
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
Message-ID: <20071011024611.GA12391@nostromo.devel.redhat.com>

Michael Stahnke (mastahnke at gmail.com) said: 
> I really think an upgrade path for the casual user is required.  Live
> CDs require the user to start over. Boo.  The DVD is huge.

The DVD isn't really any bigger than the previous CD images are.

> A minimal
> upgrade, like editing the repo files and yum update would be nice.
> Especially if everything worked correctly.  (I am not saying it
> doesn't currently, but in the past, it sure didn't).   Or, could there
> be a package group like "start here for upgrades" or something? Again,
> for the more casual linux user, not the system admins.

Some potential upgrade enhancements may be looked at for F9.

Bill



From mastahnke at gmail.com  Thu Oct 11 02:51:27 2007
From: mastahnke at gmail.com (Michael Stahnke)
Date: Wed, 10 Oct 2007 21:51:27 -0500
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <20071011024611.GA12391@nostromo.devel.redhat.com>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<20071011024611.GA12391@nostromo.devel.redhat.com>
Message-ID: <7874d9dd0710101951r5971baffpe9c9b67c020b9993@mail.gmail.com>

On 10/10/07, Bill Nottingham <notting at redhat.com> wrote:
> Michael Stahnke (mastahnke at gmail.com) said:
> > I really think an upgrade path for the casual user is required.  Live
> > CDs require the user to start over. Boo.  The DVD is huge.
>
> The DVD isn't really any bigger than the previous CD images are.
I think I was displeased by the huge number of CDs also.  I really
like the idea of one cd and then grabbing what I want off of the
network.  (but I have a decent pipe).
>
> > A minimal
> > upgrade, like editing the repo files and yum update would be nice.
> > Especially if everything worked correctly.  (I am not saying it
> > doesn't currently, but in the past, it sure didn't).   Or, could there
> > be a package group like "start here for upgrades" or something? Again,
> > for the more casual linux user, not the system admins.
>
> Some potential upgrade enhancements may be looked at for F9.
>
> Bill
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From marc at mwiriadi.id.au  Thu Oct 11 02:52:37 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 11 Oct 2007 10:52:37 +0800
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D8ED8.9010509@BitWagon.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
Message-ID: <470D8FF5.8070402@mwiriadi.id.au>

John Reiser wrote:
>> So the real question is what do we 'suggest' our default install be?
>>
>> 1) Live CD: Can't upgrade, do package selection or specify install method.
>>     
>
> Why can't a system that is installed from the Live CD be upgraded?
> What would it take to make such an installation upgradeable?
> I believe it is reasonable if the upgrade is possible, even if it
> requires a separate step after initial installation from Live CD.
> [Specifying install method and package selection is a natural for the
> Rescue CD; see #3 below.]
>
>   
>> 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do
>> installs.
>>     
>
> In the "first world" a DVD burner is $50 or less and a DVD reader is
> $30 or less.  In other places (or if those prices are a serious barrier)
> then share through a user group or a buddy, or postal mail, etc.  Seriously.
> The isolated boxes with no DVD also tend to have anemic network connectivity.
> Five CD images take a *week* at dialup speeds (I know, I created F7 CDs
> and spoon fed them to somebody at 33.6Kbaud.)
>
> I would like to see a step-by-step method with explanation for doing
> an install from a DVD.iso on a separate partition on the same machine,
> and over NFS from another machine that has DVD.iso (unpacking the .iso
> beforehand is not allowed.)  I believe that the current directions
> for these cases are too glib.
>
>   
>> 3) boot.iso: a little too advanced for causal users, etc.
>>     
>
> For the suggested default, I favor network install booted from the Rescue CD.
> Please make the Rescue CD available separately, at least for official Release.
> In the test series for Fedora 8, particularly the torrents, the Rescue CD
> was "bundled" with the DVD.  This bundling defeats the size advantage (120MB
> vs 3GB.)
>
>   

You can separate out your download's using the torrents to download the 
specific Rescue CD. 

Regards,

Marc



From jreiser at BitWagon.com  Thu Oct 11 03:01:38 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Wed, 10 Oct 2007 20:01:38 -0700
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D8FF5.8070402@mwiriadi.id.au>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D8FF5.8070402@mwiriadi.id.au>
Message-ID: <470D9212.2040304@BitWagon.com>

>> In the test series for Fedora 8, particularly the torrents, the Rescue CD
>> was "bundled" with the DVD.  This bundling defeats the size advantage
>> (120MB vs 3GB.)

> You can separate out your download's using the torrents to download the
> specific Rescue CD.

There is no indication that the Rescue CD is bundled with the DVD.
The official directions at http://torrent.fedoraproject.org/
do not tell how to split the Rescue CD from the DVD.
Indeed, splitting cannot be done using Fedora bittorrent rpm.

-- 



From mmcgrath at redhat.com  Thu Oct 11 03:43:55 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 10 Oct 2007 22:43:55 -0500
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
Message-ID: <470D9BFB.2050203@redhat.com>

Michael Stahnke wrote:
> I really think an upgrade path for the casual user is required.  Live
> CDs require the user to start over. Boo.  The DVD is huge.  A minimal
> upgrade, like editing the repo files and yum update would be nice.
> Especially if everything worked correctly.  (I am not saying it
> doesn't currently, but in the past, it sure didn't).   Or, could there
> be a package group like "start here for upgrades" or something? Again,
> for the more casual linux user, not the system admins.
>
>   

A link to a docs.fp.o site about upgrades is a good idea.

    -Mike



From mmcgrath at redhat.com  Thu Oct 11 03:46:16 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 10 Oct 2007 22:46:16 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D8ED8.9010509@BitWagon.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
Message-ID: <470D9C88.9050106@redhat.com>

John Reiser wrote:
>> So the real question is what do we 'suggest' our default install be?
>>
>> 1) Live CD: Can't upgrade, do package selection or specify install method.
>>     
>
> Why can't a system that is installed from the Live CD be upgraded?
> What would it take to make such an installation upgradeable?
> I believe it is reasonable if the upgrade is possible, even if it
> requires a separate step after initial installation from Live CD.
> [Specifying install method and package selection is a natural for the
> Rescue CD; see #3 below.]
>   

Because the live cd install does an image copy and not an install.  The 
workings behind the scenes are not the same right now in anaconda for 
the live cd and the normal install.

>   
>> 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do
>> installs.
>>     
>
> In the "first world" a DVD burner is $50 or less and a DVD reader is
> $30 or less.  In other places (or if those prices are a serious barrier)
> then share through a user group or a buddy, or postal mail, etc.  Seriously.
> The isolated boxes with no DVD also tend to have anemic network connectivity.
> Five CD images take a *week* at dialup speeds (I know, I created F7 CDs
> and spoon fed them to somebody at 33.6Kbaud.)
>
>   
*or* just download something else.  I'd like to point out that I 
consider myself an avid Linux user and I've never done a DVD install.


    -Mike



From halfline at gmail.com  Thu Oct 11 03:55:20 2007
From: halfline at gmail.com (Ray Strode)
Date: Wed, 10 Oct 2007 23:55:20 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1192029636.26943.20.camel@raptor.sr.unh.edu>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<1192029636.26943.20.camel@raptor.sr.unh.edu>
Message-ID: <45abe7d80710102055t7eb29314rc26008b93897acac@mail.gmail.com>

Hi,

> I tracked this down more and it happens with metacity too on my intel
> graphics laptop. After logging out, if I go to a text console and kill
> just gnome-session, the logout finishes and gdm comes back up.
>
> Does this "fix" work for anyone else having the problem? It seems that
> since this apparently is not happening for everyone, it must be
> something I'm running that causes gnome-session to hang. I checked and
> pulseaudio is not running so I'm don't think it is the culprit.

Do you have vino ("Remote Desktop") installed ?  I think there's a bug
on one of the F8 tracker lists that mentions some weird interaction
between vino and gnome-session on logout.  I haven't looked into it
yet.

--Ray



From Matt_Domsch at dell.com  Thu Oct 11 03:56:41 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 10 Oct 2007 22:56:41 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D81BB.2070404@redhat.com>
References: <470D81BB.2070404@redhat.com>
Message-ID: <20071011035641.GA11220@auslistsprd01.us.dell.com>

On Wed, Oct 10, 2007 at 08:51:55PM -0500, Mike McGrath wrote:
> 3) boot.iso: a little too advanced for causal users, etc.

If this would use the mirrorlists to choose a download server, I'd +1
it in a heartbeat.  I think that's in the plan for F9 though.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From skvidal at fedoraproject.org  Thu Oct 11 03:58:30 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 10 Oct 2007 23:58:30 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D9C88.9050106@redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com>
Message-ID: <1192075110.19308.21.camel@cutter>


On Wed, 2007-10-10 at 22:46 -0500, Mike McGrath wrote:
> John Reiser wrote:
> >> So the real question is what do we 'suggest' our default install be?
> >>
> >> 1) Live CD: Can't upgrade, do package selection or specify install method.
> >>     
> >
> > Why can't a system that is installed from the Live CD be upgraded?
> > What would it take to make such an installation upgradeable?
> > I believe it is reasonable if the upgrade is possible, even if it
> > requires a separate step after initial installation from Live CD.
> > [Specifying install method and package selection is a natural for the
> > Rescue CD; see #3 below.]
> >   
> 
> Because the live cd install does an image copy and not an install.  The 
> workings behind the scenes are not the same right now in anaconda for 
> the live cd and the normal install.

Wait - you can upgrade after you boot into the installed livecd image.
You just can't upgrade it FROM the boot live image.

-sv




From ssorce at redhat.com  Thu Oct 11 03:41:33 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 10 Oct 2007 23:41:33 -0400
Subject: samba license change
In-Reply-To: <20071010235754.GA1083997@hiwaay.net>
References: <loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
	<1192051876.26017.45.camel@localhost.localdomain>
	<20071010235754.GA1083997@hiwaay.net>
Message-ID: <1192074093.27891.8.camel@localhost.localdomain>

On Wed, 2007-10-10 at 18:57 -0500, Chris Adams wrote:
> Once upon a time, Simo Sorce <ssorce at redhat.com> said:
> > On Wed, 2007-10-10 at 13:21 -0800, Jeff Spaleta wrote:
> > > But Nicolas has stated my murkier concern. If we just drop re-licensed
> > > libsmbclient into place with no enforced technical break like a soname
> > > change or a library renaming, are we acting negligently with regard to
> > > protecting our own users who consume pieces of rawhide to suppliment
> > > F7 or soon to be F8? If the re-licensed code can just drop into place,
> > > are we encouraging users to violate the license at runtime by making
> > > it too easy to use the re-licensing binary in situations where its
> > > inappropriate?
> > 
> > Short answer: no
> 
> So what if KDE used a private copy of libsmclient.so.0 (from 3.0 so
> GPLv2) during build but didn't ship it?  As long as the newer version is
> ABI compatible (even if the license isn't), is there a violation?  I'm
> sure some would say it is a violation of the spirit, but is there a
> technical violation?
> 
> If so, where is the violation?  Where does it physically occur?
> 
> I haven't read GPLv3 closely, but "linking" doesn't appear anywhere in
> GPLv2 except in a single note in the appendix (not in the license terms
> itself).  Everything else in GPLv2 talks about derivative works.
> Arguably, KDE's use of libsmbclient is a derivative work of a GPLv2
> product.  As long as the interface to that product doesn't change (so
> KDE's use of the product doesn't change), KDE could claim to be a
> derivative work of the GPLv2 product.  Samba is NOT changing the ABI, so
> any derivative works (that are derivative by action of using the
> libsmbclient.so.0 interface) can still claim to be derivatives of only
> the GPLv2 library.
> 
> I'm really curious about this (not just trying to still the flames): if
> a GPLv2-only program is linked against a GPLv2 (or 2+) library and the
> library switches to GPLv3 (or 3+), who is violating the license?  Use
> (e.g. an end-user actually loading the KDE binary that dynamically links
> against libsmbclient.so.0) is not covered by the GPLv2, so the end-user
> is not violating it (because they aren't distributing).  A distributor
> could be building against a GPLv2 version of the library but only
> distributing the GPLv3 version; is that a violation (why)?

Far from being a flame.
Your question is perfectly legitimate, but I don't think there is
anybody on this list with enough legal expertise to answer.
We need legal advice to be able to answer this question.

Simo.



From dmc.fedora at filteredperception.org  Thu Oct 11 04:05:53 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Wed, 10 Oct 2007 23:05:53 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D8ED8.9010509@BitWagon.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
Message-ID: <470DA121.7050905@filteredperception.org>

John Reiser wrote:
>> So the real question is what do we 'suggest' our default install be?
>>
>> 1) Live CD: Can't upgrade, do package selection or specify install method.
> 
> Why can't a system that is installed from the Live CD be upgraded?
> What would it take to make such an installation upgradeable?

The livecd is not a collection of rpms, it is an installed filesystem 
image that runs live.

One idea, if one were so inclined, and wanted to make it upgradeable, 
would be to write an abstraction layer (I'm thinking fuse filesystem) 
that could mount an installed filesystem image, and provide a mounted 
view of it as the collection of rpms it contains.  I.e. using that rpm 
functionality that lets you rebuild a binary rpm from the installed 
files and rpmdb on a system.  Not pretty, but the best I think you could 
do in the traditional sense.  If you want to go to more of a 'wipegrade' 
type upgrade, that provides the user tools to ease the migration of old 
modified system state, to a new fresh system image, that would be 
another possible track.

-dmc



From poelstra at redhat.com  Thu Oct 11 05:02:36 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 10 Oct 2007 22:02:36 -0700
Subject: Plan for tomorrows (20071011) FESCO meeting
In-Reply-To: <1192040583.6641.2.camel@kennedy>
References: <1192040583.6641.2.camel@kennedy>
Message-ID: <470DAE6C.3070009@redhat.com>

Brian Pepple said the following on 10/10/2007 11:23 AM Pacific Time:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
> in #fedora-meeting on irc.freenode.org:
> 
> /topic FESCo meeting -- Free discussion around Fedora
> 
> There's nothing on the schedule for tomorrow so if you want something
> to be discussed, send a note to the list in reply to this mail and I'll
> add it to the schedule.  You can also propose topics in the meeting
> while it is in the "Free discussion around Fedora" phase.

Need to follow-up on the remaining unfinished features from last week:
http://fedoraproject.org/wiki/Releases/8/FeatureList

In particular:
http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements
http://fedoraproject.org/wiki/Releases/FeatureNetworkManager
http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity

The feature pages need to reflect what is 100% done and push unfinished items to a new wiki page for Fedora 9.

Thank you,
John



From louisg00 at bellsouth.net  Thu Oct 11 05:17:53 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Thu, 11 Oct 2007 01:17:53 -0400
Subject: Looking for pcre.h?
Message-ID: <1192079873.14881.3.camel@tiger>

I'm trying to compile goffice-0.5 and configure can't find pcre.h. I do
have perl-devel installed but looking through it I can't see this header
file. What other devel package am I missing?

-Thanks



From green at redhat.com  Thu Oct 11 05:28:12 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 10 Oct 2007 22:28:12 -0700
Subject: Looking for pcre.h?
In-Reply-To: <1192079873.14881.3.camel@tiger>
References: <1192079873.14881.3.camel@tiger>
Message-ID: <470DB46C.9050100@redhat.com>

Louis E Garcia II wrote:
> I'm trying to compile goffice-0.5 and configure can't find pcre.h. I do
> have perl-devel installed but looking through it I can't see this header
> file. What other devel package am I missing?

pcre-devel

Note that "yum install /usr/include/pcre.h" should have done the trick.

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071010/9231ee88/attachment.vcf>

From rc040203 at freenet.de  Thu Oct 11 05:28:33 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 11 Oct 2007 07:28:33 +0200
Subject: Looking for pcre.h?
In-Reply-To: <1192079873.14881.3.camel@tiger>
References: <1192079873.14881.3.camel@tiger>
Message-ID: <1192080514.3058.35.camel@mccallum.corsepiu.local>

On Thu, 2007-10-11 at 01:17 -0400, Louis E Garcia II wrote:
> I'm trying to compile goffice-0.5 and configure can't find pcre.h. I do
> have perl-devel installed but looking through it I can't see this header
> file. What other devel package am I missing?

# rpm -qf /usr/include/pcre.h
pcre-devel-7.0-2

=> yum install pcre-devel
?

Ralf




From j.w.r.degoede at hhs.nl  Thu Oct 11 06:04:49 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 11 Oct 2007 08:04:49 +0200
Subject: samba license change
In-Reply-To: <20071010235754.GA1083997@hiwaay.net>
References: <loom.20071010T112610-389@post.gmane.org>	<1192019946.13627.65.camel@localhost.localdomain>	<loom.20071010T162828-161@post.gmane.org>	<1192040623.26017.24.camel@localhost.localdomain>	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>	<1192045676.23415.1.camel@rousalka.dyndns.org>	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>	<1192049742.3065.101.camel@vespa.kabelta.loc>	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>	<1192051876.26017.45.camel@localhost.localdomain>
	<20071010235754.GA1083997@hiwaay.net>
Message-ID: <470DBD01.30603@hhs.nl>

Chris Adams wrote:
> I'm really curious about this (not just trying to still the flames): if
> a GPLv2-only program is linked against a GPLv2 (or 2+) library and the
> library switches to GPLv3 (or 3+), who is violating the license?  Use
> (e.g. an end-user actually loading the KDE binary that dynamically links
> against libsmbclient.so.0) is not covered by the GPLv2, so the end-user
> is not violating it (because they aren't distributing).  A distributor
> could be building against a GPLv2 version of the library but only
> distributing the GPLv3 version; is that a violation (why)?
> 

If you build against a GPLv2(+) lib and distribute only a GPLv3(+) lib, then 
you (the distributer) are violating the GPL, it doesn't matter against what you 
build (as long as it works), for the license what you distribute is what 
counts, as the license is about *distributing*. And the GPLv2 says in section 
3, you may only distribute a work under the GPLv2 if you:
"a) Accompany it with the complete corresponding machine-readable
  source code, which must be distributed under the terms of Sections
  1 and 2 above on a medium customarily used for software interchange; or,"

And the source code is:
"For an executable work, complete source code means all the source code for all 
modules it contains, plus any associated interface definition files, plus the 
scripts used to control compilation and installation of the executable."

Where "modules" means all parts needed to make it run, so including libraries, 
and notice "which must be distributed under the terms of Sections 1 and 2 
above", which say that the covered work must be distributed under the same 
License (GPLv2).

So you must distribute it together with a GPLv2 licensed samba, so no loop 
holes here (luckily!).

Regards,

Hans



From nicolas.mailhot at laposte.net  Thu Oct 11 06:27:16 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 08:27:16 +0200
Subject: samba license change
In-Reply-To: <200710102332.46708.opensource@till.name>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<200710102332.46708.opensource@till.name>
Message-ID: <1192084036.4029.0.camel@rousalka.dyndns.org>


Le mercredi 10 octobre 2007 ? 23:32 +0200, Till Maas a ?crit :
> On Mi Oktober 10 2007, Nicolas Mailhot wrote:
> 
> > ??? Even if you build against gplv2 samba, as soon as the result is
> > distributed with gpl3 samba and links against it on user systems, you're
> > in the wrong.
> 
> Is this really the case? Afaik the GPL only defines rules for distributing the 
> software and rights for receiving GPL software.

Read my sentence again. The *full* sentence

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

From nicolas.mailhot at laposte.net  Thu Oct 11 06:30:32 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 08:30:32 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192069420.19308.15.camel@cutter>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
Message-ID: <1192084232.4029.3.camel@rousalka.dyndns.org>


Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :

> livecd - you can do pkg selection after you're installed 

And users do not want that. That's the same thing as the "reboot before
continuing" windows plague

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

From nicolas.mailhot at laposte.net  Thu Oct 11 06:31:36 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 08:31:36 +0200
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
Message-ID: <1192084296.4029.5.camel@rousalka.dyndns.org>


Le mercredi 10 octobre 2007 ? 21:36 -0500, Michael Stahnke a ?crit :
> I really think an upgrade path for the casual user is required.

Unless they've been dunked, network install/updates should fit the bill

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

From sundaram at fedoraproject.org  Thu Oct 11 07:27:29 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 12:57:29 +0530
Subject: better install experience
In-Reply-To: <470D315B.3070604@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
Message-ID: <470DD061.4030600@fedoraproject.org>

Thorsten Leemhuis wrote:

> 
> Sure, ntfs-3g is around -- but some people still prefer the in-kernel
> driver and it still gets downloaded from a well know 3rd party repo as
> kmod a lot.

That repo should drop the package ideally. It is confusing end users 
into believing that Fedora itself doesn't support NTFS and the FUSE 
module in Fedora is way better.

Rahul



From fedora at leemhuis.info  Thu Oct 11 07:31:25 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 11 Oct 2007 09:31:25 +0200
Subject: better install experience
In-Reply-To: <1192051066.3261.103.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>	<1192046031.3261.85.camel@localhost.localdomain>	<470D315B.3070604@leemhuis.info>	<1192047795.3261.88.camel@localhost.localdomain>	<470D3DE7.90401@leemhuis.info>
	<1192051066.3261.103.camel@localhost.localdomain>
Message-ID: <470DD14D.1050301@leemhuis.info>

/me got some download numbers from livna, so I'll send one final mail

On 10.10.2007 23:17, Tom "spot" Callaway wrote:
> On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
>> /me will keep away from this thread now -- this won't lead to anything
>> anyway; I'll tag it in the growing categories "Fedora knows better
>> then
>> me want I want" and "why Fedora never will become a true community
>> distribution"
> DaveJ doesn't want the bugreports. Are you volunteering to take them?

Sure.

> There are two ntfs implementations. One is old, crufted, and poorly
> maintained. The other one is actively maintained, with lots of new
> releases, bugfixes, and performance improvements.

Nevertheless there are about 4500 F7 users installed kmod-ntfs from
livna. I'd assume they didn't do that by accident. And I'd further
assume most howtos these days will describe ntfs-3g, so I bet a good
percentage of those 4500 chose the older one for a reason.

> Which one should Fedora put forward for users, who don't know better?
> Both?

Sure -- just make ntfs-3g the default. Then normal users are happy and
those that want the old stuff can use it easily.

CU
knurd



From sundaram at fedoraproject.org  Thu Oct 11 07:33:32 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 13:03:32 +0530
Subject: better install experience
In-Reply-To: <fejqd3$p2r$1@sea.gmane.org>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045935.26533.2.camel@localhost.localdomain>
	<fejqd3$p2r$1@sea.gmane.org>
Message-ID: <470DD1CC.6010206@fedoraproject.org>

Neal Becker wrote:

> 2) Does fedora have a good way to organize suggestions and develop them into
> goals?  I guess I'm not really aware of anything, other than posting on
> this list - and with this method good ideas might easily be forgotten.

Yes. There are atleast two methods.

1) File a RFE.

http://fedoraproject.org/wiki/BugsAndFeatureRequests

2) Write down a feature proposal

http://fedoraproject.org/wiki/Features/Policy

Rahul



From lkundrak at redhat.com  Thu Oct 11 07:44:41 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 09:44:41 +0200
Subject: better install experience
In-Reply-To: <470D3DE7.90401@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
Message-ID: <1192088681.6070.3.camel@localhost.localdomain>


On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:

> NTFS FILESYSTEM

Come on, NTFS is soooo 90's ;)

> /me will keep away from this thread now -- this won't lead to anything
> anyway; I'll tag it in the growing categories "Fedora knows better then
> me want I want" and "why Fedora never will become a true community
> distribution"

Users don't want in-kernel ntfs, or ntfs-3g. What they want is the NTFS
support.

"If I'd asked my customers what they wanted, they'd have chosen a faster
horse"

     -- Henry Ford

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From kmaraas at broadpark.no  Thu Oct 11 07:49:34 2007
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Thu, 11 Oct 2007 09:49:34 +0200
Subject: acpid and logging
In-Reply-To: <200710100933.50936.sgrubb@redhat.com>
References: <470CD0A3.2030204@redhat.com>
	<200710100933.50936.sgrubb@redhat.com>
Message-ID: <1192088974.2517.4.camel@localhost.localdomain>


on., 10.10.2007 kl. 09.33 -0400, skrev Steve Grubb:
> On Wednesday 10 October 2007 09:16:19 Zdenek Prikryl wrote:
> > since version 1.0.6, acpid does not use separate file for logging. It uses
> > openlog() and vsyslog() instead of own implementation of logging. So
> > everything go to /var/log/messages. 
> 
> Yes, I have been chatting with upstream since I'm getting about 6-8 events a 
> second. He claims I'm the only person on the planet that is getting this rate 
> of events and my BIOS is broken. It makes syslog hard to use for researching 
> problems, but not unreadable.
> 
> > But it could be dangerous. According to this bug
> > https://bugzilla.redhat.com/show_bug.cgi?id=294391, it could lead 
> > to unreadable /var/log/messages.
> 
> I do not see anything in that bug that tells how it damages or makes syslog 
> unusable. I find that it floods syslog, but its not unreadable.
> 
> > So there are two options:
> > 1. Get back to old style logging (but upstream does not want to)
> > 2. In /etc/rsyslog.conf append a filter for acpid, so rsyslog will be
> > logging messages form acpid in separate file.
> 
> There's a third option, which I've asked upstream about, make some of these 
> messages DEBUG and only log abnormal messages at the higher syslog 
> priorities. IOW, not all messages are of the same importance. Seriously, my 
> battery being full of power or me connecting to AC power is not a syslog 
> worthy or any log worthy event unless I'm debugging a problem. 
> 
> Upstream is of the opinion that I'm the only person seeing a high rate of 
> events and doesn't really want to fix it unless others report similar 
> problems. Am I the only one?
> 
I don't see many events per second, but still acpid is flooding syslog:

[root at localhost log]# tail -f /var/log/messages
Oct 11 09:42:26 localhost acpid: notifying client 2145[0:0]
Oct 11 09:42:26 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:42:27 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:42:27 localhost acpid: notifying client 2001[68:68]
Oct 11 09:42:27 localhost acpid: notifying client 2145[0:0]
Oct 11 09:42:27 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:42:41 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:42:41 localhost acpid: notifying client 2001[68:68]
Oct 11 09:42:41 localhost acpid: notifying client 2145[0:0]
Oct 11 09:42:41 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:43:00 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:43:00 localhost acpid: notifying client 2001[68:68]
Oct 11 09:43:00 localhost acpid: notifying client 2145[0:0]
Oct 11 09:43:00 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:43:43 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:43:43 localhost acpid: notifying client 2001[68:68]
Oct 11 09:43:43 localhost acpid: notifying client 2145[0:0]
Oct 11 09:43:43 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:44:16 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:44:16 localhost acpid: notifying client 2001[68:68]
Oct 11 09:44:16 localhost acpid: notifying client 2145[0:0]
Oct 11 09:44:16 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:44:57 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
Oct 11 09:44:57 localhost acpid: notifying client 2001[68:68]
Oct 11 09:44:57 localhost acpid: notifying client 2145[0:0]
Oct 11 09:44:57 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"

Do we really neew to log all these?

Cheers
Kjartan




From fedora at leemhuis.info  Thu Oct 11 07:55:41 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 11 Oct 2007 09:55:41 +0200
Subject: better install experience
In-Reply-To: <470DD061.4030600@fedoraproject.org>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>	<1192046031.3261.85.camel@localhost.localdomain>	<470D315B.3070604@leemhuis.info>
	<470DD061.4030600@fedoraproject.org>
Message-ID: <470DD6FD.1090309@leemhuis.info>



On 11.10.2007 09:27, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
> 
>> Sure, ntfs-3g is around -- but some people still prefer the in-kernel
>> driver and it still gets downloaded from a well know 3rd party repo as
>> kmod a lot.
> 
> That repo should drop the package ideally.

I agreed, once there is no user demand for the kmod and once ntfs-3g is
clearly better.

> It is confusing end users 
> into believing that Fedora itself doesn't support NTFS and the FUSE 
> module in Fedora is way better.

Yeah, while at it let's drop Gnome from Fedora, KDE is way better.

CU
knurd

P.S.: To make it more obvious: I'm using Gnome and don't meant the last
sentence seriously.



From szaka at ntfs-3g.org  Thu Oct 11 07:59:30 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Thu, 11 Oct 2007 10:59:30 +0300 (EEST)
Subject: better install experience
Message-ID: <Pine.LNX.4.62.0710111011320.27551@tamago.serverit.net>


Hi,

On 11/10/07, Jeff Spaleta  wrote:
> On 10/10/07, Christopher Brown <snecklifter gmail com> wrote:
> >
> > Love to.
> >
> > http://linuxhelp.150m.com/resources/fs-benchmarks.htm

The benchmark on the above page used the ntfs-3g-0.20070118-BETA driver 
(mentioned in the 6th paragraph) and since then tremendous amount of 
performance work went into NTFS-3G. Please see

	http://ntfs-3g.org/releases.html

Nevertheless the driver is still very much __NOT__ optimized but being 
worked on the kernel, FUSE and NTFS-3G level by at least Nick Piggin, 
Miklos Szeredi and the NTFS-3G team.

> > >    Something like:
> > >    http://ntfs-3g.org/performance.html
> 
> > ..which doesn't compare the ntfs kernel driver strangely enough

The kernel driver can't create/delete files hereby it couldn't run the 
benchmark.

However if you look carefully the streaming read/write performances than 
you can notice that that the NTFS-3G performance is very close to the 
performance of the kernel file systems. The reason is simple, typically the 
disk bandwidth is the bottleneck, not the file system quality.

Btw, the above numbers are also outdated and all maintained filesystems 
were improved since then. These numbers are more recent (and not done 
by me ;) though still almost half year old.

http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-fuse-for-fuse-performance

> Correct me if I'm reading it wrong... but the information on that 
> benchmark page seems to indicate that the NTFS listings are made using 
> the native Windows NTFS driver running under Windows XP.

Yes, the Windows NTFS driver and NTFS-3G were tested. The kernel NTFS 
driver can't run most of those tests because it can only read files.

> "Interestingly enough, the NTFS/fuse project is most probably another
> effort designed to have NTFS preform poorly under Linux. By design,
> NTFS/fuse is a user space driver, and thus will never compete
> favorably with Microsoft's kernel drivers. 

High performance, block device based hybrid-space file systems are very new 
on Linux and they need quite a lot of optimization work in the kernel, FUSE 
and the file system driver itself. NTFS is also very complex (Windows NTFS 
is about 300,000, ntfs-3g 70,000, ext3 30,000, fat 3,000 source lines 
without comments, etc) and we simply can't do better now.

> The Linux NTFS kernel driver was knocked on the head some years ago, 
> after claims, probably false, of how dangerous it was to use. 

Here the writer confuses Loewis' kernel NTFS driver with Anton's kernel 
NTFS driver.

> Anyway, instead of fixing the supposed problems, the work to that point 
> was just thrown away and the NTFS/fuse project started."

Absolutely untrue. Anton's kernel driver and NTFS-3G have the same source 
base, the later being actively worked on by developers but not the former 
what Anton says he completely rewrote, and it's closed source for now.

Regards,
	    Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From jcm at redhat.com  Thu Oct 11 07:59:52 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 11 Oct 2007 03:59:52 -0400
Subject: should readahead allow generic paths?
Message-ID: <1192089592.6478.36.camel@jcmlaptop>

Yo,

Seems to me that it'd be more useful if the readahead package
configuration files (default/later) could use wildcards for path
components such as firefox, python, etc. (so that you don't have quite
the disconnect/lock-step requirement between these packages).

Is there a reason why it's hard wired?

Jon.




From szaka at ntfs-3g.org  Thu Oct 11 08:19:02 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Thu, 11 Oct 2007 11:19:02 +0300 (EEST)
Subject: better install experience
In-Reply-To: <1192088681.6070.3.camel@localhost.localdomain>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
	<1192088681.6070.3.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.62.0710111109090.27551@tamago.serverit.net>


On Thu, 11 Oct 2007, Lubomir Kundrak wrote:
> On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> 
> > NTFS FILESYSTEM
> 
> Come on, NTFS is soooo 90's ;)

Actually its root is in the 70's (FILES-11) but it was a bit 
over[re]designed in the 90's for the [0...]0's.
 
> Lubomir Kundrak (Red Hat Security Response Team)

Could please take a quick look at 

	https://bugzilla.redhat.com/show_bug.cgi?id=298651#c21

and explain shortly why you think your advisory is correct, so 
people could avoid similar problems in the future? 

Thank you,
		Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From fedora at camperquake.de  Thu Oct 11 08:43:16 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 11 Oct 2007 10:43:16 +0200
Subject: Merging totem and totem-xine
In-Reply-To: <1192056719.3626.145.camel@cookie.hadess.net>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<470B0E6D.3000606@gmail.com>
	<20071009130752.GA18900@nostromo.devel.redhat.com>
	<loom.20071009T134853-933@post.gmane.org>
	<1191939517.3626.90.camel@cookie.hadess.net>
	<1191964106.23786.9.camel@Diffingo.localdomain>
	<1191965382.3626.108.camel@cookie.hadess.net>
	<1191965532.23786.18.camel@Diffingo.localdomain>
	<20071009191853.3c023603@redhat.com>
	<1191978010.7325.4.camel@Diffingo.localdomain>
	<1191996861.4028.8.camel@localhost.localdomain>
	<1191996974.4028.11.camel@localhost.localdomain>
	<1192053645.19184.2.camel@Diffingo.localdomain>
	<1192056719.3626.145.camel@cookie.hadess.net>
Message-ID: <20071011104316.29b39a1b@banea.int.addix.net>

Hi.

On Wed, 10 Oct 2007 23:51:59 +0100, Bastien Nocera wrote:

> > PS. Doesn't xine-lib itself support DVD menus, just not
> > (css-)encrypted ones?
> 
> No, as there's no MPEG-2 video decoder in Fedora's xine-lib (and if
> there is, it shouldn't be there).

So this isn't about DVD menus at all, but about DVDs in general.



From zprikryl at redhat.com  Thu Oct 11 08:51:55 2007
From: zprikryl at redhat.com (Zdenek Prikryl)
Date: Thu, 11 Oct 2007 10:51:55 +0200
Subject: acpid and logging
In-Reply-To: <1192088974.2517.4.camel@localhost.localdomain>
References: <470CD0A3.2030204@redhat.com>	<200710100933.50936.sgrubb@redhat.com>
	<1192088974.2517.4.camel@localhost.localdomain>
Message-ID: <470DE42B.9050302@redhat.com>

Kjartan Maraas napsal(a):
> I don't see many events per second, but still acpid is flooding syslog:
> 
> [root at localhost log]# tail -f /var/log/messages
> Oct 11 09:42:26 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:42:26 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:42:27 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:42:27 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:42:27 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:42:27 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:42:41 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:42:41 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:42:41 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:42:41 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:43:00 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:43:00 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:43:00 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:43:00 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:43:43 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:43:43 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:43:43 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:43:43 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:44:16 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:44:16 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:44:16 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:44:16 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:44:57 localhost acpid: received event "thermal_zone TZ0 00000081 00000000"
> Oct 11 09:44:57 localhost acpid: notifying client 2001[68:68]
> Oct 11 09:44:57 localhost acpid: notifying client 2145[0:0]
> Oct 11 09:44:57 localhost acpid: completed event "thermal_zone TZ0 00000081 00000000"
> 
> Do we really neew to log all these?

As Steve Grubb wrote, probably the best solution for that is log only messages
with warnings or error priority. Messages above have notify and info priority,
so if acpid is not running with -d as a parameter (in debug mode), then those
messages should not be logged into syslog.

Zdenek



From lkundrak at redhat.com  Thu Oct 11 09:17:19 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 11:17:19 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192084232.4029.3.camel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
Message-ID: <1192094239.6070.20.camel@localhost.localdomain>


On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> 
> > livecd - you can do pkg selection after you're installed 
> 
> And users do not want that. That's the same thing as the "reboot before
> continuing" windows plague

What's wrong with that? You have to reboot anyways.

Well, years ago I heard that Caldera's Linux was able to switch to the
installed system without reboot. SUSE also, if I recall correctly. Not
an option though -- the user can choose kernel (xen v. non-xen at least)
at install time and, well, reboot is a way to verify if boot loader was
installed correctly.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From tsmetana at redhat.com  Thu Oct 11 09:18:49 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Thu, 11 Oct 2007 11:18:49 +0200
Subject: Retiring procinfo
Message-ID: <20071011111849.3e47b20e.tsmetana@redhat.com>

Hello,
  I would like to retire the procinfo package because:

- latest upstream release in 2001
- nobody seems to be actually using it -- it has probably never worked
on 64-bit architectures, under certain circumstances it crashed even on
i386 but I have no bugreport mentioning that (found it myself when
solving the 64-bit problem)

In any case I'd rather ask...  Any objections?

--
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From ian at stams.strath.ac.uk  Thu Oct 11 09:22:15 2007
From: ian at stams.strath.ac.uk (Ian Thurlbeck)
Date: Thu, 11 Oct 2007 10:22:15 +0100
Subject: F9: system wide proxy settings at install
Message-ID: <470DEB47.3050408@stams.strath.ac.uk>


Hi

I was having some issues with firefox on F8t3 today, so I moved
aside my .mozilla directory to re-generate the default setup.
However, firefox wouldn't restart because it's looking for updates or
something and I'm behind a mandatory web proxy/cache.

Copying in my old prefs.js file gets me running again.

I can't tell you how many times I have to set application
specific settings to get past the proxy - wget, php pear, yum, firefox (!),
rkhunter, extra Fedora software during install, etc, etc.

For FC9, how about setting a proxy early in the installer and using this
for all web-using applications ?

I appreciate there are many outstanding requests/bug reports to do with
proxies, so I'm just trying to raise its profile a bit.

Many thanks

Ian
-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



From alan at redhat.com  Thu Oct 11 09:55:45 2007
From: alan at redhat.com (Alan Cox)
Date: Thu, 11 Oct 2007 05:55:45 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D8ED8.9010509@BitWagon.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
Message-ID: <20071011095545.GB19149@devserv.devel.redhat.com>

On Wed, Oct 10, 2007 at 07:47:52PM -0700, John Reiser wrote:
> > 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do
> > installs.
> 
> In the "first world" a DVD burner is $50 or less and a DVD reader is
> $30 or less.  In other places (or if those prices are a serious barrier)

Oh god not this again

Today people still ship new laptops with CD-R/CD-RW drives. Lots of them.
You can't fit a $30 DVD reader to them.

> then share through a user group or a buddy, or postal mail, etc.  Seriously.
> The isolated boxes with no DVD also tend to have anemic network connectivity.

Mine has 100Mbit ethernet, wireless, bluetooth and serial.


We should be shipping a CD set. I consistently see people going to Ubuntu
after asking for a Fedora CD and being told they can't update that way.

Alan



From lemenkov at gmail.com  Thu Oct 11 10:03:56 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Thu, 11 Oct 2007 14:03:56 +0400
Subject: "rpmq: no arguments given for query" message while trying to make
	<anything> in Fedora's CVS tree
Message-ID: <adf480660710110303o7629910aga7a2a142a8c23987@mail.gmail.com>

Hello All!
Since couple of days ago I can't build tag or make anything else in
Fedora's CVS tree. All my attemps ends with message in subj.

Looking with ps aux I fond only this suspicious process:

31470 pts/1    Ss     0:00  \_ /bin/bash
31496 pts/1    S+     0:00      \_ make tag
31576 pts/1    S+     0:00          \_ grep -i ^buildarch:.*noarch

My system is PowerPC-based Mac Mini with Fedora 7 installed.
-- 
With best regards!



From sundaram at fedoraproject.org  Thu Oct 11 10:13:44 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 15:43:44 +0530
Subject: better install experience
In-Reply-To: <470DD6FD.1090309@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>	<1192045121.3261.82.camel@localhost.localdomain>	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>	<1192046031.3261.85.camel@localhost.localdomain>	<470D315B.3070604@leemhuis.info>	<470DD061.4030600@fedoraproject.org>
	<470DD6FD.1090309@leemhuis.info>
Message-ID: <470DF758.9080009@fedoraproject.org>

Thorsten Leemhuis wrote:
> 
> On 11.10.2007 09:27, Rahul Sundaram wrote:
>> Thorsten Leemhuis wrote:
>>
>>> Sure, ntfs-3g is around -- but some people still prefer the in-kernel
>>> driver and it still gets downloaded from a well know 3rd party repo as
>>> kmod a lot.
>> That repo should drop the package ideally.
> 
> I agreed, once there is no user demand for the kmod and once ntfs-3g is
> clearly better.

A lot of people continue to believe old information that Fedora does not 
have any NTFS support and this is the primary reason for them going to 
third party repositories. If end users are aware of better functionality 
in ntfs-3g compared to kmod, the demand would be drastically less.

>> It is confusing end users 
>> into believing that Fedora itself doesn't support NTFS and the FUSE 
>> module in Fedora is way better.
> 
> Yeah, while at it let's drop Gnome from Fedora, KDE is way better.

This is not a meaningful comparison.

Rahul





From carlo.cassinelli at gmail.com  Thu Oct 11 10:23:41 2007
From: carlo.cassinelli at gmail.com (Carlo Cassinelli)
Date: Thu, 11 Oct 2007 12:23:41 +0200
Subject: Bluetooth activation
Message-ID: <dc43962f0710110323p535454bdkd2263a9859ef2975@mail.gmail.com>

I have a thinkpad T43 width fedora 8 test3 installed, and there is a big
bluetooth's bug. The Fn+F5 button to activate/deactivate the interface it
does not work, when the interface is activated before the loading of kernel
the key work, but as soon as the fedora 8 test3 kernel is loaded this key
does not work and the interface cannot be activated.
If the bluetooth is activated before the loading of fedora 8 this works
well, I think it is not a problem of bluez but of the kernel.
I have last kernel and the all system is up to date.

Sorry for my english.

Solutions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/c599899b/attachment.htm>

From buc at odusz.so-cdu.ru  Thu Oct 11 10:43:04 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 11 Oct 2007 14:43:04 +0400
Subject: rsync license change
In-Reply-To: <1192055258.27891.4.camel@localhost.localdomain>
References: <1192054064.27891.1.camel@localhost.localdomain>
	<1192055258.27891.4.camel@localhost.localdomain>
Message-ID: <470DFE38.1010003@odu.neva.ru>

Simo Sorce wrote:
> On Wed, 2007-10-10 at 18:07 -0400, Simo Sorce wrote:
>   
>> Rsync has changed it's license from GPLv2+ to GPLv3+
>> The license change affects version 3.0.0 (still a pre-release now).
>> In F-8 we will still have 2.6.9 so the change affects F-9
>>     
>
> Btw,
> the rsync package provides just one binary and no libraries so there is
> no license dependency problem.
> Also the package itself uses just 2 system libraries (libacl, libpopot)
>   

Hmm... and what about "libattr" as well?


~buc



From nicolas.mailhot at laposte.net  Thu Oct 11 11:10:27 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 13:10:27 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192094239.6070.20.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
Message-ID: <42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 11:17, Lubomir Kundrak a ?crit :
>
> On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
>> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
>>
>> > livecd - you can do pkg selection after you're installed
>>
>> And users do not want that. That's the same thing as the "reboot
>> before
>> continuing" windows plague
>
> What's wrong with that? You have to reboot anyways.

It's user-unfriendly. People want to configure their install, press
go, and walk away do other stuff while the install proceeds.

Any install process that alternates computer-work with human-work
instead of grouping human work in a single continuous phase is bad.

-- 
Nicolas Mailhot



From cmadams at hiwaay.net  Thu Oct 11 11:14:43 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 11 Oct 2007 06:14:43 -0500
Subject: samba license change
In-Reply-To: <470DBD01.30603@hhs.nl>
References: <loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
	<1192051876.26017.45.camel@localhost.localdomain>
	<20071010235754.GA1083997@hiwaay.net> <470DBD01.30603@hhs.nl>
Message-ID: <20071011111443.GA1324613@hiwaay.net>

Once upon a time, Hans de Goede <j.w.r.degoede at hhs.nl> said:
> So you must distribute it together with a GPLv2 licensed samba, so no loop 
> holes here (luckily!).

Okay, so you distribute both the GPLv2 and GPLv3 libraries, with the
GPLv2 version named something like "compat-libsomething".  Then it
depends on which one gets installed as to whether a license violation
occurs.  If you take the case of anaconda (where the shortest package
name "wins" to satisfy the libsomething.so.0 dependency), the GPLv3
library would always be installed.

Or you get crazier and you use the alternatives system; install both and
let the user switch (but have the GPLv3 version the default).

-- 
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 buildsys at redhat.com  Thu Oct 11 11:14:56 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 11 Oct 2007 07:14:56 -0400
Subject: rawhide report: 20071011 changes
Message-ID: <200710111114.l9BBEu2I014145@porkchop.devel.redhat.com>

New package GREYCstoration
	An image denoising and interpolation tool

New package bluecurve-classic-metacity-theme
	Bluecurve Classic metacity theme

New package bluecurve-gdm-theme
	Bluecurve GDM theme

New package bluecurve-gnome-theme
	Bluecurve GNOME theme

New package bluecurve-gtk-themes
	Bluecurve GTK+ theme

New package bluecurve-icon-theme
	Bluecurve icon theme

New package bluecurve-kde-theme
	Bluecurve KDE theme

New package bluecurve-kdm-theme
	Bluecurve KDM theme

New package bluecurve-kwin-theme
	Bluecurve kwin theme

New package bluecurve-metacity-theme
	Bluecurve metacity theme

New package bluecurve-xmms-skin
	Bluecurve xmms skin

New package fedora-gnome-theme
	Fedora GNOME theme

New package fedora-icon-theme
	Fedora icon theme

New package fedora-screensaver-theme
	Fedora screensaver theme

New package fedorabubbles-gdm-theme
	FedoraBubbles GDM theme

New package fedoradna-gdm-theme
	FedoraDNA GDM theme

New package fedoradna-kdm-theme
	FedoraDNA KDM theme

New package fedoraflyinghigh-gdm-theme
	FedoraFlyingHigh GDM theme

New package fedoraflyinghigh-kdm-theme
	Fedora Flying High KDM theme

New package fedorainfinity-gdm-theme
	Fedora Infinity GDM theme

New package fedorainfinity-screensaver-theme
	Fedora Infinity screensaver theme

New package imageinfo
	Extract attributes of digital images

New package nget
	Command line NNTP file grabber

New package php-pear-creole
	A database abstraction layer for PHP5

New package xgrep
	A grep-like utility for XML files


Removed package redhat-artwork

Updated Packages:

Maelstrom-3.0.6-14
------------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> 3.0.6-14
- rebuild for buildid

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

NetworkManager-1:0.7.0-0.3.svn2970.fc8
--------------------------------------
* Wed Oct 10 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2970
- Fix segfault with deferred connections
- Fix default username with vpnc VPN plugin
- Hidden SSID fixes

NetworkManager-vpnc-1:0.7.0-0.2.svn2970.fc8
-------------------------------------------
* Wed Oct 10 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.2.svn2970
- Fix default username

OpenIPMI-2.0.11-3.fc8
---------------------
* Wed Oct 10 2007 Phil Knirsch <pknirsch at redhat.com> - 2.0.11-3
- Added missing perl-devel buildrequires

* Mon Sep 24 2007 Phil Knirsch <pknirsch at redhat.com> - 2.0.11-2
- Added missing popt-devel buildrequires

anaconda-11.3.0.38-1
--------------------
* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.38-1
- Copy over modprobe.conf from live system 
- Don't traceback with unconfigured nics (#325071)
- Disable selinux on upgrades if the user has booted with selinux=0 (#242510)
- More speedups building stage2 images (Orion Poplawski)
- Fix some translations (#322681)

apcupsd-3.14.2-1.fc8
--------------------
* Wed Oct 10 2007 - Orion Poplawski <orion at cora.nwra.com> - 3.14.2-1
- Update to 3.14.2, remove upstreamed patches

autobuild-applet-1.0.3-4.fc8
----------------------------
* Wed Oct 10 2007 Daniel P. Berrange <dan at berrange.com> 1.0.3-4.fc8
- Rebuild for pick up build ID from new compiler toolchain

bluez-gnome-0.14-8.fc8
----------------------
* Wed Oct 10 2007 - Bastien Nocera <bnocera at redhat.com> - 0.14-8
- Require gnome-vfs2-obexftp, so that the functionality works
  as expected (#326231)

booty-0.89-1.fc8
----------------
* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> - 0.89-1
- fix setting up dual-boot by not calling a function which no longer 
  exists from isys (#322401)

* Wed Aug 08 2007 Peter Jones <pjones at redhat.com> - 0.88-1
- Cleanup patch (from Shandy Brown)

bouml-2.32-1.fc8
----------------
* Thu Oct 11 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.32-1
- Version bump to 2.32. Closes Red Hat Bugzilla bug #303721.

* Wed Oct 03 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.31.3-1
- Version bump to 2.31.3. Closes Red Hat Bugzilla bug #292541.

* Fri Sep 14 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.31.2-1
- Version bump to 2.31.2. Closes Red Hat Bugzilla bug #286661.

codeina-0.10.1-4.fc8
--------------------
* Wed Oct 10 2007 - Bastien Nocera <bnocera at redhat.com> - 0.10.1-4
- Remove some useless verbose (#325301)

compiz-0.6.0-1.fc8
------------------
* Wed Oct 10 2007 Warren Togami <wtogami at redhat.com> - 0.6.0-1
- 0.6.0 final
- always-restack-windows-on-map

compiz-fusion-0.5.2-9.09b700.fc8
--------------------------------
* Wed Oct 10 2007 Warren Togami <wtogami at redhat.com> 0.5.2-9.09b700
- >= instead of = to allow compiz upgrade flexibility

* Sun Sep 23 2007 Adel Gadllah <adel.gadllag at gmail.com> 0.5.2-8.09b700
- Fix changelog date

* Sat Sep 22 2007 Adel Gadllah <adel.gadllag at gmail.com> 0.5.2-7.09b700
- Update to 0.6 branch (builds against current compiz)

compiz-fusion-extras-0.5.2-8.6871d0.fc8
---------------------------------------
* Wed Oct 10 2007 Warren Togami <wtogami at redhat.com> 0.5.2-8.6871d0
- >= instead of = to allow compiz upgrade flexibility

cups-1:1.3.3-3.fc8
------------------
* Wed Oct 10 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.3-3
- Use ppdev instead of libieee1284 for parallel port Device ID
  retrieval (bug #311671).  This avoids SELinux audit messages.

dirac-0.8.0-2.fc8
-----------------
* Wed Oct 10 2007 kwizart < kwizart at gmail.com > - 0.8.0-2
- Fix perms

* Wed Oct 10 2007 kwizart < kwizart at gmail.com > - 0.8.0-1
- Update to 0.8.0

dkms-2.0.17.5-1.fc8
-------------------
* Wed Oct 10 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.17.5
- call udevtrigger if we install a module for the currently running kernel
- uninstall from /extra before DEST_MODULE_LOCATION (Red Hat BZ#264981)
- Run depmod after uninstall

esmtp-0.6.0-1.fc8
-----------------
* Wed Oct 10 2007 Patrice Dumas <pertusus at free.fr> 0.6.0-1
- update to 0.6.0

fedora-logos-7.94.0-1.fc8
-------------------------
* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 7.94.0-1
- drop bluecurve gdm fedora logo images that aren't trademarked

* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 7.93.0-1
- Install fedora 7 logo in the right place

fedora-release-7.92-2
---------------------
* Wed Oct 10 2007 Jesse Keating <jkeating at redhat.com> - 7.92-2
- Add gpg info to development repos

* Fri Sep 28 2007 Jesse Keating <jkeating at redhat.com> - 7.92-1
- Bump for F8 Test2.
- Package up the compose kickstart files

* Fri Sep 14 2007 Jesse Keating <jkeating at redhat.com> - 7.91-2
- Use failovermethod=priority in yum configs (243698)

firstboot-1.4.38-1.fc8
----------------------
* Wed Oct 10 2007 Chris Lumens <clumens at redhat.com> 1.4.38-1
- Remove redundant password length check (#296651).
- Rename sr at Latn.po to sr at latin.po (#312431).

gdb-6.6-32.fc8
--------------
* Wed Oct 10 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-32
- Fix debug load for sparse assembler files (such as vDSO32 for i386-on-x86_64).
- Fix a TUI visual corruption due to the build-id warnings (BZ 320061).
- Fixed the kernel i386-on-x86_64 VDSO loading (producing `Lowest section in').

* Fri Oct 05 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-31
- Fix address changes of the ctors/dtors breakpoints w/multiple PCs (BZ 301701).
- Delete an info doc file on `rpmbuild -bp' later rebuilt during `rpmbuild -bc'.

* Tue Sep 25 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-30
- Fix re-setting of the ctors/dtors breakpoints with multiple PCs (BZ 301701).
- Avoid one useless user question in the core files locator (build-id).

glade2-2.12.1-10.fc8
--------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-10
- Rebuild

glibc-2.6.90-18
---------------
* Wed Oct 10 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-18
- add signalfd, eventfd, eventfd_read, eventfd_write
- qsort speedups
- workaround for cpuid bugs (#324081)
- make sure gettext's conversion_lock is initialized even if
  program isn't linked against libpthread.so.0, only dlopens it (#321761)
- misc fixes (BZ#5112, BZ#5113, BZ#5104, BZ#5063, BZ#5010, BZ#4407,
  BZ#3924, BZ#5103, BZ#2633, BZ#181, BZ#73, #321901)

gnome-media-2.20.1-2.fc8
------------------------
* Wed Oct 10 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Install the schema for the mixer properly (#186791)

* Wed Sep 19 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-1
- Update to 2.20.1
- Remove obsolete icons patch

gnome-pilot-conduits-2.0.15-4.fc8
---------------------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-4.fc8
- Rebuild

gnome-screensaver-2.20.0-8.fc8
------------------------------
* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-8
- Require the appropriate artwork (bug 327161)

* Fri Oct 05 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-7
- fix up gamma handling, patch by John Bryant (should fix 290611)

* Fri Sep 28 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-6
- Use small bullets in the password entry

gnome-spell-1.0.7-6.fc8
-----------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 1.0.7-6.fc8
- Rebuild

* Sat Apr 21 2007 Matthias Clasen <mclasen at redhat.com> - 1.0.7-5
- Don't install INSTALL

gnome-vfs2-monikers-2.15.3-4.fc8
--------------------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 2.15.3-4
- Rebuild
- Update license field
gnucash-2.2.1-3.fc8
-------------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> - 2.2.1-3
- silence binreloc warning
gtk-vnc-0.2.0-4.fc8
-------------------
* Wed Oct 10 2007 Daniel P. Berrange <berrange at redhat.com> - 0.2.0-4.fc8
- Fixed coroutine cleanup to avoid SEGV (rhbz #325731)

gtkspell-2.0.11-4.fc8
---------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.11-4.fc8
- Rebuild

gurlchecker-0.10.1-4.fc8
------------------------
* Tue Oct 09 2007 Arindam Ghosh <makghosh AT gmail DOT com> - 0.10.1-4
- Minor changes in %doc

* Fri Oct 05 2007 Arindam Ghosh <makghosh AT gmail DOT com> - 0.10.1-3
- Fixed build requires
- Removed redundant requires
- Added INSTALL option in make tag
- Desktop file install added
- Rebuild
- Bump release

gweled-0.7-9.1
--------------
* Fri Aug 03 2007 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info>
- Update License field due to the "Licensing guidelines changes"

* Thu Apr 19 2007 Thorsten Leemhuis <fedora[AT]leemhuis.info> - 0.7-9
- remove dist in devel
- rebuild for new mikmod

gwenhywfar-2.6.1-2.fc8
----------------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> - 2.6.1-2
- fix build, rebuild for buildid

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

* Wed Jul 11 2007 Bill Nottingham <notting at redhat.com> - 2.6.1-1
- update to 2.6.1

jed-0.99.18-6.fc8
-----------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> - 0.99.18-6
- rebuild for buildid

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

kernel-2.6.23-5.fc8
-------------------
* Wed Oct 10 2007 John W. Linville <linville at redhat.com>
- fix scanning for hidden SSID w/ NetworkManager

* Wed Oct 10 2007 Dave Jones <davej at redhat.com>
- Update highres timers patch to latest upstream (2.6.23-hrt1)

* Wed Oct 10 2007 Chuck Ebbert <cebbert at redhat.com>
- Fix date/time printed during boot.
- Port ACPI suspend/resume fixes to cpuidle.

kernel-xen-2.6-2.6.21-2949.fc8
------------------------------
* Wed Oct 10 2007 Eduardo Habkost <ehabkost at redhat.com>
- Remove bogus WARN_ON() from synchronize_irq() (bug #293451)

ldns-1.2.1-1.fc8
----------------
* Wed Oct 10 2007 Paul Wouters <paul at xelerance.com> - 1.2.1-1
- Updated to 1.2.1
- Removed patches that got moved into upstream

* Wed Aug 08 2007 Paul Wouters <paul at xelerance.com> 1.2.0-11
- Patch for ldns-key2ds to write to stdout
- Again remove extra set of man pages from doc
- own /usr/include/ldns (bug 233858)

libX11-1.1.3-2.fc8
------------------
* Wed Oct 10 2007 Adam Jackson <ajax at redhat.com> 1.1.3-2
- libX11-1.1.3-xkb-lock-fix.patch: Don't LockDisplay() recursively.  Fixes
  Gnome hang at logout. (#326461)

libburn-0.3.8-2.fc8
-------------------
* Wed Oct 10 2007 Jesse Keating <jkeating at redhat.com> - 0.3.8-2
- Rebuild for BuildID

libcroco-0.6.1-3.fc8
--------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 0.6.1-3
- Rebuild
- Update license tag

libgnome-2.20.0-3.fc8
---------------------
* Tue Sep 18 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-3
- Add Requires: fedora-gnome-theme

* Tue Sep 18 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-2
- the location of the default background setting changed, 
  update correct schema input file

libgnomecups-0.2.2-11.fc8
-------------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 0.2.2-11
- Rebuild

* Tue Aug 07 2007 Matthias Clasen <mclasen at redhat.com> - 0.2.2-10
- Update license field

* Sat Apr 21 2007 Matthias Clasen <mclasen at redhat.com> - 0.2.2-9
- Don't ship static libraries
- Small spec file cleanups

libisofs-0.2.8-2.fc8
--------------------
* Wed Oct 10 2007 Jesse Keating <jkeating at redhat.com> - 0.2.8-2
- Rebuild for BuildID

libnotify-0.4.4-8.fc8
---------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 0.4.4-8
- Rebuild

* Tue Aug 07 2007 Matthias Clasen <mclasen at redhat.com> - 0.4.4-7
- Update licence field

libofx-0.8.3-4
--------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> - 0.8.3-4
- rebuild for buildid

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

libuser-0.56.5-1
----------------
* Thu Oct 11 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.5-1
- Work around spurious error messages when run against the Fedora Directory
  server
- Fix error reporting when creating home directories and creating/removing mail
  spool files
  Resolves: #318121

logwatch-7.3.6-8.fc8
--------------------
* Wed Oct 10 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-8
- add secure service patch

* Wed Oct 10 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-7
- add cron service patch
- add pam-unix service patch

man-pages-it-0.3.0-17.2
-----------------------
* Wed Oct 10 2007 Ding-Yi Chen <dchen at redhat.com> - 0.3.0-17.2
- Bugzilla Bug 236116: Unsupported programs in man-pages-it
- remove celibacy.1 and sex.6

nautilus-sendto-0.12-3.fc8
--------------------------
* Wed Oct 10 2007 Matthias Clasen <mclasen at redhat.com> - 0.12-3
- Rebuild

ncurses-5.6-11.20070812.fc8
---------------------------
* Wed Oct 10 2007 Miroslav Lichvar <mlichvar at redhat.com> 5.6-11.20070812
- don't write beyond field buffer in form driver (#310071)

nspluginwrapper-0.9.91.5-6.fc8
------------------------------
* Wed Oct 10 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-6
- removed possibble deadlock during plugin restart

pycairo-1.4.0-2.fc8
-------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 1.4.0-2.fc7
- Rebuild

pyorbit-2.14.3-1.fc8
--------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 2.14.3-1.fc8
- Update to 2.14.3

python-ldap-0:2.3.1-1.fc8
-------------------------
* Wed Oct 10 2007 Matthew Barnes <mbarnes at redhat.com> - 0:2.3.1-1.fc8
- Update to 2.3.1

python-urlgrabber-3.0.0-3.fc8
-----------------------------
* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> - 3.0.0-3
- fix type checking of strings to also include unicode strings; fixes 
  regets from yum (#235618)

squirrelmail-1.4.11-1.fc8
-------------------------
* Wed Oct 10 2007 Martin Bacovsky <mbacovsk at redhat.com> - 1.4.11-1
- upgrade to new upstream 1.4.11

system-config-soundcard-2.0.6-11.fc8
------------------------------------
* Wed Oct 10 2007 Martin Stransky <stransky at redhat.com> - 2.0.6-11
- fixed #319151 - Wrong button ordering
- Updated license tag

sysvinit-2.86-18
----------------
* Wed Oct 10 2007 Bill Nottingham <notting at redhat.com> - 2.86-18
- rebuild for buildid

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

tcptraceroute-1.5-0.4.beta7.fc8
-------------------------------

tog-pegasus-2:2.6.1-2.fc8
-------------------------
* Tue Oct 09 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2.6.1-2
- Fix files permissions
  Resolves: #200906

traceroute-3:2.0.9-1.fc8
------------------------
* Wed Oct 10 2007 Martin Bacovsky <mbacovsk at redhat.com> - 3:2.0.9-1
- upgrade to new upstream traceroute-2.0.9

twinkle-1.1-3.fc8
-----------------
* Wed Oct 10 2007 Kevin Fenzi <kevin at tummy.com> - 1.1-3
- Rebuild for BuilID

udev-115-5.20070921git.fc8
--------------------------
* Wed Oct 10 2007 Harald Hoyer <harald at redhat.com> 115-5.20070921git
- better modprobe options for the kernel command line 'modprobedebug' option

xen-3.1.0-12.fc8
----------------
* Wed Oct 10 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-12.fc8
- Pull in QEMU BIOS boot menu patch from KVM package
- Fix QEMU patch for locating x509 certificates based on command line args
- Add XenD config options for TLS x509 certificate setup

* Wed Sep 26 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-11.fc8
- Fixed rtl8139 checksum calculation for Vista (rhbz #308201)

xorg-x11-drv-nv-2.1.5-2.fc8
---------------------------
* Thu Oct 11 2007 Dave Airlie <airlied at redhat.com> 2.1.5-2
- nouveau-fix-bswap32.patch - fix nouveau driver on ppc/ppc64

yum-3.2.6-3.fc8
---------------
* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> - 3.2.6-3
- pull in upstream fixes for obsoletes to not pull in extra arches (#301661),
  expose key fingerprint in callback and to remove a debug message

* Mon Oct 08 2007 Seth Vidal <skvidal at fedoraproject.org> 3.2.6-2
- fixes pre-3.2.7

* Fri Oct 05 2007 Seth Vidal <skvidal at fedoraproject.org> 3.2.6-1
- 3.2.6 
- remove all old patches

yum-updatesd-1:0.6-1.fc8
------------------------
* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> - 1:0.6-1
- add lsb initscript header (#247106)
- overly simplistic service start speed-up

zynaddsubfx-2.2.1-17.fc8
------------------------
* Wed Oct 10 2007 Fernando Lopez-Lezcano <nando at ccrma.stanford.edu> 2.2.1-17
- added tweaked unzombify patch by Lars Luthman (patch3), see:
  http://sourceforge.net/tracker/index.php?func=detail&aid=1498438&group_id=62934&atid=502314

Broken deps for i386
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.i386 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	ntfs-config - 1.0-0.4.rc5.fc8.noarch requires redhat-artwork
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.x86_64 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	ntfs-config - 1.0-0.4.rc5.fc8.noarch requires redhat-artwork
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.ppc requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	ntfs-config - 1.0-0.4.rc5.fc8.noarch requires redhat-artwork
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	icewm - 1.2.32-4.fc8.ppc64 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	ntfs-config - 1.0-0.4.rc5.fc8.noarch requires redhat-artwork
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From mclasen at redhat.com  Thu Oct 11 11:15:24 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 11 Oct 2007 07:15:24 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <45abe7d80710102055t7eb29314rc26008b93897acac@mail.gmail.com>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<1192029636.26943.20.camel@raptor.sr.unh.edu>
	<45abe7d80710102055t7eb29314rc26008b93897acac@mail.gmail.com>
Message-ID: <1192101324.2571.0.camel@localhost.localdomain>


On Wed, 2007-10-10 at 23:55 -0400, Ray Strode wrote:
> Hi,
> 
> > I tracked this down more and it happens with metacity too on my intel
> > graphics laptop. After logging out, if I go to a text console and kill
> > just gnome-session, the logout finishes and gdm comes back up.
> >
> > Does this "fix" work for anyone else having the problem? It seems that
> > since this apparently is not happening for everyone, it must be
> > something I'm running that causes gnome-session to hang. I checked and
> > pulseaudio is not running so I'm don't think it is the culprit.
> 
> Do you have vino ("Remote Desktop") installed ?  I think there's a bug
> on one of the F8 tracker lists that mentions some weird interaction
> between vino and gnome-session on logout.  I haven't looked into it
> yet.
> 

That should be fixed in todays libX11.



From mclasen at redhat.com  Thu Oct 11 11:18:56 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 11 Oct 2007 07:18:56 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192084232.4029.3.camel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
Message-ID: <1192101536.2571.3.camel@localhost.localdomain>


On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> 
> > livecd - you can do pkg selection after you're installed 
> 
> And users do not want that. That's the same thing as the "reboot before
> continuing" windows plague

Just saying that its the same does not make it the same. 
You are not going to get an install/upgrade without a single reboot. 



From nicolas.mailhot at laposte.net  Thu Oct 11 11:30:31 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 13:30:31 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192101536.2571.3.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192101536.2571.3.camel@localhost.localdomain>
Message-ID: <31210.192.54.193.51.1192102231.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 13:18, Matthias Clasen a ?crit :
>
> On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
>> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
>>
>> > livecd - you can do pkg selection after you're installed
>>
>> And users do not want that. That's the same thing as the "reboot
>> before
>> continuing" windows plague
>
> Just saying that its the same does not make it the same.

It makes it exactly the same since reboot is needed before continuing
and human interaction is needed both before and after the reboot

> You are not going to get an install/upgrade without a single reboot.

But you can group all the long and annoying computer stuff phases so
users don't have to attend through them.

-- 
Nicolas Mailhot



From simon.andrews at bbsrc.ac.uk  Thu Oct 11 11:31:41 2007
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Thu, 11 Oct 2007 12:31:41 +0100
Subject: F9: system wide proxy settings at install
In-Reply-To: <470DEB47.3050408@stams.strath.ac.uk>
References: <470DEB47.3050408@stams.strath.ac.uk>
Message-ID: <fel1iu$ui2$1@sea.gmane.org>

Ian Thurlbeck wrote:
> 
> For FC9, how about setting a proxy early in the installer and using this
> for all web-using applications ?

As someone else who sits behind a compulsory proxy I'd second any 
request to improve proxy support in Fedora and would be happy to help 
out to make this happen.

However, the problem could end up being quite complex.  Lots of programs 
  (eg firefox) have their own proxy settings and sorting all of these 
out won't be trivial.

The other problem is that a proxy isn't forever!  If I take my laptop 
and stick it on a wireless network I don't want it trying to contact my 
work's proxy server.

A previous suggestion (ages ago and not by me) was to set up a local 
proxy on the machine and make all applications use that.  You'd then use 
Network Manager to manipulate the local proxy to pass through the 
appropriate proxy for whichever connection you were currently using. 
Isn't this similar to what is currently done for DNS services through 
Network Manager?  It does smell a bit like a kludge though...

Simon.



From asric at asric.com  Thu Oct 11 11:38:44 2007
From: asric at asric.com (Steven R. Ringwald)
Date: Thu, 11 Oct 2007 04:38:44 -0700
Subject: Retiring procinfo
In-Reply-To: <20071011111849.3e47b20e.tsmetana@redhat.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>

-----Original Message-----
From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Tom?? Smetana
Sent: Thursday, October 11, 2007 2:19 AM
To: fedora-devel-list at redhat.com
Subject: Retiring procinfo

Hello,
  I would like to retire the procinfo package because:

- latest upstream release in 2001
- nobody seems to be actually using it -- it has probably never worked
on 64-bit architectures, under certain circumstances it crashed even on
i386 but I have no bugreport mentioning that (found it myself when
solving the 64-bit problem)

In any case I'd rather ask...  Any objections?

--
I use procinfo all the time, on PPC32, Intel64, and Intel32 machines (all running F7). In the past, I have used it on AMD64 machines running FC5. I am not sure if there is anything else out there that fits the niche that this handy little application does, especially if you are monitoring interrupt usage. I have never had procinfo *crash*, though I have had it display unexpected results in the past. I would vote against removing it, but I am just one user, and could probably get by running a script across /proc/interrupts.

My $0.02.

Steve





From j.w.r.degoede at hhs.nl  Thu Oct 11 11:45:09 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 11 Oct 2007 13:45:09 +0200
Subject: samba license change
In-Reply-To: <20071011111443.GA1324613@hiwaay.net>
References: <loom.20071010T162828-161@post.gmane.org>	<1192040623.26017.24.camel@localhost.localdomain>	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>	<1192045676.23415.1.camel@rousalka.dyndns.org>	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>	<1192049742.3065.101.camel@vespa.kabelta.loc>	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>	<1192051876.26017.45.camel@localhost.localdomain>	<20071010235754.GA1083997@hiwaay.net>
	<470DBD01.30603@hhs.nl> <20071011111443.GA1324613@hiwaay.net>
Message-ID: <470E0CC5.5000501@hhs.nl>

Chris Adams wrote:
> Once upon a time, Hans de Goede <j.w.r.degoede at hhs.nl> said:
>> So you must distribute it together with a GPLv2 licensed samba, so no loop 
>> holes here (luckily!).
> 
> Okay, so you distribute both the GPLv2 and GPLv3 libraries, with the
> GPLv2 version named something like "compat-libsomething".  Then it
> depends on which one gets installed as to whether a license violation
> occurs.  If you take the case of anaconda (where the shortest package
> name "wins" to satisfy the libsomething.so.0 dependency), the GPLv3
> library would always be installed.
> 
> Or you get crazier and you use the alternatives system; install both and
> let the user switch (but have the GPLv3 version the default).
> 

Or you honor not only the letter but also the spirit of the license and link 
GPLv2 only software to the GPLv2 one and GPLv3 software to the GPLv3 one. Yes 
this would require a different soname. I would like to suggest 
libsmbclient-gplv2.so.0 . This would need to be in a new package and once this 
package is in the build-root, kde and other packages which are causing this 
pain (IMHO kde is causing the pain here, not samba) would then need to be build 
against this before samba gets updated to the GPLv3 version.

Regards,

Hans




From lkundrak at redhat.com  Thu Oct 11 12:14:53 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 14:14:53 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
Message-ID: <1192104893.6070.26.camel@localhost.localdomain>


On Thu, 2007-10-11 at 13:10 +0200, Nicolas Mailhot wrote:
> Le Jeu 11 octobre 2007 11:17, Lubomir Kundrak a ?crit :
> >
> > On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> >> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> >>
> >> > livecd - you can do pkg selection after you're installed
> >>
> >> And users do not want that. That's the same thing as the "reboot
> >> before
> >> continuing" windows plague
> >
> > What's wrong with that? You have to reboot anyways.
> 
> It's user-unfriendly. People want to configure their install, press
> go, and walk away do other stuff while the install proceeds.

Every activity that deals with computers consists of user actions and
waiting for a computer to finish a task, and then action again, etc. The
software just have to balance the extent this happens to depending on
complexity of possible software solutions and available hardware.

This already happens. Avoiding possible ugly solutions, the users with
sufficient hardware (DVD media and reader for it) are able to install it
more comfortably than ones that install from Live media or minimal
install CDs. That's perfect.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lkundrak at redhat.com  Thu Oct 11 12:21:53 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 14:21:53 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071011095545.GB19149@devserv.devel.redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
Message-ID: <1192105313.6070.30.camel@localhost.localdomain>


On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
> We should be shipping a CD set. I consistently see people going to Ubuntu
> after asking for a Fedora CD and being told they can't update that way.

+1 Exactly this. We should pick packages for an installation that fits
in 1CD. Is anyone already working on a one CD spin, or interested in
working on it?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From debarshi.ray at gmail.com  Thu Oct 11 12:25:36 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 11 Oct 2007 17:55:36 +0530
Subject: Retiring procinfo
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
Message-ID: <3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>

>>   I would like to retire the procinfo package because:
>>
>> [...]
>>
>> In any case I'd rather ask...  Any objections?

> I use procinfo all the time, on PPC32, Intel64, and Intel32 machines
>
> [...]
>
> I would vote against removing it

Tomas, if you intend to orphan procinfo and not retire it, I am
willing to take it over if no one else is interested or has problems
with me taking it. :-)

Happy hacking,
Debrashi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sundaram at fedoraproject.org  Thu Oct 11 12:27:13 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 17:57:13 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192105313.6070.30.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
Message-ID: <470E16A1.8030501@fedoraproject.org>

Lubomir Kundrak wrote:
> On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
>> We should be shipping a CD set. I consistently see people going to Ubuntu
>> after asking for a Fedora CD and being told they can't update that way.
> 
> +1 Exactly this. We should pick packages for an installation that fits
> in 1CD. Is anyone already working on a one CD spin, or interested in
> working on it?

If you just want a single CD installation, you can use the installable 
Live CD (x86)

Rahul



From cmadams at hiwaay.net  Thu Oct 11 12:28:54 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 11 Oct 2007 07:28:54 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192105313.6070.30.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
Message-ID: <20071011122853.GC1324613@hiwaay.net>

Once upon a time, Lubomir Kundrak <lkundrak at redhat.com> said:
> On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
> > We should be shipping a CD set. I consistently see people going to Ubuntu
> > after asking for a Fedora CD and being told they can't update that way.
> 
> +1 Exactly this. We should pick packages for an installation that fits
> in 1CD. Is anyone already working on a one CD spin, or interested in
> working on it?

What about using the LiveCD package set?  Would that set of packages
plus the regular installer fit as a minimal install/upgrade CD?
-- 
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 mk at crc.dk  Thu Oct 11 12:42:02 2007
From: mk at crc.dk (Mogens Kjaer)
Date: Thu, 11 Oct 2007 14:42:02 +0200
Subject: Retiring procinfo
In-Reply-To: <20071011111849.3e47b20e.tsmetana@redhat.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
Message-ID: <470E1A1A.7090408@crc.dk>

Tom?? Smetana wrote:
> Hello,
>   I would like to retire the procinfo package because:
> 
> - latest upstream release in 2001
> - nobody seems to be actually using it -- it has probably never worked
> on 64-bit architectures, under certain circumstances it crashed even on
> i386 but I have no bugreport mentioning that (found it myself when
> solving the 64-bit problem)
> 
> In any case I'd rather ask...  Any objections?

One a F7-x86_64:

$ procinfo
Segmentation fault

strace tells me that it occurs while reading /proc/interrupts

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 lkundrak at redhat.com  Thu Oct 11 12:43:19 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 14:43:19 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470E16A1.8030501@fedoraproject.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
Message-ID: <1192106599.6070.32.camel@localhost.localdomain>


On Thu, 2007-10-11 at 17:57 +0530, Rahul Sundaram wrote:
> Lubomir Kundrak wrote:
> > On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
> >> We should be shipping a CD set. I consistently see people going to Ubuntu
> >> after asking for a Fedora CD and being told they can't update that way.
> > 
> > +1 Exactly this. We should pick packages for an installation that fits
> > in 1CD. Is anyone already working on a one CD spin, or interested in
> > working on it?
> 
> If you just want a single CD installation, you can use the installable 
> Live CD (x86)

Well, and if I want to upgrade?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicolas.mailhot at laposte.net  Thu Oct 11 12:50:45 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 14:50:45 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192104893.6070.26.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
	<1192104893.6070.26.camel@localhost.localdomain>
Message-ID: <36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 14:14, Lubomir Kundrak a ?crit :
>
> On Thu, 2007-10-11 at 13:10 +0200, Nicolas Mailhot wrote:
>> Le Jeu 11 octobre 2007 11:17, Lubomir Kundrak a ?crit :
>> >
>> > On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
>> >> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
>> >>
>> >> > livecd - you can do pkg selection after you're installed
>> >>
>> >> And users do not want that. That's the same thing as the "reboot
>> >> before continuing" windows plague
>> >
>> > What's wrong with that? You have to reboot anyways.
>>
>> It's user-unfriendly. People want to configure their install, press
>> go, and walk away do other stuff while the install proceeds.
>
> Every activity that deals with computers consists of user actions and
> waiting for a computer to finish a task, and then action again, etc.
> The
> software just have to balance the extent this happens to depending on
> complexity of possible software solutions and available hardware.

Err, I'm sorry but the guy who wrote the MS installer could have
answered the same as you.

-- 
Nicolas Mailhot



From szaka at ntfs-3g.org  Thu Oct 11 12:51:27 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Thu, 11 Oct 2007 15:51:27 +0300 (EEST)
Subject: better install experience
Message-ID: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>


On 10/10/2007, Christopher Brown wrote:
>     On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
>
> >    There are two ntfs implementations. One is old, crufted, and poorly
> >    maintained.
>
> Sorry but that is bullshit. Old and crufted aren't very good technical 

As I mentioned previously, the kernel driver and ntfs-3g have the same 
source base. When I developed ntfs-3g then I noted the potentially serious 
problems in the kernel (e.g. in truncate). I also mentioned them to Dave 
Jones. I never got a reply for any of my emails. Recently a buffer overflow 
was discovered (Andrew Morton fixed it), driver hangs during logfile reset 
(maintainer made a patch).

It seems as the kernel evolves, the kernel NTFS driver isn't adjusted as 
Miklos Szeredi does for the FUSE kernel module, so the kernel side of the 
NTFS-3G driver can stay safe, deadlock and corruption free, no need to 
worry about it. He is also extremely responsive both design and 
troubleshooting discussions and quality coding wise. He is employed by 
Novell and allowed to work on FUSE in a certain amount of his work time.

> arguments and poorly maintained is simply untrue. 

The maintainer has been working for a non-Linux company since 2005 and from 
that point his open source contribution and leadership role is minimal. 
I've worked with him 4 years when it was decided finally a year ago that a 
partial fork is needed to ensure driver reliability and maintainability.

For example we (linux-ntfs team at that time) were reported that some ntfs 
utilities made Vista unbootable. The reason was found and fixed a year ago, 
still the official bugfix was released only 10 days ago. The serious fix 
was sitting in the CVS for a year.

Obviously everybody thinks differently what is "poorly maintained". For me 
the above is one sign, amongst several others.

> If this boils down to "It doesn't have write support, bwaaaaaaaah" then 
> "poorly maintained" isn't much of one either. The reason there have been 
> so few git commits is because it works fine in the state that its in and 
> as I explained, the core developer is focused mainly on the new driver 
> which, license debates aside, will be released in about a year.

In 2005, we were offered NTFS code in favour of letting a company use and 
dual licence what we have developed. Then it became 2006 then the story 
changed a bit then the date was 2007 and then 2008.

>     Dave asked me for my opinion, and I said that we shouldn't ship
>     something that's not recommended by one of its authors, and has no 
>     real maintenance upstream:
>
>     http://ntfs-3g.org/about.html
>
> You're taking that from Szaka's mouth

Please rephrase it better and I'll happily update the page if you're right. 
As long as it's correct, I really don't care how the info is on the page.

> who spat the dummy and went off and created ntfs-3g when he could have 
> merged it with ntfsprogs.

Here is my original announcement:

http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.21.0607141859080.31588-100000%40mlf.linux.rulez.org

I did the work as a long time Linux-NTFS project member. There wasn't 
__anything__ to merge. The work itself was Linux-NTFS, so in fact I __did__ 
merge it when I published it. The code could have been just used without 
any change. I was the only one working on write support and there wasn't 
really anything to merge with because they were already included.

After two-three months later the project still wasn't going the way it 
should have hereby the fork was made. 

> It actually has nothing to do with the kernel driver.

As I wrote, it has quite a lot, in fact.

	Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From ssorce at redhat.com  Thu Oct 11 12:52:35 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 11 Oct 2007 08:52:35 -0400
Subject: rsync license change
In-Reply-To: <470DFE38.1010003@odu.neva.ru>
References: <1192054064.27891.1.camel@localhost.localdomain>
	<1192055258.27891.4.camel@localhost.localdomain>
	<470DFE38.1010003@odu.neva.ru>
Message-ID: <1192107155.851.1.camel@localhost.localdomain>

On Thu, 2007-10-11 at 14:43 +0400, Dmitry Butskoy wrote:
> Simo Sorce wrote:
> > On Wed, 2007-10-10 at 18:07 -0400, Simo Sorce wrote:
> >   
> >> Rsync has changed it's license from GPLv2+ to GPLv3+
> >> The license change affects version 3.0.0 (still a pre-release now).
> >> In F-8 we will still have 2.6.9 so the change affects F-9
> >>     
> >
> > Btw,
> > the rsync package provides just one binary and no libraries so there is
> > no license dependency problem.
> > Also the package itself uses just 2 system libraries (libacl, libpopot)
> >   
> 
> Hmm... and what about "libattr" as well?

Right, libattr is required by libacl, an is used as well, good catch.

Simo.



From gilboad at gmail.com  Thu Oct 11 12:52:52 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 11 Oct 2007 14:52:52 +0200
Subject: xdg-menu, icewm and bluecurve-icon-theme's missing sym-links.
Message-ID: <1192107172.32192.16.camel@gilboa-work-dev.localdomain>

Hello all,

I'm the maintainer of icewm.
Currently, icewm uses a pyxdg-based script to auto-generate its menus
using the default bluecurve icon theme.
A couple of weeks ago redhat-artwork was broken into a number of sub
packages. All the bluecurve icons were pushed into their own
bluecurve-icon-theme package.
However, the old package contained a number of syn-links that are no
longer included in the new package. (E.g. gnome-terminal.png ->
icon-terminal.png; mozilla-icon.png -> icon-web-browser.png; etc)

Does anyone know if pyxdg is capable of handling the new icon names?
(Read: Attach icon-terminal.png to gnome-terminal, etc)
(My -devel machine is currently dead [vmware problem] so I can really
test it right now)

- Gilboa



From lkundrak at redhat.com  Thu Oct 11 13:05:55 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 11 Oct 2007 15:05:55 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
	<1192104893.6070.26.camel@localhost.localdomain>
	<36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>
Message-ID: <1192107955.6070.37.camel@localhost.localdomain>

Off list; so I don't pollute the list with a personal rant :)

On Thu, 2007-10-11 at 14:50 +0200, Nicolas Mailhot wrote:
> Le Jeu 11 octobre 2007 14:14, Lubomir Kundrak a ?crit :
> >
> > On Thu, 2007-10-11 at 13:10 +0200, Nicolas Mailhot wrote:
> >> Le Jeu 11 octobre 2007 11:17, Lubomir Kundrak a ?crit :
> >> >
> >> > On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> >> >> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> >> >>
> >> >> > livecd - you can do pkg selection after you're installed
> >> >>
> >> >> And users do not want that. That's the same thing as the "reboot
> >> >> before continuing" windows plague
> >> >
> >> > What's wrong with that? You have to reboot anyways.
> >>
> >> It's user-unfriendly. People want to configure their install, press
> >> go, and walk away do other stuff while the install proceeds.
> >
> > Every activity that deals with computers consists of user actions and
> > waiting for a computer to finish a task, and then action again, etc.
> > The
> > software just have to balance the extent this happens to depending on
> > complexity of possible software solutions and available hardware.
> 
> Err, I'm sorry but the guy who wrote the MS installer could have
> answered the same as you.

When I last saw windows, what the installer was doing after the reboot
was essential system configuration. Maybe roughly equivalent to our
firstboot, but that's another story.

This is completly different to selecting additional packages to install.
Most, if not all people install packages to an installed system
(rebooted after install). I really don't know what's the problem with it
-- install a (fairly complete, when it comes to the Live media) system,
reboot and then add a couple of apps you use.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicolas.mailhot at laposte.net  Thu Oct 11 13:26:54 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 15:26:54 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192107955.6070.37.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
	<1192104893.6070.26.camel@localhost.localdomain>
	<36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>
	<1192107955.6070.37.camel@localhost.localdomain>
Message-ID: <26905.192.54.193.51.1192109214.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 15:05, Lubomir Kundrak a ?crit :
> Off list;

Not really :)

> so I don't pollute the list with a personal rant :)

It's not a rant and it's not personal. I'll do it one last time in
pseudo_code

For each install_process
   where install_process=(H1...Hn human intervention)+(C1...Cm
computer processing)

   if interleaved((H1...Hn), (C1...Cn)) then {
      total_required_attended_install = sum(H1...Hn)+sum(C1...Cn) ;
      print("This is user-unfriendly) ;
      return -ENEWUBUNTUUSER ;
      }
   else {
      total_required_attended_install = sum(H1...Hn) ;
      print("Fedora has a nice installer") ;
      return NEWFEDORAUSER ;
   }


-- 
Nicolas Mailhot



From silfreed at silfreed.net  Thu Oct 11 13:29:36 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Thu, 11 Oct 2007 09:29:36 -0400
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <20071011024611.GA12391@nostromo.devel.redhat.com>
References: <470D81BB.2070404@redhat.com>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<20071011024611.GA12391@nostromo.devel.redhat.com>
Message-ID: <200710110929.36551.silfreed@silfreed.net>

On Wednesday 10 October 2007, Bill Nottingham wrote:
> > A minimal
> > upgrade, like editing the repo files and yum update would be nice.
> > Especially if everything worked correctly. ?(I am not saying it
> > doesn't currently, but in the past, it sure didn't). ? Or, could there
> > be a package group like "start here for upgrades" or something? Again,
> > for the more casual linux user, not the system admins.
>
> Some potential upgrade enhancements may be looked at for F9.

I'm very interested in helping improve the upgrade situation (and 
especially "online upgrades").  Several of us had a good chat in 
#fedora-devel last week about it; I still haven't got around to writing up 
that summary, but it's still on the radar.

-Doug
-------------- 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/20071011/fafb1e67/attachment.sig>

From tcallawa at redhat.com  Thu Oct 11 13:34:19 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 11 Oct 2007 09:34:19 -0400
Subject: better install experience
In-Reply-To: <470DD14D.1050301@leemhuis.info>
References: <fej8ij$v89$1@sea.gmane.org>
	<1192045121.3261.82.camel@localhost.localdomain>
	<Pine.LNX.4.64.0710101551340.14894@newtla.xelerance.com>
	<1192046031.3261.85.camel@localhost.localdomain>
	<470D315B.3070604@leemhuis.info>
	<1192047795.3261.88.camel@localhost.localdomain>
	<470D3DE7.90401@leemhuis.info>
	<1192051066.3261.103.camel@localhost.localdomain>
	<470DD14D.1050301@leemhuis.info>
Message-ID: <1192109659.3261.117.camel@localhost.localdomain>


On Thu, 2007-10-11 at 09:31 +0200, Thorsten Leemhuis wrote:
> /me got some download numbers from livna, so I'll send one final mail
> 
> On 10.10.2007 23:17, Tom "spot" Callaway wrote:
> > On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> >> /me will keep away from this thread now -- this won't lead to anything
> >> anyway; I'll tag it in the growing categories "Fedora knows better
> >> then
> >> me want I want" and "why Fedora never will become a true community
> >> distribution"
> > DaveJ doesn't want the bugreports. Are you volunteering to take them?
> 
> Sure.
> 
> > There are two ntfs implementations. One is old, crufted, and poorly
> > maintained. The other one is actively maintained, with lots of new
> > releases, bugfixes, and performance improvements.
> 
> Nevertheless there are about 4500 F7 users installed kmod-ntfs from
> livna. I'd assume they didn't do that by accident. And I'd further
> assume most howtos these days will describe ntfs-3g, so I bet a good
> percentage of those 4500 chose the older one for a reason.

FWIW, most of the howtos are still not mentioning ntfs-3g.

~spot



From mclasen at redhat.com  Thu Oct 11 13:36:45 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 11 Oct 2007 09:36:45 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <26905.192.54.193.51.1192109214.squirrel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
	<1192104893.6070.26.camel@localhost.localdomain>
	<36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>
	<1192107955.6070.37.camel@localhost.localdomain>
	<26905.192.54.193.51.1192109214.squirrel@rousalka.dyndns.org>
Message-ID: <1192109805.2571.7.camel@localhost.localdomain>

Nicolas, 

I believe we mostly agree that it is better to have an unattended
install where you enter all required information in advance, then click
the "install" button, and later come back to a login screen waiting for
your password. We had some discussions about that internally, but it is
not as easy as it sounds...

We may disagree on whether package selections is a "required human
interaction" during the install process.







From mjs at CLEMSON.EDU  Thu Oct 11 13:45:58 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Thu, 11 Oct 2007 09:45:58 -0400
Subject: samba license change
In-Reply-To: <1192074093.27891.8.camel@localhost.localdomain>
References: <loom.20071010T112610-389@post.gmane.org>
	<1192019946.13627.65.camel@localhost.localdomain>
	<loom.20071010T162828-161@post.gmane.org>
	<1192040623.26017.24.camel@localhost.localdomain>
	<604aa7910710101155u443ec8f8vb8e51592cad55745@mail.gmail.com>
	<1192045676.23415.1.camel@rousalka.dyndns.org>
	<604aa7910710101344t79ed6beag5107d9062416502@mail.gmail.com>
	<1192049742.3065.101.camel@vespa.kabelta.loc>
	<604aa7910710101421u561a61fet4e1884b15df81325@mail.gmail.com>
	<1192051876.26017.45.camel@localhost.localdomain>
	<20071010235754.GA1083997@hiwaay.net>
	<1192074093.27891.8.camel@localhost.localdomain>
Message-ID: <1192110358.27181.6.camel@vincent52.localdomain>

On Wed, 2007-10-10 at 23:41 -0400, Simo Sorce wrote:
> On Wed, 2007-10-10 at 18:57 -0500, Chris Adams wrote:
> > Once upon a time, Simo Sorce <ssorce at redhat.com> said:
> > > On Wed, 2007-10-10 at 13:21 -0800, Jeff Spaleta wrote:
> > > > But Nicolas has stated my murkier concern. If we just drop re-licensed
> > > > libsmbclient into place with no enforced technical break like a soname
> > > > change or a library renaming, are we acting negligently with regard to
> > > > protecting our own users who consume pieces of rawhide to suppliment
> > > > F7 or soon to be F8? If the re-licensed code can just drop into place,
> > > > are we encouraging users to violate the license at runtime by making
> > > > it too easy to use the re-licensing binary in situations where its
> > > > inappropriate?
> > > 
> > > Short answer: no
> > 
> > So what if KDE used a private copy of libsmclient.so.0 (from 3.0 so
> > GPLv2) during build but didn't ship it?  As long as the newer version is
> > ABI compatible (even if the license isn't), is there a violation?  I'm
> > sure some would say it is a violation of the spirit, but is there a
> > technical violation?
> > 
> > If so, where is the violation?  Where does it physically occur?
> > 
> > I haven't read GPLv3 closely, but "linking" doesn't appear anywhere in
> > GPLv2 except in a single note in the appendix (not in the license terms
> > itself).  Everything else in GPLv2 talks about derivative works.
> > Arguably, KDE's use of libsmbclient is a derivative work of a GPLv2
> > product.  As long as the interface to that product doesn't change (so
> > KDE's use of the product doesn't change), KDE could claim to be a
> > derivative work of the GPLv2 product.  Samba is NOT changing the ABI, so
> > any derivative works (that are derivative by action of using the
> > libsmbclient.so.0 interface) can still claim to be derivatives of only
> > the GPLv2 library.
> > 
> > I'm really curious about this (not just trying to still the flames): if
> > a GPLv2-only program is linked against a GPLv2 (or 2+) library and the
> > library switches to GPLv3 (or 3+), who is violating the license?  Use
> > (e.g. an end-user actually loading the KDE binary that dynamically links
> > against libsmbclient.so.0) is not covered by the GPLv2, so the end-user
> > is not violating it (because they aren't distributing).  A distributor
> > could be building against a GPLv2 version of the library but only
> > distributing the GPLv3 version; is that a violation (why)?
> 
> Far from being a flame.
> Your question is perfectly legitimate, but I don't think there is
> anybody on this list with enough legal expertise to answer.
> We need legal advice to be able to answer this question.

Probably a good idea.  But one point to consider is: In GPLv2, there is
a clause that says that you do not need to GPL a work that links to a
GPLv2 library if there is another library that performs the same
function that you could (in principle) link to instead.  If there is a
similar clause in GPLv3, that would seem to make the situation Chris
describes not a violation.  It seem that as long as the ABIs remain
identical, the existence of a GPLv2 lib that one could link to would
mean that code linking to the GPLv3 lib would not have to be GPLv3.

IANAL, of course, but it sounds at least like a plausible interpretation
to me.

> 
> Simo.
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From sgrubb at redhat.com  Thu Oct 11 13:50:55 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 11 Oct 2007 09:50:55 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <1192089592.6478.36.camel@jcmlaptop>
References: <1192089592.6478.36.camel@jcmlaptop>
Message-ID: <200710110950.56112.sgrubb@redhat.com>

On Thursday 11 October 2007 03:59:52 Jon Masters wrote:
> Seems to me that it'd be more useful if the readahead package
> configuration files (default/later) could use wildcards for path
> components such as firefox, python, etc. (so that you don't have quite
> the disconnect/lock-step requirement between these packages).

I've been working on a tool that scans certain important paths looking for any 
file that is unpackaged. What I've found is that a lot of files get installed 
where the package creates the directory structure, but does not actually own 
it. IOW, a packager will do:

%config(noreplace) %attr(640,root,root) /etc/audit/auditd.conf

but DOES NOT do:

%attr(750,root,root) %dir /etc/audit

So, when the package is upgraded later by another version or uninstalled, you 
have *many* files laying around and dead-end directories. Here's a SMALL 
sample of a typical rawhide system:

/usr/lib/gtk is not owned by a package
/usr/lib/gtk/themes is not owned by a package
/usr/lib/gtk/themes/engines is not owned by a package
/usr/lib/pwlib is not owned by a package
/usr/lib/pwlib/codecs is not owned by a package 
/usr/lib/pwlib/codecs/audio is not owned by a package
/usr/lib/mozilla-1.7.8 is not owned by a package
/usr/lib/mozilla is not owned by a package
/usr/lib/mozilla/plugins is not owned by a package
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi is not owned by a 
package
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto is not owned by 
a package
/usr/lib/perl5/vendor_perl/5.8.8/auto is not owned by a package
/usr/lib/perl5/vendor_perl/5.8.6/HTML is not owned by a package
/usr/lib/perl5/vendor_perl/5.8.6/XML is not owned by a package
/usr/lib/samba is not owned by a package
/usr/lib/samba/auth is not owned by a package
/usr/lib64/gimp/2.0/interpreters is not owned by a package
/usr/lib64/mozilla-1.7.12 is not owned by a package
/usr/lib64/mozilla-1.7.12/chrome is not owned by a package
/usr/lib64/mozilla-1.7.12/chrome/overlayinfo is not owned by a package
/usr/lib64/mozilla-1.7.12/chrome/overlayinfo/messenger is not owned by a 
package
/usr/lib64/mozilla-1.7.12/chrome/overlayinfo/messenger/content is not owned by 
a package
/usr/lib64/mozilla-1.7.12/chrome/overlayinfo/messenger/content/overlays.rdf is 
not owned by a package
/usr/lib64/X11/app-defaults is not owned by a package
/usr/lib64/X11/locale is not owned by a package
/usr/lib64/mozilla-1.7.11 is not owned by a package
/usr/lib64/mozilla-1.7.11/chrome is not owned by a package
/usr/lib64/mozilla-1.7.11/chrome/overlayinfo is not owned by a package
/usr/lib64/mozilla-1.7.11/chrome/overlayinfo/messenger is not owned by a 
package
/usr/lib64/mozilla-1.7.11/chrome/overlayinfo/messenger/content is not owned by 
a package
/usr/lib64/mozilla-1.7.11/chrome/overlayinfo/messenger/content/overlays.rdf is 
not owned by a package
/usr/lib64/openoffice.org2.1 is not owned by a package
/usr/lib64/openoffice.org2.1/share is not owned by a package
/usr/lib64/libkdeinit_kview.so.#prelink#.n5F8Qg is not owned by a package
/usr/lib64/totem is not owned by a package
/usr/lib64/python2.4 is not owned by a package
/usr/lib64/python2.4/site-packages is not owned by a package
/usr/lib64/python2.4/site-packages/dbus is not owned by a package
/usr/lib64/python2.4/site-packages/gtk-2.0 is not owned by a package
/usr/lib64/python2.4/site-packages/gtk-2.0/gtk is not owned by a package
/usr/lib64/python2.4/site-packages/GMenuSimpleEditor is not owned by a package
/usr/lib64/ruby/1.8/x86_64-linux/io is not owned by a package
/usr/lib64/ruby/1.8/x86_64-linux/racc is not owned by a package
/usr/lib64/ruby/1.8/optparse is not owned by a package
/usr/lib64/ruby/1.8/dl is not owned by a package
/usr/lib64/gcj-4.1.0 is not owned by a package
/usr/lib64/gcj-4.1.0/classmap.db is not owned by a package
/usr/lib64/openoffice.org2.0 is not owned by a package
/usr/lib64/openoffice.org2.0/program is not owned by a package
/usr/lib64/python2.5/site-packages/dbus is not owned by a package
/usr/lib64/gcj-4.0.1 is not owned by a package 
/usr/lib64/gcj-4.0.1/classmap.db is not owned by a package
/usr/lib64/rhythmbox/plugins is not owned by a package 
/usr/lib64/gcj/xerces-j2 is not owned by a package
/usr/lib64/gcj/tomcat5 is not owned by a package
/usr/lib64/gcj/sinjdoc is not owned by a package
/usr/lib64/firefox-2.0.0.6/plugin-config is not owned by a package
/usr/lib64/mozilla-1.7.10 is not owned by a package
/usr/lib64/mozilla-1.7.10/chrome is not owned by a package
/usr/lib64/mozilla-1.7.10/chrome/overlayinfo is not owned by a package
/usr/lib64/mozilla-1.7.10/chrome/overlayinfo/messenger is not owned by a 
package
/usr/lib64/mozilla-1.7.10/chrome/overlayinfo/messenger/content is not owned by 
a package
/usr/lib64/mozilla-1.7.10/chrome/overlayinfo/messenger/content/overlays.rdf is 
not owned by a package
/usr/lib64/gtk-2.0/2.10.0/filesystems is not owned by a package
/usr/lib64/firefox-2.0.0.5 is not owned by a package
/usr/lib64/firefox-2.0.0.5/plugin-config is not owned by a package
/usr/lib64/sasl is not owned by a package
/usr/lib64/udev is not owned by a package
/usr/lib64/firefox-2.0.0.2 is not owned by a package
/usr/lib64/firefox-2.0.0.2/updates is not owned by a package
/usr/lib64/firefox-2.0.0.2/updates/0 is not owned by a package
/usr/lib64/gcj-4.1.1 is not owned by a package
/usr/lib64/gcj-4.1.1/classmap.db is not owned by a package

and perl5 is a very naughty package too. This is a small sample of all the 
unclaimed files/dirs on a system. So, if you have a wildcard, the search for 
the right file can go down a lot of deadends before it finds the right one. 
Then what if the wildcard picks something that is the wrong version?

I think one thing that would help performance overall is that packages must 
own all the directories they create and delete them when its uninstalled. 
This removes directory entries and improves search time.

-Steve



From tsmetana at redhat.com  Thu Oct 11 13:55:03 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Thu, 11 Oct 2007 15:55:03 +0200
Subject: Retiring procinfo
In-Reply-To: <470E1A1A.7090408@crc.dk>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<470E1A1A.7090408@crc.dk>
Message-ID: <20071011155503.e3f11fcf.tsmetana@redhat.com>

On Thu, 11 Oct 2007 14:42:02 +0200
Mogens Kjaer <mk at crc.dk> wrote:

> One a F7-x86_64:
> 
> $ procinfo
> Segmentation fault
> 
> strace tells me that it occurs while reading /proc/interrupts

Yes.  This is what I had on mind.  If people were really using procinfo,
such a bug would have been discovered much earlier (it's fixed already
together with all the others I was able to find).

-- 
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From tonynelson at georgeanelson.com  Thu Oct 11 14:00:28 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Thu, 11 Oct 2007 10:00:28 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <1192089592.6478.36.camel@jcmlaptop>
References: <1192089592.6478.36.camel@jcmlaptop>
Message-ID: <p04330102c333d3e26fe9@[192.168.123.162]>

At 3:59 AM -0400 10/11/07, Jon Masters wrote:
>Yo,
>
>Seems to me that it'd be more useful if the readahead package
>configuration files (default/later) could use wildcards for path
>components such as firefox, python, etc. (so that you don't have quite
>the disconnect/lock-step requirement between these packages).
>
>Is there a reason why it's hard wired?

It's an attempt to not read files that weren't read normally.  Since
readahead already reads whole files when usually only parts were read
normally, it's already at a disadvantage.  Reading unused files would be
worse.

Readahead has the ability to make a new list of files just for your own
machine.

In any case, readahead does not improve boot time, and unless you can show
how to make readahead improve boot time, there is unlikely to be any work
done on making it keep reading all the files after updates.  It doesn't
make booting any slower if readahead can't find its files, or any faster if
it can.

Microsoft's approach, which is probably patented, involves tracking what
disk blocks are actually read and re-organizing the data on disk so that no
seeking is involved.  It speeds up booting.

Readahead's approach involves reading entire files, for any file that was
read from during boot.  Readahead sorts its list of files to minimize
seeking.  It doesn't speed up booting.

Without finding a way that readahead can speed up booting, work put into
optimizing readhead is just wasted.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From nicolas.mailhot at laposte.net  Thu Oct 11 14:02:58 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 16:02:58 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192109805.2571.7.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
	<42400.192.54.193.51.1192101027.squirrel@rousalka.dyndns.org>
	<1192104893.6070.26.camel@localhost.localdomain>
	<36987.192.54.193.51.1192107045.squirrel@rousalka.dyndns.org>
	<1192107955.6070.37.camel@localhost.localdomain>
	<26905.192.54.193.51.1192109214.squirrel@rousalka.dyndns.org>
	<1192109805.2571.7.camel@localhost.localdomain>
Message-ID: <27356.192.54.193.51.1192111378.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 15:36, Matthias Clasen a ?crit :
> Nicolas,

Matthias ,

Thank you for bringing some calm to this discussion.

> I believe we mostly agree that it is better to have an unattended
> install

I certainly hope so.

> We had some discussions about that internally, but it
> is not as easy as it sounds...

I don't doubt it.

> We may disagree on whether package selections is a "required human
> interaction" during the install process.

I fear that now we emphasize single-CD spins, it has become pretty
much required. This was not the case in the past when the primary
install method gave you access to a significant part of the Fedora
package collection.

Regards,

-- 
Nicolas Mailhot



From opensource at till.name  Thu Oct 11 14:07:40 2007
From: opensource at till.name (Till Maas)
Date: Thu, 11 Oct 2007 16:07:40 +0200
Subject: samba license change
In-Reply-To: <1192084036.4029.0.camel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710102332.46708.opensource@till.name>
	<1192084036.4029.0.camel@rousalka.dyndns.org>
Message-ID: <200710111607.45639.opensource@till.name>

On Do Oktober 11 2007, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 23:32 +0200, Till Maas a ?crit :
> > On Mi Oktober 10 2007, Nicolas Mailhot wrote:
> > > ??? Even if you build against gplv2 samba, as soon as the result is
> > > distributed with gpl3 samba and links against it on user systems,
> > > you're in the wrong.
> >
> > Is this really the case? Afaik the GPL only defines rules for
> > distributing the software and rights for receiving GPL software.
>
> Read my sentence again. The *full* sentence

Hm, maybe I do not understand the sentence correctly. Do you mean, that when 
some gplv2 software is built using parts of gplv2 samba and the result is in 
package foo.rpm and one distributes this with a gplv3 samba, which is in a 
package samba.rpm, then this a gplv2 license violation of the gplv2 samba 
used to compile foo.rpm?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/39679e46/attachment.sig>

From tsmetana at redhat.com  Thu Oct 11 14:18:19 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Thu, 11 Oct 2007 16:18:19 +0200
Subject: Retiring procinfo
In-Reply-To: <3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
	<3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>
Message-ID: <20071011161819.87949eae.tsmetana@redhat.com>

On Thu, 11 Oct 2007 17:55:36 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> Tomas, if you intend to orphan procinfo and not retire it, I am
> willing to take it over if no one else is interested or has problems
> with me taking it. :-)

I'll have to stay as a RHEL maintainer anyway, so it would not make
much sense to orphan it in Fedora -- there are almost no bugreports on
procinfo anyway.  But it's 6 years dead piece of software and by today
I haven't heard of anybody using it.

-- 
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From sundaram at fedoraproject.org  Thu Oct 11 14:18:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 19:48:36 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192106599.6070.32.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<1192105313.6070.30.camel@localhost.localdomain>	<470E16A1.8030501@fedoraproject.org>
	<1192106599.6070.32.camel@localhost.localdomain>
Message-ID: <470E30BC.9040407@fedoraproject.org>

Lubomir Kundrak wrote:
> On Thu, 2007-10-11 at 17:57 +0530, Rahul Sundaram wrote:
>> Lubomir Kundrak wrote:
>>> On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
>>>> We should be shipping a CD set. I consistently see people going to Ubuntu
>>>> after asking for a Fedora CD and being told they can't update that way.
>>> +1 Exactly this. We should pick packages for an installation that fits
>>> in 1CD. Is anyone already working on a one CD spin, or interested in
>>> working on it?
>> If you just want a single CD installation, you can use the installable 
>> Live CD (x86)
> 
> Well, and if I want to upgrade?

Yum upgrade works for me. Live upgrades is where our focus should be 
IMO. There is one proposal that uses Anaconda to perform something 
similar (http://fedoraproject.org/wiki/Features/PreUpgrade) but yum 
upgrades can work very well usually and even better if we spend some 
more time in testing this method of upgrade more and fixing any 
packaging problems.

Rahul



From jima at beer.tclug.org  Thu Oct 11 14:19:55 2007
From: jima at beer.tclug.org (Jima)
Date: Thu, 11 Oct 2007 09:19:55 -0500 (CDT)
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <1192084296.4029.5.camel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<1192084296.4029.5.camel@rousalka.dyndns.org>
Message-ID: <Pine.LNX.4.64.0710110912020.4486@beer.tclug.org>

On Thu, 11 Oct 2007, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 21:36 -0500, Michael Stahnke a ?crit :
>> I really think an upgrade path for the casual user is required.
>
> Unless they've been dunked, network install/updates should fit the bill

  I forget if this ever went anywhere, but I remember some time ago someone 
suggesting that we should have an installable package that would plop 
(essentially) the kernel image and initrd from the boot.iso into /boot, 
and add an entry into grub.conf for the next release's installer.  No 
CD/DVD required, no mucking around to figure out how to get your machine 
to boot to the optical drive...it'd be just the same as a network 
install/upgrade.  As Matt Domsch pointed out, it could even use our 
mirrorlist infrastructure to pick the download source.  We could even 
include the stage2.img (optionally, with a non-dependent subpackage that 
would pull in the main one).  It would handle the 
wants-to-upgrade-but-not-use-yum segment nicely, IMO.
  Alas, I don't remember if this ever got off the ground.  Sure seems like 
a nice potential target for F-9.

      Jima

From sandeen at redhat.com  Thu Oct 11 14:20:10 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 11 Oct 2007 09:20:10 -0500
Subject: should readahead allow generic paths?
In-Reply-To: <p04330102c333d3e26fe9@[192.168.123.162]>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
Message-ID: <470E311A.8020406@redhat.com>

Tony Nelson wrote:

> In any case, readahead does not improve boot time, and unless you can show
> how to make readahead improve boot time, there is unlikely to be any work
> done on making it keep reading all the files after updates.  It doesn't
> make booting any slower if readahead can't find its files, or any faster if
> it can.

Well, actually I don't quite agree (see also my "boot-time / readahead
investigations" thread)

with stock readahead (0:59):
http://sandeen.net/fedora_boot/bootchart-stockreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-stockreadahead-noselinux.png

without readahead (0:49):
http://sandeen.net/fedora_boot/bootchart-noreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-noreadahead-noselinux.png

with tweaked readahead (updated/sorted lists, run earlier) (0:44):
http://sandeen.net/fedora_boot/bootchart-fixedreadahead-noselinux.png
http://sandeen.net/fedora_boot/seekwatcher-fixedreadahead-noselinux.png

so, it's a small win for me.  The approach still feels a bit inelegant
to me, but it does seem to save a bit if it's done properly.  But from
above, if it's done wrong, it hurts a lot more than it helps.

Tossing a default list out there and hoping for the best probably won't
work, at any rate.

-Eric



From mclasen at redhat.com  Thu Oct 11 14:22:41 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 11 Oct 2007 10:22:41 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <470E311A.8020406@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]> <470E311A.8020406@redhat.com>
Message-ID: <1192112561.2571.9.camel@localhost.localdomain>


On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:

> 
> Tossing a default list out there and hoping for the best probably won't
> work, at any rate.

So are we going to get your fixed lists into F8 ?



From limb at jcomserv.net  Thu Oct 11 14:21:42 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470E16A1.8030501@fedoraproject.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
Message-ID: <7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>


> Lubomir Kundrak wrote:
>> On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
>>> We should be shipping a CD set. I consistently see people going to
>>> Ubuntu
>>> after asking for a Fedora CD and being told they can't update that way.
>>
>> +1 Exactly this. We should pick packages for an installation that fits
>> in 1CD. Is anyone already working on a one CD spin, or interested in
>> working on it?
>
> If you just want a single CD installation, you can use the installable
> Live CD (x86)

But the point is if you have no DVD drive, the only upgrade method, AFAIK
is yum, which is not officially supported.

Heck, I'm I'm still upset that we don't have boot floppies anymore, but I
live with it.

> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From pertusus at free.fr  Thu Oct 11 14:26:34 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 11 Oct 2007 16:26:34 +0200
Subject: should readahead allow generic paths?
In-Reply-To: <200710110950.56112.sgrubb@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<200710110950.56112.sgrubb@redhat.com>
Message-ID: <20071011142634.GC3659@free.fr>

On Thu, Oct 11, 2007 at 09:50:55AM -0400, Steve Grubb wrote:
> 
> and perl5 is a very naughty package too. This is a small sample of all the 
> unclaimed files/dirs on a system. 

These are all packaging bugs. For packages coming from core that haven't
already been reviewed it should be pretty common, though. It can also
happen if you put yourself some files in the directory prior from
removing the package owning the directory.

> I think one thing that would help performance overall is that packages must 
> own all the directories they create and delete them when its uninstalled. 
> This removes directory entries and improves search time.

See
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a5931a7372c4a00065713430984fa5875513e6d4

--
Pat



From jcm at redhat.com  Thu Oct 11 14:27:46 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 11 Oct 2007 10:27:46 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <200710110950.56112.sgrubb@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<200710110950.56112.sgrubb@redhat.com>
Message-ID: <1192112866.6478.83.camel@jcmlaptop>

On Thu, 2007-10-11 at 09:50 -0400, Steve Grubb wrote:
> On Thursday 11 October 2007 03:59:52 Jon Masters wrote:
> > Seems to me that it'd be more useful if the readahead package
> > configuration files (default/later) could use wildcards for path
> > components such as firefox, python, etc. (so that you don't have quite
> > the disconnect/lock-step requirement between these packages).
> 
> I've been working on a tool that scans certain important paths looking for any 
> file that is unpackaged. What I've found is that a lot of files get installed 
> where the package creates the directory structure, but does not actually own 
> it. IOW, a packager will do:

> I think one thing that would help performance overall is that packages must 
> own all the directories they create and delete them when its uninstalled. 
> This removes directory entries and improves search time.

You're (partially) joking though, right? I mean the time spent in the
kernel searching a directory path due to these is small fry ;-)

Valid point though!

Jon.




From snecklifter at gmail.com  Thu Oct 11 14:28:04 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Thu, 11 Oct 2007 15:28:04 +0100
Subject: better install experience
In-Reply-To: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
Message-ID: <364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>

On 11/10/2007, Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:
>
>
> On 10/10/2007, Christopher Brown wrote:
> >     On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> >
> > >    There are two ntfs implementations. One is old, crufted, and poorly
> > >    maintained.


Not sure what is to blame here but Thorsten didn't write that, Spot did.

>
> > Sorry but that is bullshit. Old and crufted aren't very good technical
>
> As I mentioned previously, the kernel driver and ntfs-3g have the same
> source base. When I developed ntfs-3g then I noted the potentially serious
> problems in the kernel (e.g. in truncate). I also mentioned them to Dave
> Jones. I never got a reply for any of my emails.


You're surprised by that?

Recently a buffer overflow
> was discovered (Andrew Morton fixed it), driver hangs during logfile reset
> (maintainer made a patch).


I'm sorry I can't see the relevance of this as an argument. Both issues were
fixed, one by the maintainer. What's the problem?

It seems as the kernel evolves, the kernel NTFS driver isn't adjusted as
> Miklos Szeredi does for the FUSE kernel module, so the kernel side of the
> NTFS-3G driver can stay safe, deadlock and corruption free, no need to
> worry about it. He is also extremely responsive both design and
> troubleshooting discussions and quality coding wise. He is employed by
> Novell and allowed to work on FUSE in a certain amount of his work time.


I'm mad keen to see figures of enterprise installations running FUSE over
kernel drivers. I mean _really_ keen.

> arguments and poorly maintained is simply untrue.
>
> The maintainer has been working for a non-Linux company since 2005 and
> from
> that point his open source contribution and leadership role is minimal.


Here we agree.

I've worked with him 4 years when it was decided finally a year ago that a
> partial fork is needed to ensure driver reliability and maintainability.


Partial? Could you define this? Please remember that I was/am a member of
the linux-ntfs project and although my contribution was only in the package
department for Rich Russon when he was around, there was nothing to indicate
you were intending to fork. and even then there was no real reason given in
your announcement that you were doing it for the above purpose.

For example we (linux-ntfs team at that time) were reported that some ntfs
> utilities made Vista unbootable. The reason was found and fixed a year
> ago,
> still the official bugfix was released only 10 days ago. The serious fix
> was sitting in the CVS for a year.


Whats wrong with bugging Linus to get it applied then? I'm having a hard
time believe crucial fixes sit in cvs simply because someone wont write an
email saying "Linus, please apply...". If Anton wont sign off (or comment)
then I'm inclined to agree the driver is dead in the water but it doesn't
look like this happened.

Obviously everybody thinks differently what is "poorly maintained". For me
> the above is one sign, amongst several others.
>
> > If this boils down to "It doesn't have write support, bwaaaaaaaah" then
> > "poorly maintained" isn't much of one either. The reason there have been
> > so few git commits is because it works fine in the state that its in and
> > as I explained, the core developer is focused mainly on the new driver
> > which, license debates aside, will be released in about a year.
>
> In 2005, we were offered NTFS code in favour of letting a company use and
> dual licence what we have developed. Then it became 2006 then the story
> changed a bit then the date was 2007 and then 2008.


True and I agree that actions speak louder than words. My original point was
that I believe Fedora should ship with the ntfs kernel driver enabled,
mount.ntfs should actually be named mount.ntfs-3g and to try and point out
the difference between functionality and stability - quite important where
filesystems are concerned.

>     Dave asked me for my opinion, and I said that we shouldn't ship
> >     something that's not recommended by one of its authors, and has no
> >     real maintenance upstream:
> >
> >     http://ntfs-3g.org/about.html


It would probably benefit from having any post-fork detail removed. As it
currently stands it might be interpreted that the reason for the fork was
the the kernel driver was not going to be released until 2008. I'm still at
a loss as to why you forked but then I was not privy to conversations that
went on behind the scenes perhaps.

> who spat the dummy and went off and created ntfs-3g when he could have
> > merged it with ntfsprogs.


My apologies, this was rude.

Here is my original announcement:
>
>
> http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.21.0607141859080.31588-100000%40mlf.linux.rulez.org
>
> I did the work as a long time Linux-NTFS project member. There wasn't
> __anything__ to merge. The work itself was Linux-NTFS, so in fact I
> __did__
> merge it when I published it. The code could have been just used without
> any change. I was the only one working on write support and there wasn't
> really anything to merge with because they were already included.
>
> After two-three months later the project still wasn't going the way it
> should have hereby the fork was made.


The announcement came without warning - this is my issue. It would've been
nice to have seen a "I'm thinking of forking because of a, b, c etc. Can
anything be done?". So yeah, I'm a little sad that the project split and now
confusion reigns.

> It actually has nothing to do with the kernel driver.
>
> As I wrote, it has quite a lot, in fact.
>

Please stop editing the posts like this; it is really bad form. NTFS-3g is
separate and distinct from the kernel driver. One is not reliant on the
other but perhaps you misunderstood me.

Please don't take this as criticism of ntfs-3g - I think it was a long time
(too long) in coming and enables lots of interesting things to happen. Keep
up the excellent work - I'm all in favour of choice which is what the
original argument was all about.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/f0104acf/attachment.htm>

From mschwendt.tmp0701.nospam at arcor.de  Thu Oct 11 14:30:10 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 11 Oct 2007 16:30:10 +0200
Subject: rpms/cpl/FC-6 cpl-qfits.patch,NONE,1.1 cpl.spec,NONE,1.1
In-Reply-To: <200710111059.l9BAxFfq025731@cvs-int.fedora.redhat.com>
References: <200710111059.l9BAxFfq025731@cvs-int.fedora.redhat.com>
Message-ID: <20071011163010.d641867f.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 11 Oct 2007 06:59:15 -0400, Sergio Pascual (sergiopr) wrote:

> Author: sergiopr
> 
> Update of /cvs/pkgs/rpms/cpl/FC-6
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv25720
> 
> Added Files:
> 	cpl-qfits.patch cpl.spec 
> Log Message:
> * Tue Oct 09 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-2
> - Updated qfits patch to build in 64 bits systems
> * Tue Sep 25 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-1
> - Minor changes
> * Thu Sep 13 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-0.3
> - Updated license tag
> * Thu May 03 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-0.2
> - Added dir for recipes.
> * Thu Apr 26 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-0.1
> - Initial spec file.

Hint: insert blank lines between your %changelog comments. Then
"make clog" cuts off after the most recent entry, and you can commit
with "make clog && cvs commit -F clog".

That improves readability.



From katzj at redhat.com  Thu Oct 11 14:29:04 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 11 Oct 2007 10:29:04 -0400
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <Pine.LNX.4.64.0710110912020.4486@beer.tclug.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<1192084296.4029.5.camel@rousalka.dyndns.org>
	<Pine.LNX.4.64.0710110912020.4486@beer.tclug.org>
Message-ID: <1192112944.26533.25.camel@localhost.localdomain>

On Thu, 2007-10-11 at 09:19 -0500, Jima wrote:
> On Thu, 11 Oct 2007, Nicolas Mailhot wrote:
> > Le mercredi 10 octobre 2007 ? 21:36 -0500, Michael Stahnke a ?crit :
> >> I really think an upgrade path for the casual user is required.
> >
> > Unless they've been dunked, network install/updates should fit the bill
> 
>   I forget if this ever went anywhere, but I remember some time ago someone 
> suggesting that we should have an installable package that would plop 
> (essentially) the kernel image and initrd from the boot.iso into /boot, 
> and add an entry into grub.conf for the next release's installer.  No 
> CD/DVD required, no mucking around to figure out how to get your machine 
> to boot to the optical drive...it'd be just the same as a network 
> install/upgrade.  As Matt Domsch pointed out, it could even use our 
> mirrorlist infrastructure to pick the download source.  We could even 
> include the stage2.img (optionally, with a non-dependent subpackage that 
> would pull in the main one).  It would handle the 
> wants-to-upgrade-but-not-use-yum segment nicely, IMO.
>   Alas, I don't remember if this ever got off the ground.  Sure seems like 
> a nice potential target for F-9.

Some bits got done here, others didn't.  Seth has the start of the
script to pre-download all of the packages as well as the kernel and
initrd to set this up.  You still then need to download stage2 from
anaconda (or boot off of the rescuecd), but the packages will get
preferred from the lookaside path on the rootfs.

Definitely could use some more testing, though.

Jeremy



From sandeen at redhat.com  Thu Oct 11 14:31:02 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 11 Oct 2007 09:31:02 -0500
Subject: should readahead allow generic paths?
In-Reply-To: <1192112561.2571.9.camel@localhost.localdomain>
References: <1192089592.6478.36.camel@jcmlaptop>	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
Message-ID: <470E33A6.7070903@redhat.com>

Matthias Clasen wrote:
> On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> 
>> Tossing a default list out there and hoping for the best probably won't
>> work, at any rate.
> 
> So are we going to get your fixed lists into F8 ?
> 

Well, part of the problem is that "my" fixed lists may not be everyone's
fixed lists - I generated a custom list from *my* boot sequence.  Coming
up with a good default list that actually speeds *everyone's* boot time
is another issue.  If we think it's worth the 4 second or so boottime
reduction, maybe some way to automatically generate the custom lists
during firstboot might be an option.  But then, they will rot over time...

I'm also testing the SuSE hack of telling glibc to readahead shared
libraries...

-Eric



From tjb at unh.edu  Thu Oct 11 14:31:34 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Thu, 11 Oct 2007 10:31:34 -0400
Subject: Gnome Logout Hangs?
In-Reply-To: <1192101324.2571.0.camel@localhost.localdomain>
References: <1191936868.4913.2.camel@raptor.sr.unh.edu>
	<1192029636.26943.20.camel@raptor.sr.unh.edu>
	<45abe7d80710102055t7eb29314rc26008b93897acac@mail.gmail.com>
	<1192101324.2571.0.camel@localhost.localdomain>
Message-ID: <1192113094.3966.0.camel@raptor.sr.unh.edu>


On Thu, 2007-10-11 at 07:15 -0400, Matthias Clasen wrote:
> On Wed, 2007-10-10 at 23:55 -0400, Ray Strode wrote:
> > Hi,
> > 
> > > I tracked this down more and it happens with metacity too on my intel
> > > graphics laptop. After logging out, if I go to a text console and kill
> > > just gnome-session, the logout finishes and gdm comes back up.
> > >
> > > Does this "fix" work for anyone else having the problem? It seems that
> > > since this apparently is not happening for everyone, it must be
> > > something I'm running that causes gnome-session to hang. I checked and
> > > pulseaudio is not running so I'm don't think it is the culprit.
> > 
> > Do you have vino ("Remote Desktop") installed ?  I think there's a bug
> > on one of the F8 tracker lists that mentions some weird interaction
> > between vino and gnome-session on logout.  I haven't looked into it
> > yet.
> > 
> 
> That should be fixed in todays libX11.
> 

I can confirm it is.

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From lemenkov at gmail.com  Thu Oct 11 14:34:11 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Thu, 11 Oct 2007 18:34:11 +0400
Subject: "rpmq: no arguments given for query" message while trying to
	make <anything> in Fedora's CVS tree
In-Reply-To: <adf480660710110303o7629910aga7a2a142a8c23987@mail.gmail.com>
References: <adf480660710110303o7629910aga7a2a142a8c23987@mail.gmail.com>
Message-ID: <adf480660710110734k11b8f757u79738c93839c05de@mail.gmail.com>

2007/10/11, Peter Lemenkov <lemenkov at gmail.com>:
> Hello All!
> Since couple of days ago I can't build tag or make anything else in
> Fedora's CVS tree. All my attemps ends with message in subj.

Resolved.
Looks like I forget to add spec-file and thus need to write 100 times
"I will always add necessary files before typing make tag" :)
-- 
With best regards!



From debarshi.ray at gmail.com  Thu Oct 11 14:35:03 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 11 Oct 2007 20:05:03 +0530
Subject: Retiring procinfo
In-Reply-To: <20071011161819.87949eae.tsmetana@redhat.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
	<3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>
	<20071011161819.87949eae.tsmetana@redhat.com>
Message-ID: <3170f42f0710110735x48d74794s8d55fb3573e7bd13@mail.gmail.com>

>  But it's 6 years dead piece of software and by today
> I haven't heard of anybody using it.

You already got a user now -- Steven R. Ringwald. :-)

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sgrubb at redhat.com  Thu Oct 11 14:34:49 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 11 Oct 2007 10:34:49 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <20071011142634.GC3659@free.fr>
References: <1192089592.6478.36.camel@jcmlaptop>
	<200710110950.56112.sgrubb@redhat.com>
	<20071011142634.GC3659@free.fr>
Message-ID: <200710111034.50135.sgrubb@redhat.com>

On Thursday 11 October 2007 10:26:34 Patrice Dumas wrote:
> > and perl5 is a very naughty package too. This is a small sample of all
> > the unclaimed files/dirs on a system.
>
> These are all packaging bugs.

Agreed.

> For packages coming from core that haven't already been reviewed it should
> be pretty common, though. It can also happen if you put yourself some files
> in the directory prior from removing the package owning the directory.

The vast majority are empty directories or ones where prelink blew up sometime 
in the past. Its rare to find anything in these dead-end directories.

> See
> http://fedoraproject.org/wiki/Packaging/Guidelines#head-a5931a7372c4a000657
>13430984fa5875513e6d4

The prime offenders from my perusal is: mozilla, ruby, perl5, and java or gcj. 
These could be fixed by now, but who knows.

-Steve



From bnocera at redhat.com  Thu Oct 11 14:36:41 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 11 Oct 2007 15:36:41 +0100
Subject: Bluetooth activation
In-Reply-To: <dc43962f0710110323p535454bdkd2263a9859ef2975@mail.gmail.com>
References: <dc43962f0710110323p535454bdkd2263a9859ef2975@mail.gmail.com>
Message-ID: <1192113401.15443.26.camel@cookie.hadess.net>

On Thu, 2007-10-11 at 12:23 +0200, Carlo Cassinelli wrote:
> I have a thinkpad T43 width fedora 8 test3 installed, and there is a
> big bluetooth's bug. The Fn+F5 button to activate/deactivate the
> interface it does not work, when the interface is activated before the
> loading of kernel the key work, but as soon as the fedora 8 test3
> kernel is loaded this key does not work and the interface cannot be
> activated.
> If the bluetooth is activated before the loading of fedora 8 this
> works well, I think it is not a problem of bluez but of the kernel.
> I have last kernel and the all system is up to date.

thinkpad_acpi allows you to enable/disable that. See the Bluetooth
section in http://ibm-acpi.sourceforge.net/README

We're still waiting for someone to hook that up to HAL though:
http://bugs.freedesktop.org/show_bug.cgi?id=10053

Cheers



From nicolas.mailhot at laposte.net  Thu Oct 11 14:38:50 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 16:38:50 +0200 (CEST)
Subject: samba license change
In-Reply-To: <200710111607.45639.opensource@till.name>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710102332.46708.opensource@till.name>
	<1192084036.4029.0.camel@rousalka.dyndns.org>
	<200710111607.45639.opensource@till.name>
Message-ID: <25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 16:07, Till Maas a ?crit :
> On Do Oktober 11 2007, Nicolas Mailhot wrote:
>> Le mercredi 10 octobre 2007 ? 23:32 +0200, Till Maas a ?crit :
>> > On Mi Oktober 10 2007, Nicolas Mailhot wrote:
>> > > ??? Even if you build against gplv2 samba, as soon as the result
>> is
>> > > distributed with gpl3 samba and links against it on user
>> systems,
>> > > you're in the wrong.
>> >
>> > Is this really the case? Afaik the GPL only defines rules for
>> > distributing the software and rights for receiving GPL software.
>>
>> Read my sentence again. The *full* sentence
>
> Hm, maybe I do not understand the sentence correctly. Do you mean,
> that when
> some gplv2 software is built using parts of gplv2 samba and the result
> is in
> package foo.rpm and one distributes this with a gplv3 samba, which is
> in a
> package samba.rpm, then this a gplv2 license violation of the gplv2
> samba used to compile foo.rpm?

IANAL, but IMHO this could be interpreted as a license violation of
the gplv3 samba distributed with GPLv2 foo.rpm that links against it.

(of course one could argue foo is not really derived from gplv3 samba
since it has been built against gplv2 samba, but gplv3 samba+gplv2 foo
is certainly derived from gplv3 samba, and that's what we'd be
distributing)

IMHO the original message I was responding to ("Thanks god we don't
have automated rebuilds") is dead wrong. The version against which
code was build or rebuild does not matter overmuch. The version we
distribute linking binaries with does.

-- 
Nicolas Mailhot



From lesmikesell at gmail.com  Thu Oct 11 14:55:04 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Oct 2007 09:55:04 -0500
Subject: samba license change
In-Reply-To: <25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>	<200710102332.46708.opensource@till.name>	<1192084036.4029.0.camel@rousalka.dyndns.org>	<200710111607.45639.opensource@till.name>
	<25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>
Message-ID: <470E3948.3090808@gmail.com>

Nicolas Mailhot wrote:
> 
> IANAL, but IMHO this could be interpreted as a license violation of
> the gplv3 samba distributed with GPLv2 foo.rpm that links against it.
> 
> (of course one could argue foo is not really derived from gplv3 samba
> since it has been built against gplv2 samba, but gplv3 samba+gplv2 foo
> is certainly derived from gplv3 samba, and that's what we'd be
> distributing)

I think there is a very good argument, going back to the FSF opinion on 
  the gmp vs, fgmp libraries, that as long as a working alternative 
library exists, code linking to one of those versions can't be 
considered a derivative of it in the copyright sense.

> IMHO the original message I was responding to ("Thanks god we don't
> have automated rebuilds") is dead wrong. The version against which
> code was build or rebuild does not matter overmuch. The version we
> distribute linking binaries with does.

If you have the right to distribute each component separately and the 
existence of a usable gplv2 copy prevents things that happen to link to 
the gplv3 version from being considered a derivative work, what's the 
problem -  at least until changes make the libraries incompatible?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From harald at redhat.com  Thu Oct 11 15:03:56 2007
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 11 Oct 2007 17:03:56 +0200
Subject: boot-time / readahead investigations
In-Reply-To: <470D5CF0.20204@redhat.com>
References: <470D5CF0.20204@redhat.com>
Message-ID: <470E3B5C.6030105@redhat.com>

Comparison of Fedora 8 Test 3 and openSUSE 10.3 on the same machine.

http://www.harald-hoyer.de/linux/f8t3boot



From david at fubar.dk  Thu Oct 11 15:15:20 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 11 Oct 2007 11:15:20 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D81BB.2070404@redhat.com>
References: <470D81BB.2070404@redhat.com>
Message-ID: <1192115720.31757.32.camel@oneill.fubar.dk>


On Wed, 2007-10-10 at 20:51 -0500, Mike McGrath wrote:
> History: Up until Fedora 7 all RH family products had an install CD that 
> people could download, stick in their drive and install a minimal set of 
> packages or at least specify a method to install from.
> 
> Problem: As of Fedora 7 (and soon with Fedora 8) they cannot do this.  
> The installable live cd can install but not in the traditional sense of 
> what people are used to.  It has no package selection and cannot upgrade.

I'm not sure why you shouldn't be able to use anaconda on the live image
to do an upgrade of an existing Fedora OS. E.g. downloading packages
from the network or media [1] as needed. 

As for "no package selection during install" on the live cd; that's just
a red herring - you can easily do this post-install. Most people just
don't notice it. Ideally the live cd installer could ask you "Do you
want to install other packages too?" and then use the network / media to
do this. 

Seems like anaconda should be able to do these things if it can't
already.

      David

[1] : one could envision live media that also includes a lot of RPM's.



From david at fubar.dk  Thu Oct 11 15:18:13 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 11 Oct 2007 11:18:13 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192084232.4029.3.camel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
Message-ID: <1192115893.31757.36.camel@oneill.fubar.dk>


On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> 
> > livecd - you can do pkg selection after you're installed 
> 
> And users do not want that. That's the same thing as the "reboot before
> continuing" windows plague

It's theoretically possible to do a reboot-less install (google for
livecd raid broken mirror) but that is IMO so far into weeds because I
simply don't think it's true that users are afraid of reboots as you
state. Hell, we require it for kernel upgrades etc. etc.

       David




From katzj at redhat.com  Thu Oct 11 15:19:57 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 11 Oct 2007 11:19:57 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192115720.31757.32.camel@oneill.fubar.dk>
References: <470D81BB.2070404@redhat.com>
	<1192115720.31757.32.camel@oneill.fubar.dk>
Message-ID: <1192115997.7423.1.camel@localhost.localdomain>

On Thu, 2007-10-11 at 11:15 -0400, David Zeuthen wrote:
> On Wed, 2007-10-10 at 20:51 -0500, Mike McGrath wrote:
> > History: Up until Fedora 7 all RH family products had an install CD that 
> > people could download, stick in their drive and install a minimal set of 
> > packages or at least specify a method to install from.
> > 
> > Problem: As of Fedora 7 (and soon with Fedora 8) they cannot do this.  
> > The installable live cd can install but not in the traditional sense of 
> > what people are used to.  It has no package selection and cannot upgrade.
> 
> I'm not sure why you shouldn't be able to use anaconda on the live image
> to do an upgrade of an existing Fedora OS. E.g. downloading packages
> from the network or media [1] as needed. 

The main thing missing is a nice way of launching anaconda to do this
(and prompting for where to get the bits from).  Beyond that, the code
is there and works.  Also for doing a "regular" install and not just
copying the live image.

> As for "no package selection during install" on the live cd; that's just
> a red herring - you can easily do this post-install. Most people just
> don't notice it. Ideally the live cd installer could ask you "Do you
> want to install other packages too?" and then use the network / media to
> do this. 

Mostly a matter of round 'tuits to just integrate the couple of pieces
needed.  All the actual hard code is there, just doing it hasn't been
high on the priority list

Jeremy



From paul at all-the-johnsons.co.uk  Thu Oct 11 15:25:44 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 11 Oct 2007 16:25:44 +0100
Subject: upload cert?
Message-ID: <1192116344.4076.0.camel@T7.Linux>

Hi,

I've hit a bit of a problem....

Where do I get the fedora-upload cert from?

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071011/16cb266f/attachment.sig>

From cdhouch at gmail.com  Thu Oct 11 15:26:52 2007
From: cdhouch at gmail.com (Caerie Houchins)
Date: Thu, 11 Oct 2007 10:26:52 -0500
Subject: compiz-fusion other apps?
Message-ID: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>

I know that compiz-fusion is seen as a tech preview in F8, but are there any
plans to include ccsm and the other applications that go along with it at
some point ?  Right now there doesn't seem to be a way to configure the
compiz-fusion plugins...

I know there are a lot of ways posted on how to put this in ourselves, but I
really would like to stick to rawhide until the release of F8 for testing
reasons.

-- 
Caerie Houchins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/4e47aab0/attachment.htm>

From cdhouch at gmail.com  Thu Oct 11 15:26:52 2007
From: cdhouch at gmail.com (Caerie Houchins)
Date: Thu, 11 Oct 2007 10:26:52 -0500
Subject: compiz-fusion other apps?
Message-ID: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>

I know that compiz-fusion is seen as a tech preview in F8, but are there any
plans to include ccsm and the other applications that go along with it at
some point ?  Right now there doesn't seem to be a way to configure the
compiz-fusion plugins...

I know there are a lot of ways posted on how to put this in ourselves, but I
really would like to stick to rawhide until the release of F8 for testing
reasons.

-- 
Caerie Houchins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/4e47aab0/attachment-0001.htm>

From mmcgrath at redhat.com  Thu Oct 11 15:21:19 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 11 Oct 2007 10:21:19 -0500
Subject: upload cert?
In-Reply-To: <1192116344.4076.0.camel@T7.Linux>
References: <1192116344.4076.0.camel@T7.Linux>
Message-ID: <470E3F6F.4050302@redhat.com>

Paul wrote:
> Hi,
>
> I've hit a bit of a problem....
>
> Where do I get the fedora-upload cert from?
>   
https://admin.fedoraproject.org/accounts/gen-cert.cgi

    -Mike



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Oct 11 15:34:18 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 12 Oct 2007 00:34:18 +0900
Subject: compiz-fusion other apps?
In-Reply-To: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
References: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
Message-ID: <470E427A.8090309@ioa.s.u-tokyo.ac.jp>

Caerie Houchins wrote, at 10/12/2007 12:26 AM +9:00:
> I know that compiz-fusion is seen as a tech preview in F8, but are there 
> any plans to include ccsm and the other applications that go along with 
> it at some point ?  Right now there doesn't seem to be a way to 
> configure the compiz-fusion plugins...

If someone submits a review request, we can review it.

Regards,
Mamoru



From sundaram at fedoraproject.org  Thu Oct 11 15:34:50 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 21:04:50 +0530
Subject: compiz-fusion other apps?
In-Reply-To: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
References: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
Message-ID: <470E429A.5090302@fedoraproject.org>

Caerie Houchins wrote:
> I know that compiz-fusion is seen as a tech preview in F8, but are there 
> any plans to include ccsm and the other applications that go along with 
> it at some point ?  Right now there doesn't seem to be a way to 
> configure the compiz-fusion plugins...
> 
> I know there are a lot of ways posted on how to put this in ourselves, 
> but I really would like to stick to rawhide until the release of F8 for 
> testing reasons.

Some of these are in review.

http://fedoraproject.org/wiki/AskFedora/2007-09-24

Rahul



From jkeating at redhat.com  Thu Oct 11 15:36:06 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Oct 2007 11:36:06 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192106599.6070.32.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<1192106599.6070.32.camel@localhost.localdomain>
Message-ID: <20071011113606.13404ee6@redhat.com>

On Thu, 11 Oct 2007 14:43:19 +0200
Lubomir Kundrak <lkundrak at redhat.com> wrote:

> Well, and if I want to upgrade?

What if what you have on your system isn't on the single CD you want to
use to upgrade?  Leave half your software unupgraded ?

For upgrades you want access to the entire package set, or a good sized
portion.  Really what you want to do is boot from media that has stage1
and stage2 (rescue iso works for this) and has the ability to point to
a network location of all the packages for the upgrade.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/57b0f657/attachment.sig>

From jkeating at redhat.com  Thu Oct 11 15:36:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Oct 2007 11:36:40 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
Message-ID: <20071011113640.2fe41b4e@redhat.com>

On Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
"Jon Ciesla" <limb at jcomserv.net> wrote:

> But the point is if you have no DVD drive, the only upgrade method,
> AFAIK is yum, which is not officially supported.

Incorrect.  rescue.iso or boot.iso + network, or harddrive.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/11e53a4d/attachment.sig>

From jan.kratochvil at redhat.com  Thu Oct 11 15:36:46 2007
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Thu, 11 Oct 2007 17:36:46 +0200
Subject: Bluetooth activation
In-Reply-To: <dc43962f0710110323p535454bdkd2263a9859ef2975@mail.gmail.com>
References: <dc43962f0710110323p535454bdkd2263a9859ef2975@mail.gmail.com>
Message-ID: <20071011153646.GA23805@host0.dyn.jankratochvil.net>

On Thu, 11 Oct 2007 12:23:41 +0200, Carlo Cassinelli wrote:
> I have a thinkpad T43 width fedora 8 test3 installed, and there is a big
> bluetooth's bug. The Fn+F5 button to activate/deactivate the interface it
> does not work,

The key worked on F7 kernels (before F8 - latest Rawhide).  It now just writes:
	Oct 11 17:35:32 host0 acpid: received event "ibm/hotkey HKEY 00000080 00001005"

On Lenovo T60 the internal bluetooth is randomly active/inactive after poweron.
This one rc.local command workarounds it:

	echo enable >/proc/acpi/ibm/bluetooth


Regards,
Lace



From mmcgrath at redhat.com  Thu Oct 11 15:40:17 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 11 Oct 2007 10:40:17 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071011113606.13404ee6@redhat.com>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<1192105313.6070.30.camel@localhost.localdomain>	<470E16A1.8030501@fedoraproject.org>	<1192106599.6070.32.camel@localhost.localdomain>
	<20071011113606.13404ee6@redhat.com>
Message-ID: <470E43E1.4050706@redhat.com>

Jesse Keating wrote:
> On Thu, 11 Oct 2007 14:43:19 +0200
> Lubomir Kundrak <lkundrak at redhat.com> wrote:
>
>   
>> Well, and if I want to upgrade?
>>     
>
> What if what you have on your system isn't on the single CD you want to
> use to upgrade?  Leave half your software unupgraded ?
>   

Same is true for a single DVD.

    -Mike



From jkeating at redhat.com  Thu Oct 11 15:52:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Oct 2007 11:52:53 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470E43E1.4050706@redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<1192106599.6070.32.camel@localhost.localdomain>
	<20071011113606.13404ee6@redhat.com> <470E43E1.4050706@redhat.com>
Message-ID: <20071011115253.76bad97e@redhat.com>

On Thu, 11 Oct 2007 10:40:17 -0500
Mike McGrath <mmcgrath at redhat.com> wrote:

> Same is true for a single DVD.

Absolutely true.  It was true of the full CD/DVD sets back in FC6< as
well when Extras was involved because your Extras packages wouldn't get
upgraded either.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/dd8d0747/attachment.sig>

From sandeen at redhat.com  Thu Oct 11 15:56:02 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 11 Oct 2007 10:56:02 -0500
Subject: boot-time / readahead investigations
In-Reply-To: <470E3B5C.6030105@redhat.com>
References: <470D5CF0.20204@redhat.com> <470E3B5C.6030105@redhat.com>
Message-ID: <470E4792.4030606@redhat.com>

Harald Hoyer wrote:
> Comparison of Fedora 8 Test 3 and openSUSE 10.3 on the same machine.
> 
> http://www.harald-hoyer.de/linux/f8t3boot
> 

Harald, also try booting that test box with readahead_early and
readahead_later chkconfig'd off, perhaps?

-Eric



From nicolas.mailhot at laposte.net  Thu Oct 11 15:59:15 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 17:59:15 +0200 (CEST)
Subject: samba license change
In-Reply-To: <470E3948.3090808@gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710102332.46708.opensource@till.name>
	<1192084036.4029.0.camel@rousalka.dyndns.org>
	<200710111607.45639.opensource@till.name>
	<25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>
	<470E3948.3090808@gmail.com>
Message-ID: <55712.192.54.193.51.1192118355.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 16:55, Les Mikesell a ?crit :

> If you have the right to distribute each component separately and the
> existence of a usable gplv2 copy prevents things that happen to link
> to the gplv3 version from being considered a derivative work, what's
the
> problem

Because you can't limit yourself to analysing components separately.
The distribution itself is an aggregate work that is subject to
copyright laws as a whole.

In a distribution context since yum or anaconda will always choose to
install foo with GPLv3 samba you can't handwave "there was a GPLv2
samba on the buildsys". That's not what users get through pour
distribution. And it's not mere aggregation since one links to the
other.

-- 
Nicolas Mailhot



From sandeen at redhat.com  Thu Oct 11 16:00:53 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 11 Oct 2007 11:00:53 -0500
Subject: boot-time / readahead investigations
In-Reply-To: <470E4792.4030606@redhat.com>
References: <470D5CF0.20204@redhat.com> <470E3B5C.6030105@redhat.com>
	<470E4792.4030606@redhat.com>
Message-ID: <470E48B5.506@redhat.com>

Eric Sandeen wrote:
> Harald Hoyer wrote:
>> Comparison of Fedora 8 Test 3 and openSUSE 10.3 on the same machine.
>>
>> http://www.harald-hoyer.de/linux/f8t3boot
>>
> 
> Harald, also try booting that test box with readahead_early and
> readahead_later chkconfig'd off, perhaps?

Oh, duh, sorry - you did do that in effect by turning off all the other
non-suse services.  Seeing how much readahead itself impacts things by
itself still may be interesting.

-Eric



From harald at redhat.com  Thu Oct 11 16:00:38 2007
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 11 Oct 2007 18:00:38 +0200
Subject: boot-time / readahead investigations
In-Reply-To: <470E4792.4030606@redhat.com>
References: <470D5CF0.20204@redhat.com> <470E3B5C.6030105@redhat.com>
	<470E4792.4030606@redhat.com>
Message-ID: <470E48A6.3060802@redhat.com>

Eric Sandeen wrote:
> Harald Hoyer wrote:
>> Comparison of Fedora 8 Test 3 and openSUSE 10.3 on the same machine.
>>
>> http://www.harald-hoyer.de/linux/f8t3boot
>>
> 
> Harald, also try booting that test box with readahead_early and
> readahead_later chkconfig'd off, perhaps?
> 
> -Eric
> 

They were off :-/



From nicolas.mailhot at laposte.net  Thu Oct 11 16:02:22 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 18:02:22 +0200 (CEST)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192115893.31757.36.camel@oneill.fubar.dk>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192115893.31757.36.camel@oneill.fubar.dk>
Message-ID: <3470.192.54.193.51.1192118542.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 17:18, David Zeuthen a ?crit :
>
> On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
>> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
>>
>> > livecd - you can do pkg selection after you're installed
>>
>> And users do not want that. That's the same thing as the "reboot
>> before continuing" windows plague
>
> It's theoretically possible to do a reboot-less install

I'm not objecting to the reboot I'm objecting to having interactive
install phases both before and after the reboot.

-- 
Nicolas Mailhot



From jon.nettleton at gmail.com  Thu Oct 11 16:04:27 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 11 Oct 2007 12:04:27 -0400
Subject: boot-time / readahead investigations
In-Reply-To: <470E4792.4030606@redhat.com>
References: <470D5CF0.20204@redhat.com> <470E3B5C.6030105@redhat.com>
	<470E4792.4030606@redhat.com>
Message-ID: <e71b3daf0710110904n17d324cbj4a2653826e3b41c3@mail.gmail.com>

On 10/11/07, Eric Sandeen <sandeen at redhat.com> wrote:
> Harald Hoyer wrote:
> > Comparison of Fedora 8 Test 3 and openSUSE 10.3 on the same machine.
> >
> > http://www.harald-hoyer.de/linux/f8t3boot
> >
>
> Harald, also try booting that test box with readahead_early and
> readahead_later chkconfig'd off, perhaps?
>

And last but not least if you are truly adventurous grab
http://www.hekanetworks.com/~jnettlet/open-source/dispatcher.d.tar.bz2

It is a bunch of scripts that you can add to
/etc/NetworkManager/dispatcher.d/  that can turn on and off Network
Services.  From the list of services you still have enabled it would
include sshd, avahi, rpc*.  Disable those in chkconfig and allow
NetworkManagerDispatcher enable and disable them.  If you only use
networked cups printers you can add that one also.

Jon



From david at fubar.dk  Thu Oct 11 16:12:32 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 11 Oct 2007 12:12:32 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <3470.192.54.193.51.1192118542.squirrel@rousalka.dyndns.org>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192115893.31757.36.camel@oneill.fubar.dk>
	<3470.192.54.193.51.1192118542.squirrel@rousalka.dyndns.org>
Message-ID: <1192119152.31757.52.camel@oneill.fubar.dk>


On Thu, 2007-10-11 at 18:02 +0200, Nicolas Mailhot wrote:
> Le Jeu 11 octobre 2007 17:18, David Zeuthen a ?crit :
> >
> > On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
> >> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
> >>
> >> > livecd - you can do pkg selection after you're installed
> >>
> >> And users do not want that. That's the same thing as the "reboot
> >> before continuing" windows plague
> >
> > It's theoretically possible to do a reboot-less install
> 
> I'm not objecting to the reboot I'm objecting to having interactive
> install phases both before and after the reboot.

That's a fair objection (and according to jeremy this can be fixed in
the future). 

Btw, we have a couple of other bugs (probably more urgent) like that;
for starters my pet peeve is firstboot; we really ought to query the
user for this information (set up users, user image (gnome cheese or
ktuberling!) etc.) at live cd install time; preferably utilizing the
time span when we're copying the OS payload to the system.

      David




From poelstra at redhat.com  Thu Oct 11 16:11:31 2007
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 11 Oct 2007 09:11:31 -0700
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D9C88.9050106@redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com>
Message-ID: <470E4B33.4060605@redhat.com>

Mike McGrath said the following on 10/10/2007 08:46 PM Pacific Time:
> John Reiser wrote:
>>> So the real question is what do we 'suggest' our default install be?
>>>
>>> 1) Live CD: Can't upgrade, do package selection or specify install 
>>> method.
>>>     
>>
>> Why can't a system that is installed from the Live CD be upgraded?
>> What would it take to make such an installation upgradeable?
>> I believe it is reasonable if the upgrade is possible, even if it
>> requires a separate step after initial installation from Live CD.
>> [Specifying install method and package selection is a natural for the
>> Rescue CD; see #3 below.]
>>   
> 
> Because the live cd install does an image copy and not an install.  The 
> workings behind the scenes are not the same right now in anaconda for 
> the live cd and the normal install.
> 

Another interesting side affect is that there is no package list in the anaconda-ks.cfg that gets created in /root.

John



From limb at jcomserv.net  Thu Oct 11 16:20:33 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Oct 2007 11:20:33 -0500 (CDT)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071011113640.2fe41b4e@redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
	<20071011113640.2fe41b4e@redhat.com>
Message-ID: <45270.63.85.68.164.1192119633.squirrel@mail.jcomserv.net>


> On Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
> "Jon Ciesla" <limb at jcomserv.net> wrote:
>
>> But the point is if you have no DVD drive, the only upgrade method,
>> AFAIK is yum, which is not officially supported.
>
> Incorrect.  rescue.iso or boot.iso + network, or harddrive.

Is this in the wiki anywhere?  Because I seem to recall asking about this
when CDs went away, and was told it was yum or fresh install.

Granted, upgrading with yum is great and works well, and is my preferred
method, but I have to have something else in case we get to a point where
a yum upgrade is impossible for some unforseen reason.

> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From berrange at redhat.com  Thu Oct 11 16:26:38 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 11 Oct 2007 17:26:38 +0100
Subject: Plan for tomorrows (20071011) FESCO meeting
In-Reply-To: <470DAE6C.3070009@redhat.com>
References: <1192040583.6641.2.camel@kennedy> <470DAE6C.3070009@redhat.com>
Message-ID: <20071011162638.GD4893@redhat.com>

On Wed, Oct 10, 2007 at 10:02:36PM -0700, John Poelstra wrote:
> Brian Pepple said the following on 10/10/2007 11:23 AM Pacific Time:
> >Hi,
> >
> >Please find below the list of topics that are likely to come up in the
> >next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
> >in #fedora-meeting on irc.freenode.org:
> >
> >/topic FESCo meeting -- Free discussion around Fedora
> >
> >There's nothing on the schedule for tomorrow so if you want something
> >to be discussed, send a note to the list in reply to this mail and I'll
> >add it to the schedule.  You can also propose topics in the meeting
> >while it is in the "Free discussion around Fedora" phase.
> 
> Need to follow-up on the remaining unfinished features from last week:
> http://fedoraproject.org/wiki/Releases/8/FeatureList
> 
> In particular:
> http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity

FYI, I just updated this page. Executive summary:

  - Xen virt stack is 100% complete
  - KVM virt stack is missing a configuration option in libvirtd to
    enable TLS on the VNC server.

I'm working on the latter & it should be addressed before end of the week

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From lesmikesell at gmail.com  Thu Oct 11 16:36:50 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 11 Oct 2007 11:36:50 -0500
Subject: samba license change
In-Reply-To: <55712.192.54.193.51.1192118355.squirrel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>	<200710102332.46708.opensource@till.name>	<1192084036.4029.0.camel@rousalka.dyndns.org>	<200710111607.45639.opensource@till.name>	<25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>	<470E3948.3090808@gmail.com>
	<55712.192.54.193.51.1192118355.squirrel@rousalka.dyndns.org>
Message-ID: <470E5122.80604@gmail.com>

Nicolas Mailhot wrote:
> Le Jeu 11 octobre 2007 16:55, Les Mikesell a ?crit :
> 
>> If you have the right to distribute each component separately and the
>> existence of a usable gplv2 copy prevents things that happen to link
>> to the gplv3 version from being considered a derivative work, what's
> the
>> problem
> 
> Because you can't limit yourself to analysing components separately.
> The distribution itself is an aggregate work that is subject to
> copyright laws as a whole.

Yes, but one part only affects another if it can be considered a 
derivative work, and as the gmp vs. fgmp situation demonstrated, if 
there is a choice of libraries the parts linking to it can't be 
considered a derived work of the one that happens to be used in any 
particular instance.

> In a distribution context since yum or anaconda will always choose to
> install foo with GPLv3 samba you can't handwave "there was a GPLv2
> samba on the buildsys". That's not what users get through pour
> distribution. And it's not mere aggregation since one links to the
> other.

But it's also not a derived work of the gplv3 instance, since that could 
be replaced by the gplv2 version and it would still work.  There wasn't 
a court case with gmp vs. fgmp, but that was the FSF opinion. Personally 
I think it is a stretch to say that any code component can ever control 
the copyright status of any other part that you obtain separately, 
meeting its own terms, but even the FSF admits that it can't in the case 
where some other component works as a replacement.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Thu Oct 11 16:36:57 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 11 Oct 2007 22:06:57 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <45270.63.85.68.164.1192119633.squirrel@mail.jcomserv.net>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<1192105313.6070.30.camel@localhost.localdomain>	<470E16A1.8030501@fedoraproject.org>	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>	<20071011113640.2fe41b4e@redhat.com>
	<45270.63.85.68.164.1192119633.squirrel@mail.jcomserv.net>
Message-ID: <470E5129.8020301@fedoraproject.org>

Jon Ciesla wrote:
>> On Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
>> "Jon Ciesla" <limb at jcomserv.net> wrote:
>>
>>> But the point is if you have no DVD drive, the only upgrade method,
>>> AFAIK is yum, which is not officially supported.
>> Incorrect.  rescue.iso or boot.iso + network, or harddrive.
> 
> Is this in the wiki anywhere?  Because I seem to recall asking about this
> when CDs went away, and was told it was yum or fresh install.

If you were told about this in the fedora-list, some folks there have 
been keen on conveying incorrect information. Refer to 
http://fedoraproject.org/wiki/Fedora7/FAQ.

Rahul



From tla at rasmil.dk  Thu Oct 11 16:54:49 2007
From: tla at rasmil.dk (Tim Lauridsen)
Date: Thu, 11 Oct 2007 18:54:49 +0200
Subject: yum-updatesd in F8?
In-Reply-To: <16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>	<200710101509.57799.jamatos@fc.up.pt>	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>	<200710101546.54277.jamatos@fc.up.pt>	<1192028116.6890.37.camel@localhost.localdomain>	<1192028348.6741.271.camel@cutter>
	<16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>
Message-ID: <470E5559.6020700@rasmil.dk>

Arthur Pemberton wrote:
> ---------- Forwarded message ----------
> From: seth vidal <skvidal at fedoraproject.org>
> Date: Oct 10, 2007 9:59 AM
> Subject: Re: yum-updatesd in F8?
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
>
>
>
> On Wed, 2007-10-10 at 16:55 +0200, Lubomir Kundrak wrote:
>   
>> On Wed, 2007-10-10 at 15:46 +0100, Jos? Matos wrote:
>>     
>>> On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
>>>       
>>>> And you don't consider that to be blocking?
>>>>         
>>> Cann't you wait less than 10 seconds (the worst wait time I had)? You are
>>> really a busy person. ;-)
>>>       
>> Now do a reasonable F-7 desktop installation, and then see if it would
>> be less than 10 seconds even if you have a moderately fast internet
>> connection. And imaging that you are a newbie and have no idea what
>> blocks what and how long would it take, and whether it will ever
>> unblock.
>>
>>     
>
> If the transaction is being performed what alternative do you have?
>
> reading from the rpmdb while a transaction is occurring is possible you
> just won't be able to rely on the results as 'correct'
>
> Now, if you're talking about grabbing a new copy of the metadata then
> what we've put on the 'future' todo list is downloading he metadata to a
> tmpdir, checking it out and putting it in place once its correct,
> however, that's a bit racy b/c you end up with the potential for 2 or
> more processes to want to write to the same location with, potentially
> different data.
>
> -sv
>
>
> Here's my somewhat similar proposal.
>
> 1) have yum-updatesd copy all the data it needs, put a watch on the
> working dataset for changes
>
> 2) have yum-updates first download all the data it needs to do the update
>
> 3) check the working dataset for changes, if there have been changes
> (more than simply updating the local copy of the meta data) end the
> process here
>
> 4) otherwise put the working dataset into a readonly mode (other UIs
> would be able to read this, and provide the user with feedback
> accordingly without simply blocking)
>
> 5) do updates with the updated dataset copy
>
> 6) then copyover/sync the working dataset with the updated one and
> release the readonly mode (any UIs would be obligated to refresh
> themselves once the readonly mode has been removed
>
> worse case scenario is that user opens a UI seconds after yum-updatesd
> begins downloading packages, and does a full update themselves... in
> which case the data would be downloaded twice - I believe that problem
> too could be mitigated
>
>   
-1.
I don't see the benefit of this, why make it so complex, it will just 
introduce a lot of issues, where things can go wrong.
It is very important to for yum to do things safely, no one dies by 
waiting a couple of seconds. :)

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/ac73b6a3/attachment.htm>

From jspaleta at gmail.com  Thu Oct 11 16:59:04 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Oct 2007 08:59:04 -0800
Subject: yum-updatesd in F8?
In-Reply-To: <470E5559.6020700@rasmil.dk>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
	<16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>
	<470E5559.6020700@rasmil.dk>
Message-ID: <604aa7910710110959x43221d82w7ad0328bc4271448@mail.gmail.com>

On 10/11/07, Tim Lauridsen <tla at rasmil.dk> wrote:
>  It is very important to for yum to do things safely, no one dies by waiting
> a couple of seconds. :)

Yeah it takes at least 10 seconds for me to strangle a kitten.

-jef



From notting at redhat.com  Thu Oct 11 17:10:23 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 11 Oct 2007 13:10:23 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071011122853.GC1324613@hiwaay.net>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<20071011122853.GC1324613@hiwaay.net>
Message-ID: <20071011171023.GC26215@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> Once upon a time, Lubomir Kundrak <lkundrak at redhat.com> said:
> > On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
> > > We should be shipping a CD set. I consistently see people going to Ubuntu
> > > after asking for a Fedora CD and being told they can't update that way.
> > 
> > +1 Exactly this. We should pick packages for an installation that fits
> > in 1CD. Is anyone already working on a one CD spin, or interested in
> > working on it?
> 
> What about using the LiveCD package set?  Would that set of packages
> plus the regular installer fit as a minimal install/upgrade CD?

Fairly sure it doesn't, but I haven't done a test compose.

Bill



From jima at beer.tclug.org  Thu Oct 11 17:16:51 2007
From: jima at beer.tclug.org (Jima)
Date: Thu, 11 Oct 2007 12:16:51 -0500 (CDT)
Subject: yum-updatesd in F8?
In-Reply-To: <604aa7910710110959x43221d82w7ad0328bc4271448@mail.gmail.com>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
	<16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>
	<470E5559.6020700@rasmil.dk>
	<604aa7910710110959x43221d82w7ad0328bc4271448@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0710111216340.4486@beer.tclug.org>

On Thu, 11 Oct 2007, Jeff Spaleta wrote:
> On 10/11/07, Tim Lauridsen <tla at rasmil.dk> wrote:
>>  It is very important to for yum to do things safely, no one dies by waiting
>> a couple of seconds. :)
>
> Yeah it takes at least 10 seconds for me to strangle a kitten.

  You should try kitten_blender, it really speeds things up.

      Jima



From pemboa at gmail.com  Thu Oct 11 17:23:40 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 11 Oct 2007 12:23:40 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <470E5559.6020700@rasmil.dk>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710101509.57799.jamatos@fc.up.pt>
	<16de708d0710100728g2d1d7bbeydfbca63458ab0e77@mail.gmail.com>
	<200710101546.54277.jamatos@fc.up.pt>
	<1192028116.6890.37.camel@localhost.localdomain>
	<1192028348.6741.271.camel@cutter>
	<16de708d0710100823v7ed6b66cs2cc5e5f51b01630e@mail.gmail.com>
	<470E5559.6020700@rasmil.dk>
Message-ID: <16de708d0710111023j6957c06y26bbfe494eef2e7e@mail.gmail.com>

On 10/11/07, Tim Lauridsen <tla at rasmil.dk> wrote:
>
>  Arthur Pemberton wrote:
>  ---------- Forwarded message ----------
> From: seth vidal <skvidal at fedoraproject.org>
> Date: Oct 10, 2007 9:59 AM
> Subject: Re: yum-updatesd in F8?
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
>
>
>
> On Wed, 2007-10-10 at 16:55 +0200, Lubomir Kundrak wrote:
>
>
>  On Wed, 2007-10-10 at 15:46 +0100, Jos? Matos wrote:
>
>
>  On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
>
>
>  And you don't consider that to be blocking?
>
>  Cann't you wait less than 10 seconds (the worst wait time I had)? You are
> really a busy person. ;-)
>
>  Now do a reasonable F-7 desktop installation, and then see if it would
> be less than 10 seconds even if you have a moderately fast internet
> connection. And imaging that you are a newbie and have no idea what
> blocks what and how long would it take, and whether it will ever
> unblock.
>
>
>  If the transaction is being performed what alternative do you have?
>
> reading from the rpmdb while a transaction is occurring is possible you
> just won't be able to rely on the results as 'correct'
>
> Now, if you're talking about grabbing a new copy of the metadata then
> what we've put on the 'future' todo list is downloading he metadata to a
> tmpdir, checking it out and putting it in place once its correct,
> however, that's a bit racy b/c you end up with the potential for 2 or
> more processes to want to write to the same location with, potentially
> different data.
>
> -sv
>
>
> Here's my somewhat similar proposal.
>
> 1) have yum-updatesd copy all the data it needs, put a watch on the
> working dataset for changes
>
> 2) have yum-updates first download all the data it needs to do the update
>
> 3) check the working dataset for changes, if there have been changes
> (more than simply updating the local copy of the meta data) end the
> process here
>
> 4) otherwise put the working dataset into a readonly mode (other UIs
> would be able to read this, and provide the user with feedback
> accordingly without simply blocking)
>
> 5) do updates with the updated dataset copy
>
> 6) then copyover/sync the working dataset with the updated one and
> release the readonly mode (any UIs would be obligated to refresh
> themselves once the readonly mode has been removed
>
> worse case scenario is that user opens a UI seconds after yum-updatesd
> begins downloading packages, and does a full update themselves... in
> which case the data would be downloaded twice - I believe that problem
> too could be mitigated
>
>
>  -1.
>  I don't see the benefit of this, why make it so complex, it will just
> introduce a lot of issues, where things can go wrong.

The benefit would never having yum-updated block other yum tools. This
is not a small problem IMHO

>  It is very important to for yum to do things safely, no one dies by waiting
> a couple of seconds. :)

Well no one dies if yum foobars something either

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From florin at andrei.myip.org  Thu Oct 11 17:32:55 2007
From: florin at andrei.myip.org (Florin Andrei)
Date: Thu, 11 Oct 2007 10:32:55 -0700
Subject: disable cpuspeed while X session active and screensaver not running
Message-ID: <470E5E47.4040006@andrei.myip.org>

On Fedora 7, running on an AMD64 dual core 6400, I disabled cpuspeed.

The results are incredible. Because the CPU clock stays up all the time 
at 3.2GHz, instead of being pushed down most of the time to 1GHz, the 
system feels much faster. All desktop apps seem to react 10x faster. 
It's like upgrading from 486 to P3
The difference in CPU temperature after stopping cpuspeed is barely 
noticeable.

But come to think of it, I only want to disable cpuspeed when these two 
conditions are fulfilled simultaneously:
- an X session is running
- the screensaver is not active
In any other case, cpuspeed should run.

Wait, for laptops, a third condition must be fulfilled too:
- the system is not running on batteries

I'm not sure whether this should be something solved upstream, or not.
Maybe cpuspeed needs to become smarter.
Maybe the distribution needs to do things that involve several different 
components, such as, in this case, xorg, cpuspeed and screensaver.

What do y'all think?

-- 
Florin Andrei

http://florin.myip.org/



From nicolas.mailhot at laposte.net  Thu Oct 11 17:34:10 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 19:34:10 +0200
Subject: samba license change
In-Reply-To: <470E5122.80604@gmail.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<200710102332.46708.opensource@till.name>
	<1192084036.4029.0.camel@rousalka.dyndns.org>
	<200710111607.45639.opensource@till.name>
	<25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>
	<470E3948.3090808@gmail.com>
	<55712.192.54.193.51.1192118355.squirrel@rousalka.dyndns.org>
	<470E5122.80604@gmail.com>
Message-ID: <1192124050.7723.5.camel@rousalka.dyndns.org>


Le jeudi 11 octobre 2007 ? 11:36 -0500, Les Mikesell a ?crit :
> Nicolas Mailhot wrote:
> > Le Jeu 11 octobre 2007 16:55, Les Mikesell a ?crit :
> > 
> >> If you have the right to distribute each component separately and the
> >> existence of a usable gplv2 copy prevents things that happen to link
> >> to the gplv3 version from being considered a derivative work, what's
> > the
> >> problem
> > 
> > Because you can't limit yourself to analysing components separately.
> > The distribution itself is an aggregate work that is subject to
> > copyright laws as a whole.
> 
> Yes, but one part only affects another if it can be considered a 
> derivative work, 

The distribution *as a whole* is a derivative work. You can say parts
are mere aggregation but that does not work for parts that link together
and have no alternative within the distribution (or alternatives
distribution tools will never install). Fedora would not be liable for
GPLv2 foo or GPLv3 samba separately, but by distributing a "Fedora"
product which is both together.

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

From florin at andrei.myip.org  Thu Oct 11 17:43:46 2007
From: florin at andrei.myip.org (Florin Andrei)
Date: Thu, 11 Oct 2007 10:43:46 -0700
Subject: disable cpuspeed while X session active and screensaver not
	running
In-Reply-To: <470E5E47.4040006@andrei.myip.org>
References: <470E5E47.4040006@andrei.myip.org>
Message-ID: <470E60D2.8000808@andrei.myip.org>

Florin Andrei wrote:
> 
> But come to think of it, I only want to disable cpuspeed

Well, it's not even required to disable cpuspeed. It's enough if 
cpuspeed can be told somehow "a user is on the GUI now, and the system 
is not running on batteries, don't throttle the CPU."

When the screensaver kicks in, or when the laptop switches to batteries, 
or when there's no active X session, cpuspeed should be told to resume 
normal throttling.

-- 
Florin Andrei

http://florin.myip.org/



From singularitaet at gmx.net  Thu Oct 11 15:55:02 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Thu, 11 Oct 2007 17:55:02 +0200
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
Message-ID: <200710111755.02714.singularitaet@gmx.net>

After the rawhide update of today, October 10th the Network Manager seems to 
be broken in a way that it interrupts my internet connection completely. I 
cannot activate eth0 manually. Internet works only if the networkmanager is 
not loaded on startup.

I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet 
controller.

Stefan



From denis at poolshark.org  Thu Oct 11 17:53:40 2007
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 11 Oct 2007 19:53:40 +0200
Subject: disable cpuspeed while X session active and screensaver
	not	running
In-Reply-To: <470E60D2.8000808@andrei.myip.org>
References: <470E5E47.4040006@andrei.myip.org>
	<470E60D2.8000808@andrei.myip.org>
Message-ID: <470E6324.6000805@poolshark.org>

Florin Andrei wrote:
> Florin Andrei wrote:
>>
>> But come to think of it, I only want to disable cpuspeed
> 
> Well, it's not even required to disable cpuspeed. It's enough if 
> cpuspeed can be told somehow "a user is on the GUI now, and the system 
> is not running on batteries, don't throttle the CPU."
> 
> When the screensaver kicks in, or when the laptop switches to batteries, 
> or when there's no active X session, cpuspeed should be told to resume 
> normal throttling.

On that subject, does anyone knows how to tell the Frequency Monitor 
applet to keep the cpu in lower frequency all the time (i.e. 'killall 
-USR2 cpuspeed', which is what you want typically when running on 
batteries) ?




From selinux at gmail.com  Thu Oct 11 17:59:13 2007
From: selinux at gmail.com (Tom London)
Date: Thu, 11 Oct 2007 10:59:13 -0700
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <200710111755.02714.singularitaet@gmx.net>
References: <200710111755.02714.singularitaet@gmx.net>
Message-ID: <4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>

On 10/11/07, Stefan Grosse <singularitaet at gmx.net> wrote:
> After the rawhide update of today, October 10th the Network Manager seems to
> be broken in a way that it interrupts my internet connection completely. I
> cannot activate eth0 manually. Internet works only if the networkmanager is
> not loaded on startup.
>
> I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
> a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet
> controller.
>
> Stefan
>
Believe these version of NM allows configurable 'auto connection'.

My would come up with no network connection, but I could manually
select it from the nm-applet.

Applications->System Tools->Configuration Editor allows setting
'autoconnect' for each connection.--

For me, this was 'system->networking->connections->1->connection->autoconnect'

After selecting that, wired comes up like before......

tom
-- 
Tom London



From florin at andrei.myip.org  Thu Oct 11 18:06:56 2007
From: florin at andrei.myip.org (Florin Andrei)
Date: Thu, 11 Oct 2007 11:06:56 -0700
Subject: disable cpuspeed while X session active and screensaver
	not	running
In-Reply-To: <470E60D2.8000808@andrei.myip.org>
References: <470E5E47.4040006@andrei.myip.org>
	<470E60D2.8000808@andrei.myip.org>
Message-ID: <470E6640.3040908@andrei.myip.org>

More cool stuff:
If there is an easy way to control cpuspeed, it would be nice to have 
some sort of dispatcher combine several types of events, make decisions 
based on them, and then send signals to cpuspeed, such as: "don't 
throttle the CPU, we're in the middle of something", or "go ahead and 
throttle, do what you want". Or even "something's wrong, force throttling".

It would be nice if applications had a way to communicate 
throttling-related info to such a dispatcher. E.g., let's say Qjackctl 
is running, and the user clicked on the Start button, so therefore jackd 
is running. In that case, even if the screensaver would later send a 
throttling request, it should be overriden by Qjackctl's own request 
that says "don't throttle, even if screensaver kicks in."
Something like a system of priorities.

I guess what I'm saying is - throttling is technically good, but it's 
something the users may not want, and because it looks like something 
that can be managed by a clever software, the burden of managing 
throttling should not be pushed onto the users.

-- 
Florin Andrei

http://florin.myip.org/



From mattdm at mattdm.org  Thu Oct 11 18:09:45 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 11 Oct 2007 14:09:45 -0400
Subject: improving online upgrade situation [was Re: CDs DVDs or netboot.
	Oh my!]
In-Reply-To: <200710110929.36551.silfreed@silfreed.net>
References: <470D81BB.2070404@redhat.com>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<20071011024611.GA12391@nostromo.devel.redhat.com>
	<200710110929.36551.silfreed@silfreed.net>
Message-ID: <20071011180945.GA18065@jadzia.bu.edu>

On Thu, Oct 11, 2007 at 09:29:36AM -0400, Douglas E. Warner wrote:
> I'm very interested in helping improve the upgrade situation (and 
> especially "online upgrades").  Several of us had a good chat in 
> #fedora-devel last week about it; I still haven't got around to writing up 
> that summary, but it's still on the radar.

One good first step would be to search anaconda for all of its crufty
special-case upgrade code, and create an upgrade-cruft plugin for yum which
replicates that logic.

Then, eventually, anaconda itself can use that plugin as well.



-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Thu Oct 11 18:11:29 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 11 Oct 2007 14:11:29 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192094239.6070.20.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192094239.6070.20.camel@localhost.localdomain>
Message-ID: <20071011181129.GB18065@jadzia.bu.edu>

On Thu, Oct 11, 2007 at 11:17:19AM +0200, Lubomir Kundrak wrote:
> Well, years ago I heard that Caldera's Linux was able to switch to the
> installed system without reboot. SUSE also, if I recall correctly. Not

You can do it with Fedora too with kexec. I did some rudimentary testing of
this with kickstart and it works.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jon.nettleton at gmail.com  Thu Oct 11 18:11:38 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 11 Oct 2007 14:11:38 -0400
Subject: disable cpuspeed while X session active and screensaver not
	running
In-Reply-To: <470E6324.6000805@poolshark.org>
References: <470E5E47.4040006@andrei.myip.org>
	<470E60D2.8000808@andrei.myip.org> <470E6324.6000805@poolshark.org>
Message-ID: <e71b3daf0710111111gb8409far6d5e95b931182f5b@mail.gmail.com>

On 10/11/07, Denis Leroy <denis at poolshark.org> wrote:
> Florin Andrei wrote:
> > Florin Andrei wrote:
> >>
> >> But come to think of it, I only want to disable cpuspeed
> >
> > Well, it's not even required to disable cpuspeed. It's enough if
> > cpuspeed can be told somehow "a user is on the GUI now, and the system
> > is not running on batteries, don't throttle the CPU."
> >
> > When the screensaver kicks in, or when the laptop switches to batteries,
> > or when there's no active X session, cpuspeed should be told to resume
> > normal throttling.
>
> On that subject, does anyone knows how to tell the Frequency Monitor
> applet to keep the cpu in lower frequency all the time (i.e. 'killall
> -USR2 cpuspeed', which is what you want typically when running on
> batteries) ?
>

If you don't run cpuspeed and use the in kernel governors you can
choose the different governor you want to use to control your speed,
or a static speed from the applet.  This is the behavior by default on
newer cpu's, but for some reason the cpuspeed damon is still used on
older processors.  I have some scripts that load these modules for
older cpu's if anyone is interested.

This whole process is being re-architected right now.  This should all
change, hopefully in time for F9.

Jon



From paul at all-the-johnsons.co.uk  Thu Oct 11 18:25:34 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 11 Oct 2007 19:25:34 +0100
Subject: upload cert?
In-Reply-To: <470E3F6F.4050302@redhat.com>
References: <1192116344.4076.0.camel@T7.Linux> <470E3F6F.4050302@redhat.com>
Message-ID: <1192127134.4076.3.camel@T7.Linux>

Hi,

> > Where do I get the fedora-upload cert from?
> >   
> https://admin.fedoraproject.org/accounts/gen-cert.cgi

That's just the fedora.cert one. I've updated mono and libgdiplus. I can
do the make tag, but make build complains that I dont
have .fedora.upload.cert.ca in my /home/paul directory

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071011/1673b0ac/attachment.sig>

From dmc.fedora at filteredperception.org  Thu Oct 11 18:38:48 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Thu, 11 Oct 2007 13:38:48 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192115893.31757.36.camel@oneill.fubar.dk>
References: <470D81BB.2070404@redhat.com>
	<1192069420.19308.15.camel@cutter>	<1192084232.4029.3.camel@rousalka.dyndns.org>
	<1192115893.31757.36.camel@oneill.fubar.dk>
Message-ID: <470E6DB8.2090701@filteredperception.org>

David Zeuthen wrote:
> On Thu, 2007-10-11 at 08:30 +0200, Nicolas Mailhot wrote:
>> Le mercredi 10 octobre 2007 ? 22:23 -0400, seth vidal a ?crit :
>>
>>> livecd - you can do pkg selection after you're installed 
>> And users do not want that. That's the same thing as the "reboot before
>> continuing" windows plague
> 
> It's theoretically possible to do a reboot-less install (google for
> livecd raid broken mirror)

or *cough* *cough*

http://www.redhat.com/archives/fedora-devel-list/2007-July/msg00768.html

  but that is IMO so far into weeds because I
> simply don't think it's true that users are afraid of reboots as you
> state. Hell, we require it for kernel upgrades etc. etc.

FWIW, I did the above not because of user fear of reboots, but rather 
user annoyance at reboots.

-dmc



From szaka at ntfs-3g.org  Thu Oct 11 18:47:27 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Thu, 11 Oct 2007 21:47:27 +0300 (EEST)
Subject: better install experience
In-Reply-To: <364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>


On Thu, 11 Oct 2007, Christopher Brown wrote:
> On 11/10/2007, Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:
> > On 10/10/2007, Christopher Brown wrote:
> > >     On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> > >
> > > >    There are two ntfs implementations. One is old, crufted, and poorly
> > > >    maintained.
> 
> Not sure what is to blame here but Thorsten didn't write that, Spot did.

Yep, my fault. Your white space indentation confuses my MUA.
 
> > > Sorry but that is bullshit. Old and crufted aren't very good technical
> >
> > As I mentioned previously, the kernel driver and ntfs-3g have the same
> > source base. When I developed ntfs-3g then I noted the potentially serious
> > problems in the kernel (e.g. in truncate). I also mentioned them to Dave
> > Jones. I never got a reply for any of my emails.
> 
> You're surprised by that?

To be honest, yes. Very much. We take bug reports, especially when 
potential corruption is involved, very seriously. We investigate and reply 
all of them and urgently fix it if needed, which is followed by a rapid 
stable release when the automtic tests pass.

As far as I know, but please correct me if I'm wrong, Dave Jones is 
(apparently was?) even paid to do this. So, some reply like "thanks, I'll 
take a quick look or forwarded it to X.Y" would have been appreciated.

So, why shouldn't one be surprised when a maintainer doesn't reply to bug 
reports he is responsible for? Please tell us, I'm really interested.

> I'm mad keen to see figures of enterprise installations running FUSE over
> kernel drivers. I mean _really_ keen.

Check out virtualization, security softwares, embedded devices, etc. More 
is coming to the market but obviously most companies prefer not to reveal 
what they use. FUSE is great invention to develop higher quality, more 
reliable and featureful software __faster__.

> > I've worked with him 4 years when it was decided finally a year ago 
> > that a partial fork is needed to ensure driver reliability and 
> > maintainability.
> 
> Partial? Could you define this? 

libntfs + ntfsmount, not the utilities. The utilities are being forked 
rigth now.

> Please remember that I was/am a member of the linux-ntfs project and 
> although my contribution was only in the package department for Rich 
> Russon when he was around, there was nothing to indicate you were 
> intending to fork. 

Then you didn't follow the linux-ntfs-dev discussions carefully.

> and even then there was no real reason given in your announcement that 
> you were doing it for the above purpose.

There were quite many reasons. 

> Whats wrong with bugging Linus to get it applied then? I'm having a hard
> time believe crucial fixes sit in cvs simply because someone wont write an
> email saying "Linus, please apply...". If Anton wont sign off (or comment)
> then I'm inclined to agree the driver is dead in the water but it doesn't
> look like this happened.

The release has nothing to do with Linus or the kernel. The maintainer 
could have make the release himself anytime in 10 minutes. He did now 
because finally somebody wrote the announcement and made him to do so. 

> It would probably benefit from having any post-fork detail removed. As it
> currently stands it might be interpreted that the reason for the fork was
> the the kernel driver was not going to be released until 2008. 

Of course that was also a very serious reason. 

> I'm still at a loss as to why you forked but then I was not privy to 
> conversations that went on behind the scenes perhaps.

There wasn't any privy behind the scenes. Or at least I wasn't involved in 
any. 

> >     Here is my original announcement:
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.21.0607141859080.31588-100000%40mlf.linux.rulez.org
>
> The announcement came without warning - this is my issue. 

The announcement went to the __development__ list. The announcement was 
itself the warning. It was not a public announcement. Nobody does a warning 
before sending something the a devel list because the sending itself is the 
warning. 

> It would've been nice to have seen a "I'm thinking of forking because of 
> a, b, c etc. Can anything be done?". So yeah, I'm a little sad that the 
> project split and now confusion reigns.

You're also confusing two things here. The announcement was in the middle 
of July and the fork at the end of October when it became obvious things 
doesn't work out as they should.

> > It actually has nothing to do with the kernel driver.
> >
> > As I wrote, it has quite a lot, in fact.
> 
> Please stop editing the posts like this; it is really bad form. 

As soon as you stop indenting emails with white spaces, the MUAs will also 
quote it properly ;-)

> NTFS-3g is separate and distinct from the kernel driver. One is not 
> reliant on the other but perhaps you misunderstood me.

Could be. I'm not a native English speaker but a Hungarian one. For me this 
is not a question of belief but a very precisely "measurable" software 
engineering:
	
	http://ntfs-3g.org/quality.html#testmethods
 
> Please don't take this as criticism of ntfs-3g - I think it was a long time
> (too long) in coming and enables lots of interesting things to happen. Keep
> up the excellent work - I'm all in favour of choice which is what the
> original argument was all about.

Thanks,
	    Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From buildsys at fedoraproject.org  Thu Oct 11 19:04:59 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 11 Oct 2007 15:04:59 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-11
Message-ID: <20071011190459.6557715212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 8

NEW astromenace-1.2-3.fc6 : Hardcore 3D space shooter with spaceship upgrade possibilities
NEW astromenace-data-1.2-1.fc6 : Hardcore 3D space shooter with spaceship upgrade possibilities
NEW fuse-python-0.2-5.fc6 : Python bindings for FUSE - filesystem in userspace
    libpng10-1.0.29-1.fc6
NEW qfits-6.2.0-3.fc6 : A stand-alone general purpose FITS library and command line utilities
    sysprof-kmod-1.0.8-1.2.6.22.9_61.fc6
    Zim-0.21-1.fc6
    zynaddsubfx-2.2.1-15.fc6


Changes in Fedora Extras 6: 


astromenace-1.2-3.fc6
---------------------
* Mon Oct 08 2007 Jon Ciesla <limb at jcomserv.net> - 1.2-3
- Added support for opengl-games-utils(F7+ only), .desktop cleanup.

* Fri Oct 05 2007 Jon Ciesla <limb at jcomserv.net> - 1.2-2
- Used main upstream sources, not sf.net fork.
- Patched for gamelang paths.

* Tue Oct 02 2007 Jon Ciesla <limb at jcomserv.net> - 1.2-1
- create.

astromenace-data-1.2-1.fc6
--------------------------
* Tue Oct 02 2007 Jon Ciesla <limb at jcomserv.net> - 1.2-1
- create.

fuse-python-0.2-5.fc6
---------------------
* Fri Oct 05 2007 Peter Lemenkov <lemenkov at gmail.com> 0.2-5
- Removed BR: python-devel (excessive since we BR: python-setuptool)
- Cleaned up mixed usage of macros and explicit commands ( __python and python)

* Fri Oct 05 2007 Peter Lemenkov <lemenkov at gmail.com> 0.2-4
- Changes according to http://fedoraproject.org/wiki/Packaging/Python/Eggs

libpng10-1.0.29-1.fc6
---------------------
* Fri Oct 05 2007 Paul Howarth <paul at city-fan.org> 1.0.29-1
- update to 1.0.29

* Tue Sep 11 2007 Paul Howarth <paul at city-fan.org> 1.0.28-1
- update to 1.0.28

* Mon Aug 20 2007 Paul Howarth <paul at city-fan.org> 1.0.27-1
- update to 1.0.27
- add new file ANNOUNCE, which lists changes since last release
- use shortname "zlib" for the license tag (package is zlib/libpng licensed)
- drop pkgconf patch, which should no longer be needed

qfits-6.2.0-3.fc6
-----------------
* Sun Sep 23 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 6.2.0-3
- Renaming: qfits qfits-libs and qfits-devel
- Using the testsuite

* Fri Sep 21 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 6.2.0-2
- Renaming: qfits qfits-lib and qfits-tools to qfits
- Removed Requires ldconfig
- defattr changed
- Keeping timestamps
- buildroot changed to the preferred option

* Fri Sep 21 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 6.2.0-1
- Patched to use properly the open function with O_CREAT

* Thu Sep 13 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 6.2.0-0.4
- Updating license tag to new Fedora guidelines

sysprof-kmod-1.0.8-1.2.6.22.9_61.fc6
------------------------------------
* Tue Aug 21 2007 Gianluca Sforna <giallu gmail com>
- Update License field

Zim-0.21-1.fc6
--------------
* Wed Oct 03 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.21-1
- update to 0.21
- add contrib/, TRepository.PL to doc
- update license tag: GPL -> GPL+
- add a requires on scrot, for the InsertScreenshot plugin

* Wed May 30 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.19-2
- add a require on Gtk2::TrayIcon; not picked up automatically
- some BR refactoring given perl splittage

zynaddsubfx-2.2.1-15.fc6
------------------------
* Wed Oct 10 2007 Fernando Lopez-Lezcano <nando at ccrma.stanford.edu> 2.2.1-15
- added tweaked unzombify patch by Lars Luthman (patch3), see:
  http://sourceforge.net/tracker/index.php?func=detail&aid=1498438&group_id=62934&atid=502314

* Fri Apr 06 2007 Anthony Green <green at redhat.com> 2.2.1-14
- Rebuild with new ImageMagick for working desktop icons.



From dcbw at redhat.com  Thu Oct 11 19:11:30 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 11 Oct 2007 15:11:30 -0400
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
References: <200710111755.02714.singularitaet@gmx.net>
	<4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
Message-ID: <1192129890.29673.1.camel@localhost.localdomain>

On Thu, 2007-10-11 at 10:59 -0700, Tom London wrote:
> On 10/11/07, Stefan Grosse <singularitaet at gmx.net> wrote:
> > After the rawhide update of today, October 10th the Network Manager seems to
> > be broken in a way that it interrupts my internet connection completely. I
> > cannot activate eth0 manually. Internet works only if the networkmanager is
> > not loaded on startup.
> >
> > I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
> > a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet
> > controller.
> >
> > Stefan
> >
> Believe these version of NM allows configurable 'auto connection'.
> 
> My would come up with no network connection, but I could manually
> select it from the nm-applet.

Right; up until last week NM 0.7 didnt have the bits to store the
network timestamp, and therefore autoconnect was turned off.  New
connections will have autoconnect turned on for a connection that you
choose from the menu.  You can update your existing connections to
autoconnect in gconf-editor or (soon) the connection editor.

Dan

> Applications->System Tools->Configuration Editor allows setting
> 'autoconnect' for each connection.--
> 
> For me, this was 'system->networking->connections->1->connection->autoconnect'
> 
> After selecting that, wired comes up like before......
> 
> tom
> -- 
> Tom London
> 



From dcbw at redhat.com  Thu Oct 11 19:11:54 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 11 Oct 2007 15:11:54 -0400
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <200710111755.02714.singularitaet@gmx.net>
References: <200710111755.02714.singularitaet@gmx.net>
Message-ID: <1192129914.29673.3.camel@localhost.localdomain>

On Thu, 2007-10-11 at 17:55 +0200, Stefan Grosse wrote:
> After the rawhide update of today, October 10th the Network Manager seems to 
> be broken in a way that it interrupts my internet connection completely. I 
> cannot activate eth0 manually. Internet works only if the networkmanager is 
> not loaded on startup.

Could you post some logs (or send them to me directly or attach to a bug
report) from /var/log/messages during a connection attempt?

Dan

> I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
> a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet 
> controller.
> 
> Stefan
> 



From luya_tfz at thefinalzone.com  Thu Oct 11 19:21:40 2007
From: luya_tfz at thefinalzone.com (Luya Tshimbalanga)
Date: Thu, 11 Oct 2007 12:21:40 -0700
Subject: Yum ambiguity
Message-ID: <470E77C4.3010608@thefinalzone.com>

Trying to install from development repository:


Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Updating:
 gimp                    x86_64     2:2.4.0-0.rc3.1.fc8 
development        13 M
Updating for dependencies:
 evince                  x86_64     2.20.0-3.fc8     development       1.2 M
 gimp-libs               x86_64     2:2.4.0-0.rc3.1.fc8 
development       574 k
 glibc                   x86_64     2.6.90-18        development       4.8 M
 glibc                   i686       2.6.90-18        development       5.4 M
 glibc-common            x86_64     2.6.90-18        development        21 M
 glibc-devel             x86_64     2.6.90-18        development       2.4 M
 glibc-headers           x86_64     2.6.90-18        development       598 k
 koffice-core            x86_64     1.6.3-11.fc8     development       1.7 M
 koffice-filters         x86_64     1.6.3-11.fc8     development       2.1 M
 koffice-kexi            x86_64     1.6.3-11.fc8     development       3.4 M
 koffice-krita           x86_64     1.6.3-11.fc8     development        31 M
 koffice-libs            x86_64     1.6.3-11.fc8     development       4.6 M
 poppler                 x86_64     0.6-1.fc8        development       3.1 M
 poppler-qt              x86_64     0.6-1.fc8        development        29 k

Transaction Summary
=============================================================================
Install      0 Package(s)        
Update      15 Package(s)        
Remove       0 Package(s)        

Total download size: 95 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): glibc-headers-2.6. 100% |=========================| 598 kB   
00:04    
(2/5): glibc-2.6.90-18.i6 100% |=========================| 5.4 MB   
00:42    
(3/5): glibc-devel-2.6.90 100% |=========================| 2.4 MB   
00:18    
(4/5): glibc-2.6.90-18.x8 100% |=========================| 4.8 MB   
00:38    
(5/5): glibc-common-2.6.9 100% |=========================|  21 MB   
02:42    
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
Package glibc-devel needs glibc = 2.6-4, this is not available.
Package glibc-devel needs glibc = 2.6-4, this is not available.
Package glibc-devel needs glibc-headers = 2.6-4, this is not available.
Package glibc-devel needs glibc-headers = 2.6-4, this is not available.
Complete!


There is no explanation about the package which can confuse users. It
looks like
those packagers are identical but there is no specification about the
architectures.

I have submitted a bug report on
https://bugzilla.redhat.com/show_bug.cgi?id=328141


Luya



From list+rh at meyering.net  Thu Oct 11 18:14:01 2007
From: list+rh at meyering.net (Jim Meyering)
Date: Thu, 11 Oct 2007 20:14:01 +0200
Subject: fedora8t2 install-from-DVD-w/no-net -> empty /etc/hosts
Message-ID: <87y7e9msd2.fsf@rho.meyering.net>

For the record, in case this can help someone else solve the same
problem, or fix the root-cause:

I installed fedora8t2 on new hardware and came up with no network.
The on-board NIC was not recognized by the kernel, so initially I
had no network.  I installed a PCI NIC for long enough to boot
and upgrade to the latest rawhide, and then, the on-board NICs were
recognized.  Later, I saw that running "ssh -Y host any-x-app" to that
system would always fail with this:

Error: Can't open display: localhost:11.0

The cause turned out to be that /etc/hosts was empty,
so the system failed to resolve "localhost".

My solution was to add this line to /etc/hosts:

127.0.0.1 localhost



From kevin.kofler at chello.at  Thu Oct 11 19:12:53 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Oct 2007 19:12:53 +0000 (UTC)
Subject: The gstreamer third way
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
Message-ID: <loom.20071011T191138-597@post.gmane.org>

Nicu Buculei <nicu_fedora <at> nicubunu.ro> writes:
> No. The ugly gstreamer plugins don't have a license problem, but a 
> patents problem and this problem apply only on certain parts of the 
> world, there are other parts where they are perfectly fine from any 
> point of view.

Yet third-party repositories are happily distributing proprietary kmod-nvidia 
modules linked against the GPLv2 kernel, which isn't any more legal than 
distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.

        Kevin Kofler



From paul at xelerance.com  Thu Oct 11 19:34:29 2007
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 11 Oct 2007 15:34:29 -0400 (EDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM machine
Message-ID: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>


Hi,

This isue is problably known, but I wanted to bring it up anyway.

ExecSum: Running a 64bit Fedora 7 Test 2 with 1GB RAM fails to update

Long story: Yum failed me while trying to update from rawhide today:

Transaction Summary
=============================================================================
Install     50 Package(s)
Update     702 Package(s)
Remove       1 Package(s)

Total download size: 976 M
Is this ok [y/N]: y
Downloading Packages:
[...]
Transaction Test Succeeded
Running Transaction
  Updating  : libgcc                       ################### [   1/1461]
error: Couldn't fork %post: Cannot allocate memory

The system was running X with default daemons. Memory usage shows this
as the top five users:

Tasks: 137 total,   2 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s): 10.6%us,  1.3%sy,  0.0%ni, 88.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1013676k total,   782344k used,   231332k free,     8788k buffers
Swap:   522104k total,   452872k used,    69232k free,   164116k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3983 paul      20   0 1002m 284m  19m R  9.9 28.7  32:17.87 firefox-bin
 2582 root      20   0  568m 106m 4680 S  0.7 10.8 198:43.15 X
 2931 paul      20   0  351m  24m 7496 S  0.0  2.5   7:38.91 gnome-terminal
 2883 paul      20   0  288m  15m 8064 S  0.0  1.6   8:34.15 wnck-applet
 2859 paul      20   0  267m  11m 9264 S  0.0  1.2   0:10.26 puplet

Firefox had 3 pages open, nothing special (eg news pages). I was running
8 xterms, with either a bash command prompt, vi on a small file, or ssh.

That alone takes up 406MB of my 1GB of ram. Looks a bit excessive to me.

When yum died, i checked the above usage, so it looks like yum tried to
use more then 300Mb of non shared RAM. That's pretty insane. Worst thing,
is that it had *completed* all the dependancy checks, so I'm a bit confused
why it still needs so much memory. All it needs at that point (it was
installing the 1st rpm), is the list of 752 package filenames in an
install-order list. Why is that taking up 300MB?

Paul



From limb at jcomserv.net  Thu Oct 11 19:37:36 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 11 Oct 2007 14:37:36 -0500 (CDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM 
 machine
In-Reply-To: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
Message-ID: <16100.63.85.68.164.1192131456.squirrel@mail.jcomserv.net>


>
> Hi,
>
> This isue is problably known, but I wanted to bring it up anyway.
>
> ExecSum: Running a 64bit Fedora 7 Test 2 with 1GB RAM fails to update
>
> Long story: Yum failed me while trying to update from rawhide today:
>
> Transaction Summary
> =============================================================================
> Install     50 Package(s)
> Update     702 Package(s)
> Remove       1 Package(s)
>
> Total download size: 976 M
> Is this ok [y/N]: y
> Downloading Packages:
> [...]
> Transaction Test Succeeded
> Running Transaction
>   Updating  : libgcc                       ################### [   1/1461]
> error: Couldn't fork %post: Cannot allocate memory
>
> The system was running X with default daemons. Memory usage shows this
> as the top five users:
>
> Tasks: 137 total,   2 running, 135 sleeping,   0 stopped,   0 zombie
> Cpu(s): 10.6%us,  1.3%sy,  0.0%ni, 88.1%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Mem:   1013676k total,   782344k used,   231332k free,     8788k buffers
> Swap:   522104k total,   452872k used,    69232k free,   164116k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  3983 paul      20   0 1002m 284m  19m R  9.9 28.7  32:17.87 firefox-bin
>  2582 root      20   0  568m 106m 4680 S  0.7 10.8 198:43.15 X
>  2931 paul      20   0  351m  24m 7496 S  0.0  2.5   7:38.91
> gnome-terminal
>  2883 paul      20   0  288m  15m 8064 S  0.0  1.6   8:34.15 wnck-applet
>  2859 paul      20   0  267m  11m 9264 S  0.0  1.2   0:10.26 puplet
>
> Firefox had 3 pages open, nothing special (eg news pages). I was running
> 8 xterms, with either a bash command prompt, vi on a small file, or ssh.
>
> That alone takes up 406MB of my 1GB of ram. Looks a bit excessive to me.
>
> When yum died, i checked the above usage, so it looks like yum tried to
> use more then 300Mb of non shared RAM. That's pretty insane. Worst thing,
> is that it had *completed* all the dependancy checks, so I'm a bit
> confused
> why it still needs so much memory. All it needs at that point (it was
> installing the 1st rpm), is the list of 752 package filenames in an
> install-order list. Why is that taking up 300MB?

Not to pick nits, but why are you running F7 test 2, out of curiousity?

> Paul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From singularitaet at gmx.net  Thu Oct 11 19:48:19 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Thu, 11 Oct 2007 21:48:19 +0200
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <1192129914.29673.3.camel@localhost.localdomain>
References: <200710111755.02714.singularitaet@gmx.net>
	<1192129914.29673.3.camel@localhost.localdomain>
Message-ID: <200710112148.19923.singularitaet@gmx.net>

On Thursday 11 October 2007 21:11:54 Dan Williams wrote:
DW > Could you post some logs (or send them to me directly or attach to a bug
DW > report) from /var/log/messages during a connection attempt?
DW >
DW > Dan

OK, here is the log from the kernel booting (NM part):

Oct 11 21:32:13 noname kernel: r8169: eth0: link up
Oct 11 21:32:13 noname kernel: r8169: eth0: link up
Oct 11 21:32:43 noname NetworkManager: <info>  starting...
Oct 11 21:32:43 noname NetworkManager: <info>  eth0: Device is fully-supported 
using driver 'r8169'.
Oct 11 21:32:43 noname NetworkManager: <info>  Now managing wired Ethernet 
(802.3) device 'eth0'.
Oct 11 21:32:43 noname NetworkManager: <info>  Bringing down device eth0
Oct 11 21:32:43 noname dhclient: receive_packet failed on eth0: Network is 
down
Oct 11 21:32:45 noname NetworkManager: <info>  Bringing up device eth0
Oct 11 21:32:45 noname kernel: r8169: eth0: link up
Oct 11 21:32:45 noname NetworkManager: <info>  Deactivating device eth0.
Oct 11 21:32:45 noname NetworkManager: <info>  wlan0: Device is 
fully-supported using driver 'iwl3945'.
Oct 11 21:32:45 noname NetworkManager: <info>  Now managing wireless (802.11) 
device 'wlan0'.
Oct 11 21:32:45 noname NetworkManager: <info>  Bringing up device wlan0
Oct 11 21:32:45 noname kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 11 21:32:45 noname NetworkManager: <info>  Deactivating device wlan0.

So no network if I start my KDE session. Interestingly if I start nm-applet 
manually in console (havent found it in the KDE menus) eth0 seems to work:

Oct 11 21:35:50 noname NetworkManager: <info>  SWITCH: no current connection, 
found better connection 'Auto Ethernet (eth0)'.
Oct 11 21:35:50 noname NetworkManager: <info>  Activating device eth0
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 1 of 5 
(Device Prepare) scheduled...
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 1 of 5 
(Device Prepare) started...
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 2 of 5 
(Device Configure) scheduled...
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 1 of 5 
(Device Prepare) complete.
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 2 of 5 
(Device Configure) starting...
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 2 of 5 
(Device Configure) successful.
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 3 of 5 
(IP Configure Start) scheduled.
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 2 of 5 
(Device Configure) complete.
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 3 of 5 
(IP Configure Start) started...
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Beginning 
DHCP transaction.
Oct 11 21:35:50 noname NetworkManager: <info>  dhclient started with pid 3294
Oct 11 21:35:50 noname NetworkManager: <info>  Activation (eth0) Stage 3 of 5 
(IP Configure Start) complete.



From james.antill at redhat.com  Thu Oct 11 20:08:58 2007
From: james.antill at redhat.com (James Antill)
Date: Thu, 11 Oct 2007 16:08:58 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
Message-ID: <1192133338.19494.10.camel@code.and.org>

On Thu, 2007-10-11 at 15:34 -0400, Paul Wouters wrote:
> Hi,
> 
> This isue is problably known, but I wanted to bring it up anyway.
> 
> ExecSum: Running a 64bit Fedora 7 Test 2 with 1GB RAM fails to update

 Yes, we want yum to use less memory and be faster, hoever...

> Long story: Yum failed me while trying to update from rawhide today:

 Not quite.

> Transaction Summary
> =============================================================================
> Install     50 Package(s)
> Update     702 Package(s)
> Remove       1 Package(s)
> 
> Total download size: 976 M
> Is this ok [y/N]: y
> Downloading Packages:
> [...]
> Transaction Test Succeeded
> Running Transaction
>   Updating  : libgcc                       ################### [   1/1461]
> error: Couldn't fork %post: Cannot allocate memory
> 
> The system was running X with default daemons. Memory usage shows this
> as the top five users:
> 
> Tasks: 137 total,   2 running, 135 sleeping,   0 stopped,   0 zombie
> Cpu(s): 10.6%us,  1.3%sy,  0.0%ni, 88.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   1013676k total,   782344k used,   231332k free,     8788k buffers
> Swap:   522104k total,   452872k used,    69232k free,   164116k cached

 You have 522MB of Swap, and 450MB is used. Add more swap. You may also
find that you have a lot of dead memory due to updated files. prelink
esp. is great for this.
 I've attached a simple python script I've used, it's not perfect but it
shows roughly how much dead memory you have and will kind of show where
it is.

> When yum died, i checked the above usage, so it looks like yum tried to
> use more then 300Mb of non shared RAM. That's pretty insane. Worst thing,
> is that it had *completed* all the dependancy checks, so I'm a bit confused
> why it still needs so much memory. All it needs at that point (it was
> installing the 1st rpm), is the list of 752 package filenames in an
> install-order list. Why is that taking up 300MB?

 300MB to upgrade 1GB of data is excessive?

-- 
James Antill -- <james.antill at redhat.com>
"Please, no.  Let's not pull in a dependency for something as simple as a
string library." -- Kristian H?gsberg <krh at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wasted-ram-updates.py
Type: text/x-python
Size: 4594 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/39a8cdcf/attachment.py>
-------------- 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/20071011/39a8cdcf/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Oct 11 20:09:20 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 11 Oct 2007 22:09:20 +0200
Subject: The gstreamer third way
In-Reply-To: <loom.20071011T191138-597@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
Message-ID: <1192133361.7723.7.camel@rousalka.dyndns.org>


Le jeudi 11 octobre 2007 ? 19:12 +0000, Kevin Kofler a ?crit :
> Nicu Buculei <nicu_fedora <at> nicubunu.ro> writes:
> > No. The ugly gstreamer plugins don't have a license problem, but a 
> > patents problem and this problem apply only on certain parts of the 
> > world, there are other parts where they are perfectly fine from any 
> > point of view.
> 
> Yet third-party repositories are happily distributing proprietary kmod-nvidia 
> modules linked against the GPLv2 kernel, which isn't any more legal than 
> distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.

Last I checked they're not distributing both kmod-nvidia and kernels in
the same repo

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

From davej at redhat.com  Thu Oct 11 20:12:38 2007
From: davej at redhat.com (Dave Jones)
Date: Thu, 11 Oct 2007 16:12:38 -0400
Subject: better install experience
In-Reply-To: <Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
Message-ID: <20071011201238.GA17998@redhat.com>

On Thu, Oct 11, 2007 at 09:47:27PM +0300, Szabolcs Szakacsits wrote:

 > As far as I know, but please correct me if I'm wrong, Dave Jones is 
 > (apparently was?) even paid to do this. So, some reply like "thanks, I'll 
 > take a quick look or forwarded it to X.Y" would have been appreciated.
 > 
 > So, why shouldn't one be surprised when a maintainer doesn't reply to bug 
 > reports he is responsible for? Please tell us, I'm really interested.

I apologise for not replying. I get crazy amounts of mail, and sometimes
stuff falls through the cracks.  A grep for your name in my mboxes from
this year doesn't have any hits, so its possible I even didn't get it
somehow ?

	Dave

-- 
http://www.codemonkey.org.uk



From kevin.kofler at chello.at  Thu Oct 11 20:07:40 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Oct 2007 20:07:40 +0000 (UTC)
Subject: xdg-menu, icewm and bluecurve-icon-theme's missing sym-links.
References: <1192107172.32192.16.camel@gilboa-work-dev.localdomain>
Message-ID: <loom.20071011T200657-803@post.gmane.org>

Gilboa Davara <gilboad <at> gmail.com> writes:
> However, the old package contained a number of syn-links that are no
> longer included in the new package. (E.g. gnome-terminal.png ->
> icon-terminal.png; mozilla-icon.png -> icon-web-browser.png; etc)

Then here's the real problem, please file a bug against bluecurve-icon-theme to 
get this fixed ASAP, the symlinks are needed by many other things too, they 
can't just go away.

        Kevin Kofler



From paul at xelerance.com  Thu Oct 11 20:28:00 2007
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 11 Oct 2007 16:28:00 -0400 (EDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM
 machine
In-Reply-To: <1192133338.19494.10.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org>
Message-ID: <Pine.LNX.4.64.0710111624000.27419@newtla.xelerance.com>

On Thu, 11 Oct 2007, James Antill wrote:

>  You have 522MB of Swap, and 450MB is used. Add more swap. You may also
> find that you have a lot of dead memory due to updated files. prelink
> esp. is great for this.
>  I've attached a simple python script I've used, it's not perfect but it
> shows roughly how much dead memory you have and will kind of show where
> it is.

I'll have a look at it, thanks!

> > why it still needs so much memory. All it needs at that point (it was
> > installing the 1st rpm), is the list of 752 package filenames in an
> > install-order list. Why is that taking up 300MB?
>
>  300MB to upgrade 1GB of data is excessive?

Well, yeah. quite. But apart from that.

When yum reaches the point of actually installing things, after
all the memory intensive dependancy computations, the only thing it
should need to remember is the ordered list of rpm packages to install
(assuming yum can't just call rpm with the packages in order). It
should be able to free most of the memory it had to use to calculate
the ordered list of packages. I am talking in the order of a few kbytes,
not 300MB.

Paul



From kevin.kofler at chello.at  Thu Oct 11 20:12:52 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Oct 2007 20:12:52 +0000 (UTC)
Subject: The gstreamer third way
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
Message-ID: <loom.20071011T201209-819@post.gmane.org>

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> Le jeudi 11 octobre 2007 ? 19:12 +0000, Kevin Kofler a ?crit :
> > Yet third-party repositories are happily distributing proprietary 
kmod-nvidia 
> > modules linked against the GPLv2 kernel, which isn't any more legal than 
> > distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.
> 
> Last I checked they're not distributing both kmod-nvidia and kernels in
> the same repo

They wouldn't be shipping Samba in the third-party repo either.

        Kevin Kofler



From opensource at till.name  Thu Oct 11 20:32:19 2007
From: opensource at till.name (Till Maas)
Date: Thu, 11 Oct 2007 22:32:19 +0200
Subject: upload cert?
In-Reply-To: <1192116344.4076.0.camel@T7.Linux>
References: <1192116344.4076.0.camel@T7.Linux>
Message-ID: <200710112232.24931.opensource@till.name>

On Do Oktober 11 2007, Paul wrote:

> Where do I get the fedora-upload cert from?

https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert
https://admin.fedoraproject.org/accounts/fedora-server-ca.cert
Source: http://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/eb4cbe6c/attachment.sig>

From seandarcy2 at gmail.com  Thu Oct 11 20:26:54 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Thu, 11 Oct 2007 16:26:54 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM 
 machine
In-Reply-To: <1192133338.19494.10.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org>
Message-ID: <fem0ue$qg8$1@sea.gmane.org>

James Antill wrote:
................
>  I've attached a simple python script I've used, it's not perfect but it
> shows roughly how much dead memory you have and will kind of show where
> it is.
> 

Great script. But is rebooting the only answer?

I wondered whether prelink cleaned up after itself.

sean



From paul at xelerance.com  Thu Oct 11 20:39:06 2007
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 11 Oct 2007 16:39:06 -0400 (EDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM
 machine
In-Reply-To: <1192133338.19494.10.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org>
Message-ID: <Pine.LNX.4.64.0710111633500.27419@newtla.xelerance.com>

On Thu, 11 Oct 2007, James Antill wrote:

> > Mem:   1013676k total,   782344k used,   231332k free,     8788k buffers
> > Swap:   522104k total,   452872k used,    69232k free,   164116k cached
>
>  You have 522MB of Swap, and 450MB is used. Add more swap.

Well, yum forced everything else into swap when it tried to take more memory
then I had.

> You may also
> find that you have a lot of dead memory due to updated files. prelink
> esp. is great for this.
>  I've attached a simple python script I've used, it's not perfect but it
> shows roughly how much dead memory you have and will kind of show where
> it is.

Your script shows:

num             = 20
vsz             = 2,225,954,816
------------------------------------------------------------------------------
s_size          = 2,225,954,816
s_rss           = 14,172,160
s_shared_clean  = 13,312,000
s_shared_dirty  = 0
s_private_clean = 389,120
s_private_dirty = 471,040
referenced      = 13,869,056

If I read this correctly, that isn't that much memory lost. And most of
that could be, because I'm running rpm -Uhv in the other window now on
those packages yum downloaded and it has installed 612 of the updates now,
causing old libraries are still used but deleted to take up extra RAM.
(eg your script shows me /lib64/libgthread-2.0.so.0.1400.0,
/lib64/libgmodule-2.0.so.0.1400.0, /usr/lib64/libORBitCosNaming-2.so.0.1.0 etc)

Note that yum died on the first package it tried to install, so these
old packages files that are in use but deleted, didn't play a part in the
original (dead) memory usage.

Paul



From szaka at ntfs-3g.org  Thu Oct 11 20:46:23 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Thu, 11 Oct 2007 23:46:23 +0300 (EEST)
Subject: better install experience
In-Reply-To: <20071011201238.GA17998@redhat.com>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
	<20071011201238.GA17998@redhat.com>
Message-ID: <Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>


On Thu, 11 Oct 2007, Dave Jones wrote:
> On Thu, Oct 11, 2007 at 09:47:27PM +0300, Szabolcs Szakacsits wrote:
> 
>  > As far as I know, but please correct me if I'm wrong, Dave Jones is 
>  > (apparently was?) even paid to do this. So, some reply like "thanks, I'll 
>  > take a quick look or forwarded it to X.Y" would have been appreciated.
>  > 
>  > So, why shouldn't one be surprised when a maintainer doesn't reply to bug 
>  > reports he is responsible for? Please tell us, I'm really interested.
> 
> I apologise for not replying. I get crazy amounts of mail, and sometimes 
> stuff falls through the cracks.  A grep for your name in my mboxes from 
> this year doesn't have any hits, so its possible I even didn't get it 
> somehow ?

It was last year:

--------------------------------------------------------------------------->
 Date: Mon, 23 Oct 2006 02:00:52 +0300 (MET DST)
 From: Szakacsits Szabolcs <szaka at sienet.hu>
 To: Dave Jones <davej at redhat.com>
 Subject: Re: ntfs kernel module

 [...]

 > the kernel driver is "safer".

 I'm not sure. It's true that its functionality is very limited (ntfs-3g 
 also supports read-only mounts of course) but

        - unlike ntfs-3g, the kernel driver isn't quality tested 

        - I've fixed many problems in the NTFS code base which could also 
          exist in the kernel driver. One of the most serious bugs I 
          remember was freeing memory in truncate() which could be modified 
          later on (random memory corruptions).

  [...]
<-----------------------------------------------------------------------------

Regards,
	    Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From jreiser at BitWagon.com  Thu Oct 11 20:52:09 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Thu, 11 Oct 2007 13:52:09 -0700
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <Pine.LNX.4.64.0710111624000.27419@newtla.xelerance.com>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>	<1192133338.19494.10.camel@code.and.org>
	<Pine.LNX.4.64.0710111624000.27419@newtla.xelerance.com>
Message-ID: <470E8CF9.9000604@BitWagon.com>

> When yum reaches the point of actually installing things, after
> all the memory intensive dependancy computations, the only thing it
> should need to remember is the ordered list of rpm packages to install
> (assuming yum can't just call rpm with the packages in order). It
> should be able to free most of the memory it had to use to calculate
> the ordered list of packages. I am talking in the order of a few kbytes,
> not 300MB.

Python is an interpreted language with garbage collection,
and address-space fragmentation rears its ugly head.  Mere free() won't
do enough.  A compact() is also needed, but is not available in the API.(!)

One way is to build the list of rpm in a file or pipe, and use a shell script
for top-level control.  Using a file has advantages for divide-and-conquer.
Another way to do this is for the top-level to fork(), with the child
doing the work for each major phase.  Then each child is guaranteed
to start out with the same small and compact layout of memory.

-- 



From jfrieben at gmx.de  Thu Oct 11 20:59:05 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Thu, 11 Oct 2007 22:59:05 +0200
Subject: xdg-menu, icewm and bluecurve-icon-theme's missing sym-links.
In-Reply-To: <loom.20071011T200657-803@post.gmane.org>
References: <1192107172.32192.16.camel@gilboa-work-dev.localdomain>
	<loom.20071011T200657-803@post.gmane.org>
Message-ID: <20071011205905.286380@gmx.net>

> Then here's the real problem, please file a bug against
> bluecurve-icon-theme to 
> get this fixed ASAP, the symlinks are needed by many other things too,
> they 
> can't just go away.
> 
>         Kevin Kofler

  https://bugzilla.redhat.com/show_bug.cgi?id=328391
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail



From mattdm at mattdm.org  Thu Oct 11 21:02:12 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 11 Oct 2007 17:02:12 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <1192133338.19494.10.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org>
Message-ID: <20071011210212.GA1025@jadzia.bu.edu>

On Thu, Oct 11, 2007 at 04:08:58PM -0400, James Antill wrote:
> > why it still needs so much memory. All it needs at that point (it was
> > installing the 1st rpm), is the list of 752 package filenames in an
> > install-order list. Why is that taking up 300MB?
>  300MB to upgrade 1GB of data is excessive?

I'm not sure I'm with you on the logic here. If I do a full-fedora upgrade,
do I need 11GB of RAM?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From kevin.kofler at chello.at  Thu Oct 11 21:04:48 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 11 Oct 2007 21:04:48 +0000 (UTC)
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
	<20071011113640.2fe41b4e@redhat.com>
Message-ID: <loom.20071011T203036-966@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> On Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
> "Jon Ciesla" <limb <at> jcomserv.net> wrote:
> > But the point is if you have no DVD drive, the only upgrade method,
> > AFAIK is yum, which is not officially supported.
> 
> Incorrect.  rescue.iso or boot.iso + network, or harddrive.

That, or use the "register installer kernel in GRUB" hack which allows 
upgrading entirely from the HDD, no media needed at all.

Here's the process:
1. You need an unused ext2/ext3 partition large enough to hold a DVD image. If 
you do a fresh install now, think of reserving an /images (or any other non-FHS 
directory) partition for that purpose. The partition must not be a RAID or LVM 
partition. (GRUB doesn't like those.) And it has to be ext2 or ext3 because the 
installer can only read those or FAT and FAT (even FAT32) can't hold DVD ISOs 
due to the maximum file size.
2. Mount the /images partition.
3. Copy the DVD ISO and the vmlinuz and initrd.img files from the 
images/pxeboot/ directory (on the mirrors) for the release you want to update 
to into /images (i.e. the root directory of your /images partition).
4. Unmount the /images partition and make sure it is NOT in /etc/fstab for the 
upgrade. Anaconda doesn't like it if the ISO is on a mounted partition. (At 
least some versions of it didn't, so better take the partition out of fstab.)
5. Add an entry like this to your /boot/grub/grub.conf:
title Fedora Core 7 Installation
        root (hd1,2)
        kernel /vmlinuz
        initrd /initrd.img
You have to enter the correct partition number for /images there.
6. Reboot.
7. In the GRUB menu, select the entry you just added.
8. Pick "Upgrade an existing Fedora installation" and select your existing 
installation. (Or "Reinstall", if that's what you want to do. WARNING: A 
reinstall will reformat (wipe out) at least your / partition! Upgrades, on the 
other hand, will keep your existing files and configuration.)
9. When Anaconda asks for the installation source, pick "hard disk", give the 
device name for your /images partition (e.g. /dev/sdb3), and for the path on 
the partition, enter / (i.e. the root directory, which was were we copied the 
image to in step 3).
10. Enjoy! I recommend running a regular yum/apt-get/smart upgrade from the 
network next to upgrade the packages not on the DVD and to get the latest 
updates.

        Kevin Kofler



From james.antill at redhat.com  Thu Oct 11 21:11:57 2007
From: james.antill at redhat.com (James Antill)
Date: Thu, 11 Oct 2007 17:11:57 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM 
	machine
In-Reply-To: <fem0ue$qg8$1@sea.gmane.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org> <fem0ue$qg8$1@sea.gmane.org>
Message-ID: <1192137117.19494.19.camel@code.and.org>

On Thu, 2007-10-11 at 16:26 -0400, sean darcy wrote:
> James Antill wrote:
> ................
> >  I've attached a simple python script I've used, it's not perfect but it
> > shows roughly how much dead memory you have and will kind of show where
> > it is.
> > 
> 
> Great script. But is rebooting the only answer?

 So what it tries to show is how much memory is being "allocated" to
files that no longer exist. This _could_ be a normal thing, but is most
often due to shared libraries that have either been upgraded or changed
via. prelink ... but which are still mapped into another application.

 So, yes, the only way to fix that is to "reboot" the application so it
uses the new version of the shared library instead of the old deleted
one. For some applications it's easy enough to just restart them, for
others you might as well just reboot the entire machine.

> I wondered whether prelink cleaned up after itself.

 It's not really prelink's fault, it's doing what it should. It can just
be annoying how much RAM it uses sometimes.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- 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/20071011/5583c2cd/attachment.sig>

From davej at redhat.com  Thu Oct 11 21:13:46 2007
From: davej at redhat.com (Dave Jones)
Date: Thu, 11 Oct 2007 17:13:46 -0400
Subject: better install experience
In-Reply-To: <Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
	<20071011201238.GA17998@redhat.com>
	<Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>
Message-ID: <20071011211346.GC11732@redhat.com>

On Thu, Oct 11, 2007 at 11:46:23PM +0300, Szabolcs Szakacsits wrote:

 > It was last year:
 > 
 > --------------------------------------------------------------------------->
 >  Date: Mon, 23 Oct 2006 02:00:52 +0300 (MET DST)
 >  From: Szakacsits Szabolcs <szaka at sienet.hu>
 >  To: Dave Jones <davej at redhat.com>
 >  Subject: Re: ntfs kernel module
 > 
 >  [...]
 > 
 >  > the kernel driver is "safer".
 > 
 >  I'm not sure. It's true that its functionality is very limited (ntfs-3g 
 >  also supports read-only mounts of course) but
 > 
 >         - unlike ntfs-3g, the kernel driver isn't quality tested 
 > 
 >         - I've fixed many problems in the NTFS code base which could also 
 >           exist in the kernel driver. One of the most serious bugs I 
 >           remember was freeing memory in truncate() which could be modified 
 >           later on (random memory corruptions).
 > 
 >   [...]
 > <-----------------------------------------------------------------------------

Doesn't ring any bells.  If the attribution of "safer" was something I
said, I'm not entirely sure what I was thinking at the time.

Given the heritage of ntfs-3g, it's clearly untrue, and I agree with
your comments.

	Dave

-- 
http://www.codemonkey.org.uk



From mattdm at mattdm.org  Thu Oct 11 21:15:12 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 11 Oct 2007 17:15:12 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <1192137117.19494.19.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org>
	<fem0ue$qg8$1@sea.gmane.org>
	<1192137117.19494.19.camel@code.and.org>
Message-ID: <20071011211512.GA2809@jadzia.bu.edu>

On Thu, Oct 11, 2007 at 05:11:57PM -0400, James Antill wrote:
> > I wondered whether prelink cleaned up after itself.
>  It's not really prelink's fault, it's doing what it should. It can just
> be annoying how much RAM it uses sometimes.

So, uh, are there numbers somewhere on the benefits of prelink on modern
hardware? It's got a lot of downsides.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From seandarcy2 at gmail.com  Thu Oct 11 21:13:32 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Thu, 11 Oct 2007 17:13:32 -0400
Subject: f8t3 live: no networking on presario 700 (Broadcom)
In-Reply-To: <1191952268.29582.88.camel@localhost>
References: <febsul$oim$1@sea.gmane.org>	<1191804935.28263.38.camel@localhost.localdomain>	<fec24n$3fu$1@sea.gmane.org>	<1191887833.28263.41.camel@localhost.localdomain>	<feg2s5$lts$1@sea.gmane.org>	<1191950696.14083.7.camel@metroid.rdu.redhat.com>
	<1191952268.29582.88.camel@localhost>
Message-ID: <fem3ls$4cc$1@sea.gmane.org>

Callum Lerwick wrote:
> On Tue, 2007-10-09 at 13:24 -0400, Will Woods wrote:
>> Just to be sure, what made you choose version 4 firmware for your
>> device? I had messages in dmesg directing me to get the version 3
>> firmware (for my BCM4306 card). I'm not sure what firmware/driver the
>> 4311 would use, but it would probably tell you in the logs..
> 
> As of F7 it demands v4. Which nicely complicated the hell out upgrading
> to F7, as finding v4 drivers to cut the firmware from was next to
> impossible upon release.
> 

Well, the answer from bcm43-devel: broadcom 4311, rev 2, cards are not 
supported by b43 or b43 legacy.

sean



From loony at loonybin.org  Thu Oct 11 21:20:10 2007
From: loony at loonybin.org (Peter Arremann)
Date: Thu, 11 Oct 2007 17:20:10 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
Message-ID: <200710111720.10343.loony@loonybin.org>

On Thursday 11 October 2007, Paul Wouters wrote:
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  3983 paul      20   0 1002m 284m  19m R  9.9 28.7  32:17.87 firefox-bin
>  2582 root      20   0  568m 106m 4680 S  0.7 10.8 198:43.15 X

You happen to run xinerama?

Peter.



From mattdm at mattdm.org  Thu Oct 11 21:21:47 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 11 Oct 2007 17:21:47 -0400
Subject: better install experience
In-Reply-To: <20071011211346.GC11732@redhat.com>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
	<20071011201238.GA17998@redhat.com>
	<Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>
	<20071011211346.GC11732@redhat.com>
Message-ID: <20071011212147.GB2809@jadzia.bu.edu>

On Thu, Oct 11, 2007 at 05:13:46PM -0400, Dave Jones wrote:
> Doesn't ring any bells.  If the attribution of "safer" was something I
> said, I'm not entirely sure what I was thinking at the time.

Someone named "dragoran" (dragoran-at-feuerpokemon-dot-de) said that, in
reference to a comment of yours where you said "If this works, there's no
reason for a kernel module to do the same thing."


<http://www.redhat.com/archives/fedora-devel-list/2006-October/msg00598.html>


I'm not sure exactly how this thread counts as you not replying to bug
reports.....

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From paul at all-the-johnsons.co.uk  Thu Oct 11 21:50:50 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 11 Oct 2007 22:50:50 +0100
Subject: upload cert?
In-Reply-To: <200710112232.24931.opensource@till.name>
References: <1192116344.4076.0.camel@T7.Linux>
	<200710112232.24931.opensource@till.name>
Message-ID: <1192139450.4076.8.camel@T7.Linux>

Hi,

> > Where do I get the fedora-upload cert from?
> 
> https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert
> https://admin.fedoraproject.org/accounts/fedora-server-ca.cert
> Source: http://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem

:-)

Now, any ideas on this one?

After I issue a make build and enter my password, I get

<type 'exceptions.AttributeError'>: 'Krb5Error' object has no attribute
'err_code'
make : *** [koji] Error 1

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071011/5544b137/attachment.sig>

From notting at redhat.com  Thu Oct 11 21:49:03 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 11 Oct 2007 17:49:03 -0400
Subject: remove readahead from default package set (was Re: should
	readahead allow generic paths?)
In-Reply-To: <470E33A6.7070903@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
Message-ID: <20071011214903.GA32504@nostromo.devel.redhat.com>

Eric Sandeen (sandeen at redhat.com) said: 
> Matthias Clasen wrote:
> > On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> > 
> >> Tossing a default list out there and hoping for the best probably won't
> >> work, at any rate.
> > 
> > So are we going to get your fixed lists into F8 ?
> > 
> 
> Well, part of the problem is that "my" fixed lists may not be everyone's
> fixed lists - I generated a custom list from *my* boot sequence.  Coming
> up with a good default list that actually speeds *everyone's* boot time
> is another issue.  If we think it's worth the 4 second or so boottime
> reduction, maybe some way to automatically generate the custom lists
> during firstboot might be an option.  But then, they will rot over time...

Given that, is there any reason to ship it on by default at this point?

Bill



From sandeen at redhat.com  Thu Oct 11 22:02:40 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 11 Oct 2007 17:02:40 -0500
Subject: remove readahead from default package set (was Re:
 should	readahead allow generic paths?)
In-Reply-To: <20071011214903.GA32504@nostromo.devel.redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>	<p04330102c333d3e26fe9@[192.168.123.162]>	<470E311A.8020406@redhat.com>	<1192112561.2571.9.camel@localhost.localdomain>	<470E33A6.7070903@redhat.com>
	<20071011214903.GA32504@nostromo.devel.redhat.com>
Message-ID: <470E9D80.1040107@redhat.com>

Bill Nottingham wrote:
> Eric Sandeen (sandeen at redhat.com) said: 
>> Matthias Clasen wrote:
>>> On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
>>>
>>>> Tossing a default list out there and hoping for the best probably won't
>>>> work, at any rate.
>>> So are we going to get your fixed lists into F8 ?
>>>
>> Well, part of the problem is that "my" fixed lists may not be everyone's
>> fixed lists - I generated a custom list from *my* boot sequence.  Coming
>> up with a good default list that actually speeds *everyone's* boot time
>> is another issue.  If we think it's worth the 4 second or so boottime
>> reduction, maybe some way to automatically generate the custom lists
>> during firstboot might be an option.  But then, they will rot over time...
> 
> Given that, is there any reason to ship it on by default at this point?
> 
> Bill

It'd be nice to get a few more datapoints, but I have yet to hear anyone
say that the default lists help them boot faster.

-Eric



From szaka at ntfs-3g.org  Thu Oct 11 22:21:39 2007
From: szaka at ntfs-3g.org (Szabolcs Szakacsits)
Date: Fri, 12 Oct 2007 01:21:39 +0300 (EEST)
Subject: better install experience
In-Reply-To: <20071011211346.GC11732@redhat.com>
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
	<20071011201238.GA17998@redhat.com>
	<Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>
	<20071011211346.GC11732@redhat.com>
Message-ID: <Pine.LNX.4.62.0710120043090.6142@tamago.serverit.net>


On Thu, 11 Oct 2007, Dave Jones wrote:

> Doesn't ring any bells.  If the attribution of "safer" was something I
> said, I'm not entirely sure what I was thinking at the time.

No, you didn't say it. I sent you the email privately where I answered 
all the concerns people made in the 'ntfs kernel module' thread you also 
commented:

  http://www.redhat.com/archives/fedora-devel-list/2006-October/thread.html#00596

Since it was a longer email, I put it here:

  http://ntfs-3g.org/docs/ntfs-kernel-module-2006-10-23.txt

Please note, that at that time there was no ntfs-3g web site, documents and 
the situation was indeed confusing for users, that's why I summarised 
things for the interested Fedora users.

But my email came back when I tried to send it to the list unsubscribed. 
I'm also always busy and get insane amount of emails and didn't have time 
to subscribe/wait/configure list filtering, etc, so I decided to send the 
email only to you, mentioning the potential kernel driver bugs (which I 
would have detail if there were interest).

Thank you for the replies.

Regards,
	    Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org



From paul at all-the-johnsons.co.uk  Thu Oct 11 22:26:08 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 11 Oct 2007 23:26:08 +0100
Subject: Getting my broadcom wireless card to work with rawhide
In-Reply-To: <1191679383.15421.3.camel@localhost.localdomain>
References: <1191510135.4157.22.camel@localhost.localdomain>
	<20071004174751.GC8375@redhat.com>
	<1191523945.4157.25.camel@localhost.localdomain>
	<20071004190909.GD8375@redhat.com> <1191527009.4157.32.camel@T7.Linux>
	<20071004202924.GF8375@redhat.com> <1191530534.4199.4.camel@T7.Linux>
	<1191679383.15421.3.camel@localhost.localdomain>
Message-ID: <1192141568.3623.1.camel@T7.Linux>

Hi,

> > Yep. I can see it in the iwlist.
> 
> Do you see the SSID for your AP in iwlist, or do you only see the MAC
> address of your AP, and the SSID is "<hidden>"?

My iwlist shows this

wlan0     Scan completed :
          Cell 01 - Address: aa:bb:cc:dd:ee:ff:
                    ESSID:"SKY83948"
                    Mode:Master
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=76/100  Signal level=-12 dBm  Noise
level=-42 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:tsf=0000004ba768a581

NetworkManager sees it, asks for the passphrase but cannot log in.

TTFN


Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071011/99a554f9/attachment.sig>

From a.badger at gmail.com  Thu Oct 11 22:49:28 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 11 Oct 2007 15:49:28 -0700
Subject: Proposals: Remove pkg.acl and owners.list
Message-ID: <470EA878.4030007@gmail.com>

I have two proposals:

1) cvs rm pkg.acl files from the cvs repo.  The packagedb has taken the 
place of these files.  Editing them doesn't do anything and it's causing 
some people confusion that they're still in the repository.  This one 
seems pretty simple.  Let me know soon if you can think of a reason not 
to do this.

2) Remove owners.list files and place a README telling people to go to 
the packagedb for the information.  owners.list{.epel,.olpc} are a 
little harder as a plethora of scripts were using owners.list.  The 
information is becoming out of date as more packages are added or change 
hands, however.  All the scripts I know of have been converted at this 
point with the exception of some things on:
   http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts
that were broken before the packagedb took over from owners.list.

If no one objects, I'll announce these changes on fedora-devel-announce 
on Monday and make the actual changes later in the week.

-Toshio



From paul at xelerance.com  Thu Oct 11 23:13:24 2007
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 11 Oct 2007 19:13:24 -0400 (EDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM
 machine
In-Reply-To: <200710111720.10343.loony@loonybin.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<200710111720.10343.loony@loonybin.org>
Message-ID: <Pine.LNX.4.64.0710111912360.28684@newtla.xelerance.com>

On Thu, 11 Oct 2007, Peter Arremann wrote:

> On Thursday 11 October 2007, Paul Wouters wrote:
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  3983 paul      20   0 1002m 284m  19m R  9.9 28.7  32:17.87 firefox-bin
> >  2582 root      20   0  568m 106m 4680 S  0.7 10.8 198:43.15 X
>
> You happen to run xinerama?

Nope. Stock install , one screen, using the "nv" driver.

Paul



From paul at all-the-johnsons.co.uk  Thu Oct 11 23:24:07 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 12 Oct 2007 00:24:07 +0100
Subject: Getting there, just figuring out koji....
Message-ID: <1192145047.3623.6.camel@T7.Linux>

Hi,

Ok, had a brain wave. It's no longer make build, but I need to use koji.

I have pretty much got it figured, except for the actual build.

Currently, I use

koji build dist-f8 'cvs://cvs.fedoraproject.org/cvs/pkgs/libgdiplus

It comes back saying it can't find the directory. Using viewcvs, it
looks right.

How do I build for rawhide/f8 using koji?

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071012/2adae54c/attachment.sig>

From pertusus at free.fr  Thu Oct 11 23:26:23 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 12 Oct 2007 01:26:23 +0200
Subject: Getting there, just figuring out koji....
In-Reply-To: <1192145047.3623.6.camel@T7.Linux>
References: <1192145047.3623.6.camel@T7.Linux>
Message-ID: <20071011232623.GB2688@free.fr>

On Fri, Oct 12, 2007 at 12:24:07AM +0100, Paul wrote:
> 
> How do I build for rawhide/f8 using koji?

I am not sure that it will answer your question, but the doc for koji in
fedora is here:

http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji

--
Pat



From david at fubar.dk  Thu Oct 11 23:36:32 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 11 Oct 2007 19:36:32 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071011171023.GC26215@nostromo.devel.redhat.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<20071011122853.GC1324613@hiwaay.net>
	<20071011171023.GC26215@nostromo.devel.redhat.com>
Message-ID: <1192145792.3071.45.camel@oneill.fubar.dk>


On Thu, 2007-10-11 at 13:10 -0400, Bill Nottingham wrote:
> Chris Adams (cmadams at hiwaay.net) said: 
> > Once upon a time, Lubomir Kundrak <lkundrak at redhat.com> said:
> > > On Thu, 2007-10-11 at 05:55 -0400, Alan Cox wrote:
> > > > We should be shipping a CD set. I consistently see people going to Ubuntu
> > > > after asking for a Fedora CD and being told they can't update that way.
> > > 
> > > +1 Exactly this. We should pick packages for an installation that fits
> > > in 1CD. Is anyone already working on a one CD spin, or interested in
> > > working on it?
> > 
> > What about using the LiveCD package set?  Would that set of packages
> > plus the regular installer fit as a minimal install/upgrade CD?
> 
> Fairly sure it doesn't, but I haven't done a test compose.

>From a theoretical point view the size of 1) a directory containing the
RPM's; and 2) the RPM's installed into a compressed file system (we use
squashfs on the live cd's); are kinda similar since RPM's themselves are
also compressed and carry mostly payload. 

In practice this also turns out to be true (and, in fact the live image
contains redundant data such as icon caches etc.). You'd also need to
add the installer, don't know how much it weighs these days, can't be
_that_ much.

     David




From loony at loonybin.org  Thu Oct 11 23:44:45 2007
From: loony at loonybin.org (Peter Arremann)
Date: Thu, 11 Oct 2007 19:44:45 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <Pine.LNX.4.64.0710111912360.28684@newtla.xelerance.com>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<200710111720.10343.loony@loonybin.org>
	<Pine.LNX.4.64.0710111912360.28684@newtla.xelerance.com>
Message-ID: <200710111944.45517.loony@loonybin.org>

On Thursday 11 October 2007, Paul Wouters wrote:
> On Thu, 11 Oct 2007, Peter Arremann wrote:
> > On Thursday 11 October 2007, Paul Wouters wrote:
> > >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > >  3983 paul      20   0 1002m 284m  19m R  9.9 28.7  32:17.87
> > > firefox-bin 2582 root      20   0  568m 106m 4680 S  0.7 10.8 198:43.15
> > > X
> >
> > You happen to run xinerama?
>
> Nope. Stock install , one screen, using the "nv" driver.
>
> Paul

Hm - I used the nv driver but got the same behavior only when using dual head. 
For me it turned out to be that firefox seems to hold onto bitmaps way too 
much. Especially when you browse webpages with lots of images, that quickly 
gets to be a pain. xrestop showed that most of the memory used by X came from 
firefox - Pxm mem column... There are some xorg bug reports out there for 
that behavior, but most of them revolve around xinerama too. 

https://bugs.freedesktop.org/show_bug.cgi?id=4942

and many others - they are old and still in new status... On the mozilla pages 
you will see similar reports... 

One solution that seems to work for many is switching to the nvidia closed 
source drivers. If you want to stay open source, try nouveau.
http://nouveau.freedesktop.org/wiki/

Both of them can fix the high pixmap memory usage for some people. Others have 
no luck with either.

Peter.



From berrange at redhat.com  Fri Oct 12 00:06:10 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 12 Oct 2007 01:06:10 +0100
Subject: Getting there, just figuring out koji....
In-Reply-To: <1192145047.3623.6.camel@T7.Linux>
References: <1192145047.3623.6.camel@T7.Linux>
Message-ID: <20071012000609.GA31882@redhat.com>

On Fri, Oct 12, 2007 at 12:24:07AM +0100, Paul wrote:
> Ok, had a brain wave. It's no longer make build, but I need to use koji.

'make build' directly invokes koji with all neccessary args. 

> How do I build for rawhide/f8 using koji?

  cvs co package
  cd package/devel
  ...do stuff to spec/sources/patches & checkin to CVS...
  make tag
  make build

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From jkeating at redhat.com  Fri Oct 12 00:08:01 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 11 Oct 2007 20:08:01 -0400
Subject: Getting there, just figuring out koji....
In-Reply-To: <1192145047.3623.6.camel@T7.Linux>
References: <1192145047.3623.6.camel@T7.Linux>
Message-ID: <20071011200801.4c12985f@redhat.com>

On Fri, 12 Oct 2007 00:24:07 +0100
Paul <paul at all-the-johnsons.co.uk> wrote:

> Ok, had a brain wave. It's no longer make build, but I need to use
> koji.
> 
> I have pretty much got it figured, except for the actual build.

Wrong, it's still 'make build'.  The makefiles will figure out the
actual command to issue to the koji client for you.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/6612ccf8/attachment.sig>

From berrange at redhat.com  Fri Oct 12 00:10:24 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 12 Oct 2007 01:10:24 +0100
Subject: upload cert?
In-Reply-To: <1192139450.4076.8.camel@T7.Linux>
References: <1192116344.4076.0.camel@T7.Linux>
	<200710112232.24931.opensource@till.name>
	<1192139450.4076.8.camel@T7.Linux>
Message-ID: <20071012001024.GB31882@redhat.com>

On Thu, Oct 11, 2007 at 10:50:50PM +0100, Paul wrote:
> Hi,
> 
> > > Where do I get the fedora-upload cert from?
> > 
> > https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert
> > https://admin.fedoraproject.org/accounts/fedora-server-ca.cert
> > Source: http://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem
> 
> :-)
> 
> Now, any ideas on this one?
> 
> After I issue a make build and enter my password, I get
> 
> <type 'exceptions.AttributeError'>: 'Krb5Error' object has no attribute
> 'err_code'
> make : *** [koji] Error 1

Koji can either either SSL/x509 or Kerberos for auth depending on the 
needs of the project. If it is attempting to use Kerberos, I'd image 
you've not successfully run  fedora-packager-setup.sh which configures
it to use SSL

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From michael.wiktowy at gmail.com  Fri Oct 12 00:16:09 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Thu, 11 Oct 2007 20:16:09 -0400
Subject: Dell Precision Workstation LiveCD boot menu selection problem
Message-ID: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>

Hello,

Has anyone else been having problems with USB keyboards being dead
during the boot menu when booting the f8test LiveCDs? I wrote up a
bugzilla [1] a while ago but got no feedback.. I read LWNs interview
with Matt Domsch today where he specifically states that Precision
Workstations are targetted for Linux compatibility so it surprises me
that this regression is unnoticed by anyone else.

/Mike

[1] https://bugzilla.redhat.com/show_bug.cgi?id=300331



From kevin.kofler at chello.at  Fri Oct 12 00:29:09 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 12 Oct 2007 00:29:09 +0000 (UTC)
Subject: better install experience
References: <Pine.LNX.4.62.0710111157350.27551@tamago.serverit.net>
	<364d303b0710110728se721b67m286de3f200b51cd2@mail.gmail.com>
	<Pine.LNX.4.62.0710111918550.6142@tamago.serverit.net>
	<20071011201238.GA17998@redhat.com>
	<Pine.LNX.4.62.0710112336110.6142@tamago.serverit.net>
	<20071011211346.GC11732@redhat.com>
	<Pine.LNX.4.62.0710120043090.6142@tamago.serverit.net>
Message-ID: <loom.20071012T002534-733@post.gmane.org>

Szabolcs Szakacsits <szaka <at> ntfs-3g.org> writes:
> But my email came back when I tried to send it to the list unsubscribed.

Hint (also for other people in the same situation): You can use GMane to get 
around the subscription requirement. There's a nice web interface, you pick the 
message to reply to, choose "Followup", write your reply, fill your captcha, 
click "Post this article" and off it goes to the list. Only the first time, 
there's a confirmation e-mail sent to validate the e-mail address, you have to 
send it back. Once that's done, replying over the web just works.

        Kevin Kofler



From katzj at redhat.com  Fri Oct 12 00:50:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 11 Oct 2007 20:50:27 -0400
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
Message-ID: <1192150227.4210.7.camel@localhost.localdomain>

On Thu, 2007-10-11 at 20:16 -0400, Michael Wiktowy wrote:
> Has anyone else been having problems with USB keyboards being dead
> during the boot menu when booting the f8test LiveCDs? I wrote up a
> bugzilla [1] a while ago but got no feedback.. I read LWNs interview
> with Matt Domsch today where he specifically states that Precision
> Workstations are targetted for Linux compatibility so it surprises me
> that this regression is unnoticed by anyone else.

Is there a BIOS update available for the box?  There have been a few
BIOS bugs which have interacted poorly with certain versions of syslinux

Jeremy



From bbbush.yuan at gmail.com  Fri Oct 12 01:04:47 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Fri, 12 Oct 2007 09:04:47 +0800
Subject: compiz-fusion other apps?
In-Reply-To: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
References: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
Message-ID: <76e72f800710111804i67f5e0day8c7ad29176bb92b1@mail.gmail.com>

2007/10/11, Caerie Houchins <cdhouch at gmail.com>:
> I know that compiz-fusion is seen as a tech preview in F8, but are there any
> plans to include ccsm and the other applications that go along with it at
> some point ?  Right now there doesn't seem to be a way to configure the
> compiz-fusion plugins...
>

there are 2 packages compiz-fusion-gnome and
compiz-fusion-extras-gnome. Understand that compiz is started with
cmdline option gconf, so you can configure the plugins there in
gconf-editor.

-- 
bbbush ^_^



From michael.wiktowy at gmail.com  Fri Oct 12 01:18:11 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Thu, 11 Oct 2007 21:18:11 -0400
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <1192150227.4210.7.camel@localhost.localdomain>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
	<1192150227.4210.7.camel@localhost.localdomain>
Message-ID: <3e4ec4600710111818i35c72933u1f19b3b8ca574385@mail.gmail.com>

On 10/11/07, Jeremy Katz <katzj at redhat.com> wrote:
> Is there a BIOS update available for the box?  There have been a few
> BIOS bugs which have interacted poorly with certain versions of syslinux

There appears to be recent updates but they only show the changelog
from the current-1 version to the current version so I am not sure if
it addresses this issue specifically. I will give it a spin tomorrow
at work when I have access to the system.

I figured it was a syslinux problem when an old version worked but the
latest did not..

I will report success/failure in the bugzilla report.

Thanks.

/Mike



From Matt_Domsch at dell.com  Fri Oct 12 03:55:38 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Thu, 11 Oct 2007 22:55:38 -0500
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <3e4ec4600710111818i35c72933u1f19b3b8ca574385@mail.gmail.com>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
	<1192150227.4210.7.camel@localhost.localdomain>
	<3e4ec4600710111818i35c72933u1f19b3b8ca574385@mail.gmail.com>
Message-ID: <20071012035538.GA16449@auslistsprd01.us.dell.com>

On Thu, Oct 11, 2007 at 09:18:11PM -0400, Michael Wiktowy wrote:
> On 10/11/07, Jeremy Katz <katzj at redhat.com> wrote:
> > Is there a BIOS update available for the box?  There have been a few
> > BIOS bugs which have interacted poorly with certain versions of syslinux
> 
> There appears to be recent updates but they only show the changelog
> from the current-1 version to the current version so I am not sure if
> it addresses this issue specifically. I will give it a spin tomorrow
> at work when I have access to the system.
> 
> I figured it was a syslinux problem when an old version worked but the
> latest did not..
> 
> I will report success/failure in the bugzilla report.

There was a syslinux bug recently found and fixed; not sure if it made
the F8 Test3 LiveCD or not though.


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From kagesenshi.87 at gmail.com  Fri Oct 12 04:29:02 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Fri, 12 Oct 2007 12:29:02 +0800
Subject: compiz-fusion other apps?
In-Reply-To: <76e72f800710111804i67f5e0day8c7ad29176bb92b1@mail.gmail.com>
References: <f0ad54e30710110826x733b85fcydb4a13868103cd6b@mail.gmail.com>
	<76e72f800710111804i67f5e0day8c7ad29176bb92b1@mail.gmail.com>
Message-ID: <c44298520710112129u504c94b0mb96335bf1a0969d3@mail.gmail.com>

On 10/12/07, Yuan Yijun <bbbush.yuan at gmail.com> wrote:
> 2007/10/11, Caerie Houchins <cdhouch at gmail.com>:
> > I know that compiz-fusion is seen as a tech preview in F8, but are there any
> > plans to include ccsm and the other applications that go along with it at
> > some point ?  Right now there doesn't seem to be a way to configure the
> > compiz-fusion plugins...
> >

the review request have been around for quite a while

libcompizconfig -> https://bugzilla.redhat.com/show_bug.cgi?id=247406
compizconfig-python -> https://bugzilla.redhat.com/show_bug.cgi?id=247408

ccsm spec was ready but it seems like 0.6.0 introduced some changes so
i need to fix the specfile first ..

my college blocks lots of protocols and i couldnt do much when i'm
there .. right now I'm having a short holiday , hopefully i can get
them done ..



-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From fedora at leemhuis.info  Fri Oct 12 04:54:30 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 12 Oct 2007 06:54:30 +0200
Subject: disable cpuspeed while X session active and
	screensaver	not	running
In-Reply-To: <470E6324.6000805@poolshark.org>
References: <470E5E47.4040006@andrei.myip.org>	<470E60D2.8000808@andrei.myip.org>
	<470E6324.6000805@poolshark.org>
Message-ID: <470EFE06.3010102@leemhuis.info>

On 11.10.2007 19:53, Denis Leroy wrote:
> 
> On that subject, does anyone knows how to tell the Frequency Monitor 
> applet to keep the cpu in lower frequency all the time (i.e. 'killall 
> -USR2 cpuspeed', which is what you want typically when running on 
> batteries) ?

Note, for new processors (like Core*) afaik that's *not* what you want
when running running on batteries: the total energy consumed often is
lower if you go to the highest speed, do what needs to be done way
quicker, and switch back to lowest speed quickly again.

http://www.lesswatts.org/projects/applications-power-management/race-to-idle.php

CU
knurd



From wtogami at redhat.com  Fri Oct 12 05:05:18 2007
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 12 Oct 2007 01:05:18 -0400
Subject: remove readahead from default package set (was Re:
 should	readahead allow generic paths?)
In-Reply-To: <20071011214903.GA32504@nostromo.devel.redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>	<p04330102c333d3e26fe9@[192.168.123.162]>	<470E311A.8020406@redhat.com>	<1192112561.2571.9.camel@localhost.localdomain>	<470E33A6.7070903@redhat.com>
	<20071011214903.GA32504@nostromo.devel.redhat.com>
Message-ID: <470F008E.2080102@redhat.com>

Bill Nottingham wrote:
> Eric Sandeen (sandeen at redhat.com) said: 
>> Matthias Clasen wrote:
>>> On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
>>>
>>>> Tossing a default list out there and hoping for the best probably won't
>>>> work, at any rate.
>>> So are we going to get your fixed lists into F8 ?
>>>
>> Well, part of the problem is that "my" fixed lists may not be everyone's
>> fixed lists - I generated a custom list from *my* boot sequence.  Coming
>> up with a good default list that actually speeds *everyone's* boot time
>> is another issue.  If we think it's worth the 4 second or so boottime
>> reduction, maybe some way to automatically generate the custom lists
>> during firstboot might be an option.  But then, they will rot over time...
> 
> Given that, is there any reason to ship it on by default at this point?
> 
> Bill
> 

Relatively simple solution:
1) Ship readahead with template lists.  This includes a list of commonly 
used stuff.  It could include wildcards like /usr/lib*/firefox*/foo in 
order to handle multilib and version numbers changing.
2) During firstboot and occasionally after boot, something generates the 
actual readahead file lists based upon several factors like:
    - is the file actually installed?
    - is the service enabled?

Later improvement:
3) Sometime later, more intelligent software could be included to help a 
user update their readahead lists based upon their own software usage 
patterns.

Unfortunately, not enough time to implement #1 and #2 before F8, even 
though they are pretty simple and easy to test.

Warren Togami
wtogami at redhat.com



From Bill.Holder at sunwater.com.au  Fri Oct 12 05:07:35 2007
From: Bill.Holder at sunwater.com.au (Holder, Bill)
Date: Fri, 12 Oct 2007 15:07:35 +1000
Subject: does this mean anything to anyone?
Message-ID: <8ADEE648D981EF47A23B6E1334BEBA610256F103@brisbane04.sunwater.com.au>

BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted)
 [<c042b0cf>] local_bh_enable+0x45/0x92
 [<c06002bd>] cond_resched_softirq+0x2c/0x42
 [<c059adf3>] release_sock+0x4f/0x9d
 [<c05c670d>] tcp_sendmsg+0x90b/0x9f9
 [<c04808a3>] core_sys_select+0x1df/0x2f3
 [<c05dec95>] inet_sendmsg+0x3b/0x45
 [<c0598731>] sock_aio_write+0xf6/0x102
 [<c045da36>] get_page_from_freelist+0x23b/0x2a5
 [<c04754ee>] do_sync_write+0xc7/0x10a
 [<c0436e71>] autoremove_wake_function+0x0/0x35
 [<c0475d47>] vfs_write+0xbc/0x154
 [<c0476342>] sys_write+0x41/0x67
 [<c0404f70>] syscall_call+0x7/0xb

this is the last message in the dmesg log after a clean boot. I know
it's probably not enough info to tell anything, but if it's nothing to
worry about I'm not going to start turning debugs and dumps etc on.
 
/B
 
 
 

Bill Holder
Systems Administrator - unix & datacomms
SunWater
Level 9, 120 Edward Street, Brisbane, QLD, 4000
Ph: +61 7 3120 0116 Fax: +61 7 3120 0302 
www.SunWater.com.au <http://www.sunwater.com.au/>  

 
 

***********************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.  
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.  
Any attachments should be checked for viruses by you, before being opened. SunWater accepts no responsibility for an attachment that contains a virus.
***********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/317a2d79/attachment.htm>

From jspaleta at gmail.com  Fri Oct 12 05:08:57 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 11 Oct 2007 21:08:57 -0800
Subject: disable cpuspeed while X session active and screensaver not
	running
In-Reply-To: <e71b3daf0710111111gb8409far6d5e95b931182f5b@mail.gmail.com>
References: <470E5E47.4040006@andrei.myip.org>
	<470E60D2.8000808@andrei.myip.org> <470E6324.6000805@poolshark.org>
	<e71b3daf0710111111gb8409far6d5e95b931182f5b@mail.gmail.com>
Message-ID: <604aa7910710112208s21ed1cd8uf8931095390aeed4@mail.gmail.com>

On 10/11/07, Jon Nettleton <jon.nettleton at gmail.com> wrote:
> If you don't run cpuspeed and use the in kernel governors you can
> choose the different governor you want to use to control your speed,
> or a static speed from the applet.  This is the behavior by default on
> newer cpu's, but for some reason the cpuspeed damon is still used on
> older processors.  I have some scripts that load these modules for
> older cpu's if anyone is interested.

On F7 the ui for this stuff isn't exposed, there is a boolen gconf key
you have to flip to enable the ui, or you can set the ac and battery
policies in gconf-editor without turning on the ui bits.

-jef



From james.antill at redhat.com  Fri Oct 12 05:44:31 2007
From: james.antill at redhat.com (James Antill)
Date: Fri, 12 Oct 2007 01:44:31 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM
	machine
In-Reply-To: <20071011211512.GA2809@jadzia.bu.edu>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org> <fem0ue$qg8$1@sea.gmane.org>
	<1192137117.19494.19.camel@code.and.org>
	<20071011211512.GA2809@jadzia.bu.edu>
Message-ID: <1192167871.19494.34.camel@code.and.org>

On Thu, 2007-10-11 at 17:15 -0400, Matthew Miller wrote:
> On Thu, Oct 11, 2007 at 05:11:57PM -0400, James Antill wrote:
> > > I wondered whether prelink cleaned up after itself.
> >  It's not really prelink's fault, it's doing what it should. It can just
> > be annoying how much RAM it uses sometimes.
> 
> So, uh, are there numbers somewhere on the benefits of prelink on modern
> hardware? It's got a lot of downsides.

 Prelink works as a multiplier for this, so if you (or anyone) want to
measure what that is you need to try and get variables for:

1. rough number of updates for fedora that replace libraries or libexec
type processes.
2. number of processes likely to be using libraries in #1.
3. how much memory VSZ/RSS is wasted because of that.
4. how much running prelink nightly changes #3.
5. how much advantage prelink gives to application startup.

...and that's the easy bit, then you have to somehow work out how long a
user keeps a machine running and often they apply updates and compare
that against how much memory/CPU they have.
 I can well imagine that users who update more often and keep their
machines running longer have significantly more RAM (and CPU) in their
machines.

 For anyone who doesn't update much, or shuts their machine down every
day or so ... I'd be very surprised if the current behaviour wasn't
optimal.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- 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/20071012/9924ae22/attachment.sig>

From lesmikesell at gmail.com  Fri Oct 12 05:46:02 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 12 Oct 2007 00:46:02 -0500
Subject: samba license change
In-Reply-To: <1192124050.7723.5.camel@rousalka.dyndns.org>
References: <1191420459.8632.60.camel@localhost.localdomain>	<200710102332.46708.opensource@till.name>	<1192084036.4029.0.camel@rousalka.dyndns.org>	<200710111607.45639.opensource@till.name>	<25936.192.54.193.51.1192113530.squirrel@rousalka.dyndns.org>	<470E3948.3090808@gmail.com>	<55712.192.54.193.51.1192118355.squirrel@rousalka.dyndns.org>	<470E5122.80604@gmail.com>
	<1192124050.7723.5.camel@rousalka.dyndns.org>
Message-ID: <470F0A1A.3010007@gmail.com>

Nicolas Mailhot wrote:

>>>> If you have the right to distribute each component separately and the
>>>> existence of a usable gplv2 copy prevents things that happen to link
>>>> to the gplv3 version from being considered a derivative work, what's
>>> the
>>>> problem
>>> Because you can't limit yourself to analysing components separately.
>>> The distribution itself is an aggregate work that is subject to
>>> copyright laws as a whole.
>> Yes, but one part only affects another if it can be considered a 
>> derivative work, 
> 
> The distribution *as a whole* is a derivative work. You can say parts
> are mere aggregation but that does not work for parts that link together
> and have no alternative within the distribution (or alternatives
> distribution tools will never install). Fedora would not be liable for
> GPLv2 foo or GPLv3 samba separately, but by distributing a "Fedora"
> product which is both together.

In the case of fgmp vs. gmp it was never necessary to distribute the 
fgmp library.  The mere fact that it existed as a possible alternate 
kept the code that might link to it from being considered a derivative 
work of gmp - which is what everyone actually used.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From kagesenshi.87 at gmail.com  Fri Oct 12 06:02:19 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Fri, 12 Oct 2007 14:02:19 +0800
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
Message-ID: <c44298520710112302x355a80f3u5dca98cf76e63027@mail.gmail.com>

On 10/12/07, Michael Wiktowy <michael.wiktowy at gmail.com> wrote:
> Hello,
>
> Has anyone else been having problems with USB keyboards being dead
> during the boot menu when booting the f8test LiveCDs? I wrote up a
> bugzilla [1] a while ago but got no feedback.. I read LWNs interview
> with Matt Domsch today where he specifically states that Precision
> Workstations are targetted for Linux compatibility so it surprises me
> that this regression is unnoticed by anyone else.
>
> /Mike
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=300331
>

are u sure its just not the mother board settings??

try checking whether the "USB Support" are set to "built-in" and not "OS" ..

I happened to experience GRUB not responding to usb devices before and
its just the motherboard configuration thats not right ..

-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From opensource at till.name  Fri Oct 12 06:04:00 2007
From: opensource at till.name (Till Maas)
Date: Fri, 12 Oct 2007 08:04:00 +0200
Subject: Getting there, just figuring out koji....
In-Reply-To: <1192145047.3623.6.camel@T7.Linux>
References: <1192145047.3623.6.camel@T7.Linux>
Message-ID: <200710120804.06238.opensource@till.name>

On Fr Oktober 12 2007, Paul wrote:

> koji build dist-f8 'cvs://cvs.fedoraproject.org/cvs/pkgs/libgdiplus
>
> It comes back saying it can't find the directory. Using viewcvs, it
> looks right.

There is the branch directory missing, e.g. "devel":

koji build dist-f8 'cvs://cvs.fedoraproject.org/cvs/pkgs/libgdiplus/devel'

or use make build ;-)

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/7fd5a04d/attachment.sig>

From opensource at till.name  Fri Oct 12 06:14:46 2007
From: opensource at till.name (Till Maas)
Date: Fri, 12 Oct 2007 08:14:46 +0200
Subject: Proposals: Remove pkg.acl and owners.list
In-Reply-To: <470EA878.4030007@gmail.com>
References: <470EA878.4030007@gmail.com>
Message-ID: <200710120814.52132.opensource@till.name>

On Fr Oktober 12 2007, Toshio Kuratomi wrote:

> 1) cvs rm pkg.acl files from the cvs repo.  The packagedb has taken the
> place of these files.  Editing them doesn't do anything and it's causing
> some people confusion that they're still in the repository.  This one
> seems pretty simple.  Let me know soon if you can think of a reason not
> to do this.

Imho everyone who uses a pkg.acl that contains a different information then 
packagedb should get an extra e-mail.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/27f10987/attachment.sig>

From drepper at redhat.com  Fri Oct 12 06:35:30 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Thu, 11 Oct 2007 23:35:30 -0700
Subject: gethostby* users
Message-ID: <470F15B2.2020809@redhat.com>

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

Even though the situation improved, there are still some programs left
which use the gethostby* functions.  These really have to be converted
to use getaddrinfo.  Here is the break-down per package of an incomplete
installation giving the number of programs/libraries with problems in
that package.  I.e., there are like more packages on an install-all
machine.  The full list with the program/library names is at

   http://people.redhat.com/drepper/gethostby-users

Samba is responsible for almost one quarter of the problems.

     22 samba-common
     16 sendmail
     14 samba-client
     10 iputils
      9 net-tools
      9 isdn4k-utils
      8 yp-tools
      8 transcode
      7 qemu
      6 lrzsz
      3 DCC
      2 rdist
      2 pilot-linkpilot-link
      2 openssl
      2 mysql-server
      2 libXmu
      2 libgtop2
      2 jwhois
      2 iproute
      2 httpd-tools
      2 gstreamer-plugins-base
      2 gnome-media
      2 gdb
      2 alsa-lib
      1 xorg-x11-xauth
      1 wvdial
      1 wireless-tools
      1 tcpdump
      1 talk
      1 syslinux
      1 smartmontools
      1 slrn
      1 rpm
      1 nfs-utils
      1 netpbm-progs
      1 libXmu-devel
      1 libwvstreams
      1 libgtop2-devel
      1 kvm
      1 iptstate
      1 initscripts
      1 gnome-system-monitor
      1 gnome-speech
      1 gnome-session
      1 emacs
      1 crash
      1 cdrdao
      1 bluez-utils


- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHDxWy2ijCOnn/RHQRAtrtAJ9g+7dJq5pYEYr111zGIvj4IsYcMwCgkVza
SwnjR9RutrSCw/3Wc9ywg+o=
=uGvi
-----END PGP SIGNATURE-----



From alexl at redhat.com  Fri Oct 12 07:10:24 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 12 Oct 2007 09:10:24 +0200
Subject: samba license change
In-Reply-To: <1192020068.13627.68.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
	<200710092018.21899.ville.skytta@iki.fi>
	<1192000528.13539.61.camel@localhost.localdomain>
	<1192020068.13627.68.camel@localhost.localdomain>
Message-ID: <1192173024.13539.91.camel@localhost.localdomain>

On Wed, 2007-10-10 at 08:41 -0400, Simo Sorce wrote:
> On Wed, 2007-10-10 at 09:15 +0200, Alexander Larsson wrote:
> > On Tue, 2007-10-09 at 20:18 +0300, Ville Skytt? wrote:
> > > On Tuesday 09 October 2007, Simo Sorce wrote:
> > > >
> > > > Ah and btw if someone can check what is the GNOME status wrt this it
> > > > would be nice. Nautilus uses libsmbclient as well.
> > > 
> > > I'm no expert on GNOME stuff but I thought it does so through gnome-vfs.
> > > 
> > > gnome-vfs2.spec has:
> > > License: LGPLv2 and LGPL+ and GPL+
> > > # the daemon and the library are LGPLv2
> > > # the modules are LGPL+ and GPL+
> > > 
> > > libsmbclient is used in modules/smb-method.c, which carries a GPLv2+ notice.  
> > > (Dunno if omission of GPLv2+ qualifies as a bug in gnome-vfs2's License tag.)
> > 
> > Furthermore, the smb module is run in the daemon, so the license of it
> > doesn't affect applications linking to gnome-vfs.
> 
> This is interesting, to be sure we should evaluate though if there is
> intimate communication and sharing of data structures between the daemon
> and the client, but things looks much better in the GNOME camp.

It just uses the standard way to put gnome-vfs modules in the daemon.
Nothing is specific to the smb backend. In fact, any backend can be put
in the daemonb by adding [daemon] to the module config file.



From alexl at redhat.com  Fri Oct 12 07:34:05 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 12 Oct 2007 09:34:05 +0200
Subject: should readahead allow generic paths?
In-Reply-To: <470E33A6.7070903@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]> <470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
Message-ID: <1192174445.13539.96.camel@localhost.localdomain>

On Thu, 2007-10-11 at 09:31 -0500, Eric Sandeen wrote:
> Matthias Clasen wrote:
> > On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> > 
> >> Tossing a default list out there and hoping for the best probably won't
> >> work, at any rate.
> > 
> > So are we going to get your fixed lists into F8 ?
> > 
> 
> Well, part of the problem is that "my" fixed lists may not be everyone's
> fixed lists - I generated a custom list from *my* boot sequence.  Coming
> up with a good default list that actually speeds *everyone's* boot time
> is another issue.  If we think it's worth the 4 second or so boottime
> reduction, maybe some way to automatically generate the custom lists
> during firstboot might be an option.  But then, they will rot over time...

Is there any chance we can use Jens Axboes "fcache"?
Info e.g. at:
http://en.opensuse.org/Fcache-howto

I don't understand why nobody seems interested in this. It seems like a
much nicer solution than readahead of files. In the current version it
has to have a separate device for mirroring the blocks, but I can't
think its that hard to create a physically linear file on an ext3
filesystem, lock it in place and use that. (Isn't this basically what
extents are?)




From denis at poolshark.org  Fri Oct 12 08:08:58 2007
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 12 Oct 2007 10:08:58 +0200
Subject: disable cpuspeed while X session active
	and	screensaver	not	running
In-Reply-To: <470EFE06.3010102@leemhuis.info>
References: <470E5E47.4040006@andrei.myip.org>	<470E60D2.8000808@andrei.myip.org>	<470E6324.6000805@poolshark.org>
	<470EFE06.3010102@leemhuis.info>
Message-ID: <470F2B9A.1070308@poolshark.org>

Thorsten Leemhuis wrote:
> On 11.10.2007 19:53, Denis Leroy wrote:
>> On that subject, does anyone knows how to tell the Frequency Monitor 
>> applet to keep the cpu in lower frequency all the time (i.e. 'killall 
>> -USR2 cpuspeed', which is what you want typically when running on 
>> batteries) ?
> 
> Note, for new processors (like Core*) afaik that's *not* what you want
> when running running on batteries: the total energy consumed often is
> lower if you go to the highest speed, do what needs to be done way
> quicker, and switch back to lowest speed quickly again.

I agree with the theory in the article, but all i can say is that on my 
old T30 it doesn't seem to apply. The default F8t2 install left me with 
an enabled cpuspeed that pushes my cpu at max frequency if I merely move 
a window around. Overall I lose about one third of my battery time in 
that mode (having done plenty of long train trips lately to actually 
test that)

My concern was mainly with the gnome cpu frequency applet that I don't 
find terribly useful: setting the frequency manually is only temporary 
as cpuspeed will change it again, and the only "mode" i have available 
is "performance". But no options for "lowest frequency always"...

I wanted to know if other people had the same issue on different laptops 
before I can and file a bug.

-denis



From a.badger at gmail.com  Fri Oct 12 08:16:23 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 12 Oct 2007 01:16:23 -0700
Subject: Proposals: Remove pkg.acl and owners.list
In-Reply-To: <200710120814.52132.opensource@till.name>
References: <470EA878.4030007@gmail.com>
	<200710120814.52132.opensource@till.name>
Message-ID: <470F2D57.1030806@gmail.com>

Till Maas wrote:
> On Fr Oktober 12 2007, Toshio Kuratomi wrote:
> 
>> 1) cvs rm pkg.acl files from the cvs repo.  The packagedb has taken the
>> place of these files.  Editing them doesn't do anything and it's causing
>> some people confusion that they're still in the repository.  This one
>> seems pretty simple.  Let me know soon if you can think of a reason not
>> to do this.
> 
> Imho everyone who uses a pkg.acl that contains a different information then 
> packagedb should get an extra e-mail.
> 
Actually, I can fix most of these.

1) pkgdb was started on August 7th.  Every pkg.acl modified before this 
date is good because that's when the acls were synced.

2) Some pkg.acl files were added for new files by mistake because of a 
bug in the new pkg script.  These pkg.acl files have never been touched 
since initial package creation and have never served a purpose.

3) A few were made extraneous when the desktop team opened the acls for 
the packages they were responsible for.

This leaves about ten packages to update or contact the maintainer if 
the logs don't show what was intended.

-Toshio



From harald at redhat.com  Fri Oct 12 08:19:30 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 12 Oct 2007 10:19:30 +0200
Subject: boot-time / readahead investigations
In-Reply-To: <e71b3daf0710110904n17d324cbj4a2653826e3b41c3@mail.gmail.com>
References: <470D5CF0.20204@redhat.com>
	<470E3B5C.6030105@redhat.com>	<470E4792.4030606@redhat.com>
	<e71b3daf0710110904n17d324cbj4a2653826e3b41c3@mail.gmail.com>
Message-ID: <470F2E12.1040406@redhat.com>

Jon Nettleton wrote:
> And last but not least if you are truly adventurous grab
> http://www.hekanetworks.com/~jnettlet/open-source/dispatcher.d.tar.bz2
>
> It is a bunch of scripts that you can add to
> /etc/NetworkManager/dispatcher.d/  that can turn on and off Network
> Services.  From the list of services you still have enabled it would
> include sshd, avahi, rpc*.  Disable those in chkconfig and allow
> NetworkManagerDispatcher enable and disable them.  If you only use
> networked cups printers you can add that one also.
>
> Jon
>   
Well, the most important things are:
- Speedup rhgb or find a replacement
- Switch off all unnecessary services
- Add LSB headers to all services and maybe use parallel service startup

Initscripts MetaBug for LSB compatibility:
https://bugzilla.redhat.com/showdependencytree.cgi?id=246824



From nicolas.mailhot at laposte.net  Fri Oct 12 08:37:20 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 10:37:20 +0200 (CEST)
Subject: boot-time / readahead investigations
Message-ID: <23240.192.54.193.51.1192178240.squirrel@rousalka.dyndns.org>



> Jon Nettleton wrote:
>> And last but not least if you are truly adventurous grab
>> http://www.hekanetworks.com/~jnettlet/open-source/dispatcher.d.tar.bz2
>>
>> It is a bunch of scripts that you can add to
>> /etc/NetworkManager/dispatcher.d/  that can turn on and off Network
>> Services.

Does that mean Network manager can work at last on systems without a
running gnome/X session? because otherwise, that's just making core
service management depend on the GUI stack.

-- 
Nicolas Mailhot



From ich at frank-schmitt.net  Fri Oct 12 07:00:21 2007
From: ich at frank-schmitt.net (Frank Schmitt)
Date: Fri, 12 Oct 2007 09:00:21 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
	<20071011113640.2fe41b4e@redhat.com>
	<loom.20071011T203036-966@post.gmane.org>
Message-ID: <m3fy0glsvu.fsf@mid.gehheimdienst.de>

Kevin Kofler <kevin.kofler at chello.at> writes:

> That, or use the "register installer kernel in GRUB" hack which allows 
> upgrading entirely from the HDD, no media needed at all.
>
> Here's the process:
[...]

Thanks, this was really informative and useful.

-- 
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.



From nicolas.mailhot at laposte.net  Fri Oct 12 08:41:27 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 10:41:27 +0200 (CEST)
Subject: gethostby* users
Message-ID: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>


Le Ven 12 octobre 2007 08:35, Ulrich Drepper a ?crit :

> Samba is responsible for almost one quarter of the problems.
>
>      22 samba-common
>      16 sendmail
>      14 samba-client

It's sad sendmail has some kind of special dispenciation and is never
discussed even though it is riddled with problems and we have better
alternatives in the repo.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Fri Oct 12 09:00:17 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 11:00:17 +0200 (CEST)
Subject: samba license change
Message-ID: <16066.192.54.193.51.1192179617.squirrel@rousalka.dyndns.org>


Le Jeu 11 octobre 2007 18:36, Les Mikesell a ?crit :
> Nicolas Mailhot wrote:

>> In a distribution context since yum or anaconda will always choose
>> to
>> install foo with GPLv3 samba you can't handwave "there was a GPLv2
>> samba on the buildsys". That's not what users get through pour
>> distribution. And it's not mere aggregation since one links to the
>> other.
>
> But it's also not a derived work of the gplv3 instance, since that
> could
> be replaced by the gplv2 version and it would still work.

With that kind of argument you could publish large harry potter
extracts in a children book anthology and never get sued. Because they
can be replaced with any other child story, right?

The distro is at some level a derived work of gplv3 samba because
you're distributing GPLv3 samba, so the specific licensing rules of
the samba version you distribute apply to some extent.

Anyway, IANAL, so I'll stop, but I doubt the case is as clear-cut as
you want it to be, especially in an i18n legal context.

-- 
Nicolas Mailhot



From P at draigBrady.com  Fri Oct 12 09:28:36 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Fri, 12 Oct 2007 10:28:36 +0100
Subject: gethostby* users
In-Reply-To: <470F15B2.2020809@redhat.com>
References: <470F15B2.2020809@redhat.com>
Message-ID: <470F3E44.5070304@draigBrady.com>

Ulrich Drepper wrote:
> Even though the situation improved, there are still some programs left
> which use the gethostby* functions.  These really have to be converted
> to use getaddrinfo.

A link to why would be appropriate:
http://udrepper.livejournal.com/16116.html

Note there is no mention of gethostby* issues in my man page.
A BUG section would be appropriate I think.

P?draig.



From buildsys at redhat.com  Fri Oct 12 10:23:14 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 12 Oct 2007 06:23:14 -0400
Subject: rawhide report: 20071012 changes
Message-ID: <200710121023.l9CANEGl028118@porkchop.devel.redhat.com>

New package centerim
	Text mode menu- and window-driven IM

New package fuse-python
	Python bindings for FUSE - filesystem in userspace

New package jack-rack
	Stereo LADSPA effects rack for the JACK audio API

New package vdr-skinsoppalusikka
	The "Soppalusikka" skin for VDR


 
Updated Packages:

PolicyKit-0.6-1.fc8
-------------------
* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.6-1.fc8
- Update to latest upstream release

PolicyKit-gnome-0.6-1.fc8
-------------------------
* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.6-1.fc8
- Update to latest upstream release

booty-0.90-1.fc8
----------------
* Thu Oct 11 2007 Chris Lumens <clumens at redhat.com> 0.90-1
- Don't write out LABEL= for filesystems that were not labeled by anaconda.

curl-7.16.4-8.fc8
-----------------
* Thu Oct 11 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-8
- list features correctly when curl is compiled against NSS (#316191)

db4-4.6.21-1.fc8
----------------
* Thu Oct 11 2007 Jindrich Novy <jnovy at redhat.com> 4.6.21-1
- update to 4.6.21
- own %{_includedir}/db4 (#274251)

desktop-backgrounds-7.92-8
--------------------------
* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 7.92-8
- Scale images

eclipse-1:3.3.0-27.fc8
----------------------
* Thu Oct 11 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-27
- Add patch to have unversioned swt.jar symlink (courtesy Patrice
  Dumas).

* Sat Oct 06 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-26
- Add encoding to desktop file.
- Fix %files list again.

* Fri Oct 05 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-25
- Fix %files list for Fedora Eclipse feature.

fedora-gnome-theme-8.0.0-1.fc8
------------------------------
* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 8.0.0-1
- Update to 8.0.0 to match F8 release
fedorainfinity-gdm-theme-8.0.0-1.fc8
------------------------------------

fedorainfinity-kdm-theme-1.0.0-3.fc8
------------------------------------

gdm-1:2.20.0-16.fc8
-------------------
* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.0-16
- make fedorainfinity-gdm-theme requires be versioned

* Fri Oct 05 2007 Dan Walsh <dwalsh at redhat.com> - 1:2.20.0-14
- Added pam_selinux_permit and pam_namespace to gdm-pam
  * This pam module allows user without a password to login when selinux is in enforcing mode
- Added pam_namespace to gdm-autologin-pam
- These changes were made to make it easier to setup the xguest user account

* Wed Oct 03 2007 Alexander Larsson <alexl at redhat.com> - 1:2.20.0-14
- Fix up pam keyring integration to be what the latest version
  of the docs says

geomview-1.9.4-4.fc8
--------------------
* Tue Oct 09 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.9.4-4
- more icons (#190218)

glibc-2.6.90-19
---------------
* Thu Oct 11 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-19
- fix <netinet/tcp.h>
- simple preprocessor in localedef, fix de_DE collation with it

gnome-mount-0.7-1.fc8
---------------------
* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.7-1.fc8
- Update to latest upstream release

* Fri Aug 31 2007 David Zeuthen <davidz at redhat.com> - 0.7-0.svn20070831.fc8
- New SVN snapshot

* Tue Aug 07 2007 Matthias Clasen <mclasen at redhat.com> 
- Update license field

gnome-nettool-2.20.0-2.fc8
--------------------------
* Thu Oct 11 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Rebuild

hal-0.5.10-1.fc8
----------------
* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.5.10-1.fc8
- Update to latest upstream release
hal-info-20071011-1.fc8
-----------------------
* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 20071011-1.fc8
- Update to latest upstream release

im-chooser-0.5.3-1.fc8
----------------------
* Thu Oct 11 2007 Akira TAGOH <tagoh at redhat.com> - 0.5.3-1
- New upstream release.
  - Fix an issue that looks like IM can't be disabled on im-chooser. (#324231)

kernel-2.6.23-6.fc8
-------------------
* Thu Oct 11 2007 Dave Jones <davej at redhat.com>
- Fix race in e100 driver.

komparator-0.8-1.fc8
--------------------
* Thu Oct 11 2007 Neal Becker <ndbecker2 at gmail.com> - 0.7-1
- Update to 0.8
libgdiplus-1.2.5-1.fc8
----------------------
* Fri Oct 05 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.5-1
- bump to 1.2.5
- disabled static build
- added fontconfig-devel requirement

* Sat Apr 21 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.4-1
- bump

* Fri Jan 26 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.3-1
- bump

libgnome-2.20.0-4.fc8
---------------------
* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-4
- Add Requires: fedora-gnome-theme >= 8.0.0

* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-3
- Add Requires: fedora-gnome-theme

* Tue Sep 18 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-2
- the location of the default background setting changed, 
  update correct schema input file

libsoup-2.2.101-2.fc8
---------------------
* Thu Oct 11 2007 Matthew Barnes <mbarnes at redhat.com> - 2.2.101-2
- Add patch for RH bug #327871 (broken Rhythmbox build).
- Suspect this is really a glibc bug.

libtheora-0:1.0beta1-1.fc8
--------------------------
* Thu Oct 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0beta1-1
- New upstream release 1.0beta1 (bz 307571)

netpbm-10.35-17.fc8
-------------------
* Thu Oct 11 2007 Jindrich Novy <jnovy at redhat.com> 10.35-17
- add xorg-x11-server-utils BR (#313301)

nss-3.11.7-10.fc8
-----------------
* Wed Oct 10 2007 Kai Engert <kengert at redhat.com> - 3.11.7-10
- Add /etc/prelink.conf.d/nss-prelink.conf in order to blacklist
  our signed libraries and protect them from modification.

ntfs-config-1.0-0.5.rc5.fc8
---------------------------
* Thu Oct 11 2007 Xavier Lamien <lxtnow at gmail.com> - 1.0-0.5.rc5
- Removed redhat-arwork as Requires.

p0f-2.0.8-3.fc8
---------------
* Thu Oct 11 2007 Kevin Fenzi <kevin at tummy.com> - 2.0.8-3
- Rebuild for BuildID
- Update License tag

procinfo-18-22.fc8
------------------
* Wed Oct 10 2007 Tomas Smetana <tsmetana at redhat.com> 18-22
- fix #323121 - segfault caused by interrupts counting
- fix division by zero in fullscreen

pungi-1.1.5-1.fc8
-----------------
* Thu Oct 11 2007 Jesse Keating <jkeating at redhat.com> - 1.1.5-1
- Add a cost to the media repo

python-virtinst-0.300.1-3.fc8
-----------------------------
* Thu Oct 11 2007 Daniel P. Berrange <berrange at redhat.com> - 0.300.1-3.fc8
- Fix missing file exception check with NFS installs (rhbz #325591)

rhythmbox-0.11.2-9.fc8
----------------------
* Thu Oct 11 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-9
- Add patch to avoid Rhythmbox escaping the primary text in notifications
  as per the spec (#242260)

rpm-4.4.2.2-2.fc8
-----------------
* Thu Oct 11 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-2
- merge review: remove static libraries (#226377)
- merge review: remove comment causing doxygen to emit non-utf output (#226377)
- other minor spec cleanups

* Wed Oct 03 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-1
- update to 4.4.2.2 final
- update matchpathcon patch to work better when selinux disabled
- resolves #251400, #315271, #296731, #308171, #305221, #295941

* Tue Sep 11 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-0.5.rc2
- 4.4.2.2-rc2
- resolves #180996, #281611, #259961, #277161, #155079
- drop debugedit-names patch now that it's really upstream

sabayon-2.20.1-2.fc8
--------------------
* Thu Oct 11 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Require pyxdg (#327851)

sopwith-1.7.1-5
---------------
* Thu Oct 11 2007 Adrian Reber <adrian at lisas.de> - 1.7.1-5
- rebuilt for BuildID
- updated license tag
- fixed sourceforge URL

system-config-nfs-1.3.29-1.fc8
------------------------------
* Thu Oct 11 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.29-1
- Merge review (#226465):
  - use xdg-open if available
  - obsolete explicit version of redhat-config-date
  - change license tag to GPLv2
  - add release tags to changelog entries to appease rpmlint
  - install most python files not as executable
  - use %config(noreplace)

* Mon Oct 08 2007 Nils Philippsen <nphilipp at redhat.com>
- add "make diff" ("dif") and "make shortdiff" ("sdif")

* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.28-1
- pick up updated translations

thinkfinger-0.3-6.fc8
---------------------
* Tue Oct 09 2007 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.3-6
- Fixed remote login sshd crash (RH #324181)

uudeview-0.5.20-13
------------------
* Thu Oct 11 2007 Adrian Reber <adrian at lisas.de> - 0.5.20-13
- rebuilt for BuildID
- updated license tag

vnstat-1.4-10.fc8
-----------------
* Thu Oct 11 2007 Adrian Reber <adrian at lisas.de> - 1.4-10
- rebuilt for BuildID
- updated license tag

w3c-markup-validator-0.8.2-1.fc8
--------------------------------
* Thu Oct 11 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.8.2-1
- 0.8.2.

xdesktopwaves-1.3-9.fc8
-----------------------
* Thu Oct 11 2007 Adrian Reber <adrian at lisas.de> - 1.3-9
- rebuilt for BuildID
- updated license tag
- fixed sourceforge URL

xmlindent-0.2.17-8.fc8
----------------------
* Thu Oct 11 2007 Adrian Reber <adrian at lisas.de> - 0.2.17-8
- rebuilt for BuildID
- updated license tag
- fixed sourceforge URL

xorg-x11-drv-vmmouse-12.4.3-1.fc8
---------------------------------
* Thu Oct 11 2007 Adam Jackson <ajax at redhat.com> 12.4.3-1
- xf86-input-vmmouse 12.4.3

xorg-x11-drv-vmware-10.15.2-1.fc8
---------------------------------
* Thu Oct 11 2007 Adam Jackson <ajax at redhat.com> 10.15.2-1
- xf86-video-vmware 10.15.2

xorg-x11-proto-devel-7.3-3.fc8
------------------------------
* Thu Oct 11 2007 Adam Jackson <ajax at redhat.com> 7.3-3
- BuildArch: noarch

* Thu Sep 27 2007 Adam Jackson <ajax at redhat.com> 7.3-2
- Require libXau-devel when not doing arch bootstrap (#207391)

yum-3.2.6-5.fc8
---------------
* Thu Oct 11 2007 Jeremy Katz <katzj at redhat.com> - 3.2.6-5
- fix corner case obsoletes depsolving bug

* Thu Oct 11 2007 Jeremy Katz <katzj at redhat.com> - 3.2.6-4
- fix typo in one of yesterday's patches

* Wed Oct 10 2007 Jeremy Katz <katzj at redhat.com> - 3.2.6-3
- pull in upstream fixes for obsoletes to not pull in extra arches (#301661),
  expose key fingerprint in callback and to remove a debug message

zsh-4.3.4-4.fc8
---------------
* Thu Oct 11 2007 James Antill <jantill at redhat.com> - 4.3.4-4
- Fix login shell detection.
- Resolves: 244684

Broken deps for i386
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.i386 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	moodss - 21.5-1.fc7.i386 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.x86_64 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	moodss - 21.5-1.fc7.x86_64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	icewm - 1.2.32-4.fc8.ppc requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	moodss - 21.5-1.fc7.ppc requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	icewm - 1.2.32-4.fc8.ppc64 requires redhat-artwork
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	moodss - 21.5-1.fc7.ppc64 requires sqlite2-tcl
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	xorg-x11-drivers - 7.2-7.fc8.ppc64 requires synaptics





From andy at warmcat.com  Fri Oct 12 10:26:35 2007
From: andy at warmcat.com (Andy Green)
Date: Fri, 12 Oct 2007 11:26:35 +0100
Subject: The gstreamer third way
In-Reply-To: <loom.20071011T201209-819@post.gmane.org>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C82D2.2010107@warmcat.com>
	<470C9681.9050905@nicubunu.ro>	<loom.20071011T191138-597@post.gmane.org>	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
Message-ID: <470F4BDB.2090009@warmcat.com>

Somebody in the thread at some point said:
> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
>> Le jeudi 11 octobre 2007 ? 19:12 +0000, Kevin Kofler a ?crit :
>>> Yet third-party repositories are happily distributing proprietary 
> kmod-nvidia 
>>> modules linked against the GPLv2 kernel, which isn't any more legal than 
>>> distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.
>> Last I checked they're not distributing both kmod-nvidia and kernels in
>> the same repo
> 
> They wouldn't be shipping Samba in the third-party repo either.

So I didn't get the objection to the original proposal.

 - Fedora just sticks with the perfectly valid last GPL2 version for
now, links KDE3 stuff against it as usual and has nothing to do with the
GPL3 version until there is a better situation

 - That is the end of the story for the typical case.  When KDE4 comes
or there is some other better resolution that allows it, Fedora just
starts using the GPL3 samba libs and goes on in a good clean way.

 - Additionally, completely externally, some other repo might offer a
standalone GPL3 samba libs package that has the same soname that
endusers might choose to use to replace Fedora's GPL2 library.  That's
up to them and the user's problem that his combined system may not be
redistributable if he goes down that path.

If I understood it, this does not violate any terms or intention of the
terms and is nice and clean.

-Andy



From abartlet at samba.org  Fri Oct 12 11:08:17 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Fri, 12 Oct 2007 21:08:17 +1000
Subject: gethostby* users
In-Reply-To: <470F15B2.2020809@redhat.com>
References: <470F15B2.2020809@redhat.com>
Message-ID: <1192187298.3672.15.camel@dragonlady>

On Thu, 2007-10-11 at 23:35 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Even though the situation improved, there are still some programs left
> which use the gethostby* functions.  These really have to be converted
> to use getaddrinfo.  Here is the break-down per package of an incomplete
> installation giving the number of programs/libraries with problems in
> that package.  I.e., there are like more packages on an install-all
> machine.  The full list with the program/library names is at
> 
>    http://people.redhat.com/drepper/gethostby-users
> 
> Samba is responsible for almost one quarter of the problems.

After some excellent work and presentations by David Holder
<david.holder at erion.co.uk> at the recent CIFS interop there is current
work to fix up Samba for IPv6.  Some parts of the protocol just don't
allow for anything but IPv4, but where we can, things are being updated
for Samba 3.2.  

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.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/20071012/e8d3774d/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Fri Oct 12 11:13:37 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 12 Oct 2007 13:13:37 +0200
Subject: Retiring procinfo
In-Reply-To: <3170f42f0710110735x48d74794s8d55fb3573e7bd13@mail.gmail.com>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
	<3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>
	<20071011161819.87949eae.tsmetana@redhat.com>
	<3170f42f0710110735x48d74794s8d55fb3573e7bd13@mail.gmail.com>
Message-ID: <20071012131337.9e32df40.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 11 Oct 2007 20:05:03 +0530, Debarshi 'Rishi' Ray wrote:

> >  But it's 6 years dead piece of software and by today
> > I haven't heard of anybody using it.
> 
> You already got a user now -- Steven R. Ringwald. :-)

I've been suggesting "socklist" from the procinfo package to newbies
regularly as an alternative to "netstat" with several args.



From tsmetana at redhat.com  Fri Oct 12 11:29:58 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Fri, 12 Oct 2007 13:29:58 +0200
Subject: Retiring procinfo
In-Reply-To: <20071012131337.9e32df40.mschwendt.tmp0701.nospam@arcor.de>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>
	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>
	<3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>
	<20071011161819.87949eae.tsmetana@redhat.com>
	<3170f42f0710110735x48d74794s8d55fb3573e7bd13@mail.gmail.com>
	<20071012131337.9e32df40.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071012132958.c235b483.tsmetana@redhat.com>

On Fri, 12 Oct 2007 13:13:37 +0200
Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:

> On Thu, 11 Oct 2007 20:05:03 +0530, Debarshi 'Rishi' Ray wrote:
> 
> > >  But it's 6 years dead piece of software and by today
> > > I haven't heard of anybody using it.
> > 
> > You already got a user now -- Steven R. Ringwald. :-)
> 
> I've been suggesting "socklist" from the procinfo package to newbies
> regularly as an alternative to "netstat" with several args.

OK.  Giving up.  Procinfo will stay and I'll keep maintaining it.

-- 
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From jon.nettleton at gmail.com  Fri Oct 12 12:13:30 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Fri, 12 Oct 2007 08:13:30 -0400
Subject: boot-time / readahead investigations
In-Reply-To: <23240.192.54.193.51.1192178240.squirrel@rousalka.dyndns.org>
References: <23240.192.54.193.51.1192178240.squirrel@rousalka.dyndns.org>
Message-ID: <e71b3daf0710120513m71471446iac3d59acffb6b3b4@mail.gmail.com>

On 10/12/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
>
> > Jon Nettleton wrote:
> >> And last but not least if you are truly adventurous grab
> >> http://www.hekanetworks.com/~jnettlet/open-source/dispatcher.d.tar.bz2
> >>
> >> It is a bunch of scripts that you can add to
> >> /etc/NetworkManager/dispatcher.d/  that can turn on and off Network
> >> Services.
>
> Does that mean Network manager can work at last on systems without a
> running gnome/X session? because otherwise, that's just making core
> service management depend on the GUI stack.
>

No I am making network dependent services managed by the
NetworkManagerDispatcher.

If you are using NetworkManager you already know that you won't have a
network connection until nm-applet starts ( unless you use a wired
connection and dhcp ).   What is the point of starting core services
that are network dependent if you don't have a network connection?

Jon



From limb at jcomserv.net  Fri Oct 12 12:12:21 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 12 Oct 2007 07:12:21 -0500 (CDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM 
 machine
In-Reply-To: <1192167871.19494.34.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org> <fem0ue$qg8$1@sea.gmane.org>
	<1192137117.19494.19.camel@code.and.org>
	<20071011211512.GA2809@jadzia.bu.edu>
	<1192167871.19494.34.camel@code.and.org>
Message-ID: <34317.63.85.68.164.1192191141.squirrel@mail.jcomserv.net>



> ...and that's the easy bit, then you have to somehow work out how long a
> user keeps a machine running and often they apply updates and compare
> that against how much memory/CPU they have.
>  I can well imagine that users who update more often and keep their
> machines running longer have significantly more RAM (and CPU) in their
> machines.

You'd think, but I actually run a small group of very old, long uptime,
frequently updated machines.  All works well for me with no special
tweaking needed.  YMMV. . .

> --
> James Antill <james.antill at redhat.com>
> Red Hat
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From ssorce at redhat.com  Fri Oct 12 12:22:41 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 12 Oct 2007 08:22:41 -0400
Subject: gethostby* users
In-Reply-To: <470F15B2.2020809@redhat.com>
References: <470F15B2.2020809@redhat.com>
Message-ID: <1192191761.851.91.camel@localhost.localdomain>

On Thu, 2007-10-11 at 23:35 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Even though the situation improved, there are still some programs left
> which use the gethostby* functions.  These really have to be converted
> to use getaddrinfo.  Here is the break-down per package of an incomplete
> installation giving the number of programs/libraries with problems in
> that package.  I.e., there are like more packages on an install-all
> machine.  The full list with the program/library names is at
> 
>    http://people.redhat.com/drepper/gethostby-users
> 
> Samba is responsible for almost one quarter of the problems.

Ulrich, the situation should be substantially better in the F-9
timeframe.
Samba 3.2.0 will show full support for IPv6 (and therefore we are
converting most calls to getaddrinfo) where possible.

Simo.



From nicolas.mailhot at laposte.net  Fri Oct 12 12:30:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 14:30:07 +0200 (CEST)
Subject: boot-time / readahead investigations
Message-ID: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>


Le Ven 12 octobre 2007 14:13, Jon Nettleton a ?crit :

> If you are using NetworkManager you already know that you won't have a
> network connection until nm-applet starts ( unless you use a wired
> connection and dhcp ).   What is the point of starting core services
> that are network dependent if you don't have a network connection?

1. A lot of core services can be both local and network (cups for
example). I have a local imap service (because decent maildir handling
has been in thunderbird's "later" pipes for years). It's used remotely
and localy. Other people have similar needs.

2. But anyway assuming those services can be tagged as "always on, the
problem is not having network-dependant services depend on network
availability but having network availability depend on an applet. You
can have home headless servers that do not use a wired connection too
(typically : print server/ HTPC box next to the controlled hardware,
and wifi-enabled AP/Home router next to the ADSL phone line plug)

-- 
Nicolas Mailhot



From jonathan.underwood at gmail.com  Fri Oct 12 12:39:48 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Fri, 12 Oct 2007 13:39:48 +0100
Subject: boot-time / readahead investigations
In-Reply-To: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>
References: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>
Message-ID: <645d17210710120539l15ab662byf171c2a6cbb6c41d@mail.gmail.com>

On 12/10/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Ven 12 octobre 2007 14:13, Jon Nettleton a ?crit :
>
> > If you are using NetworkManager you already know that you won't have a
> > network connection until nm-applet starts ( unless you use a wired
> > connection and dhcp ).   What is the point of starting core services
> > that are network dependent if you don't have a network connection?
>
> 1. A lot of core services can be both local and network (cups for
> example). I have a local imap service (because decent maildir handling
> has been in thunderbird's "later" pipes for years). It's used remotely
> and localy. Other people have similar needs.
>

I do exactly this as well (have dovecot listening locally). Other
examples are having Samba running locally for virtualised machines,
and of course sendmail, and also apache to test web pages locally.



From jon.nettleton at gmail.com  Fri Oct 12 12:53:11 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Fri, 12 Oct 2007 08:53:11 -0400
Subject: boot-time / readahead investigations
In-Reply-To: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>
References: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>
Message-ID: <e71b3daf0710120553p10de8824qfe81ba7b94b57300@mail.gmail.com>

On 10/12/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Ven 12 octobre 2007 14:13, Jon Nettleton a ?crit :
>
> > If you are using NetworkManager you already know that you won't have a
> > network connection until nm-applet starts ( unless you use a wired
> > connection and dhcp ).   What is the point of starting core services
> > that are network dependent if you don't have a network connection?
>
> 1. A lot of core services can be both local and network (cups for
> example). I have a local imap service (because decent maildir handling
> has been in thunderbird's "later" pipes for years). It's used remotely
> and localy. Other people have similar needs.

Yes and you can still run those services during boot if you would
like.  Nothing is stopping you.  Actually if you looked at my scripts
you will see I don't even include scripts for either of these
services.

>
> 2. But anyway assuming those services can be tagged as "always on, the
> problem is not having network-dependant services depend on network
> availability but having network availability depend on an applet. You
> can have home headless servers that do not use a wired connection too
> (typically : print server/ HTPC box next to the controlled hardware,
> and wifi-enabled AP/Home router next to the ADSL phone line plug)

I am not sure why this is even being brought up.  I understand what a
server is, and what it's purpose is.  However That is not what this
discussion is about.  This discussion is about speeding up the boot
time of his DESKTOP machine.

Since Harald had done a good amount of tweaking and testing boot time,
I was simply asking if moving some init services to be handled by NMD
would speed up the boot even further.  By the way.  Thanks Harald for
the testing and write up.

Jon



From cmadams at hiwaay.net  Fri Oct 12 13:02:30 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 12 Oct 2007 08:02:30 -0500
Subject: gethostby* users
In-Reply-To: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
Message-ID: <20071012130230.GA1451534@hiwaay.net>

Once upon a time, Nicolas Mailhot <nicolas.mailhot at laposte.net> said:
> It's sad sendmail has some kind of special dispenciation and is never
> discussed even though it is riddled with problems and we have better
> alternatives in the repo.

"never discussed"?  I suggest you read the list archives.

"riddled with problems" such as...?

I know it is fun to pick on sendmail, but it works well and I can use it
to do things not easily done in some other MTAs.

sendmail already supports IPv6 without getaddrinfo() (since sendmail is
about more than Linux and not all other platforms have getaddrinfo()).
-- 
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 ssorce at redhat.com  Fri Oct 12 13:06:04 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 12 Oct 2007 09:06:04 -0400
Subject: samba license change
In-Reply-To: <16066.192.54.193.51.1192179617.squirrel@rousalka.dyndns.org>
References: <16066.192.54.193.51.1192179617.squirrel@rousalka.dyndns.org>
Message-ID: <1192194364.851.97.camel@localhost.localdomain>

On Fri, 2007-10-12 at 11:00 +0200, Nicolas Mailhot wrote:
> Le Jeu 11 octobre 2007 18:36, Les Mikesell a ?crit :
> > Nicolas Mailhot wrote:
> 
> >> In a distribution context since yum or anaconda will always choose
> >> to
> >> install foo with GPLv3 samba you can't handwave "there was a GPLv2
> >> samba on the buildsys". That's not what users get through pour
> >> distribution. And it's not mere aggregation since one links to the
> >> other.
> >
> > But it's also not a derived work of the gplv3 instance, since that
> > could
> > be replaced by the gplv2 version and it would still work.
> 
> With that kind of argument you could publish large harry potter
> extracts in a children book anthology and never get sued. Because they
> can be replaced with any other child story, right?

No, you are comparing apples and oranges, a book is not a functional
work, and software is a very special case in copyright, behaves somewhat
differently from other works.

> The distro is at some level a derived work of gplv3 samba because
> you're distributing GPLv3 samba, so the specific licensing rules of
> the samba version you distribute apply to some extent.

Rubbish, if that were true the distribution would have to be GPLv3 in
all of its components. A distribution is a mere aggregation of
copyrighted works.

> Anyway, IANAL, so I'll stop, but I doubt the case is as clear-cut as
> you want it to be, especially in an i18n legal context.

We don't have all the answers, but we can certainly exclude some exotic
ones :)

Simo.



From nicolas.mailhot at laposte.net  Fri Oct 12 13:23:19 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 15:23:19 +0200 (CEST)
Subject: boot-time / readahead investigations
Message-ID: <25635.192.54.193.51.1192195399.squirrel@rousalka.dyndns.org>


Le Ven 12 octobre 2007 14:53, Jon Nettleton a ?crit :

> I am not sure why this is even being brought up.  I understand what a
> server is, and what it's purpose is.  However That is not what this
> discussion is about.  This discussion is about speeding up the boot
> time of his DESKTOP machine.

Please also understand the frontier between server and desktop is not
as clear cut as you seem to want it, and a lot of home systems are
mixed usage.

My server is my desktop and my desktop is my server. I don't have the
money or the space to nicely separate the functions in different
systems to simplify your life. That's the same for a lot of people -
they buy a desktop, laptop or shuttle and expect it to fill all their
home computing needs.

Fedora network and service management has been going nowhere for a few
releases because the people that should drive the changes have decided
they could focus on single-user single-usage laptops exclusively. As a
result every other Fedora group is waiting for them to come to their
senses instead of moving fedora packages to the bright new future the
desktop team dreams of.

Fedora does not have a "desktop boot system" or a "desktop network
system". It has a "general-purpose boot system" and a "general-purpose
network system".

But anyway you've answered my original question. NetworkManager and
anything that depends on it is still something totally unsuitable for
my desktop.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Fri Oct 12 13:26:03 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 12 Oct 2007 15:26:03 +0200 (CEST)
Subject: gethostby* users
Message-ID: <38134.192.54.193.51.1192195563.squirrel@rousalka.dyndns.org>


Le Ven 12 octobre 2007 15:02, Chris Adams a ?crit :

> "riddled with problems" such as...?

Such as being #2 in the posted profile.

-- 
Nicolas Mailhot



From ssorce at redhat.com  Fri Oct 12 13:35:04 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 12 Oct 2007 09:35:04 -0400
Subject: samba license change
In-Reply-To: <1192173024.13539.91.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<1191936845.8880.8.camel@localhost.localdomain>
	<1191948598.8880.24.camel@localhost.localdomain>
	<200710092018.21899.ville.skytta@iki.fi>
	<1192000528.13539.61.camel@localhost.localdomain>
	<1192020068.13627.68.camel@localhost.localdomain>
	<1192173024.13539.91.camel@localhost.localdomain>
Message-ID: <1192196104.10852.5.camel@localhost.localdomain>

On Fri, 2007-10-12 at 09:10 +0200, Alexander Larsson wrote:
> > 
> > This is interesting, to be sure we should evaluate though if there
> is
> > intimate communication and sharing of data structures between the
> daemon
> > and the client, but things looks much better in the GNOME camp.
> 
> It just uses the standard way to put gnome-vfs modules in the daemon.
> Nothing is specific to the smb backend. In fact, any backend can be
> put
> in the daemonb by adding [daemon] to the module config file.

I guess here you are saying: the gnome-vfs interface, is generic and a
kind of standard and so it isolate the work and makes upper layers
non-derivative.

This make sense, and GPLv3 helps a lot in this case as the revised
wording concerning this case is much better than what you find in GPLv2:

        A ?Standard Interface? means an interface that either is an
        official standard defined by a recognized standards body, or, in
        the case of interfaces specified for a particular programming
        language, one that is widely used among developers working in
        that language.

from 1. Source code, gplv3

Not sure this apply, may be a bit of a stretch, but it seem a case where
this make sense.

Simo.



From khc at pm.waw.pl  Fri Oct 12 13:42:30 2007
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Fri, 12 Oct 2007 15:42:30 +0200
Subject: samba license change
In-Reply-To: <16066.192.54.193.51.1192179617.squirrel@rousalka.dyndns.org>
	(Nicolas Mailhot's message of "Fri,
	12 Oct 2007 11:00:17 +0200 (CEST)")
References: <16066.192.54.193.51.1192179617.squirrel@rousalka.dyndns.org>
Message-ID: <m34pgwbgah.fsf@maximus.localdomain>

"Nicolas Mailhot" <nicolas.mailhot at laposte.net> writes:

> With that kind of argument you could publish large harry potter
> extracts in a children book anthology and never get sued. Because they
> can be replaced with any other child story, right?

Sure, if you have a licence to distribute harry potter as a whole,
of course.
-- 
Krzysztof Halasa



From stickster at gmail.com  Fri Oct 12 13:59:54 2007
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 12 Oct 2007 09:59:54 -0400
Subject: CDs DVDs or netboot. Oh my!
In-Reply-To: <1192112944.26533.25.camel@localhost.localdomain>
References: <470D81BB.2070404@redhat.com> <1192069420.19308.15.camel@cutter>
	<7874d9dd0710101936x304fc3e5m9f67a07411269881@mail.gmail.com>
	<1192084296.4029.5.camel@rousalka.dyndns.org>
	<Pine.LNX.4.64.0710110912020.4486@beer.tclug.org>
	<1192112944.26533.25.camel@localhost.localdomain>
Message-ID: <1192197594.4033.7.camel@localhost.localdomain>


On Thu, 2007-10-11 at 10:29 -0400, Jeremy Katz wrote:
> On Thu, 2007-10-11 at 09:19 -0500, Jima wrote:
> > On Thu, 11 Oct 2007, Nicolas Mailhot wrote:
> > > Le mercredi 10 octobre 2007 ? 21:36 -0500, Michael Stahnke a ?crit :
> > >> I really think an upgrade path for the casual user is required.
> > >
> > > Unless they've been dunked, network install/updates should fit the bill
> > 
> >   I forget if this ever went anywhere, but I remember some time ago someone 
> > suggesting that we should have an installable package that would plop 
> > (essentially) the kernel image and initrd from the boot.iso into /boot, 
> > and add an entry into grub.conf for the next release's installer.  No 
> > CD/DVD required, no mucking around to figure out how to get your machine 
> > to boot to the optical drive...it'd be just the same as a network 
> > install/upgrade.  As Matt Domsch pointed out, it could even use our 
> > mirrorlist infrastructure to pick the download source.  We could even 
> > include the stage2.img (optionally, with a non-dependent subpackage that 
> > would pull in the main one).  It would handle the 
> > wants-to-upgrade-but-not-use-yum segment nicely, IMO.
> >   Alas, I don't remember if this ever got off the ground.  Sure seems like 
> > a nice potential target for F-9.
> 
> Some bits got done here, others didn't.  Seth has the start of the
> script to pre-download all of the packages as well as the kernel and
> initrd to set this up.  You still then need to download stage2 from
> anaconda (or boot off of the rescuecd), but the packages will get
> preferred from the lookaside path on the rootfs.
> 
> Definitely could use some more testing, though.

I know I'm late to this thread, but there is material in the F8
Installation Guide on how to perform these tasks, albeit manually.  I'm
not saying this obviates the need for a pretty packaged solution, just
that we have a centralized source for this info now.

I've also added information on upgrades, and have been posting new
drafts at my fedorapeople.org site (pfrields.fedorapeople.org) to
collect community input.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- 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/20071012/912f63cb/attachment.sig>

From stickster at gmail.com  Fri Oct 12 14:28:00 2007
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 12 Oct 2007 10:28:00 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <45270.63.85.68.164.1192119633.squirrel@mail.jcomserv.net>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<1192105313.6070.30.camel@localhost.localdomain>
	<470E16A1.8030501@fedoraproject.org>
	<7301.63.85.68.164.1192112502.squirrel@mail.jcomserv.net>
	<20071011113640.2fe41b4e@redhat.com>
	<45270.63.85.68.164.1192119633.squirrel@mail.jcomserv.net>
Message-ID: <1192199280.4033.9.camel@localhost.localdomain>


On Thu, 2007-10-11 at 11:20 -0500, Jon Ciesla wrote:
> > On Thu, 11 Oct 2007 09:21:42 -0500 (CDT)
> > "Jon Ciesla" <limb at jcomserv.net> wrote:
> >
> >> But the point is if you have no DVD drive, the only upgrade method,
> >> AFAIK is yum, which is not officially supported.
> >
> > Incorrect.  rescue.iso or boot.iso + network, or harddrive.
> 
> Is this in the wiki anywhere?  Because I seem to recall asking about this
> when CDs went away, and was told it was yum or fresh install.
> 
> Granted, upgrading with yum is great and works well, and is my preferred
> method, but I have to have something else in case we get to a point where
> a yum upgrade is impossible for some unforseen reason.

The Installation Guide has information on doing this.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- 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/20071012/5ba34c85/attachment.sig>

From berrange at redhat.com  Fri Oct 12 15:04:58 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 12 Oct 2007 16:04:58 +0100
Subject: gethostby* users
In-Reply-To: <470F15B2.2020809@redhat.com>
References: <470F15B2.2020809@redhat.com>
Message-ID: <20071012150458.GB20817@redhat.com>

On Thu, Oct 11, 2007 at 11:35:30PM -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Even though the situation improved, there are still some programs left
> which use the gethostby* functions.  These really have to be converted
> to use getaddrinfo.  Here is the break-down per package of an incomplete
> installation giving the number of programs/libraries with problems in
> that package.  I.e., there are like more packages on an install-all
> machine.  The full list with the program/library names is at
> 
>    http://people.redhat.com/drepper/gethostby-users
> 
>       7 qemu
>       1 kvm

You can add 'xen' to this list too. Basically they all use QEMU, and QEMU
has really crude IPv4 handling written in such a way that its pretty hard
to switch to getaddrinfo(). It is none-the-less on my list of things to
attack in upstream QEMU, because the rest of the virt stack is fully IPv6
enabled & QEMU's VNC server is a glaring missing link :-(

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From louisg00 at bellsouth.net  Fri Oct 12 15:44:49 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Fri, 12 Oct 2007 11:44:49 -0400
Subject: Lastest initscripts does not save sound
Message-ID: <1192203889.2492.2.camel@tiger>

Today my laptop booted with sound muted. Didn't happen before. I can
only thing of initscripts being updated yesterday.




From louisg00 at bellsouth.net  Fri Oct 12 15:48:28 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Fri, 12 Oct 2007 11:48:28 -0400
Subject: gdm dosen't show my pix on the face greeter
Message-ID: <1192204108.2492.7.camel@tiger>

I put a pix of myself in the 'about me' capplet and have a .face in my
home dir. Why doesn't gdm pick it up?

-Louis



From bnocera at redhat.com  Fri Oct 12 15:55:39 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 12 Oct 2007 16:55:39 +0100
Subject: Lastest initscripts does not save sound
In-Reply-To: <1192203889.2492.2.camel@tiger>
References: <1192203889.2492.2.camel@tiger>
Message-ID: <1192204539.16148.1.camel@cookie.hadess.net>

On Fri, 2007-10-12 at 11:44 -0400, Louis E Garcia II wrote:
> Today my laptop booted with sound muted. Didn't happen before. I can
> only thing of initscripts being updated yesterday.

Try removing nas from the initscripts.



From bnocera at redhat.com  Fri Oct 12 15:56:28 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 12 Oct 2007 16:56:28 +0100
Subject: gdm dosen't show my pix on the face greeter
In-Reply-To: <1192204108.2492.7.camel@tiger>
References: <1192204108.2492.7.camel@tiger>
Message-ID: <1192204588.16148.3.camel@cookie.hadess.net>

On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> I put a pix of myself in the 'about me' capplet and have a .face in my
> home dir. Why doesn't gdm pick it up?

Check the permissions on your home directory and ~/.face.

If your home directory doesn't allow for the gdm user to access ~/.face,
then it won't work...



From david at fubar.dk  Fri Oct 12 16:19:54 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 12 Oct 2007 12:19:54 -0400
Subject: gdm dosen't show my pix on the face greeter
In-Reply-To: <1192204588.16148.3.camel@cookie.hadess.net>
References: <1192204108.2492.7.camel@tiger>
	<1192204588.16148.3.camel@cookie.hadess.net>
Message-ID: <1192205994.19420.11.camel@oneill.fubar.dk>


On Fri, 2007-10-12 at 16:56 +0100, Bastien Nocera wrote:
> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > I put a pix of myself in the 'about me' capplet and have a .face in my
> > home dir. Why doesn't gdm pick it up?
> 
> Check the permissions on your home directory and ~/.face.
> 
> If your home directory doesn't allow for the gdm user to access ~/.face,
> then it won't work...

Actually it's supposed to work because the gdm greeter gets the faces
through a pipe from the master gdm process which is running as root.

      David



From gilboad at gmail.com  Fri Oct 12 16:53:30 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Fri, 12 Oct 2007 18:53:30 +0200
Subject: xdg-menu, icewm and bluecurve-icon-theme's missing sym-links.
In-Reply-To: <loom.20071011T200657-803@post.gmane.org>
References: <1192107172.32192.16.camel@gilboa-work-dev.localdomain>
	<loom.20071011T200657-803@post.gmane.org>
Message-ID: <1192208010.31406.0.camel@gilboa-home-dev.localdomain>

On Thu, 2007-10-11 at 20:07 +0000, Kevin Kofler wrote:
> Gilboa Davara <gilboad <at> gmail.com> writes:
> > However, the old package contained a number of syn-links that are no
> > longer included in the new package. (E.g. gnome-terminal.png ->
> > icon-terminal.png; mozilla-icon.png -> icon-web-browser.png; etc)
> 
> Then here's the real problem, please file a bug against bluecurve-icon-theme to 
> get this fixed ASAP, the symlinks are needed by many other things too, they 
> can't just go away.
> 
>         Kevin Kofler
> 

Somehow, due to lack of sleep - most-likely, I thought it was
intentional.
Thanks for the head's-up.

- Gilboa



From jspaleta at gmail.com  Fri Oct 12 16:55:54 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 12 Oct 2007 08:55:54 -0800
Subject: boot-time / readahead investigations
In-Reply-To: <e71b3daf0710120553p10de8824qfe81ba7b94b57300@mail.gmail.com>
References: <20981.192.54.193.51.1192192207.squirrel@rousalka.dyndns.org>
	<e71b3daf0710120553p10de8824qfe81ba7b94b57300@mail.gmail.com>
Message-ID: <604aa7910710120955x478bdf0fs7960102036a9d9be@mail.gmail.com>

On 10/12/07, Jon Nettleton <jon.nettleton at gmail.com> wrote:
> Yes and you can still run those services during boot if you would
> like.  Nothing is stopping you.  Actually if you looked at my scripts
> you will see I don't even include scripts for either of these
> services.

I don't mind seeing services turned into NWD controlled items which
only come on if the network is present by default.  But if we are
going to move to NWD based services in by default, we need some
integration with UI such that we can easily tag those services as
always on at boot on a case by case basis.  So when I'm using my
desktop/server/laptop I don't have to drill down and figure out wtf
the NWD managed scripts live and I can just open up the services UI
and tell each managed service to stop being dynamic and start being
always on.

-jef



From tmz at pobox.com  Fri Oct 12 17:33:38 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 12 Oct 2007 13:33:38 -0400
Subject: upload cert?
In-Reply-To: <1192127134.4076.3.camel@T7.Linux>
References: <1192116344.4076.0.camel@T7.Linux> <470E3F6F.4050302@redhat.com>
	<1192127134.4076.3.camel@T7.Linux>
Message-ID: <20071012173338.GA3536@psilocybe.teonanacatl.org>

Paul wrote:
> That's just the fedora.cert one. I've updated mono and libgdiplus. I
> can do the make tag, but make build complains that I dont have
> .fedora.upload.cert.ca in my /home/paul directory

Try running fedora-packager-setup.sh to pull the certs and set things
up that may be missing.

BTW, I noticed in the mono import that some changelog (and possibly
other) history was overwritten.  Was that intentional?

http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg01129.html

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't mean to sound cold, or cruel, or vicious,
but I am, so that's the way it comes out.
    -- Bill Hicks

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

From gilboad at gmail.com  Fri Oct 12 17:52:53 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Fri, 12 Oct 2007 19:52:53 +0200
Subject: plague times out when trying to build icewm/EL-5, FC-6.
Message-ID: <1192211573.27039.3.camel@gilboa-home-dev.localdomain>

Hello all,

I'm trying build a new icewm using plague and it times out on me.
Or actually, it EWOULDBLOCKs on me on read().

Server down?

$ strace /usr/bin/plague-client build icewm icewm-1_2_32-5_el5 el5 2>
~/plague.log
Error connecting to build server: '(110, 'Operation timed out.')'

Trace log attached.

- Gilboa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plague.log.bz2
Type: application/x-bzip
Size: 13556 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/cf9042f8/attachment.bin>

From Curtis at GreenKey.net  Fri Oct 12 18:09:13 2007
From: Curtis at GreenKey.net (Curtis Doty)
Date: Fri, 12 Oct 2007 11:09:13 -0700 (PDT)
Subject: Memory usage - default X install can't use yum with 1GB RAM 
 machine
In-Reply-To: <1192137117.19494.19.camel@code.and.org>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org> <fem0ue$qg8$1@sea.gmane.org>
	<1192137117.19494.19.camel@code.and.org>
Message-ID: <20071012180914.3AE6C6F1C5@alopias.GreenKey.net>

Yesterday James Antill said:

> On Thu, 2007-10-11 at 16:26 -0400, sean darcy wrote:
>> James Antill wrote:
>> ................
>>>  I've attached a simple python script I've used, it's not perfect but it
>>> shows roughly how much dead memory you have and will kind of show where
>>> it is.
>>>
>>
>> Great script. But is rebooting the only answer?
>
> So what it tries to show is how much memory is being "allocated" to
> files that no longer exist. This _could_ be a normal thing, but is most
> often due to shared libraries that have either been upgraded or changed
> via. prelink ... but which are still mapped into another application.
>
> So, yes, the only way to fix that is to "reboot" the application so it
> uses the new version of the shared library instead of the old deleted
> one. For some applications it's easy enough to just restart them, for
> others you might as well just reboot the entire machine.
>

Yes way cool, James. That script hightlights a bunch of info I've been 
curious about and too lazy to RTF proc(5). Here's a little patch to make 
it disclose which processes are sitting on the deleted libs.

--- wasted-ram-updates.py.orig  2007-10-12 09:55:34.000000000 -0700
+++ wasted-ram-updates.py       2007-10-12 10:38:17.000000000 -0700
@@ -13,6 +13,7 @@ def loc_num(x):
      return locale.format("%d", int(x), True)

  pids = []
+cmds = {}
  for d in os.listdir("/proc/"):
      try:
          pid = int(d)
@@ -20,6 +21,14 @@ for d in os.listdir("/proc/"):
      except:
          pass

+def cmdFromPID(pid):
+    """fetch command line from a process id"""
+    try:
+        cmdline= open("/proc/%i/cmdline" %pid).readlines()[0]
+        return " ".join(cmdline.split("\x00")).rstrip()
+    except:
+        return ""
+
  def map_sz(x):
      (beg, end) = x.split('-')
      return (int(end, 16) - int(beg, 16))
@@ -38,10 +47,7 @@ for pid in pids:
          while off < len(lines):
              line = lines[off]
              off += 1
-            try:
-                int(line[0])
-            except:
-                continue
+            if line[0] in ["S", "R", "P"]: continue

              data = line.split(None, 5)
              try:
@@ -59,6 +65,8 @@ for pid in pids:
              if '(deleted)' not in data[5]:
                  continue

+            cmds[pid]= cmdFromPID(pid)
+
              key = "%s:%d" % (data[3], ino)
              if key not in files:
                  files[key] = lambda x: x # Hack
@@ -121,7 +129,9 @@ for x in files.values():
      s_private_dirty += x.s_private_dirty
      referenced      += x.referenced

-    print x.pids, loc_num(x.vsz), x.name,
+    print "%7sKB %s" %(loc_num(x.vsz/1024), x.name),
+    for p in frozenset(x.pids):
+        print "      %5i %s" %(p, cmds[p])
  print "\
  =============================================================================="
  print "num             = %-20s" % loc_num(len(files))

Note that it also attempts to fix a (possible?) bug of missing an address 
above 2.5GB. Although I dunno the likelyhood of this, the "fix" is neater 
though.

Thanks!
../C



From drepper at redhat.com  Fri Oct 12 18:10:15 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 12 Oct 2007 11:10:15 -0700
Subject: gethostby* users
In-Reply-To: <1192187298.3672.15.camel@dragonlady>
References: <470F15B2.2020809@redhat.com> <1192187298.3672.15.camel@dragonlady>
Message-ID: <470FB887.2020101@redhat.com>

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

Andrew Bartlett wrote:
> Some parts of the protocol just don't
> allow for anything but IPv4, but where we can, things are being updated
> for Samba 3.2.  

I've pointed out at numerous occasions that getaddrinfo is not for IPv6
only.  You should always use getaddrinfo, even for IPv4-only situations.
  See

  http://udrepper.livejournal.com/16116.html

The gethostby* interfaces simply don't cut it in today's network anymore.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHD7iH2ijCOnn/RHQRAkRJAKCIK9hnfYlCCfUIIYTtlhAH1hpKBgCgugIq
RVe/7rt4HyA65HKlTCi8TQQ=
=yQ2L
-----END PGP SIGNATURE-----



From cmadams at hiwaay.net  Fri Oct 12 18:18:38 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 12 Oct 2007 13:18:38 -0500
Subject: gethostby* users
In-Reply-To: <38134.192.54.193.51.1192195563.squirrel@rousalka.dyndns.org>
References: <38134.192.54.193.51.1192195563.squirrel@rousalka.dyndns.org>
Message-ID: <20071012181838.GD1451534@hiwaay.net>

Once upon a time, Nicolas Mailhot <nicolas.mailhot at laposte.net> said:
> Le Ven 12 octobre 2007 15:02, Chris Adams a ??crit :
> > "riddled with problems" such as...?
> 
> Such as being #2 in the posted profile.

grep doesn't tell the whole story; see the sendmail source.
-- 
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 notting at redhat.com  Fri Oct 12 19:05:57 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 12 Oct 2007 15:05:57 -0400
Subject: Lastest initscripts does not save sound
In-Reply-To: <1192203889.2492.2.camel@tiger>
References: <1192203889.2492.2.camel@tiger>
Message-ID: <20071012190557.GA5515@nostromo.devel.redhat.com>

Louis E Garcia II (louisg00 at bellsouth.net) said: 
> Today my laptop booted with sound muted. Didn't happen before. I can
> only thing of initscripts being updated yesterday.

I believe this is a selinux policy bug. See 329901.

Bill



From mmcgrath at redhat.com  Fri Oct 12 19:07:11 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 12 Oct 2007 14:07:11 -0500
Subject: plague times out when trying to build icewm/EL-5, FC-6.
In-Reply-To: <1192211573.27039.3.camel@gilboa-home-dev.localdomain>
References: <1192211573.27039.3.camel@gilboa-home-dev.localdomain>
Message-ID: <470FC5DF.6090409@redhat.com>

Gilboa Davara wrote:
> Hello all,
>
> I'm trying build a new icewm using plague and it times out on me.
> Or actually, it EWOULDBLOCKs on me on read().
>
> Server down?
>
> $ strace /usr/bin/plague-client build icewm icewm-1_2_32-5_el5 el5 2>
> ~/plague.log
> Error connecting to build server: '(110, 'Operation timed out.')'
>
>   
FWIW it looks like it succeeded?  - 
http://buildsys.fedoraproject.org/build-status/job.psp?uid=36632  Could 
be a slow connection.  I'll keep my ears out to see if others are having 
any issues.

    -Mike



From davej at redhat.com  Fri Oct 12 19:14:57 2007
From: davej at redhat.com (Dave Jones)
Date: Fri, 12 Oct 2007 15:14:57 -0400
Subject: should readahead allow generic paths?
In-Reply-To: <1192174445.13539.96.camel@localhost.localdomain>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
	<1192174445.13539.96.camel@localhost.localdomain>
Message-ID: <20071012191457.GA6022@redhat.com>

On Fri, Oct 12, 2007 at 09:34:05AM +0200, Alexander Larsson wrote:

 > Is there any chance we can use Jens Axboes "fcache"?
 > Info e.g. at:
 > http://en.opensuse.org/Fcache-howto

That really needs to get into the upstream kernel before I'm comfortable
enabling it in Fedora.

 > I don't understand why nobody seems interested in this. It seems like a
 > much nicer solution than readahead of files. In the current version it
 > has to have a separate device for mirroring the blocks, but I can't
 > think its that hard to create a physically linear file on an ext3
 > filesystem

ext3's block allocation policy seems a little.. suboptimal in some cases.
It doesn't seem particularly difficult to end up with fragmented files,
especially with large ones.

 > , lock it in place and use that. (Isn't this basically what
 > extents are?)

ext3 doesn't have extents, and ext4 continues to drag its heals.

	Dave

-- 
http://www.codemonkey.org.uk



From notting at redhat.com  Fri Oct 12 19:28:16 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 12 Oct 2007 15:28:16 -0400
Subject: remove readahead from default package set (was Re: should
	readahead allow generic paths?)
In-Reply-To: <470E9D80.1040107@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
	<20071011214903.GA32504@nostromo.devel.redhat.com>
	<470E9D80.1040107@redhat.com>
Message-ID: <20071012192816.GA5757@nostromo.devel.redhat.com>

Eric Sandeen (sandeen at redhat.com) said: 
> It'd be nice to get a few more datapoints, but I have yet to hear anyone
> say that the default lists help them boot faster.

Given this and other comments, I'm removing readahead from the default
install set.

Bill



From david at lovesunix.net  Fri Oct 12 19:54:19 2007
From: david at lovesunix.net (David Nielsen)
Date: Fri, 12 Oct 2007 21:54:19 +0200
Subject: The gstreamer third way
In-Reply-To: <470F4BDB.2090009@warmcat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com>
Message-ID: <1192218859.3498.8.camel@dawkins>

fre, 12 10 2007 kl. 11:26 +0100, skrev Andy Green:
> Somebody in the thread at some point said:
> > Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> >> Le jeudi 11 octobre 2007 ? 19:12 +0000, Kevin Kofler a ?crit :
> >>> Yet third-party repositories are happily distributing proprietary 
> > kmod-nvidia 
> >>> modules linked against the GPLv2 kernel, which isn't any more legal than 
> >>> distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.
> >> Last I checked they're not distributing both kmod-nvidia and kernels in
> >> the same repo
> > 
> > They wouldn't be shipping Samba in the third-party repo either.
> 
> So I didn't get the objection to the original proposal.
> 
>  - Fedora just sticks with the perfectly valid last GPL2 version for
> now, links KDE3 stuff against it as usual and has nothing to do with the
> GPL3 version until there is a better situation
> 
>  - That is the end of the story for the typical case.  When KDE4 comes
> or there is some other better resolution that allows it, Fedora just
> starts using the GPL3 samba libs and goes on in a good clean way.
> 
>  - Additionally, completely externally, some other repo might offer a
> standalone GPL3 samba libs package that has the same soname that
> endusers might choose to use to replace Fedora's GPL2 library.  That's
> up to them and the user's problem that his combined system may not be
> redistributable if he goes down that path.
> 
> If I understood it, this does not violate any terms or intention of the
> terms and is nice and clean.

And when QT never moves to a GPLv3 compliant licensing scheme, Fedora
will be stuck with technology that is unsupported by upstream and
growing outdated and non-functional by the second, that or becomes a
fullblown fork and thus a major burden we carry on behalf of TrollTech.

Fedora needs to stay on a current samba, it is a major selling point and
a much requested feature, especially given Microsoft love for changing
the protocol and otherwise playing games. It's the only way we can stay
working and lessen the support burden for us and Samba upstream.

This is a QT bug, I suggest the QT people fix it, if need be then KDE
can be compiled without said support till a solution is found. Naturally
it's undesirable to withhold said functionality from these users but
TrollTech knew these was coming and it's a well understood problem which
can only be fixed in a satifactory manner by them.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/e60fbb13/attachment.sig>

From dominik at greysector.net  Fri Oct 12 18:41:17 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 12 Oct 2007 20:41:17 +0200
Subject: The gstreamer third way
In-Reply-To: <1192218859.3498.8.camel@dawkins>
References: <1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com> <1192218859.3498.8.camel@dawkins>
Message-ID: <20071012184117.GC8027@ryvius.pekin.waw.pl>

On Friday, 12 October 2007 at 21:54, David Nielsen wrote:
[...]
> This is a QT bug, I suggest the QT people fix it, if need be then KDE
> can be compiled without said support till a solution is found. Naturally
> it's undesirable to withhold said functionality from these users but
> TrollTech knew these was coming and it's a well understood problem which
> can only be fixed in a satifactory manner by them.

This problem wouldn't have arised if samba just stayed with GPLv2.
I cannot imagine how you can call this a QT bug.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From lamont at gurulabs.com  Fri Oct 12 20:36:14 2007
From: lamont at gurulabs.com (Lamont Peterson)
Date: Fri, 12 Oct 2007 14:36:14 -0600
Subject: rpmbuild -bp and BR:
Message-ID: <20071012143614.10531202@reaver.lamontpeterson.net>

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

Just wondering why running "rpmbuild -bp" fails if I don't have all the BR:'s
installed.  I don't really need them in this case, as I'm not going to be
running ./configure or the compile.

I'm using rpmbuild -bp in order to get a source tree that's patched the way the
package was built so I can explore some of the source to try and track down
some things.  Later, if I'm ready to build it (you know, test a patch or
whatever), then I'll install the BR:'s, but until then, I'd prefer not to,
sometimes.
- -- 
Lamont Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHD9q++YBsl9wN1AkRAm21AKDApQj+VKukVrDThzlipSymNFY21wCfRzgY
FoKVGEJFG+sfhzhqBl+EBZI=
=3YRw
-----END PGP SIGNATURE-----



From emmanuel.seyman at club-internet.fr  Fri Oct 12 20:35:42 2007
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 12 Oct 2007 22:35:42 +0200
Subject: The gstreamer third way
In-Reply-To: <20071012184117.GC8027@ryvius.pekin.waw.pl>
References: <470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com> <1192218859.3498.8.camel@dawkins>
	<20071012184117.GC8027@ryvius.pekin.waw.pl>
Message-ID: <20071012203542.GA3308@orient.maison.lan>

* Dominik 'Rathann' Mierzejewski [12/10/2007 22:27] :
>
> This problem wouldn't have arised if samba just stayed with GPLv2.

Minor nitpick, samba 3.0 is released under GPLv2+, not GPLv2.

> I cannot imagine how you can call this a QT bug.

Well, it's actually a KDE bug (since KDE depends on both QT and samba,
which are distributed under incompatible licences).
So the correct workabout, IMHO, is to disable one or the other in KDE.
Since you can't disable QT, that leaves Samba.

Emmanuel



From lamont at gurulabs.com  Fri Oct 12 20:42:35 2007
From: lamont at gurulabs.com (Lamont Peterson)
Date: Fri, 12 Oct 2007 14:42:35 -0600
Subject: rpmbuild -bp and BR:
In-Reply-To: <20071012143614.10531202@reaver.lamontpeterson.net>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
Message-ID: <20071012144235.71b7409f@reaver.lamontpeterson.net>

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

On Fri, 12 Oct 2007 14:36:14 -0600
Lamont Peterson <lamont at gurulabs.com> wrote:
> Just wondering why running "rpmbuild -bp" fails if I don't have all the BR:'s
> installed.  I don't really need them in this case, as I'm not going to be
> running ./configure or the compile.
> 
> I'm using rpmbuild -bp in order to get a source tree that's patched the way
> the package was built so I can explore some of the source to try and track
> down some things.  Later, if I'm ready to build it (you know, test a patch or
> whatever), then I'll install the BR:'s, but until then, I'd prefer not to,
> sometimes.

OK.  I wrote that before actually installing the packages and then went on and
discovered that "autoreconf" was being run at the end of %prep.  Shouldn't
something like that be in the beginning of %build instead?

For the curious, I'm working in the pam package.
- -- 
Lamont Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHD9w7+YBsl9wN1AkRApphAJ9udfuetEhbZStWBhsKzicHvljUiACfeB4y
4T/RG518GS7qH/YUkiLRtWs=
=pgVW
-----END PGP SIGNATURE-----



From matt at truch.net  Fri Oct 12 20:57:27 2007
From: matt at truch.net (Matthew D Truch)
Date: Fri, 12 Oct 2007 16:57:27 -0400
Subject: shared libraries and selinux
Message-ID: <20071012205727.GB2831@truch.net>

Greetings,

I'm the kst maintainer (a KDE scientific plotting program) and I'm
locally building version 1.5.0 (just released) for testing before I
place things in Fedora proper.  

I can easily build rpms and install them, but I get the following error:
kst: error while loading shared libraries: /usr/lib/libkstextdate.so.1:
cannot restore segment prot after reloc: Permission denied

The following chcon commands in %post fix the problem, but I don't
really know much about selinux, if this is the correct course of action,
or am I misunderstanding things.  
chcon -t texrel_shlib_t %{_libdir}/libkst*so.1*
chcon -t texrel_shlib_t %{_libdir}/kde3/kst*so
chcon -t texrel_shlib_t %{_libdir}/kde3/kstplugins/*so

Thanks in advance for any help.  

-- 
"Two Hundred -- And Forty Dollars -- Worth of Pudding -- Aww Yeah!"
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.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/20071012/6bd1b310/attachment.sig>

From jos at xos.nl  Fri Oct 12 20:59:44 2007
From: jos at xos.nl (Jos Vos)
Date: Fri, 12 Oct 2007 22:59:44 +0200
Subject: rpmbuild -bp and BR:
In-Reply-To: <20071012143614.10531202@reaver.lamontpeterson.net>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
Message-ID: <20071012205944.GA29758@jasmine.xos.nl>

On Fri, Oct 12, 2007 at 02:36:14PM -0600, Lamont Peterson wrote:

> Just wondering why running "rpmbuild -bp" fails if I don't have all the BR:'s
> installed.  I don't really need them in this case, as I'm not going to be
> running ./configure or the compile.

Use --nodeps if you want to do -bp and don't want to be bothered by
the BR's.  IMHO, it is ok that all (but one (*)) rpmbuild commands
check for the BR's, as you can override this during development (even
by commenting out the BR's).

(*)  Even rpmbuild -bs (only built src.rpm) fails whne the BR's are
     not satisfied (or has this been fixed now?).  This is useless.

-- 
--    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 jakub at redhat.com  Fri Oct 12 21:04:44 2007
From: jakub at redhat.com (Jakub Jelinek)
Date: Fri, 12 Oct 2007 17:04:44 -0400
Subject: shared libraries and selinux
In-Reply-To: <20071012205727.GB2831@truch.net>
References: <20071012205727.GB2831@truch.net>
Message-ID: <20071012210444.GA5451@devserv.devel.redhat.com>

On Fri, Oct 12, 2007 at 04:57:27PM -0400, Matthew D Truch wrote:
> I'm the kst maintainer (a KDE scientific plotting program) and I'm
> locally building version 1.5.0 (just released) for testing before I
> place things in Fedora proper.  
> 
> I can easily build rpms and install them, but I get the following error:
> kst: error while loading shared libraries: /usr/lib/libkstextdate.so.1:
> cannot restore segment prot after reloc: Permission denied
> 
> The following chcon commands in %post fix the problem, but I don't
> really know much about selinux, if this is the correct course of action,
> or am I misunderstanding things.  
> chcon -t texrel_shlib_t %{_libdir}/libkst*so.1*
> chcon -t texrel_shlib_t %{_libdir}/kde3/kst*so
> chcon -t texrel_shlib_t %{_libdir}/kde3/kstplugins/*so

Instead of these hacks please try to fix the Makefiles, so that the library
doesn't have text relocations.
You can e.g. start with
eu-findtextrel /usr/lib/libkstextdate.so.1

	Jakub



From habig at neutrino.d.umn.edu  Fri Oct 12 21:12:51 2007
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Fri, 12 Oct 2007 16:12:51 -0500
Subject: yum-updatesd in F8?
In-Reply-To: <200710100132.35256.ville.skytta@iki.fi>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710092346.24965.ville.skytta@iki.fi>
	<20071009211851.GD24144@neutrino.d.umn.edu>
	<200710100132.35256.ville.skytta@iki.fi>
Message-ID: <20071012211251.GA20074@neutrino.d.umn.edu>

Ville Skytt? writes:
> Alec T. Habig wrote:
> > Ville Skytt? writes:
> > > Can yum-cron do download+notify only?  That's the mode I'd prefer for
> > > most setups.
> >
> > Yes.  In /etc/sysconfig/yum-cron, set
> >
> >   CHECK_ONLY=yes
> 
> That seems to result in it running "yum check-update" which AFAIK does
> not actually download the _packages_.

Oops.  And yum seems to have lost it's "--download-only" option, which
is what we could use here.

We could bring in yum-utils to use yumdownloader to drop them into the
spool directory, but that's starting to get complicated and fragile.
Hmm.

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/
-------------- 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/20071012/c46ec378/attachment.sig>

From matt at truch.net  Fri Oct 12 21:29:43 2007
From: matt at truch.net (Matthew D Truch)
Date: Fri, 12 Oct 2007 17:29:43 -0400
Subject: shared libraries and selinux
In-Reply-To: <20071012210444.GA5451@devserv.devel.redhat.com>
References: <20071012205727.GB2831@truch.net>
	<20071012210444.GA5451@devserv.devel.redhat.com>
Message-ID: <20071012212943.GC2831@truch.net>

> > I'm the kst maintainer (a KDE scientific plotting program) and I'm
> > locally building version 1.5.0 (just released) for testing before I
> > place things in Fedora proper.  
> > 
> > I can easily build rpms and install them, but I get the following error:
> > kst: error while loading shared libraries: /usr/lib/libkstextdate.so.1:
> > cannot restore segment prot after reloc: Permission denied
> > 
> > The following chcon commands in %post fix the problem, but I don't
> > really know much about selinux, if this is the correct course of action,
> > or am I misunderstanding things.  
> > chcon -t texrel_shlib_t %{_libdir}/libkst*so.1*
> > chcon -t texrel_shlib_t %{_libdir}/kde3/kst*so
> > chcon -t texrel_shlib_t %{_libdir}/kde3/kstplugins/*so
> 
> Instead of these hacks please try to fix the Makefiles, so that the library
> doesn't have text relocations.
> You can e.g. start with
> eu-findtextrel /usr/lib/libkstextdate.so.1

That's why I emailed this list, I didn't want the hacks.  But I have no
idea what this eu-findtextrel is or does.  Attached is the output, but
none of it mentions anything about text relocations (that I can figure
out).  

-- 
"I think better with a glass of beer in front of me; two heads are better than one!"
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.net/
-------------- next part --------------
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetime.cpp not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qvaluelist.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextcalendarsystem.cpp not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextcalendarsystemgregorian.cpp not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetbl.moc not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qcstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qobject.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetbl.cpp not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatepicker.moc not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatepicker.cpp not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qcstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qobject.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetimeedit.moc not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qcstring.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetimeedit.cpp not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qobject.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qvaluelist.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatewidget.moc not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qcstring.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatewidget.cpp not compiled with -fpic/-fPIC
either the file containing the function '_fini' or the file containing the function '_ZN3KST7ExtDate15m_shortDayNamesE' is not compiled with -fpic/-fPIC
the file containing the function '_ZN3KST7ExtDate17m_shortMonthNamesE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZN3KST7ExtDate17m_shortMonthNamesE' or the file containing the function '_ZN3KST7ExtDate16m_longMonthNamesE' is not compiled with -fpic/-fPIC
the file containing the function '_ZN3KST7ExtDate15m_shortDayNamesE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZN3KST7ExtDate15m_shortDayNamesE' or the file containing the function '_ZN3KST7ExtDate14m_longDayNamesE' is not compiled with -fpic/-fPIC
the file containing the function '_ZN3KST7ExtDate16m_longMonthNamesE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZN3KST7ExtDate16m_longMonthNamesE' or the file containing the function '_ZTV6QGList' is not compiled with -fpic/-fPIC
the file containing the function '_ZN3KST7ExtDate14m_longDayNamesE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTI6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetime.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetime.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qdatastream.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qevent.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qstring.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qdict.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetbl.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatetimeedit.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qptrlist.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/private/qrichtext_p.h not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST11KPopupFrameE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST26ExtDateInternalMonthPickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST15ExtDateTimeEditE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST11ExtDateEditE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST19ExtDateTimeEditBaseE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST21ExtDateTimeSpinWidgetE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST13ExtDateWidgetE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/private/qucom_p.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/private/qucom_p.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/private/qucom_p.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/private/qucom_p.h not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qwidget.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qapplication.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qapplication.h not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST12ExtDateTableE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST27ExtDateInternalYearSelectorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST27ExtDateInternalWeekSelectorE' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qwidget.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qpainter.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qcolor.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qwidget.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qfont.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qvalidator.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qframe.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qframe.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatepicker.h not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST16ExtDateValidatorE' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qobjectdefs.h not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qgarray.h not compiled with -fpic/-fPIC
the file containing the function '_ZTV6QGList' is not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qrangecontrol.h not compiled with -fpic/-fPIC
/home/matt/rpms/BUILD/kst-1.5.0/kst/src/extdate/kstextdatewidget.h not compiled with -fpic/-fPIC
/usr/lib/qt-3.3/include/qspinbox.h not compiled with -fpic/-fPIC
the file containing the function '_ZTI8QPtrListI12QTextCommandE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTV8QPtrListI12QTextCommandE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS6QGList' or the file containing the function '_ZTVN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST26ExtCalendarSystemGregorianE' or the file containing the function '_ZTVN3KST12ExtDateTableE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST12ExtDateTableE' or the file containing the function '_ZTSN3KST16ExtDateValidatorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST16ExtDateValidatorE' or the file containing the function '_ZTSN3KST11KPopupFrameE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST11KPopupFrameE' or the file containing the function '_ZTSN3KST27ExtDateInternalYearSelectorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST27ExtDateInternalYearSelectorE' or the file containing the function '_ZTSN3KST26ExtDateInternalMonthPickerE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST26ExtDateInternalMonthPickerE' or the file containing the function '_ZTSN3KST27ExtDateInternalWeekSelectorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST17ExtDateTimeEditorE' or the file containing the function '_ZTSN3KST15ExtDateTimeEditE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST15ExtDateTimeEditE' or the file containing the function '_ZTSN3KST11ExtDateEditE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST11ExtDateEditE' or the file containing the function '_ZTSN3KST19ExtDateTimeEditBaseE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST19ExtDateTimeEditBaseE' or the file containing the function '_ZTV8QPtrListI12QTextCommandE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTV8QPtrListI12QTextCommandE' or the file containing the function '_ZTS8QPtrListI12QTextCommandE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTVN3KST21ExtDateTimeSpinWidgetE' or the file containing the function '_ZTSN3KST21ExtDateTimeSpinWidgetE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST13ExtDateWidgetE' or the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTVN3KST20ExtDateWidgetSpinBoxE' or the file containing the function '_ZTSN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTI6QGList' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTSN3KST17ExtCalendarSystemE' or the file containing the function '_ZTVN3KST26ExtCalendarSystemGregorianE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS19QTextCommandHistory' or the file containing the function '_ZTSN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST17ExtCalendarSystemE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST12ExtDateTableE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST26ExtDateInternalMonthPickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST16ExtDateValidatorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST11KPopupFrameE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST27ExtDateInternalYearSelectorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST27ExtDateInternalWeekSelectorE' or the file containing the function '_ZTV5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTS5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' or the file containing the function '_ZTVN3KST13ExtDatePickerE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTI5QDictIN3KST12ExtDateTable19ExtDateTablePrivate16DatePaintingModeEE' is not compiled with -fpic/-fPIC
either the file containing the function '_ZTIN3KST13ExtDatePickerE' or the file containing the function '_ZTVN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST11ExtDateEditE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTV19QTextCommandHistory' is not compiled with -fpic/-fPIC
the file containing the function '_ZTI19QTextCommandHistory' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST17ExtDateTimeEditorE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST15ExtDateTimeEditE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST19ExtDateTimeEditBaseE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST13ExtDateWidgetE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST21ExtDateTimeSpinWidgetE' is not compiled with -fpic/-fPIC
the file containing the function '_ZTIN3KST20ExtDateWidgetSpinBoxE' is not compiled with -fpic/-fPIC
-------------- 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/20071012/f5c78422/attachment.sig>

From jkeating at redhat.com  Fri Oct 12 21:49:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 12 Oct 2007 17:49:31 -0400
Subject: Co-maintaining mono packages
In-Reply-To: <1191578779.4199.11.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
Message-ID: <20071012174931.6a4a7371@redhat.com>

On Fri, 05 Oct 2007 11:06:19 +0100
Paul <paul at all-the-johnsons.co.uk> wrote:

> Currently, mono in rawhide is dropping behind the actual releases

That could be because we're past the Feature Freeze and we're not
supposed to be doing builds which introduce features, just fix bugs.

Given that your build attempt failed, perhaps you should wait on this
upgrade until after Fedora 8 is released and it can get some proper
time in updates-testing, or better yet target Fedora 9 for the new
version and work out the issues there?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071012/ec92d2da/attachment.sig>

From abartlet at samba.org  Fri Oct 12 21:54:21 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Sat, 13 Oct 2007 07:54:21 +1000
Subject: The gstreamer third way
In-Reply-To: <470F4BDB.2090009@warmcat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com>
Message-ID: <1192226061.4423.3.camel@naomi>


On Fri, 2007-10-12 at 11:26 +0100, Andy Green wrote:

>  - Additionally, completely externally, some other repo might offer a
> standalone GPL3 samba libs package that has the same soname that
> endusers might choose to use to replace Fedora's GPL2 library.  That's
> up to them and the user's problem that his combined system may not be
> redistributable if he goes down that path.
> 
> If I understood it, this does not violate any terms or intention of the
> terms and is nice and clean.

Why are we, as a Free Software community, spending time looking for new
and interesting ways to violate Samba's licence, in fact or in spirit?

Just because people have created a history of non-compliance with the
kernel's licence for convenience does not make me any more comfortable
with this thread's direction.  

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071013/95062db4/attachment.sig>

From mike at miketc.com  Fri Oct 12 22:12:08 2007
From: mike at miketc.com (Mike Chambers)
Date: Fri, 12 Oct 2007 17:12:08 -0500
Subject: Echo icons missing
Message-ID: <1192227128.2260.1.camel@scrappy.miketc.com>

I noticed over the last couple days, a couple of icons from echo-theme
have resorted back to the gnome icons?  The file manager and xchat icons
changed it seems to the big two drawer cabinet and the big X.

Any ideas?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From david at lovesunix.net  Fri Oct 12 22:19:09 2007
From: david at lovesunix.net (David Nielsen)
Date: Sat, 13 Oct 2007 00:19:09 +0200
Subject: The gstreamer third way
In-Reply-To: <20071012184117.GC8027@ryvius.pekin.waw.pl>
References: <1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com> <1192218859.3498.8.camel@dawkins>
	<20071012184117.GC8027@ryvius.pekin.waw.pl>
Message-ID: <1192227549.3498.22.camel@dawkins>


fre, 12 10 2007 kl. 20:41 +0200, skrev Dominik 'Rathann' Mierzejewski:
> On Friday, 12 October 2007 at 21:54, David Nielsen wrote:
> [...]
> > This is a QT bug, I suggest the QT people fix it, if need be then KDE
> > can be compiled without said support till a solution is found. Naturally
> > it's undesirable to withhold said functionality from these users but
> > TrollTech knew these was coming and it's a well understood problem which
> > can only be fixed in a satifactory manner by them.
> 
> This problem wouldn't have arised if samba just stayed with GPLv2.
> I cannot imagine how you can call this a QT bug.

Samba has (to the best of my knowledge) always been GPLv2+, they
preannounced the intention to go to GPLv3+. TrollTech has had plenty of
time to at least make an announcement on the issue to say they were
working on it. 

It's a TrollTech problem, I have no idea how they should solve it, I
just don't see why Fedora should do it for them by shipping an older
version of Samba which we can only be assured is supported for serious
bugs and security fixes for another year. Especially since the worst
case would be that they decide to never become compliant or work around
the issue, since that means we basically fork Samba - something I'm sure
everyone can agree is undesirable. I'm also sure that our users missing
out on the latest Samba work for the coming releases while TrollTech
works on the licensing issue is also undesirable. And naturally it's
undesirable to see KDE users without such support, which goes without
saying - this is a matter of selecting the lesser evil which will go
away the quickest.

It's a hard problem but I think the ball is in TrollTechs court, at
least for a comment on whither or not they are going to solve this
issue. If they are working on it and a solution can be expected in the
near future then I'd agree with holding back on the Samba version is
acceptable but I'm terrified of doing so if we don't even have a promise
that the problem will go away.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071013/c1edc1b5/attachment.sig>

From mzerqung at 0pointer.de  Fri Oct 12 22:29:45 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 13 Oct 2007 00:29:45 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<1191964048.7000.16.camel@localhost.localdomain>
	<c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>
Message-ID: <20071012222945.GE4130@tango.0pointer.de>

On Wed, 10.10.07 06:18, Hikaru Amano (kagesenshi.87 at gmail.com) wrote:

> [kagesenshi at Hikari ~]$ while true;do pulseaudio ;echo "DIED";done
> Soft CPU time limit exhausted, terminating.
> E: module-volume-restore.c: failed to open file '(null)': No such file
> or directory
> DIED
> 

If the daemon is stopped due to a time limit exhaustion you either
managed to trigger some kind of endless loop in PA. Or your CPU is
very, very slow.

Could you please run pa with the "-vv" arugment?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From lkundrak at redhat.com  Fri Oct 12 22:54:05 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sat, 13 Oct 2007 00:54:05 +0200
Subject: Pulseaudio not restarting after crash
In-Reply-To: <20071012222945.GE4130@tango.0pointer.de>
References: <c44298520710090237p2f23c39dya513ebb8b9a3b00b@mail.gmail.com>
	<1191964048.7000.16.camel@localhost.localdomain>
	<c44298520710091518n2382b6cage07ef2cbe5b9b5f@mail.gmail.com>
	<20071012222945.GE4130@tango.0pointer.de>
Message-ID: <1192229645.30148.6.camel@localhost.localdomain>


On Sat, 2007-10-13 at 00:29 +0200, Lennart Poettering wrote:
> On Wed, 10.10.07 06:18, Hikaru Amano (kagesenshi.87 at gmail.com) wrote:
> 
> > [kagesenshi at Hikari ~]$ while true;do pulseaudio ;echo "DIED";done
> > Soft CPU time limit exhausted, terminating.
> > E: module-volume-restore.c: failed to open file '(null)': No such file
> > or directory
> > DIED
> > 
> 
> If the daemon is stopped due to a time limit exhaustion you either
> managed to trigger some kind of endless loop in PA. Or your CPU is
> very, very slow.

Not quite. In my case, I was often experiencing this, but for some
unknown reason I can not reproduce it anymore. Nevertheless, I compiled
pa with -pg -DPRINT_CPU_LOAD to inspect what really happens. While
profiling revealed no useful information (probably it's not pa who's
guilty for the consumption but some of the libs?), PRINT_CPU_LOAD
reveals some interesting information: While I am playing music from
rhythmbox and feed it into pa via ESound emulation, the average CPU
consumption is around 5%. Quite much, as my machine is 2x2200 MHz
(though might be a bit slower due to cpuspeed, maybe 2x800 MHz). When
using native pulseaudio sink, cpu consumption is around 10%.

It is worth noting that CPU load arises suddenly when changing tracks --
I can probably even force PA death by high CPU consumption then.

Until I do some investigate what really consumes the time (BTW how do I
tell oprofile to use debugging symbols from another file as the
executable) -- Does anyone else observe this behavior?

> Could you please run pa with the "-vv" arugment?
> 
> Lennart

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From myfedora at richip.dhs.org  Fri Oct 12 23:05:30 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 12 Oct 2007 17:05:30 -0600
Subject: gethostby* users
In-Reply-To: <470F15B2.2020809@redhat.com>
References: <470F15B2.2020809@redhat.com>
Message-ID: <1192230330.22759.8.camel@localhost6.localdomain6>

Hi, Ulrich.

On Thu, 2007-10-11 at 23:35 -0700, Ulrich Drepper wrote:
> Even though the situation improved, there are still some programs left
> which use the gethostby* functions.  These really have to be converted
> to use getaddrinfo.  Here is the break-down per package of an incomplete
> installation giving the number of programs/libraries with problems in
> that package.  I.e., there are like more packages on an install-all
> machine.  The full list with the program/library names is at

Were you addressing your message to the maintainers of the software you
mentioned or to fedora developers and package maintainers?

For now, I'll assume you were addressing fedora developers in general so
I'll give my Can$0.02.

Would it make sense to address these individual packages and convert all
gethostby*(3) function calls to getaddrinfo(3)? It seems like an easy
enough task for anyone with a basic knowledge of C to work on (I tried
looking at talk-0.17-29.2.3.src.rpm as an example and it looks pretty
straightforward).

One approach I can think of is to go ahead and make these patches, apply
them to Fedora packages and submit them upstream to their corresponding
maintainers. If it gets applied upstream, the package maintainers can
rebase and drop the patch. If upstream says "no", then the patches can
be dropped and the software reverted.

I'm just worrying about the different platforms these software are
expected to run on. According to gethostbyname(3), the function conforms
to POSIX as well as 4.3BSD so certain platforms might not have support
for getaddrinfo(). What's the proper way of addressing these?
Preprocessor directives?
--

Richi Plana



From andy at warmcat.com  Fri Oct 12 23:28:05 2007
From: andy at warmcat.com (Andy Green)
Date: Sat, 13 Oct 2007 00:28:05 +0100
Subject: The gstreamer third way
In-Reply-To: <1192226061.4423.3.camel@naomi>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C82D2.2010107@warmcat.com>
	<470C9681.9050905@nicubunu.ro>	<loom.20071011T191138-597@post.gmane.org>	<1192133361.7723.7.camel@rousalka.dyndns.org>	<loom.20071011T201209-819@post.gmane.org>	<470F4BDB.2090009@warmcat.com>
	<1192226061.4423.3.camel@naomi>
Message-ID: <47100305.4020705@warmcat.com>

Somebody in the thread at some point said:
> On Fri, 2007-10-12 at 11:26 +0100, Andy Green wrote:
> 
>>  - Additionally, completely externally, some other repo might offer a
>> standalone GPL3 samba libs package that has the same soname that
>> endusers might choose to use to replace Fedora's GPL2 library.  That's
>> up to them and the user's problem that his combined system may not be
>> redistributable if he goes down that path.
>>
>> If I understood it, this does not violate any terms or intention of the
>> terms and is nice and clean.
> 
> Why are we, as a Free Software community, spending time looking for new
> and interesting ways to violate Samba's licence, in fact or in spirit?

Yow for the second time of being jumped on can I ask what bit of which
license is violated by Fedora just shipping the GPL2 version as it
always has -- end of Fedora's story?

To be clear I don't have any boxes any more that use CIFS/Samba, I won't
care if Samba is completely pulled, although I see other people do care.

-Andy



From ringwald at gmail.com  Sat Oct 13 00:02:21 2007
From: ringwald at gmail.com (Steven Ringwald)
Date: Fri, 12 Oct 2007 17:02:21 -0700
Subject: Retiring procinfo
In-Reply-To: <20071012131337.9e32df40.mschwendt.tmp0701.nospam@arcor.de>
References: <20071011111849.3e47b20e.tsmetana@redhat.com>	<!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAJt3ucjx5SxHsQE3yUJaB5UBAAAAAA==@gmail.com>	<3170f42f0710110525o13e312b7gfcfeff542904f465@mail.gmail.com>	<20071011161819.87949eae.tsmetana@redhat.com>	<3170f42f0710110735x48d74794s8d55fb3573e7bd13@mail.gmail.com>
	<20071012131337.9e32df40.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAJMdTmxU+ddJuMJseJsBQXXCgAAAEAAAAHs5LQfMBmBGiei/2XcOvw4BAAAAAA==@gmail.com>

> On Thu, 11 Oct 2007 20:05:03 +0530, Debarshi 'Rishi' Ray wrote:
> 
> > >  But it's 6 years dead piece of software and by today
> > > I haven't heard of anybody using it.
> >
> > You already got a user now -- Steven R. Ringwald. :-)
> 
> I've been suggesting "socklist" from the procinfo package to newbies
> regularly as an alternative to "netstat" with several args.


That works fine for the status of sockets, but does it keep track of
interrupts or system load/etc. I have been meaning to write my own
application, and this may just be the kick-in-the-butt that I have been
needing.

Steve





From michael.wiktowy at gmail.com  Sat Oct 13 00:27:31 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Fri, 12 Oct 2007 20:27:31 -0400
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <20071012035538.GA16449@auslistsprd01.us.dell.com>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
	<1192150227.4210.7.camel@localhost.localdomain>
	<3e4ec4600710111818i35c72933u1f19b3b8ca574385@mail.gmail.com>
	<20071012035538.GA16449@auslistsprd01.us.dell.com>
Message-ID: <3e4ec4600710121727g91a16a7ne6c61192919c3f4f@mail.gmail.com>

On 10/11/07, Matt Domsch <Matt_Domsch at dell.com> wrote:
> There was a syslinux bug recently found and fixed; not sure if it made
> the F8 Test3 LiveCD or not though.

Updating the BIOS from A03 to A06 made things work properly.
I did check for the problem with rawhide-2007-09-25 LiveCD and it
existed then ... not certain about F8test3.

/Mike



From michael.wiktowy at gmail.com  Sat Oct 13 00:29:58 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Fri, 12 Oct 2007 20:29:58 -0400
Subject: Dell Precision Workstation LiveCD boot menu selection problem
In-Reply-To: <c44298520710112302x355a80f3u5dca98cf76e63027@mail.gmail.com>
References: <3e4ec4600710111716q68f1aa29i89146390d909a03e@mail.gmail.com>
	<c44298520710112302x355a80f3u5dca98cf76e63027@mail.gmail.com>
Message-ID: <3e4ec4600710121729l16cc9b84gdd21b9eb9c79b8e6@mail.gmail.com>

On 10/12/07, Hikaru Amano <kagesenshi.87 at gmail.com> wrote:
> are u sure its just not the mother board settings??
>
> try checking whether the "USB Support" are set to "built-in" and not "OS" ..
>
> I happened to experience GRUB not responding to usb devices before and
> its just the motherboard configuration thats not right ..

Since older LiveCDs worked fine, I didn't suspect the motherboard or
settings. It would appear that the newer syslinux agrivated something
with a buggy BIOS version though.

/Mike



From a.badger at gmail.com  Sat Oct 13 01:00:12 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 12 Oct 2007 18:00:12 -0700
Subject: The gstreamer third way
In-Reply-To: <1192227549.3498.22.camel@dawkins>
References: <1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C82D2.2010107@warmcat.com>
	<470C9681.9050905@nicubunu.ro>	<loom.20071011T191138-597@post.gmane.org>	<1192133361.7723.7.camel@rousalka.dyndns.org>	<loom.20071011T201209-819@post.gmane.org>	<470F4BDB.2090009@warmcat.com>
	<1192218859.3498.8.camel@dawkins>	<20071012184117.GC8027@ryvius.pekin.waw.pl>
	<1192227549.3498.22.camel@dawkins>
Message-ID: <4710189C.8060903@gmail.com>

David Nielsen wrote:
> fre, 12 10 2007 kl. 20:41 +0200, skrev Dominik 'Rathann' Mierzejewski:
>> On Friday, 12 October 2007 at 21:54, David Nielsen wrote:
>> [...]
>>> This is a QT bug, I suggest the QT people fix it, if need be then KDE
>>> can be compiled without said support till a solution is found. Naturally
>>> it's undesirable to withhold said functionality from these users but
>>> TrollTech knew these was coming and it's a well understood problem which
>>> can only be fixed in a satifactory manner by them.
>> This problem wouldn't have arised if samba just stayed with GPLv2.
>> I cannot imagine how you can call this a QT bug.
> 
> Samba has (to the best of my knowledge) always been GPLv2+, they
> preannounced the intention to go to GPLv3+. TrollTech has had plenty of
> time to at least make an announcement on the issue to say they were
> working on it. 
> 
> It's a TrollTech problem, I have no idea how they should solve it, I
> just don't see why Fedora should do it for them by shipping an older
> version of Samba which we can only be assured is supported for serious
> bugs and security fixes for another year. Especially since the worst
> case would be that they decide to never become compliant or work around
> the issue, since that means we basically fork Samba - something I'm sure
> everyone can agree is undesirable. I'm also sure that our users missing
> out on the latest Samba work for the coming releases while TrollTech
> works on the licensing issue is also undesirable. And naturally it's
> undesirable to see KDE users without such support, which goes without
> saying - this is a matter of selecting the lesser evil which will go
> away the quickest.
> 
> It's a hard problem but I think the ball is in TrollTechs court, at
> least for a comment on whither or not they are going to solve this
> issue. If they are working on it and a solution can be expected in the
> near future then I'd agree with holding back on the Samba version is
> acceptable but I'm terrified of doing so if we don't even have a promise
> that the problem will go away.
> 
I'd much prefer to leave this in the KDE maintainers' courts.  The Samba 
maintainer has made clear his intention to move to a GPLv3 library in 
F9.  The KDE maintainers can decide how best to handle the situation 
from there.

Their options are:
1) Fork samba.  This is what happens with any package which no longer 
has an upstream but has people within Fedora who care about it 
sufficiently to deal with it.

2) Convince upstream KDE to fork samba.  It would be best if they take 
the time to make the library not conflict with the distro version of 
samba (probably by renaming.  libsamba-gpl2 was proposed earlier and 
would work.) but even if they don't we've worked around bad packaging in 
upstream tarballs before.

3) Remove samba support until the license situation allows linking to 
libsmbclient again.

4) Port kio-smb to gnome-vfs2 :-)

We can all see drawbacks with each of these options but it's really up 
to those who are going to do the kde packaging work to decide which of 
the choices is "right".

-Toshio



From skvidal at fedoraproject.org  Sat Oct 13 01:26:32 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 12 Oct 2007 21:26:32 -0400
Subject: yum-updatesd in F8?
In-Reply-To: <20071012211251.GA20074@neutrino.d.umn.edu>
References: <loom.20071009T110055-482@post.gmane.org>
	<200710092346.24965.ville.skytta@iki.fi>
	<20071009211851.GD24144@neutrino.d.umn.edu>
	<200710100132.35256.ville.skytta@iki.fi>
	<20071012211251.GA20074@neutrino.d.umn.edu>
Message-ID: <1192238792.19308.117.camel@cutter>


On Fri, 2007-10-12 at 16:12 -0500, Alec T. Habig wrote:
> Ville Skytt? writes:
> > Alec T. Habig wrote:
> > > Ville Skytt? writes:
> > > > Can yum-cron do download+notify only?  That's the mode I'd prefer for
> > > > most setups.
> > >
> > > Yes.  In /etc/sysconfig/yum-cron, set
> > >
> > >   CHECK_ONLY=yes
> > 
> > That seems to result in it running "yum check-update" which AFAIK does
> > not actually download the _packages_.
> 
> Oops.  And yum seems to have lost it's "--download-only" option, which
> is what we could use here.
> 
> We could bring in yum-utils to use yumdownloader to drop them into the
> spool directory, but that's starting to get complicated and fragile.
> Hmm.
> 

download-only hasn't been in yum except for an accidental inclusion in
the 2.2.X series. You mean "install the download-only plugin" which is
in yum-utils now and works just fine.

-sv




From kevin.kofler at chello.at  Sat Oct 13 04:01:21 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 13 Oct 2007 04:01:21 +0000 (UTC)
Subject: shared libraries and selinux
References: <20071012205727.GB2831@truch.net>
	<20071012210444.GA5451@devserv.devel.redhat.com>
	<20071012212943.GC2831@truch.net>
Message-ID: <loom.20071013T035945-799@post.gmane.org>

Matthew D Truch <matt <at> truch.net> writes:
> That's why I emailed this list, I didn't want the hacks.  But I have no
> idea what this eu-findtextrel is or does.  Attached is the output, but
> none of it mentions anything about text relocations (that I can figure
> out).  

Shared libraries are supposed to be compiled with -fpic or -fPIC. If you don't 
do that, you end up with those text relocations. You need to add the missing 
PIC (Position Independent Code) flag to the makefile for the shared libraries.

        Kevin Kofler




From drepper at redhat.com  Sat Oct 13 04:59:34 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 12 Oct 2007 21:59:34 -0700
Subject: gethostby* users
In-Reply-To: <1192230330.22759.8.camel@localhost6.localdomain6>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
Message-ID: <471050B6.5000605@redhat.com>

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

Richi Plana wrote:
> Would it make sense to address these individual packages and convert all
> gethostby*(3) function calls to getaddrinfo(3)?

That's the idea.


> One approach I can think of is to go ahead and make these patches, apply
> them to Fedora packages and submit them upstream to their corresponding
> maintainers. If it gets applied upstream, the package maintainers can
> rebase and drop the patch. If upstream says "no", then the patches can
> be dropped and the software reverted.

There is no reason to drop them.  Using the gethostby* functions is
simply wrong.  Just like any other bug fix the patch should be carried
until upstream takes it in one form or another.


> I'm just worrying about the different platforms these software are
> expected to run on. According to gethostbyname(3), the function conforms
> to POSIX as well as 4.3BSD so certain platforms might not have support
> for getaddrinfo(). What's the proper way of addressing these?
> Preprocessor directives?

autoconf

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEFC22ijCOnn/RHQRAmhfAJ0ePG3sA7SC/OIFN2UYn2Y025n2WwCgpOgY
xgS/O6RhWDhi4hlXUVMCszI=
=HcQd
-----END PGP SIGNATURE-----



From kevin.kofler at chello.at  Sat Oct 13 05:20:48 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 13 Oct 2007 05:20:48 +0000 (UTC)
Subject: gethostby* users
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
Message-ID: <loom.20071013T051855-88@post.gmane.org>

Richi Plana <myfedora <at> richip.dhs.org> writes:
> I'm just worrying about the different platforms these software are
> expected to run on. According to gethostbyname(3), the function conforms
> to POSIX as well as 4.3BSD so certain platforms might not have support
> for getaddrinfo(). What's the proper way of addressing these?
> Preprocessor directives?

Ideally they'd just drop support for the obsolete systems which don't have 
getaddrinfo. Even winsock implements it since XP. And of course all current 
POSIX-compliant systems have it as it's part of POSIX.1-2001.

        Kevin Kofler



From myfedora at richip.dhs.org  Sat Oct 13 05:51:48 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 12 Oct 2007 23:51:48 -0600
Subject: gethostby* users
In-Reply-To: <471050B6.5000605@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<471050B6.5000605@redhat.com>
Message-ID: <1192254708.24739.2.camel@localhost6.localdomain6>

On Fri, 2007-10-12 at 21:59 -0700, Ulrich Drepper wrote:

> There is no reason to drop them.  Using the gethostby* functions is
> simply wrong.  Just like any other bug fix the patch should be carried
> until upstream takes it in one form or another.

Well, you know that mantra: upstream, upstream, upstream.

> > I'm just worrying about the different platforms these software are
> > expected to run on. According to gethostbyname(3), the function conforms
> > to POSIX as well as 4.3BSD so certain platforms might not have support
> > for getaddrinfo(). What's the proper way of addressing these?
> > Preprocessor directives?
> 
> autoconf

Sorry. Been meaning to get around to reading autoconf. Could someone
give a summary?
--

Richi Plana



From cmadams at hiwaay.net  Sat Oct 13 05:58:25 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 13 Oct 2007 00:58:25 -0500
Subject: gethostby* users
In-Reply-To: <loom.20071013T051855-88@post.gmane.org>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
Message-ID: <20071013055825.GA1192122@hiwaay.net>

Once upon a time, Kevin Kofler <kevin.kofler at chello.at> said:
> Ideally they'd just drop support for the obsolete systems which don't have 
> getaddrinfo. Even winsock implements it since XP. And of course all current 
> POSIX-compliant systems have it as it's part of POSIX.1-2001.

Some of us have to work with software and systems in the real world.

I've seen the page http://udrepper.livejournal.com/16116.html mentioned
a couple of times in this thread.  First, that's a relatively contrived
situation (depending on the client resolver to choose an address
"properly" is poor network design).  Second, I can't find anything that
says getaddrinfo() returns a sorted list.  I checked SUSv3 as well as
man pages from Linux, Solaris 9, and Tru64 5.1B.

The cited RFC 3484 appears to be about address selection in an IPv6
network, while the above page talks about an IPv4 network.

I don't see gethostby* listed as deprecated or obsolete by any standard
group or documentation.

-- 
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 drepper at redhat.com  Sat Oct 13 06:10:24 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 12 Oct 2007 23:10:24 -0700
Subject: gethostby* users
In-Reply-To: <20071013055825.GA1192122@hiwaay.net>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net>
Message-ID: <47106150.1090303@redhat.com>

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

Chris Adams wrote:
> I don't see gethostby* listed as deprecated or obsolete by any standard
> group or documentation.

Then you haven't even tried looking.  The functions are obsolete in the
current Unix spec and will be gone in the next revision which we will
finish next year.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEGFQ2ijCOnn/RHQRAgUDAJ40Kdgj0NysfO5HsKB662NoVkcLAQCgoAg1
8L405fAQY/pBJhpgV83wxcw=
=fZZG
-----END PGP SIGNATURE-----



From ivazqueznet at gmail.com  Sat Oct 13 06:25:39 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 13 Oct 2007 02:25:39 -0400
Subject: rpmbuild -bp and BR:
In-Reply-To: <20071012144235.71b7409f@reaver.lamontpeterson.net>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
	<20071012144235.71b7409f@reaver.lamontpeterson.net>
Message-ID: <1192256739.3208.45.camel@ignacio.lan>

On Fri, 2007-10-12 at 14:42 -0600, Lamont Peterson wrote:
> OK.  I wrote that before actually installing the packages and then went on and
> discovered that "autoreconf" was being run at the end of %prep.  Shouldn't
> something like that be in the beginning of %build instead?

Yes. Log a bug please.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071013/30daed32/attachment.sig>

From luya_tfz at thefinalzone.com  Sat Oct 13 07:20:10 2007
From: luya_tfz at thefinalzone.com (Luya Tshimbalanga)
Date: Sat, 13 Oct 2007 03:20:10 -0400
Subject: Echo icons missing
In-Reply-To: <1192227128.2260.1.camel@scrappy.miketc.com>
References: <1192227128.2260.1.camel@scrappy.miketc.com>
Message-ID: <1192260010.471071aae3ead@ssl.mecca.ca>

Quoting Mike Chambers <mike at miketc.com>:

> I noticed over the last couple days, a couple of icons from echo-theme
> have resorted back to the gnome icons?  The file manager and xchat icons
> changed it seems to the big two drawer cabinet and the big X.
>
> Any ideas?

Strange. I have not seen that problem with File Manager. I can't tell with xchat
icon. Both icons were not "echofied" yet. Could you post a screenshot?

-- 
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga



From dwmw2 at infradead.org  Sat Oct 13 09:28:54 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 13 Oct 2007 10:28:54 +0100
Subject: gethostby* users
In-Reply-To: <20071012130230.GA1451534@hiwaay.net>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
Message-ID: <1192267734.13901.2.camel@pmac.infradead.org>

On Fri, 2007-10-12 at 08:02 -0500, Chris Adams wrote:
> I know it is fun to pick on sendmail, but it works well and I can use
> it to do things not easily done in some other MTAs.

Examples?

-- 
dwmw2



From gilboad at gmail.com  Sat Oct 13 10:49:09 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 13 Oct 2007 12:49:09 +0200
Subject: plague times out when trying to build icewm/EL-5, FC-6.
In-Reply-To: <470FC5DF.6090409@redhat.com>
References: <1192211573.27039.3.camel@gilboa-home-dev.localdomain>
	<470FC5DF.6090409@redhat.com>
Message-ID: <1192272549.27039.5.camel@gilboa-home-dev.localdomain>

On Fri, 2007-10-12 at 14:07 -0500, Mike McGrath wrote:
> Gilboa Davara wrote:
> > Hello all,
> >
> > I'm trying build a new icewm using plague and it times out on me.
> > Or actually, it EWOULDBLOCKs on me on read().
> >
> > Server down?
> >
> > $ strace /usr/bin/plague-client build icewm icewm-1_2_32-5_el5 el5 2>
> > ~/plague.log
> > Error connecting to build server: '(110, 'Operation timed out.')'
> >
> >   
> FWIW it looks like it succeeded?  - 
> http://buildsys.fedoraproject.org/build-status/job.psp?uid=36632  Could 
> be a slow connection.  I'll keep my ears out to see if others are having 
> any issues.
> 
>     -Mike
> 

Weird.... I'm sitting on a fairly fast 2.5/384KB cable connection...
Over-loaded plague build-machine?

- Gilboa



From nicolas.mailhot at laposte.net  Sat Oct 13 12:10:24 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 13 Oct 2007 14:10:24 +0200
Subject: The Fedora Fonts SIG is open
Message-ID: <1192277424.6996.79.camel@rousalka.dyndns.org>

Dear potential SIG contributor,

You're receiving this message because you're subscribed to one of the
general relevant Fedora mailing lists, or because our awesome
minion-finding powers have detected your interest in fonts and text
rendering/layouting in Fedora, EPEL or OLPC?. 

Last month's consultation showed there was enough possible contributors
and needed work to justify creating a Fedora Fonts Special Interest
Group.

To get the ball rolling I've started seeding a Fonts SIG space in the
Fedora wiki:
http://fedoraproject.org/wiki/SIGs/Fonts

Recently, the Fedora infrastructure team created us a mailing list to
coordinate SIG activities:
https://www.redhat.com/mailman/listinfo/fedora-fonts-list
In addition to human posts I intend to get it CCed on every font-related
bug in our bugzilla.

That means we have enough infrastructure to open shop, and I hereby
declare the Fonts SIG born.

If you are interested in the Fonts SIG, please:
? read the wiki, and the proposed Fonts SIG charter,
? subscribe to the mailing list,
? let us know there where you want the SIG to evolve
? and what *you* are ready to contribute to make this evolution happen

(in particular only respond to this message on fedora-fonts-list!)

I've created the SIG but we can make it live. It's not a tool to
implement my personal vision?. It's not some sort of public to-do list
either.

Stuff will happen because we make it happen. SIG organisation is only
there to help implement our wishes; I've sadly no access to magical
fairies ready to do the work in our stead.

I hope to find many of you on on the Fonts SIG list!

Regards,

? ie you already maintain or co-maintain a fonts-related package in
Fedora (fonts, major text layouting library, font tool?), or made the
mistake to ask about fonts on one of the Fedora lists I read

? Visions are for people standing too long under the sun, and there's
been a distinct lack of it here recently

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

From enrico.scholz at informatik.tu-chemnitz.de  Sat Oct 13 13:19:00 2007
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 13 Oct 2007 15:19:00 +0200
Subject: gethostby* users
In-Reply-To: <1192267734.13901.2.camel@pmac.infradead.org> (David Woodhouse's
	message of "Sat, 13 Oct 2007 10:28:54 +0100")
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
Message-ID: <87ve9bywxn.fsf@kosh.bigo.ensc.de>

David Woodhouse <dwmw2 at infradead.org> writes:

>> I know it is fun to pick on sendmail, but it works well and I can use
>> it to do things not easily done in some other MTAs.
>
> Examples?

creating RFC compliant bounces (e.g. not possible with exim due to
missing MIME support)


Enrico



From rc040203 at freenet.de  Sat Oct 13 14:21:03 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 13 Oct 2007 16:21:03 +0200
Subject: rpmbuild -bp and BR:
In-Reply-To: <1192256739.3208.45.camel@ignacio.lan>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
	<20071012144235.71b7409f@reaver.lamontpeterson.net>
	<1192256739.3208.45.camel@ignacio.lan>
Message-ID: <1192285263.3500.70.camel@mccallum.corsepiu.local>

On Sat, 2007-10-13 at 02:25 -0400, Ignacio Vazquez-Abrams wrote:
> On Fri, 2007-10-12 at 14:42 -0600, Lamont Peterson wrote:
> > OK.  I wrote that before actually installing the packages and then went on and
> > discovered that "autoreconf" was being run at the end of %prep.  Shouldn't
> > something like that be in the beginning of %build instead?
> 
> Yes. Log a bug please.
No. autoreconf belongs into %prep, not into build.

Ralf




From dwalsh at redhat.com  Sat Oct 13 14:33:56 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Sat, 13 Oct 2007 10:33:56 -0400
Subject: If you are maintinaing of developing a Fedora Package.
Message-ID: <4710D754.2090101@redhat.com>

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

If the location of the executable changes,
for example from /usr/bin to /usr/sbin.  Please make sure the SELinux
context is correct in the new location

matchpathcon /usr/bin/MYAPP
matchpathcon /ust/sbin/MYAPP

If they aren't the same, then SELinux might have a problem.

Please either fix the file_contect if you include SELinux policy or
contact the maintainer of selinux-policy (me currently) package to tell
him/her.  This way we can coordinate the updates.

Changing this could cause a security vulnerabilty, an confined
application can go to unconfined if it moves to a bin_t labeling.

Thanks,

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHENdUrlYvE4MpobMRAk+hAKDesCevzKCK/pA+aVcT0N5Ghfo33QCdHhgw
UqxsTUljrqjHIgOmGMc+grQ=
=WngZ
-----END PGP SIGNATURE-----



From arjan at infradead.org  Sat Oct 13 14:51:39 2007
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 13 Oct 2007 07:51:39 -0700
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <4710D754.2090101@redhat.com>
References: <4710D754.2090101@redhat.com>
Message-ID: <20071013075139.5d50626c@laptopd505.fenrus.org>

On Sat, 13 Oct 2007 10:33:56 -0400
Daniel J Walsh <dwalsh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> If the location of the executable changes,
> for example from /usr/bin to /usr/sbin.  Please make sure the SELinux
> context is correct in the new location
> 
> matchpathcon /usr/bin/MYAPP
> matchpathcon /ust/sbin/MYAPP
> 
> If they aren't the same, then SELinux might have a problem.
> 
> Please either fix the file_contect if you include SELinux policy or
> contact the maintainer of selinux-policy (me currently) package to
> tell him/her.  This way we can coordinate the updates.
> 

wouldn't it be a nice thing if the build system would notice such
changes and would send out a mail to some list if they happen... so
that you and others could just get automatic notices?
we could use the same for detecting things like "hey this rpm added a
setuid binary" and stuff like that.
I can think of about 40 other tests that I'd like to do in such a
program ;)



From jkeating at redhat.com  Sat Oct 13 15:00:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 13 Oct 2007 11:00:38 -0400
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <20071013075139.5d50626c@laptopd505.fenrus.org>
References: <4710D754.2090101@redhat.com>
	<20071013075139.5d50626c@laptopd505.fenrus.org>
Message-ID: <20071013110038.35ccf487@redhat.com>

On Sat, 13 Oct 2007 07:51:39 -0700
Arjan van de Ven <arjan at infradead.org> wrote:

> wouldn't it be a nice thing if the build system would notice such
> changes and would send out a mail to some list if they happen... so
> that you and others could just get automatic notices?
> we could use the same for detecting things like "hey this rpm added a
> setuid binary" and stuff like that.
> I can think of about 40 other tests that I'd like to do in such a
> program ;)

Patches, RFEs, etc... accepted -> thataway...
https://hosted.fedoraproject.org/projects/koji/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071013/a5c3261f/attachment.sig>

From ssorce at redhat.com  Sat Oct 13 15:03:11 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 11:03:11 -0400
Subject: gethostby* users
In-Reply-To: <loom.20071013T051855-88@post.gmane.org>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
Message-ID: <1192287791.10852.80.camel@localhost.localdomain>

On Sat, 2007-10-13 at 05:20 +0000, Kevin Kofler wrote:
> Richi Plana <myfedora <at> richip.dhs.org> writes:
> > I'm just worrying about the different platforms these software are
> > expected to run on. According to gethostbyname(3), the function conforms
> > to POSIX as well as 4.3BSD so certain platforms might not have support
> > for getaddrinfo(). What's the proper way of addressing these?
> > Preprocessor directives?
> 
> Ideally they'd just drop support for the obsolete systems which don't have 
> getaddrinfo. Even winsock implements it since XP. And of course all current 
> POSIX-compliant systems have it as it's part of POSIX.1-2001.

Sorry but this is not the Linux kernel, many packages don't want to drop
support for older systems, and given the differences in behavior between
getaddrinfo and gethostby* it is not really advisable in all situations
to replace these functions blindly, upstream approval is certainly
important.

Simo.



From arjan at infradead.org  Sat Oct 13 15:03:04 2007
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 13 Oct 2007 08:03:04 -0700
Subject: disable cpuspeed while X session active and screensaver not
 running
In-Reply-To: <470E5E47.4040006@andrei.myip.org>
References: <470E5E47.4040006@andrei.myip.org>
Message-ID: <20071013080304.59991f7e@laptopd505.fenrus.org>

On Thu, 11 Oct 2007 10:32:55 -0700
Florin Andrei <florin at andrei.myip.org> wrote:

> On Fedora 7, running on an AMD64 dual core 6400, I disabled cpuspeed.
> 
> The results are incredible. Because the CPU clock stays up all the
> time at 3.2GHz, instead of being pushed down most of the time to
> 1GHz, the system feels much faster. All desktop apps seem to react
> 10x faster. It's like upgrading from 486 to P3
> The difference in CPU temperature after stopping cpuspeed is barely 
> noticeable.
> 

are you using the ondemand governer?
if so.. can you try the latest hal/gnome-power-manager? (they used to
change some tunings that ended up not meaning what was intended)

I'm also surprised.. reaction time doesn't really depend on clock
speed...



From ssorce at redhat.com  Sat Oct 13 15:05:46 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 11:05:46 -0400
Subject: gethostby* users
In-Reply-To: <47106150.1090303@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net>  <47106150.1090303@redhat.com>
Message-ID: <1192287946.10852.83.camel@localhost.localdomain>

On Fri, 2007-10-12 at 23:10 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Adams wrote:
> > I don't see gethostby* listed as deprecated or obsolete by any standard
> > group or documentation.
> 
> Then you haven't even tried looking.  The functions are obsolete in the
> current Unix spec and will be gone in the next revision which we will
> finish next year.

Ulrich, some people claim that glibc's getaddrinfo breaks IPv4 DNS round
robin as it reorders also IPv4 address, can you comment on this? In some
cases it is important.

Simo.



From pertusus at free.fr  Sat Oct 13 15:06:23 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 13 Oct 2007 17:06:23 +0200
Subject: rpmbuild -bp and BR:
In-Reply-To: <1192285263.3500.70.camel@mccallum.corsepiu.local>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
	<20071012144235.71b7409f@reaver.lamontpeterson.net>
	<1192256739.3208.45.camel@ignacio.lan>
	<1192285263.3500.70.camel@mccallum.corsepiu.local>
Message-ID: <20071013150623.GA2657@free.fr>

On Sat, Oct 13, 2007 at 04:21:03PM +0200, Ralf Corsepius wrote:
> On Sat, 2007-10-13 at 02:25 -0400, Ignacio Vazquez-Abrams wrote:
> > On Fri, 2007-10-12 at 14:42 -0600, Lamont Peterson wrote:
> > > OK.  I wrote that before actually installing the packages and then went on and
> > > discovered that "autoreconf" was being run at the end of %prep.  Shouldn't
> > > something like that be in the beginning of %build instead?
> > 
> > Yes. Log a bug please.
> No. autoreconf belongs into %prep, not into build.

Although I also prefer myself when autoreconf or the like is in %prep, I
think that it should be left to the packager.

--
Pat



From mr.gopal.das at gmail.com  Sat Oct 13 16:03:12 2007
From: mr.gopal.das at gmail.com (gopal das)
Date: Sat, 13 Oct 2007 21:33:12 +0530
Subject: xboard chess interface installation failed on fedora
Message-ID: <6f631c430710130903h4085997ahb9a0dfdef36ff5b@mail.gmail.com>

Hi Friends,
I was going to install xboard on Fedora 6 for play chess. But there is a
error while configure and the following was given:
xboard requires the X Window System header files and libraries!
They were not found on your system. See FAQ topic C.2.
configure failed
 here the FAQ C.2 saying: [C2] Configuring  or building XBoard fails due to
missing header files, missing libraries, or undefined symbols.

So, please give me a solve.

Cheers
gopal das
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071013/919ff1ad/attachment.htm>

From drepper at redhat.com  Sat Oct 13 16:14:33 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sat, 13 Oct 2007 09:14:33 -0700
Subject: gethostby* users
In-Reply-To: <1192287946.10852.83.camel@localhost.localdomain>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>
	<47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
Message-ID: <4710EEE9.7060109@redhat.com>

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

Simo Sorce wrote:
> Ulrich, some people claim that glibc's getaddrinfo breaks IPv4 DNS round
> robin as it reorders also IPv4 address, can you comment on this? In some
> cases it is important.

It is not necessary (and quite wrong) to implement RR in the server.
It's an approximation at best anyway.  In no way better than
randomization.  And nothing stops programs from randomizing the results
returned by getaddrinfo before using them.  Normal programs won't do
that but there is nothing which stops programs like ntpd from doing this.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEO7p2ijCOnn/RHQRAmz7AJ9LjfmhMIEBpkQ/C3stOJ+qCnVfyQCdEjDe
07WL2BrQeuop3VkIB5hIUaw=
=PqK2
-----END PGP SIGNATURE-----



From ssorce at redhat.com  Sat Oct 13 16:34:47 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 12:34:47 -0400
Subject: gethostby* users
In-Reply-To: <4710EEE9.7060109@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
Message-ID: <1192293287.20815.3.camel@localhost.localdomain>

On Sat, 2007-10-13 at 09:14 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simo Sorce wrote:
> > Ulrich, some people claim that glibc's getaddrinfo breaks IPv4 DNS round
> > robin as it reorders also IPv4 address, can you comment on this? In some
> > cases it is important.
> 
> It is not necessary (and quite wrong) to implement RR in the server.
> It's an approximation at best anyway.  In no way better than
> randomization.  And nothing stops programs from randomizing the results
> returned by getaddrinfo before using them.  Normal programs won't do
> that but there is nothing which stops programs like ntpd from doing this.

Well, whether this is good or not, it is a mechanism widely used in many
cases, because it is good enough. Not sure breaking it on purpose make
sense, after all IPv4 sorting is just arbitrary, why caring to do it at
all?
What is the purpose of IPv4 address reordering ?

Simo.



From drepper at redhat.com  Sat Oct 13 16:37:26 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sat, 13 Oct 2007 09:37:26 -0700
Subject: gethostby* users
In-Reply-To: <1192293287.20815.3.camel@localhost.localdomain>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>
	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
Message-ID: <4710F446.1000402@redhat.com>

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

Simo Sorce wrote:
> What is the purpose of IPv4 address reordering ?

So that the most promising and possibly fastest/cheapest address is
used.  Read RFC 3484.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEPRG2ijCOnn/RHQRAlvQAKDKKvaUJ+LxKhzp82F72XO2zIBGIQCdGRLm
KNeRywkn4MIA4fj7SFe9Va4=
=nxQ+
-----END PGP SIGNATURE-----



From dwmw2 at infradead.org  Sat Oct 13 16:44:23 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 13 Oct 2007 17:44:23 +0100
Subject: gethostby* users
In-Reply-To: <87ve9bywxn.fsf@kosh.bigo.ensc.de>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<87ve9bywxn.fsf@kosh.bigo.ensc.de>
Message-ID: <1192293863.13901.45.camel@pmac.infradead.org>

On Sat, 2007-10-13 at 15:19 +0200, Enrico Scholz wrote:
> creating RFC compliant bounces (e.g. not possible with exim due to
> missing MIME support)

You mean the bounces-in-MIME thing? What RFC is that again? Is there any
particular reason to care about it?

I believe it's _possible_, although you originally said 'easily', and I
won't claim that it's easy.

-- 
dwmw2



From ssorce at redhat.com  Sat Oct 13 17:24:02 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 13:24:02 -0400
Subject: gethostby* users
In-Reply-To: <4710F446.1000402@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
	<4710F446.1000402@redhat.com>
Message-ID: <1192296242.20815.29.camel@localhost.localdomain>

On Sat, 2007-10-13 at 09:37 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simo Sorce wrote:
> > What is the purpose of IPv4 address reordering ?
> 
> So that the most promising and possibly fastest/cheapest address is
> used.  Read RFC 3484.

Sorry, but this may make sense for IPv6, but you have no way to know
which IPv4 address is closer by it's value. Except for loopback, and
other 'link-local' address, even considering private addresses
'site-local' seem to be a stretch as they are often used for VPN, and
may well be much farther than a normal global scope one.

A simple example: say I have 2 sites with 2 replicated services, I want
to have a preference for people in one site to connect to their site
server.
Site A has public IP addresses for servers because you also offer
services to the outside and contains most clients (which instead use
private addresses).
Site B has private IP addresses for servers because it is a branch
office that has only intranet replicated service (clients also have
private addresses but on a different network).
You have 2 DNS servers with views, and the 2 sites are connected by a
relatively slow link.
On Site A you configure the DNS to return locally Site A (global scope)
addresses before Site B ones, that are used just as backup.
On Site B you configure the DNS to return locally Site B (site-local)
addresses before Site A ones.

Now if you reorder these addresses what happen is that the main site A
clients will always try to contact the branch office servers instead, as
they have 'site-local' ones.

Address reordering can therefore easily make it the worst route.

I know about RFC 3484 10.5, but consider that this is highly unexpected
behavior on sites that uses IPv4 only and have pre-existing
configurations.
Also configuring the policy tables of each client (not always possible
as glibc doesn't have a way to configure policy table in versions older
then a year or so) is a lot more effort than just configuring one single
DNS server, and impossible if you want to provide different
configurations depending on the server/protocol used.

Simo.



From buildsys at fedoraproject.org  Sat Oct 13 18:00:08 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Sat, 13 Oct 2007 14:00:08 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-13
Message-ID: <20071013180008.ABBBC15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 8

    AGReader-1.2-4.fc6
    gammu-1.13.0-1.fc6
NEW jack-rack-1.4.6-3.fc6 : Stereo LADSPA effects rack for the JACK audio API
    ntfs-config-1.0-0.5.rc5.fc6
    pybliographer-1.2.11-1.fc6
    python-gammu-0.22-2.fc6
    superiotool-0-0.5.20071012svn2849.fc6
    wine-0.9.46-1.fc6


Changes in Fedora Extras 6: 


AGReader-1.2-4.fc6
------------------
* Sat Oct 13 2007 Ian Chapman <packages[AT]amiga-hardware.com> 1.2-4
- Added man page

* Tue Aug 21 2007 Ian Chapman <packages[AT]amiga-hardware.com> 1.2-3
- Release bump for F8 mass rebuild
- License change due to new guidelines
- A few cosmetic cleanups of the spec file

* Mon Aug 28 2006 Ian Chapman <packages[AT]amiga-hardware.com> 1.2-2
- Release bump for FC6 mass rebuild

gammu-1.13.0-1.fc6
------------------
* Fri Oct 12 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.13.0-1
- Updated Release.

* Thu Aug 02 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.12.92-1
- Updated Release.

jack-rack-1.4.6-3.fc6
---------------------
* Thu Oct 11 2007 kwizart <kwizart at gmail.com > - 1.4.6-3
- Build with new lash 5.3 
  (Removed obsolete ladcca-devel)
- Move dtds dir. to %{_datadir}/xml/jack-rack/dtds

* Thu Oct 04 2007 kwizart <kwizart at gmail.com > - 1.4.6-2
- Fix desktop file, License field, NEWS encoding
- Add BR ladcca-devel and Add --enable-lash

ntfs-config-1.0-0.5.rc5.fc6
---------------------------
* Thu Oct 11 2007 Xavier Lamien <lxtnow at gmail.com> - 1.0-0.5.rc5
- Removed redhat-arwork as Requires.

pybliographer-1.2.11-1.fc6
--------------------------
* Mon Oct 01 2007 Zoltan Kota <z.kota at gmx.net> - 1.2.11-1
- update to 1.2.11

python-gammu-0.22-2.fc6
-----------------------
* Sat Oct 13 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.22-2
- Excluded pcc arch for now, build error reported to upstream.

* Fri Oct 12 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.22-1
- Updated Release.

superiotool-0-0.5.20071012svn2849.fc6
-------------------------------------
* Fri Oct 12 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.5.20071012svn2849
- svn ver 2849 (support for SMSC FDC37M81x, SMSC FDC37B78x, SMSC FDC37B72x,
  Winbond W83627THF/THG, NSC PC87351 and some more SMSC, ITE and NSC chips
- added manpage

wine-0.9.46-1.fc6
-----------------
* Mon Oct 08 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

* Sat Aug 25 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.44-1
- version upgrade

* Sat Aug 18 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.43-2
- fix license

* Sat Aug 11 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.43-1
- version upgrade
- fix init-script output (#252144)
- add lsb stuff (#247096)



From sean.bruno at dsl-only.net  Sat Oct 13 19:21:30 2007
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Sat, 13 Oct 2007 12:21:30 -0700
Subject: My attempt to understand dmraid
Message-ID: <1192303290.23979.26.camel@home-desk>

I am trying to delve into dmraid/device-mapper and learn how the magic
happens and I came up with what I think is the "way it works."  Please
critique and correct me where I am wrong or over-simplify the operation
of the current dmraid architecture as it is used under Fedora/redhat
systems.

Assumptions:
  dmraid compatible device(sil3118)
  Hard Drives of equal size(SATA in my case)
  Installation of Fedora Core 7(x86_64)

1.
The initial setup occurs on the RAID controller where I selected RAID1
with my two disks.  This initialized the drives for use with
dmraid/device-mapper by placing the SiL metadata on the drives and set
them to a initialized state.

2.
The system boots off the first hard drive(sda) and loads the kernel from
there.

3.
Booting Fedora Core 7, /etc/rc.sysinit loads the fake RAID1 module
"dm-mirror".  This actually works with the software RAID code in md to
manage the RAID1.  The system then detects that the drives are a RAID1
set by invoking '/sbin/dmraid  -ay -i -p -t' This detects the RAID1 set
and creates /dev/mapper/silXXXXXXX through the device-mapper libraries.


What is unclear to me is where the system mounts the filesystems
on /dev/mapper/silXXXXXX and how the dm-mirror module manages drive
failues.  Can someone fill in the pieces for me?

Sean



From lesmikesell at gmail.com  Sat Oct 13 20:02:16 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 13 Oct 2007 15:02:16 -0500
Subject: gethostby* users
In-Reply-To: <4710EEE9.7060109@redhat.com>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
Message-ID: <47112448.6010106@gmail.com>

Ulrich Drepper wrote:

> Simo Sorce wrote:
>> Ulrich, some people claim that glibc's getaddrinfo breaks IPv4 DNS round
>> robin as it reorders also IPv4 address, can you comment on this? In some
>> cases it is important.
> 
> It is not necessary (and quite wrong) to implement RR in the server.
> It's an approximation at best anyway.  In no way better than
> randomization.  And nothing stops programs from randomizing the results
> returned by getaddrinfo before using them.  Normal programs won't do
> that but there is nothing which stops programs like ntpd from doing this.

A client has no possible way to know what the "best" choice from a list 
of RR DNS IP's might be, whereas server products like F5's 3DNS/global 
load balancer monitor server load/availability and and an assortment of 
other things to offer the best choice.  I don't know if any of these 
products send an ordered list in the preferred choice, but things would 
be more robust if they did and the client walked the list in the 
presented order.  If the server must send only one IP to control the 
client's choice, it causes a problem when circumstances change during 
the client application's run time.   Many clients (particularly IE - the 
most popular one..) will cache the list given in the initial lookup and 
on subsequent failure will retry others from that list but will not do 
another DNS lookup as part of the error recovery.  Thus if they have 
been given a preferred and backup IP in the first lookup, they'll keep 
working even if the preferred server becomes unreachable.  But, if they 
resort the list, half of them will pick the wrong first choice even when 
it is reachable.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mcepl at redhat.com  Sat Oct 13 20:07:26 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 13 Oct 2007 22:07:26 +0200
Subject: The gstreamer third way
References: <1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com> <1192218859.3498.8.camel@dawkins>
	<20071012184117.GC8027@ryvius.pekin.waw.pl>
Message-ID: <slrnfh29bu.c4m.mcepl@hubmaier.ceplovi.cz>

On 2007-10-12, 18:41 GMT, Dominik 'Rathann' Mierzejewski wrote:
> This problem wouldn't have arised if samba just stayed with 
> GPLv2. I cannot imagine how you can call this a QT bug.

I am sorry, but upstream has every right to change their license 
to whatever they wish. If somebody wants to use their 
functionality (you know, KDE is using product of Samba folks 
work), then he/she/it must accommodate his code.

b) When choosing whether we want to fork Samba or whether KDE 
will suck it up, we probably decide what is more important to us 
-- fully functional Samba fully supported by upstream or KDE 
supporting smb:// (the situation would be the same if it was 
Gnome what is affected -- don't drag me into that religious war)?  
I am afraid the answer is obvious.

Mat?j



From benny+usenet at amorsen.dk  Sat Oct 13 20:26:50 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 13 Oct 2007 22:26:50 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
Message-ID: <m3fy0e92wl.fsf@ursa.amorsen.dk>

>>>>> "AC" == Alan Cox <alan at redhat.com> writes:

AC> Today people still ship new laptops with CD-R/CD-RW drives. Lots
AC> of them. You can't fit a $30 DVD reader to them.

Is there a handy way to use a USB key for install? dd'ing boot.img
works fine, but with today's large USB sticks, you might as well stick
the DVD there too. But how?


/Benny




From tjb at unh.edu  Sat Oct 13 20:50:51 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Sat, 13 Oct 2007 16:50:51 -0400
Subject: kojiweb down
Message-ID: <1192308651.12999.20.camel@continuity.bakerconsulting.com>


FYI, kojiweb is broken at the moment. Here is what I get going to just
the top level:

Mod_python error: "PythonHandler mod_python.publisher"

Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
    result = object(req)

  File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 213, in handler
    published = publish_object(req, object)

  File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object
    return publish_object(req,util.apply_fs_data(object, req.form, req=req))

  File "/usr/lib/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data
    return object(**args)

  File "/usr/share/koji-web/scripts/index.py", line 175, in index
    start=buildStart, dataName='builds', prefix='build', order=buildOrder, pageSize=10)

  File "/usr/share/koji-web/lib/kojiweb/util.py", line 109, in paginateMethod
    totalRows = getattr(server, methodName)(*args, **kw)

  File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1075, in __call__
    return self.__func(self.__name,args,opts)

  File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1300, in _callMethod
    return proxy.__getattr__(name)(*args)

  File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
    return self.__send(self.__name, args)

  File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
    verbose=self.__verbose

  File "/usr/lib/python2.4/xmlrpclib.py", line 1137, in request
    headers

ProtocolError: 

Not a big deal for me, just reporting it.

tjb
--
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From drago01 at gmail.com  Sat Oct 13 21:01:43 2007
From: drago01 at gmail.com (dragoran)
Date: Sat, 13 Oct 2007 23:01:43 +0200
Subject: kojiweb down
In-Reply-To: <1192308651.12999.20.camel@continuity.bakerconsulting.com>
References: <1192308651.12999.20.camel@continuity.bakerconsulting.com>
Message-ID: <f6ca9fed0710131401m2a40872enb8281399e151fe98@mail.gmail.com>

On 10/13/07, Thomas J. Baker <tjb at unh.edu> wrote:
>
> FYI, kojiweb is broken at the moment. Here is what I get going to just
> the top level:

works fine here...



From seandarcy2 at gmail.com  Sat Oct 13 21:02:09 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sat, 13 Oct 2007 17:02:09 -0400
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
References: <200710111755.02714.singularitaet@gmx.net>
	<4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
Message-ID: <ferboh$ok2$1@ger.gmane.org>

Tom London wrote:
> On 10/11/07, Stefan Grosse <singularitaet at gmx.net> wrote:
>> After the rawhide update of today, October 10th the Network Manager seems to
>> be broken in a way that it interrupts my internet connection completely. I
>> cannot activate eth0 manually. Internet works only if the networkmanager is
>> not loaded on startup.
>>
>> I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
>> a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet
>> controller.
>>
>> Stefan
>>
> Believe these version of NM allows configurable 'auto connection'.
> 
> My would come up with no network connection, but I could manually
> select it from the nm-applet.
> 
> Applications->System Tools->Configuration Editor allows setting
> 'autoconnect' for each connection.--
> 
> For me, this was 'system->networking->connections->1->connection->autoconnect'
> 

I do not see "networking" under system the the Configuration Editor. I 
have NM, NM-gnome, NM-glib installed.

Am I missing something? Hope so, cause NM is really messing me up.

sean



From dmc.fedora at filteredperception.org  Sat Oct 13 21:24:05 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sat, 13 Oct 2007 16:24:05 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <m3fy0e92wl.fsf@ursa.amorsen.dk>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
Message-ID: <47113775.1090805@filteredperception.org>

Benny Amorsen wrote:
>>>>>> "AC" == Alan Cox <alan at redhat.com> writes:
> 
> AC> Today people still ship new laptops with CD-R/CD-RW drives. Lots
> AC> of them. You can't fit a $30 DVD reader to them.
> 
> Is there a handy way to use a USB key for install? dd'ing boot.img
> works fine, but with today's large USB sticks, you might as well stick
> the DVD there too. But how?

Here is the relevant current link.

http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo

But there is a vast amount of work that can be done to improve the 
situation and provide more flexibility.  I.e. on the simple end, would 
be turning the above process into an easy to use GUI.  On the more 
complex end, you could do something like using grub2's loopback feature 
and modifications to the install DVD's initramfs, to support something 
more like what you were suggesting.

And on top of that, there are many, many other interesting theoretical 
options that can be explored.  My personal favorite being a LiveUSB with 
multiple differing persistence images, each of which could be chosen to 
be rebootlessly installed...

-dmc



From tjb at unh.edu  Sat Oct 13 21:26:10 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Sat, 13 Oct 2007 17:26:10 -0400
Subject: kojiweb down
In-Reply-To: <f6ca9fed0710131401m2a40872enb8281399e151fe98@mail.gmail.com>
References: <1192308651.12999.20.camel@continuity.bakerconsulting.com>
	<f6ca9fed0710131401m2a40872enb8281399e151fe98@mail.gmail.com>
Message-ID: <1192310770.28639.0.camel@continuity.bakerconsulting.com>


On Sat, 2007-10-13 at 23:01 +0200, dragoran wrote:
> On 10/13/07, Thomas J. Baker <tjb at unh.edu> wrote:
> >
> > FYI, kojiweb is broken at the moment. Here is what I get going to just
> > the top level:
> 
> works fine here...
> 

Works for me now too.

tjb
--
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From jon at fedoraunity.org  Sat Oct 13 21:27:04 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Sat, 13 Oct 2007 15:27:04 -0600
Subject: kojiweb down
In-Reply-To: <1192308651.12999.20.camel@continuity.bakerconsulting.com>
References: <1192308651.12999.20.camel@continuity.bakerconsulting.com>
Message-ID: <47113828.5000000@fedoraunity.org>

Thomas J. Baker wrote:
> FYI, kojiweb is broken at the moment. Here is what I get going to just
> the top level:
> 

This is a known issue and it is being worked on. Thanks for the report.

Jonathan



From emmanuel.seyman at club-internet.fr  Sat Oct 13 21:42:06 2007
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sat, 13 Oct 2007 23:42:06 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <m3fy0e92wl.fsf@ursa.amorsen.dk>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
Message-ID: <20071013214206.GA20157@orient.maison.lan>

* Benny Amorsen [13/10/2007 23:14] :
>
> Is there a handy way to use a USB key for install? dd'ing boot.img
> works fine, but with today's large USB sticks, you might as well stick
> the DVD there too. But how?

I believe* you just need to copy the iso to the key and, during the first
steps of install, select "Hard drive installation" then point Anaconda to
the partition and directory where the iso is located.

Emmanuel



From seandarcy2 at gmail.com  Sat Oct 13 22:20:15 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sat, 13 Oct 2007 18:20:15 -0400
Subject: how to keep ssb kernel module from loading?
Message-ID: <fergav$3dv$1@ger.gmane.org>

I have a laptop with a braodcom 4311 wireless card :(.

The b43 and ssb kernel modules don't work. I need to load ndiswrapper.

Are there kernel parameters that I can use in grub.conf to stop ssb from 
loading, and to load ndiswrapper.

sean



From ssorce at redhat.com  Sat Oct 13 22:28:15 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 18:28:15 -0400
Subject: The gstreamer third way
In-Reply-To: <20071012184117.GC8027@ryvius.pekin.waw.pl>
References: <1191987490.10594.1.camel@naomi>
	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com> <1192218859.3498.8.camel@dawkins>
	<20071012184117.GC8027@ryvius.pekin.waw.pl>
Message-ID: <1192314495.21735.3.camel@localhost.localdomain>

On Fri, 2007-10-12 at 20:41 +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 12 October 2007 at 21:54, David Nielsen wrote:
> [...]
> > This is a QT bug, I suggest the QT people fix it, if need be then KDE
> > can be compiled without said support till a solution is found. Naturally
> > it's undesirable to withhold said functionality from these users but
> > TrollTech knew these was coming and it's a well understood problem which
> > can only be fixed in a satifactory manner by them.
> 
> This problem wouldn't have arised if samba just stayed with GPLv2.
> I cannot imagine how you can call this a QT bug.

This problem would never have been if QT were GPLv2+.
So what do you want to do?
Keep passing the ball?

Simo.



From darth_linux at ameritech.net  Sat Oct 13 22:23:44 2007
From: darth_linux at ameritech.net (eah)
Date: Sat, 13 Oct 2007 18:23:44 -0400
Subject: how to keep ssb kernel module from loading?
In-Reply-To: <fergav$3dv$1@ger.gmane.org>
References: <fergav$3dv$1@ger.gmane.org>
Message-ID: <200710131823.44983.darth_linux@ameritech.net>

On Saturday 13 October 2007 18:20:15 pm sean darcy wrote:
> I have a laptop with a braodcom 4311 wireless card :(.
>
> The b43 and ssb kernel modules don't work. I need to load ndiswrapper.
>
> Are there kernel parameters that I can use in grub.conf to stop ssb from
> loading, and to load ndiswrapper.
>
> sean

I usually unload ssb with rmmod ssb then put blacklist ssb 
into /etc/modules.d/blacklist* and then modprobe ndiswrapper (assumming 
ndiswrapper is already configured). 



eah 



From arjan at infradead.org  Sat Oct 13 22:28:39 2007
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 13 Oct 2007 15:28:39 -0700
Subject: how to keep ssb kernel module from loading?
In-Reply-To: <fergav$3dv$1@ger.gmane.org>
References: <fergav$3dv$1@ger.gmane.org>
Message-ID: <20071013152839.709cdf57@laptopd505.fenrus.org>

On Sat, 13 Oct 2007 18:20:15 -0400
sean darcy <seandarcy2 at gmail.com> wrote:

> I have a laptop with a braodcom 4311 wireless card :(.
> 
> The b43 and ssb kernel modules don't work.


what is the bugzilla number for this?



From ssorce at redhat.com  Sat Oct 13 22:30:34 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 13 Oct 2007 18:30:34 -0400
Subject: The gstreamer third way
In-Reply-To: <470F4BDB.2090009@warmcat.com>
References: <1191420459.8632.60.camel@localhost.localdomain>
	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>
	<200710091925.01313@rineau.tsetse>
	<1191951027.8880.34.camel@localhost.localdomain>
	<20071009175637.GF1500118@hiwaay.net>
	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>
	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>
	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>
	<1191990002.13627.35.camel@localhost.localdomain>
	<470C82D2.2010107@warmcat.com> <470C9681.9050905@nicubunu.ro>
	<loom.20071011T191138-597@post.gmane.org>
	<1192133361.7723.7.camel@rousalka.dyndns.org>
	<loom.20071011T201209-819@post.gmane.org>
	<470F4BDB.2090009@warmcat.com>
Message-ID: <1192314634.21735.6.camel@localhost.localdomain>

On Fri, 2007-10-12 at 11:26 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
> > Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> >> Le jeudi 11 octobre 2007 ? 19:12 +0000, Kevin Kofler a ?crit :
> >>> Yet third-party repositories are happily distributing proprietary 
> > kmod-nvidia 
> >>> modules linked against the GPLv2 kernel, which isn't any more legal than 
> >>> distributing a GPLv2 kio_smb linked against a GPLv3 Samba would be.
> >> Last I checked they're not distributing both kmod-nvidia and kernels in
> >> the same repo
> > 
> > They wouldn't be shipping Samba in the third-party repo either.
> 
> So I didn't get the objection to the original proposal.
> 
>  - Fedora just sticks with the perfectly valid last GPL2 version for
> now, links KDE3 stuff against it as usual and has nothing to do with the
> GPL3 version until there is a better situation
> 
>  - That is the end of the story for the typical case.  When KDE4 comes
> or there is some other better resolution that allows it, Fedora just
> starts using the GPL3 samba libs and goes on in a good clean way.

If KDE4 will not be ready for F-9 timeframe I will do my best to have
samba 3.2.x in Fedora anyway. Even if that means stopping linking
libsmbclient into KDE.

>  - Additionally, completely externally, some other repo might offer a
> standalone GPL3 samba libs package that has the same soname that
> endusers might choose to use to replace Fedora's GPL2 library.  That's
> up to them and the user's problem that his combined system may not be
> redistributable if he goes down that path.

This is not ideal nor desirable.

> If I understood it, this does not violate any terms or intention of the
> terms and is nice and clean.

It's not nice, nor 'clean'. KDE (I mean really Trolltech here as KDE
people can't do much) at least starting discussing the problem would be
nice an clean.

Simo.



From seandarcy2 at gmail.com  Sat Oct 13 22:42:06 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sat, 13 Oct 2007 18:42:06 -0400
Subject: how to keep ssb kernel module from loading?
In-Reply-To: <20071013152839.709cdf57@laptopd505.fenrus.org>
References: <fergav$3dv$1@ger.gmane.org>
	<20071013152839.709cdf57@laptopd505.fenrus.org>
Message-ID: <ferhju$63v$1@ger.gmane.org>

Arjan van de Ven wrote:
> On Sat, 13 Oct 2007 18:20:15 -0400
> sean darcy <seandarcy2 at gmail.com> wrote:
> 
>> I have a laptop with a braodcom 4311 wireless card :(.
>>
>> The b43 and ssb kernel modules don't work.
> 
> 
> what is the bugzilla number for this?
> 

I didn't file.

Posted to the upstream bcm43xx-dev at lists.berlios.de:

sean darcy wrote:
 > Compaq Presario C714NR, Intel GM965
 >
 > uname -r
 > 2.6.23-0.224.rc9.git6.fc8
 >
 > lspci
 > 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
 > mini-PCI (rev 02)

As John Linville suggested, rev 02 of the 4311's are not supported. At 
the moment, the reverse
engineers need to take apart the latest Broadcom driver and write the 
specifications for this
device. Until they find the time, this device will not work with either 
b43 or bcm43xx.

Sorry,

Larry

Should I file it? It's not a fedora issue, or is this to keep track of 
upstream issues?

sean



From seandarcy2 at gmail.com  Sat Oct 13 22:43:17 2007
From: seandarcy2 at gmail.com (sean darcy)
Date: Sat, 13 Oct 2007 18:43:17 -0400
Subject: how to keep ssb kernel module from loading?
In-Reply-To: <200710131823.44983.darth_linux@ameritech.net>
References: <fergav$3dv$1@ger.gmane.org>
	<200710131823.44983.darth_linux@ameritech.net>
Message-ID: <ferhm5$63v$2@ger.gmane.org>

eah wrote:
> On Saturday 13 October 2007 18:20:15 pm sean darcy wrote:
>> I have a laptop with a braodcom 4311 wireless card :(.
>>
>> The b43 and ssb kernel modules don't work. I need to load ndiswrapper.
>>
>> Are there kernel parameters that I can use in grub.conf to stop ssb from
>> loading, and to load ndiswrapper.
>>
>> sean
> 
> I usually unload ssb with rmmod ssb then put blacklist ssb 
> into /etc/modules.d/blacklist* and then modprobe ndiswrapper (assumming 
> ndiswrapper is already configured). 
> 
> 
> 
> eah 
> 

I can do that, but I was hoping to use a kernel parameter in grub.conf.

sean



From cmadams at hiwaay.net  Sat Oct 13 23:57:55 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 13 Oct 2007 18:57:55 -0500
Subject: gethostby* users
In-Reply-To: <4710F446.1000402@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
	<4710F446.1000402@redhat.com>
Message-ID: <20071013235755.GA1497083@hiwaay.net>

Once upon a time, Ulrich Drepper <drepper at redhat.com> said:
> So that the most promising and possibly fastest/cheapest address is
> used.  Read RFC 3484.

Have you read it?  Once again, it is about IPv6.  Stop citing an RFC
(both here and in your blog) that doesn't support your claim.

Once again (since you ignored it last time), there is no documentation
in either SUSv3 or OS man pages that mentions address sorting, and the
RFC only talks about IPv4 in a dual-stack setup.

-- 
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 lesmikesell at gmail.com  Sun Oct 14 00:46:58 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 13 Oct 2007 19:46:58 -0500
Subject: gethostby* users
In-Reply-To: <1192267734.13901.2.camel@pmac.infradead.org>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
Message-ID: <47116702.10604@gmail.com>

David Woodhouse wrote:
> On Fri, 2007-10-12 at 08:02 -0500, Chris Adams wrote:
>> I know it is fun to pick on sendmail, but it works well and I can use
>> it to do things not easily done in some other MTAs.
> 
> Examples?

Running MimeDefang is a good example.  MimeDefang runs as a milter, does 
whatever spam/virus scanning and other processing you want, controlled 
by a small perl script in real time during the smtp conversation so it 
can reject based on the results.  However it does not need a 1 to 1 
ratio of perl processes to sendmail processes and does not make fast 
operations wait on slow ones due to the way the milter interface handles 
separate steps.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dwmw2 at infradead.org  Sun Oct 14 03:13:19 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 14 Oct 2007 04:13:19 +0100
Subject: gethostby* users
In-Reply-To: <47116702.10604@gmail.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<47116702.10604@gmail.com>
Message-ID: <1192331600.3015.4.camel@localhost.localdomain>

On Sat, 2007-10-13 at 19:46 -0500, Les Mikesell wrote:
> Running MimeDefang is a good example.

RFC3464 MIME bounces were a better example, although I still don't
really see the point in them. Probably worth implementing though, just
for completeness.

A brief look at MimeDefang doesn't seem to show up anything it can do
which Exim can't, with its built-in interfaces to SpamAssassin, ClamAV,
etc.

Did I miss something?

-- 
dwmw2



From lesmikesell at gmail.com  Sun Oct 14 01:50:02 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 13 Oct 2007 20:50:02 -0500
Subject: gethostby* users
In-Reply-To: <1192331600.3015.4.camel@localhost.localdomain>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>
	<1192331600.3015.4.camel@localhost.localdomain>
Message-ID: <471175CA.7090708@gmail.com>

David Woodhouse wrote:
> On Sat, 2007-10-13 at 19:46 -0500, Les Mikesell wrote:
>> Running MimeDefang is a good example.
> 
> RFC3464 MIME bounces were a better example, although I still don't
> really see the point in them. Probably worth implementing though, just
> for completeness.
> 
> A brief look at MimeDefang doesn't seem to show up anything it can do
> which Exim can't, with its built-in interfaces to SpamAssassin, ClamAV,
> etc.
> 
> Did I miss something?
> 

These slides give the whole story but the big things are that you can do 
anything you want by writing a small amount of perl code, the scanning 
processes don't run under the same uid as the mailer, and it is very 
efficient. Most other approaches start a scanner process for each 
message, wasting a lot of time, or tie it to a mailer process for its 
entire run, wasting a lot of memory or limiting the number of mailers 
you can be running.

http://www.mimedefang.org/static/mimedefang-lisa04.pdf?PHPSESSID=5aa480195a2bef83bcc79a537c94808c


Sendmail runs multiple processes that connect to a milter for each 
operation needed (slide 16).  MimeDefang provides a milter socket and 
multiplexes the connections to some number of perl processes that do the 
work (slide 31).  So, you don't have to start a process for each run and 
you can run many more sendmail processes than perl/mimedefang processes 
since sendmail connects for each operation and mimedefang connects the 
job to an available, already running process to do the work.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jcm at redhat.com  Sun Oct 14 03:52:37 2007
From: jcm at redhat.com (Jon Masters)
Date: Sat, 13 Oct 2007 23:52:37 -0400
Subject: ps2 mouse input support broken on F8T3?
Message-ID: <1192333957.3155.46.camel@jcmlaptop>

Yo,

Anyone else having problems with PS2 mouse support during installation?

Jon.




From lmacken at redhat.com  Sun Oct 14 05:12:21 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sun, 14 Oct 2007 01:12:21 -0400
Subject: intermittent fedora web service outages
Message-ID: <20071014051221.GA5135@crow.myhome.westell.com>

Mike is in the process of tracking down some issues with our database at
the moment, so there may be some intermittent outages with some of our
web services, including:

    - bodhi
    - koji
    - pkgdb
    - mirrormanager
    - accounts system

Thanks,

luke



From james.antill at redhat.com  Sun Oct 14 06:13:22 2007
From: james.antill at redhat.com (James Antill)
Date: Sun, 14 Oct 2007 02:13:22 -0400
Subject: Memory usage - default X install can't use yum with 1GB RAM 
	machine
In-Reply-To: <20071012180914.3AE6C6F1C5@alopias.GreenKey.net>
References: <Pine.LNX.4.64.0710111523370.22902@newtla.xelerance.com>
	<1192133338.19494.10.camel@code.and.org> <fem0ue$qg8$1@sea.gmane.org>
	<1192137117.19494.19.camel@code.and.org>
	<20071012180914.3AE6C6F1C5@alopias.GreenKey.net>
Message-ID: <1192342402.4018.5.camel@code.and.org>

On Fri, 2007-10-12 at 11:09 -0700, Curtis Doty wrote:

> Yes way cool, James. That script hightlights a bunch of info I've been 
> curious about and too lazy to RTF proc(5). Here's a little patch to make 
> it disclose which processes are sitting on the deleted libs.

 Well it was something I threw together a few months ago to give myself
some rough numbers, but here's an update which is a bit more
userfriendly (also does the detailed info by pids, if that is the first
argument).

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wasted-ram-updates.py
Type: text/x-python
Size: 8058 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/a39a607d/attachment.py>
-------------- 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/20071014/a39a607d/attachment.sig>

From jcm at redhat.com  Sun Oct 14 06:26:58 2007
From: jcm at redhat.com (Jon Masters)
Date: Sun, 14 Oct 2007 02:26:58 -0400
Subject: ps2 mouse input support broken on F8T3?
In-Reply-To: <1192333957.3155.46.camel@jcmlaptop>
References: <1192333957.3155.46.camel@jcmlaptop>
Message-ID: <1192343218.3155.51.camel@jcmlaptop>

On Sat, 2007-10-13 at 23:52 -0400, Jon Masters wrote:
> Yo,
> 
> Anyone else having problems with PS2 mouse support during installation?

Hmmm...I think it's conveniently timed hardware failure. Mouse
intermittently is detected correctly. Great.

Jon.




From j.w.r.degoede at hhs.nl  Sun Oct 14 07:32:45 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 14 Oct 2007 09:32:45 +0200
Subject: xboard chess interface installation failed on fedora
In-Reply-To: <6f631c430710130903h4085997ahb9a0dfdef36ff5b@mail.gmail.com>
References: <6f631c430710130903h4085997ahb9a0dfdef36ff5b@mail.gmail.com>
Message-ID: <4711C61D.3000301@hhs.nl>

gopal das wrote:
> Hi Friends,
> I was going to install xboard on Fedora 6 for play chess. But there is a
> error while configure and the following was given:
> xboard requires the X Window System header files and libraries!
> They were not found on your system. See FAQ topic C.2.
> configure failed
>  here the FAQ C.2 saying: [C2] Configuring  or building XBoard fails due to
> missing header files, missing libraries, or undefined symbols.
> 
> So, please give me a solve.
> 
You need todo a "yum install libXaw-devel"

Regards,


Hans



From nicolas.mailhot at laposte.net  Sun Oct 14 08:01:42 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 14 Oct 2007 10:01:42 +0200
Subject: gethostby* users
In-Reply-To: <47116702.10604@gmail.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<47116702.10604@gmail.com>
Message-ID: <1192348902.12099.1.camel@rousalka.dyndns.org>


Le samedi 13 octobre 2007 ? 19:46 -0500, Les Mikesell a ?crit :
> David Woodhouse wrote:
> > On Fri, 2007-10-12 at 08:02 -0500, Chris Adams wrote:
> >> I know it is fun to pick on sendmail, but it works well and I can use
> >> it to do things not easily done in some other MTAs.
> > 
> > Examples?
> 
> Running MimeDefang is a good example.  MimeDefang runs as a milter

and other MTAs than sandmail support the milter interface (and they also
have non-milter alternatives to MimeDefang)

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

From andy at warmcat.com  Sun Oct 14 08:18:53 2007
From: andy at warmcat.com (Andy Green)
Date: Sun, 14 Oct 2007 09:18:53 +0100
Subject: The gstreamer third way
In-Reply-To: <1192314634.21735.6.camel@localhost.localdomain>
References: <1191420459.8632.60.camel@localhost.localdomain>	<fefvuq$ak4$1@sea.gmane.org>	<20071009134321.GA4031@redhat.com>	<200710091925.01313@rineau.tsetse>	<1191951027.8880.34.camel@localhost.localdomain>	<20071009175637.GF1500118@hiwaay.net>	<604aa7910710091107u5c0ecdb4vc9b05dca0cbd7851@mail.gmail.com>	<1191970821.8865.28.camel@dragonlady>	<470C0D29.4050101@gmail.com>	<1191987490.10594.1.camel@naomi>	<470C4BB9.5060905@fedoraproject.org>	<1191990002.13627.35.camel@localhost.localdomain>	<470C82D2.2010107@warmcat.com>
	<470C9681.9050905@nicubunu.ro>	<loom.20071011T191138-597@post.gmane.org>	<1192133361.7723.7.camel@rousalka.dyndns.org>	<loom.20071011T201209-819@post.gmane.org>	<470F4BDB.2090009@warmcat.com>
	<1192314634.21735.6.camel@localhost.localdomain>
Message-ID: <4711D0ED.1010105@warmcat.com>

Somebody in the thread at some point said:

>>  - That is the end of the story for the typical case.  When KDE4 comes
>> or there is some other better resolution that allows it, Fedora just
>> starts using the GPL3 samba libs and goes on in a good clean way.
> 
> If KDE4 will not be ready for F-9 timeframe I will do my best to have
> samba 3.2.x in Fedora anyway. Even if that means stopping linking
> libsmbclient into KDE.

Is it possible to use some LD_LIBRARY_PATH or somesuch to bind
libsmbclient only to the GPL2 samba libs in that case?

>>  - Additionally, completely externally, some other repo might offer a
>> standalone GPL3 samba libs package that has the same soname that
>> endusers might choose to use to replace Fedora's GPL2 library.  That's
>> up to them and the user's problem that his combined system may not be
>> redistributable if he goes down that path.
> 
> This is not ideal nor desirable.

Nor is it under your control in the least -- it is out of scope for
Fedora by definition.  It's also *legitimate* if an enduser wants to
combine stuff in a nondistributable way (at least it is true for GPL2
era stuff, I don't fully apprehend the GPL3)... and indeed doesn't
distribute it.  I don't propose it should be done or anyone here has to
do or acknowledge or bless it, just that it is a real permutation that
can exist under the sun without violation.

>> If I understood it, this does not violate any terms or intention of the
>> terms and is nice and clean.
> 
> It's not nice, nor 'clean'. KDE (I mean really Trolltech here as KDE
> people can't do much) at least starting discussing the problem would be
> nice an clean.

Well at least we seem to agree it doesn't violate anything.

Within the boundaries of what Fedora actually controls, it's clean.

-Andy



From atkac at redhat.com  Sun Oct 14 08:46:47 2007
From: atkac at redhat.com (Adam Tkac)
Date: Sun, 14 Oct 2007 10:46:47 +0200
Subject: gethostby* users
In-Reply-To: <4710EEE9.7060109@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
Message-ID: <20071014084646.GA4328@traged.englab.brq.redhat.com>

On Sat, Oct 13, 2007 at 09:14:33AM -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simo Sorce wrote:
> > Ulrich, some people claim that glibc's getaddrinfo breaks IPv4 DNS round
> > robin as it reorders also IPv4 address, can you comment on this? In some
> > cases it is important.
> 
> It is not necessary (and quite wrong) to implement RR in the server.
> It's an approximation at best anyway.  In no way better than
> randomization.  And nothing stops programs from randomizing the results
> returned by getaddrinfo before using them.  Normal programs won't do
> that but there is nothing which stops programs like ntpd from doing this.
>

I'm not sure why it is wrong. When you get response from server many applications simply take first record and use them. It could cause overload of one server and other will do nothing. Also I'm not sure about get{addr,name}info() implemetation in other systems (BSD, Sun, and maybe Windows) if they implementing RR or some other mechanism. Generally RR implemented in server is good way how all DNS records will be used balanced.

Adam



From jonathan.underwood at gmail.com  Sun Oct 14 08:58:04 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 14 Oct 2007 09:58:04 +0100
Subject: xboard chess interface installation failed on fedora
In-Reply-To: <6f631c430710130903h4085997ahb9a0dfdef36ff5b@mail.gmail.com>
References: <6f631c430710130903h4085997ahb9a0dfdef36ff5b@mail.gmail.com>
Message-ID: <645d17210710140158k2db19e87hba90a20e8bda552b@mail.gmail.com>

On 13/10/2007, gopal das <mr.gopal.das at gmail.com> wrote:
> Hi Friends,
> I was going to install xboard on Fedora 6 for play chess. But there is a
> error while configure and the following was given:
> xboard requires the X Window System header files and libraries!
> They were not found on your system. See FAQ topic C.2.
> configure failed
>  here the FAQ C.2 saying: [C2] Configuring  or building XBoard fails due to
> missing header files, missing libraries, or undefined symbols.
>
> So, please give me a solve.

xboard is part of the Fedora Extras package collection for Fedora Core
6. Therefore, you don't need to compile the program yourself, but
rather do

yum install xboard

as root user, assuming you have the Fedora Extras repository activated.

Please note that this list is for questions about fedora development,
and not user problems such as the one you posted. Those sorts of
questions should be asked on fedora-list, not here.

Jonathan.



From 440volt.tux at gmail.com  Sun Oct 14 09:03:02 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Sun, 14 Oct 2007 14:33:02 +0530
Subject: nucleo version problem
Message-ID: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>

Hi !

I was thinking of packaging nucleo
[http://insitu.lri.fr/~roussel/projects/nucleo/]
First ..Is anybody working on this already??
Second... Nucleo comes in Nucleo-2007-XX-XX format. how to resolve this ??

-- 
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From kwizart at gmail.com  Sun Oct 14 09:11:44 2007
From: kwizart at gmail.com (KH KH)
Date: Sun, 14 Oct 2007 11:11:44 +0200
Subject: nucleo version problem
In-Reply-To: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
References: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
Message-ID: <e1760170710140211y31cfa082g56c0eeafb9319d5@mail.gmail.com>

2007/10/14, subhodip biswas <440volt.tux at gmail.com>:
>
> Hi !
>
> I was thinking of packaging nucleo
> [http://insitu.lri.fr/~roussel/projects/nucleo/]
> First ..Is anybody working on this already??
> Second... Nucleo comes in Nucleo-2007-XX-XX format. how to resolve this ??


Already done, see :
http://kwizart.free.fr/fedora/7/SRPMS/nucleo-0.7-0.1.20070725cvs.kwizart.fc7.src.rpm
It may need some patches for x86_64, I've dropped them, but they seems still
usefull  as Metisse in x86_64 isn't working:
http://kwizart.free.fr/fedora/patches/nucleo-20061224-64bit-fixes.bin

Same for Metisse...

The problem is that nucleo have dependency that cannot be found on Fedora
(if used)
Maybe can you see with rpmfusion.org in this case...

So, feel free to improve the package (new snapshoot or else)
and keep me up2date...

Nicolas (kwizart )

--
> GPG key : FAEA34AB
> Server : pgp.mit.edu
> http://subhodipbiswas.wordpress.com
> http:/www.fedoraproject.org/wiki/SubhodipBiswas
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/da7a00db/attachment.htm>

From enrico.scholz at informatik.tu-chemnitz.de  Sun Oct 14 09:26:36 2007
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sun, 14 Oct 2007 11:26:36 +0200
Subject: gethostby* users
In-Reply-To: <1192293863.13901.45.camel@pmac.infradead.org> (David Woodhouse's
	message of "Sat, 13 Oct 2007 17:44:23 +0100")
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<87ve9bywxn.fsf@kosh.bigo.ensc.de>
	<1192293863.13901.45.camel@pmac.infradead.org>
Message-ID: <87odf2yrlf.fsf@kosh.bigo.ensc.de>

David Woodhouse <dwmw2 at infradead.org> writes:

>> creating RFC compliant bounces (e.g. not possible with exim due to
>> missing MIME support)
>
> You mean the bounces-in-MIME thing? What RFC is that again?

RFC 2821, sec 2.3.1

  The content is textual in nature, expressed using the US-ASCII
  repertoire [1]. Although SMTP extensions (such as "8BITMIME" [20])
  may relax this restriction for the content body

exim violates this when generating bounces for mails which contain
e.g. umlauts in the cited part[1]



Enrico

Footnotes: 
[1]  http://thread.gmane.org/gmane.mail.exim.user/74841

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/165100d6/attachment.sig>

From dtimms at iinet.net.au  Sun Oct 14 09:57:07 2007
From: dtimms at iinet.net.au (David Timms)
Date: Sun, 14 Oct 2007 19:57:07 +1000
Subject: does this mean anything to anyone?
In-Reply-To: <8ADEE648D981EF47A23B6E1334BEBA610256F103@brisbane04.sunwater.com.au>
References: <8ADEE648D981EF47A23B6E1334BEBA610256F103@brisbane04.sunwater.com.au>
Message-ID: <4711E7F3.3020803@iinet.net.au>

Holder, Bill wrote:
> BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted)
>  [<c042b0cf>] local_bh_enable+0x45/0x92
>  [<c06002bd>] cond_resched_softirq+0x2c/0x42
>  [<c059adf3>] release_sock+0x4f/0x9d
>  [<c05c670d>] tcp_sendmsg+0x90b/0x9f9
>  [<c04808a3>] core_sys_select+0x1df/0x2f3
>  [<c05dec95>] inet_sendmsg+0x3b/0x45
>  [<c0598731>] sock_aio_write+0xf6/0x102
>  [<c045da36>] get_page_from_freelist+0x23b/0x2a5
>  [<c04754ee>] do_sync_write+0xc7/0x10a
>  [<c0436e71>] autoremove_wake_function+0x0/0x35
>  [<c0475d47>] vfs_write+0xbc/0x154
>  [<c0476342>] sys_write+0x41/0x67
>  [<c0404f70>] syscall_call+0x7/0xb
> 
> this is the last message in the dmesg log after a clean boot. I know
> it's probably not enough info to tell anything, but if it's nothing to
> worry about I'm not going to start turning debugs and dumps etc on.
kernel version {uname -a} ?

DaveT.



From dwmw2 at infradead.org  Sun Oct 14 11:29:35 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 14 Oct 2007 12:29:35 +0100
Subject: gethostby* users
In-Reply-To: <471175CA.7090708@gmail.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>
	<1192331600.3015.4.camel@localhost.localdomain>
	<471175CA.7090708@gmail.com>
Message-ID: <1192361375.3015.10.camel@localhost.localdomain>

On Sat, 2007-10-13 at 20:50 -0500, Les Mikesell wrote:
> These slides give the whole story but the big things are that you can do 
> anything you want by writing a small amount of perl code, the scanning 
> processes don't run under the same uid as the mailer, and it is very 
> efficient.

Looks like it's just trying to provide sendmail with the kind of
functionality which is built in to Exim. I find Exim's ACL language much
easier to use than perl, because it's actually designed for processing
email. And of course you can call out to separate scanning processes
(running with their own uid) such as spamd, clamd etc. 

-- 
dwmw2



From rc040203 at freenet.de  Sun Oct 14 11:33:50 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 14 Oct 2007 13:33:50 +0200
Subject: rpmbuild -bp and BR:
In-Reply-To: <20071013150623.GA2657@free.fr>
References: <20071012143614.10531202@reaver.lamontpeterson.net>
	<20071012144235.71b7409f@reaver.lamontpeterson.net>
	<1192256739.3208.45.camel@ignacio.lan>
	<1192285263.3500.70.camel@mccallum.corsepiu.local>
	<20071013150623.GA2657@free.fr>
Message-ID: <1192361630.3500.83.camel@mccallum.corsepiu.local>

On Sat, 2007-10-13 at 17:06 +0200, Patrice Dumas wrote:
> On Sat, Oct 13, 2007 at 04:21:03PM +0200, Ralf Corsepius wrote:
> > On Sat, 2007-10-13 at 02:25 -0400, Ignacio Vazquez-Abrams wrote:
> > > On Fri, 2007-10-12 at 14:42 -0600, Lamont Peterson wrote:
> > > > OK.  I wrote that before actually installing the packages and then went on and
> > > > discovered that "autoreconf" was being run at the end of %prep.  Shouldn't
> > > > something like that be in the beginning of %build instead?
> > > 
> > > Yes. Log a bug please.
> > No. autoreconf belongs into %prep, not into build.
> 
> Although I also prefer myself when autoreconf or the like is in %prep, I
> think that it should be left to the packager.
Well, I disagree. The autotools are supposed to be run in advance to
building. Not as part of a build-process.

Ralf




From hughsient at gmail.com  Sun Oct 14 11:56:49 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 14 Oct 2007 12:56:49 +0100
Subject: Making PackageKit work with pirut and pup
Message-ID: <1192363009.24022.20.camel@hughsie-laptop>

I've come across a problem: The aim is for a user to be able to install
either:

* system-config-printer, pirut and yum
* system-config-printer, PackageKit and yum
* system-config-printer, PackageKit, pirut and yum

Unfortunately system-config-printer hardcodes:

Requires: pirut

when it should probably either
"Require: /usr/sbin/system-install-packages" or require some other
identifier that both PackageKit and pirut could provide.

I don't think PackageKit can just "Provide: pirut 1.1.4" as this
prevents us installing both pirut and PackageKit, nor can we just do
"Obsoletes: pirut, Provides: Pirut" in the PackageKit spec file.

If system-config-printer requires /usr/sbin/system-install-packages then
we should probably use alternatives so that PackageKit and pirut can
both provide this file.

Advice on how to patch s-c-p and also how to setup alternatives is
welcomed. I can't really submit PackageKit into the fedora repo until
this issue is fixed.

Thanks!

Richard.




From alan at redhat.com  Sun Oct 14 12:00:43 2007
From: alan at redhat.com (Alan Cox)
Date: Sun, 14 Oct 2007 08:00:43 -0400
Subject: gethostby* users
In-Reply-To: <1192331600.3015.4.camel@localhost.localdomain>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<47116702.10604@gmail.com>
	<1192331600.3015.4.camel@localhost.localdomain>
Message-ID: <20071014120043.GA9146@devserv.devel.redhat.com>

On Sun, Oct 14, 2007 at 04:13:19AM +0100, David Woodhouse wrote:
> RFC3464 MIME bounces were a better example, although I still don't
> really see the point in them. Probably worth implementing though, just
> for completeness.

MIME bounces need great care as for many countries the bounce needs
to meet accessibility rules - MIME bounces can but not all do.



From mike at miketc.com  Sun Oct 14 12:26:03 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 14 Oct 2007 07:26:03 -0500
Subject: Echo icons missing
In-Reply-To: <1192260010.471071aae3ead@ssl.mecca.ca>
References: <1192227128.2260.1.camel@scrappy.miketc.com>
	<1192260010.471071aae3ead@ssl.mecca.ca>
Message-ID: <1192364763.14410.3.camel@scrappy.miketc.com>

On Sat, 2007-10-13 at 03:20 -0400, Luya Tshimbalanga wrote:
> Quoting Mike Chambers <mike at miketc.com>:
> 
> > I noticed over the last couple days, a couple of icons from echo-theme
> > have resorted back to the gnome icons?  The file manager and xchat icons
> > changed it seems to the big two drawer cabinet and the big X.
> >
> > Any ideas?
> 
> Strange. I have not seen that problem with File Manager. I can't tell with xchat
> icon. Both icons were not "echofied" yet. Could you post a screenshot?

File size little big, so go to the URL below to view the screen shot,
notice bottom left as my panel isn't where the installed one is...

http://www.miketc.com/Screenshot.png

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From dwmw2 at infradead.org  Sun Oct 14 13:04:57 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 14 Oct 2007 14:04:57 +0100
Subject: gethostby* users
In-Reply-To: <20071014120043.GA9146@devserv.devel.redhat.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>
	<47116702.10604@gmail.com>
	<1192331600.3015.4.camel@localhost.localdomain>
	<20071014120043.GA9146@devserv.devel.redhat.com>
Message-ID: <1192367097.13901.51.camel@pmac.infradead.org>

On Sun, 2007-10-14 at 08:00 -0400, Alan Cox wrote:
> MIME bounces need great care as for many countries the bounce needs
> to meet accessibility rules - MIME bounces can but not all do.

AFAICT the biggest 'accessibility' problem with bounces is the fact that
the recipients' brains tend to shut down when faced with them, and they
don't even bother to _read_ the reason for the bounce. I don't foresee a
technical fix for that :)

-- 
dwmw2



From benny+usenet at amorsen.dk  Sun Oct 14 13:53:24 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sun, 14 Oct 2007 15:53:24 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
	<20071013214206.GA20157@orient.maison.lan>
Message-ID: <m3bqb1950r.fsf@ursa.amorsen.dk>

>>>>> "ES" == Emmanuel Seyman <emmanuel.seyman at club-internet.fr> writes:

ES> I believe* you just need to copy the iso to the key and, during
ES> the first steps of install, select "Hard drive installation" then
ES> point Anaconda to the partition and directory where the iso is
ES> located.

I can't boot from the same key then, which rather defeats the purpose.
And if I dd boot.img to the key after putting the iso file on, I
overwrite the beginning of the iso image.


/Benny




From benny+usenet at amorsen.dk  Sun Oct 14 13:56:00 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sun, 14 Oct 2007 15:56:00 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
	<47113775.1090805@filteredperception.org>
Message-ID: <m37ilp94wf.fsf@ursa.amorsen.dk>

>>>>> "DM" == Douglas McClendon <dmc.fedora at filteredperception.org> writes:

DM> I.e. on the simple end, would be turning the above process into an
DM> easy to use GUI. On the more complex end, you could do something
DM> like using grub2's loopback feature and modifications to the
DM> install DVD's initramfs, to support something more like what you
DM> were suggesting.

How about someone simply making a Fedora Everything spin for USB keys,
and share that with bittorrent? Anyone up for it?

Not a Live image, but a good old-fashioned installation image.


/Benny




From paul at all-the-johnsons.co.uk  Sun Oct 14 14:59:39 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 14 Oct 2007 15:59:39 +0100
Subject: Co-maintaining mono packages
In-Reply-To: <20071012174931.6a4a7371@redhat.com>
References: <1191578779.4199.11.camel@T7.Linux>
	<20071012174931.6a4a7371@redhat.com>
Message-ID: <1192373979.3516.1.camel@T7.Linux>

Hi,

> > Currently, mono in rawhide is dropping behind the actual releases
> 
> That could be because we're past the Feature Freeze and we're not
> supposed to be doing builds which introduce features, just fix bugs.

Sure

> Given that your build attempt failed, perhaps you should wait on this
> upgrade until after Fedora 8 is released and it can get some proper
> time in updates-testing, or better yet target Fedora 9 for the new
> version and work out the issues there?

When is F8 out?

TTFN

Paul

-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- 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/20071014/e0ed7905/attachment.sig>

From dan at danny.cz  Sun Oct 14 15:23:32 2007
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 14 Oct 2007 17:23:32 +0200
Subject: Co-maintaining mono packages
In-Reply-To: <1192373979.3516.1.camel@T7.Linux>
References: <1191578779.4199.11.camel@T7.Linux>
	<20071012174931.6a4a7371@redhat.com> <1192373979.3516.1.camel@T7.Linux>
Message-ID: <1192375412.4270.5.camel@eagle.danny.cz>


> > Given that your build attempt failed, perhaps you should wait on this
> > upgrade until after Fedora 8 is released and it can get some proper
> > time in updates-testing, or better yet target Fedora 9 for the new
> > version and work out the issues there?
> 
> When is F8 out?

8.11. (see http://fedoraproject.org/wiki/Releases/8/Schedule), but you
can request F-8 branch (current devel will be cloned to F8), so you can
work in devel, that will later become F9


		Dan




From loupgaroublond at gmail.com  Sun Oct 14 15:26:45 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Sun, 14 Oct 2007 11:26:45 -0400
Subject: Making PackageKit work with pirut and pup
In-Reply-To: <1192363009.24022.20.camel@hughsie-laptop>
References: <1192363009.24022.20.camel@hughsie-laptop>
Message-ID: <7f692fec0710140826oc0aa8c0mba1e01cb0f48a35b@mail.gmail.com>

On 10/14/07, Richard Hughes <hughsient at gmail.com> wrote:
> I've come across a problem: The aim is for a user to be able to install
> either:
>
> * system-config-printer, pirut and yum
> * system-config-printer, PackageKit and yum
> * system-config-printer, PackageKit, pirut and yum
>
> Unfortunately system-config-printer hardcodes:
>
> Requires: pirut
>
> when it should probably either
> "Require: /usr/sbin/system-install-packages" or require some other
> identifier that both PackageKit and pirut could provide.
>
> I don't think PackageKit can just "Provide: pirut 1.1.4" as this
> prevents us installing both pirut and PackageKit, nor can we just do
> "Obsoletes: pirut, Provides: Pirut" in the PackageKit spec file.
>
> If system-config-printer requires /usr/sbin/system-install-packages then
> we should probably use alternatives so that PackageKit and pirut can
> both provide this file.
>
> Advice on how to patch s-c-p and also how to setup alternatives is
> welcomed. I can't really submit PackageKit into the fedora repo until
> this issue is fixed.

system-standard-package-manager?

I'm not sure how open Fedora is to this naming scheme, but in Debian,
alot of packages provide things like system-www-browser and
system-terminal, or similar names.  I'm not booted up into debian atm,
so i can't tell you what they are exactly.  The goal is for the admin
to define a default editor, and in a university or other setting, the
default editor can be emacs or vi for everything, or even nano,
because that's what they taught all the students to use.

-Yaakov



From lesmikesell at gmail.com  Sun Oct 14 15:27:05 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 14 Oct 2007 10:27:05 -0500
Subject: gethostby* users
In-Reply-To: <1192361375.3015.10.camel@localhost.localdomain>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>	<1192331600.3015.4.camel@localhost.localdomain>	<471175CA.7090708@gmail.com>
	<1192361375.3015.10.camel@localhost.localdomain>
Message-ID: <47123549.8010207@gmail.com>

David Woodhouse wrote:
> On Sat, 2007-10-13 at 20:50 -0500, Les Mikesell wrote:
>> These slides give the whole story but the big things are that you can do 
>> anything you want by writing a small amount of perl code, the scanning 
>> processes don't run under the same uid as the mailer, and it is very 
>> efficient.
> 
> Looks like it's just trying to provide sendmail with the kind of
> functionality which is built in to Exim.

I doubt that Exim can match perl's functionality in the general case... 
How much does it know about MIME?

> I find Exim's ACL language much
> easier to use than perl, because it's actually designed for processing
> email.

I've never enjoyed having to learn a new language for every task.  I 
suppose reusable code is a matter of taste.  In fact, all the normal 
operations are supplied as perl subroutines so the part you customize 
consists of a few lines to call the subroutines in the right order and 
respond according to the returned values.  For example, if you are 
running MimeDefang on a rely machine that doesn't have the user base, 
there is a routine supplied to check via smtp that the user exists on 
the delivery server before responding to the sender's recipient check. 
Also, per the name, MimeDefang splits out the mail parts into files once 
and optionally unzips zipped attachments (using a re-usable CPAN module, 
of course) so that the subsequent multiple passes of spam and virus 
scans don't have to repeat this work.

> And of course you can call out to separate scanning processes
> (running with their own uid) such as spamd, clamd etc. 

Spamassassin, being perl itself, is more efficiently run inside the 
MimeDefang process.  For clamd, it passes the location of the unpacked 
files over the socket.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From ivazqueznet at gmail.com  Sun Oct 14 16:40:09 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 14 Oct 2007 12:40:09 -0400
Subject: Making PackageKit work with pirut and pup
In-Reply-To: <7f692fec0710140826oc0aa8c0mba1e01cb0f48a35b@mail.gmail.com>
References: <1192363009.24022.20.camel@hughsie-laptop>
	<7f692fec0710140826oc0aa8c0mba1e01cb0f48a35b@mail.gmail.com>
Message-ID: <1192380009.3208.53.camel@ignacio.lan>

On Sun, 2007-10-14 at 11:26 -0400, Yaakov Nemoy wrote:
> I'm not sure how open Fedora is to this naming scheme...

Fedora already uses virtual provides in several cases:

webclient (firefox, dillo, etc.)
smtpdaemon (sendmail, postfix, etc.)

And a few more, I'm sure.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071014/ba55c6f8/attachment.sig>

From drepper at redhat.com  Sun Oct 14 16:56:03 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sun, 14 Oct 2007 09:56:03 -0700
Subject: gethostby* users
In-Reply-To: <1192296242.20815.29.camel@localhost.localdomain>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>
	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>	<1192293287.20815.3.camel@localhost.localdomain>	<4710F446.1000402@redhat.com>
	<1192296242.20815.29.camel@localhost.localdomain>
Message-ID: <47124A23.3080707@redhat.com>

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

Simo Sorce wrote:
> Now if you reorder these addresses what happen is that the main site A
> clients will always try to contact the branch office servers instead, as
> they have 'site-local' ones.

Why would we reorder?  This is not a given.  First, if the local network
addresses have a longer matching prefix it is automatically preferred.
Second, even if somebody is in the situation where somebody bad a bad
decision that this is not the case (e.g., always remember a machine can
have more than one IP address) you can overwrite the default preferences
getaddrinfo uses for sorting using /etc/gai.conf.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEkoj2ijCOnn/RHQRArTbAJ0RKAKykT5dvBOwZXXtP7xkV+69HQCgt1bd
yHN+OB2pGt1+8mZ3puyKJQk=
=euZA
-----END PGP SIGNATURE-----



From hughsient at gmail.com  Sun Oct 14 16:58:15 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 14 Oct 2007 17:58:15 +0100
Subject: Making PackageKit work with pirut and pup
In-Reply-To: <1192380009.3208.53.camel@ignacio.lan>
References: <1192363009.24022.20.camel@hughsie-laptop>
	<7f692fec0710140826oc0aa8c0mba1e01cb0f48a35b@mail.gmail.com>
	<1192380009.3208.53.camel@ignacio.lan>
Message-ID: <1192381095.29109.8.camel@hughsie-laptop>

On Sun, 2007-10-14 at 12:40 -0400, Ignacio Vazquez-Abrams wrote:
> Fedora already uses virtual provides in several cases:
> 
> webclient (firefox, dillo, etc.)
> smtpdaemon (sendmail, postfix, etc.)

What about using "systeminstaller"?

Richard.




From drepper at redhat.com  Sun Oct 14 17:03:35 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sun, 14 Oct 2007 10:03:35 -0700
Subject: gethostby* users
In-Reply-To: <47112448.6010106@gmail.com>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>
	<47112448.6010106@gmail.com>
Message-ID: <47124BE7.9070503@redhat.com>

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

Les Mikesell wrote:
> But, if they
> resort the list, half of them will pick the wrong first choice even when
> it is reachable.

No.  The sorting performed is not a universal and complete ordering.
For once, it depends on the addresses of the client machines.  Second,
if all target addresses are equally "bad" (i.e., for IPv4, all have the
same matching prefix length) the sorting will not change the order in
which the entries are returned.  Hence the RR DNS will not lose its effect.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEkvn2ijCOnn/RHQRAsdnAKDB8e+K2Ev6XkceFgN90v64kbNpcgCgxH/S
6/J//0HcWfLfGQNdmw3Y9nY=
=vqs4
-----END PGP SIGNATURE-----



From drepper at redhat.com  Sun Oct 14 17:05:39 2007
From: drepper at redhat.com (Ulrich Drepper)
Date: Sun, 14 Oct 2007 10:05:39 -0700
Subject: gethostby* users
In-Reply-To: <20071013235755.GA1497083@hiwaay.net>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>
	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>	<1192293287.20815.3.camel@localhost.localdomain>	<4710F446.1000402@redhat.com>
	<20071013235755.GA1497083@hiwaay.net>
Message-ID: <47124C63.4090203@redhat.com>

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

Chris Adams wrote:
> Have you read it?  Once again, it is about IPv6.  [...]

Everything, but really everything, you say is complete garbage.  People
like you are the reason I try my hardest to avoid having anything to do
with Fedora development.  Go, dig a hole and sit in it.  It's a more
worthwhile use of your time.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHEkxj2ijCOnn/RHQRAgCMAJ4o9nZ6oz2KzSLSaf6k6V/t7Br7gwCeL0Mj
9IuJ7VHkoHGmNRSxc6FE3jA=
=dhSg
-----END PGP SIGNATURE-----



From dcbw at redhat.com  Sun Oct 14 17:28:21 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 14 Oct 2007 13:28:21 -0400
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <ferboh$ok2$1@ger.gmane.org>
References: <200710111755.02714.singularitaet@gmx.net>
	<4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
	<ferboh$ok2$1@ger.gmane.org>
Message-ID: <1192382901.10377.0.camel@localhost.localdomain>

On Sat, 2007-10-13 at 17:02 -0400, sean darcy wrote:
> Tom London wrote:
> > On 10/11/07, Stefan Grosse <singularitaet at gmx.net> wrote:
> >> After the rawhide update of today, October 10th the Network Manager seems to
> >> be broken in a way that it interrupts my internet connection completely. I
> >> cannot activate eth0 manually. Internet works only if the networkmanager is
> >> not loaded on startup.
> >>
> >> I have an Asus A8Js notebook with intel 3945 for wlan and for wired I have:
> >> a realtek (pci, r8169, NETWORK, RTL8111/8168B PCI Express Gigabit) Ethernet
> >> controller.
> >>
> >> Stefan
> >>
> > Believe these version of NM allows configurable 'auto connection'.
> > 
> > My would come up with no network connection, but I could manually
> > select it from the nm-applet.
> > 
> > Applications->System Tools->Configuration Editor allows setting
> > 'autoconnect' for each connection.--
> > 
> > For me, this was 'system->networking->connections->1->connection->autoconnect'
> > 
> 
> I do not see "networking" under system the the Configuration Editor. I 
> have NM, NM-gnome, NM-glib installed.
> 
> Am I missing something? Hope so, cause NM is really messing me up.

You'll only get something there if you've tried to connect to a network
before with the applet.

Dan



From dgboles at gmail.com  Sun Oct 14 17:31:10 2007
From: dgboles at gmail.com (David Boles)
Date: Sun, 14 Oct 2007 13:31:10 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <m37ilp94wf.fsf@ursa.amorsen.dk>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<m3fy0e92wl.fsf@ursa.amorsen.dk>	<47113775.1090805@filteredperception.org>
	<m37ilp94wf.fsf@ursa.amorsen.dk>
Message-ID: <4712525E.2010906@gmail.com>

on 10/14/2007 9:56 AM, Benny Amorsen wrote:
>>>>>> "DM" == Douglas McClendon <dmc.fedora at filteredperception.org> writes:
> 
> DM> I.e. on the simple end, would be turning the above process into an
> DM> easy to use GUI. On the more complex end, you could do something
> DM> like using grub2's loopback feature and modifications to the
> DM> install DVD's initramfs, to support something more like what you
> DM> were suggesting.
> 
> How about someone simply making a Fedora Everything spin for USB keys,
> and share that with bittorrent? Anyone up for it?
> 
> Not a Live image, but a good old-fashioned installation image.


I don't know that I have ever seen a 9 Gig USB keys. Where did you get yours?
-- 

  David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/82effb7b/attachment.sig>

From rwwyatt01 at gmail.com  Sun Oct 14 17:34:24 2007
From: rwwyatt01 at gmail.com (Randy Wyatt)
Date: Sun, 14 Oct 2007 10:34:24 -0700
Subject: gethostby* users
In-Reply-To: <47124C63.4090203@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
	<4710F446.1000402@redhat.com> <20071013235755.GA1497083@hiwaay.net>
	<47124C63.4090203@redhat.com>
Message-ID: <34e52d0c0710141034g566b0a82pd0efa5bb1e958143@mail.gmail.com>

On 10/14/07, Ulrich Drepper <drepper at redhat.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris Adams wrote:
> > Have you read it?  Once again, it is about IPv6.  [...]
>
> Everything, but really everything, you say is complete garbage.  People
> like you are the reason I try my hardest to avoid having anything to do
> with Fedora development.  Go, dig a hole and sit in it.  It's a more
> worthwhile use of your time.



Ulrich,
  I have a great respect for your knowledge and general contribution,  but
please avoid personal attacks on the mailing list.  The above email was best
sent privately to the individual.

Best Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/f0172b62/attachment.htm>

From buildsys at redhat.com  Sun Oct 14 17:40:36 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 14 Oct 2007 13:40:36 -0400
Subject: rawhide report: 20071014 changes
Message-ID: <200710141740.l9EHeahP027243@porkchop.devel.redhat.com>

New package nbd
	Network Block Device user-space tools (TCP version)


 
Updated Packages:

eclipse-rpm-editor-0.1.0-10.fc8
-------------------------------
* Sun Oct 14 2007 Alphonse Van Assche <alcapcom at fedoraproject.org> 0.1.0-10
- Just tag the sources correctly.

* Sun Oct 14 2007 Alphonse Van Assche <alcapcom at fedoraproject.org> 0.1.0-9
- Fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=206160
- Fix https://bugzilla.redhat.com/show_bug.cgi?id=327101

* Mon Sep 24 2007 Alphonse Van Assche <alcapcom at fedoraproject.org> 0.1.0-8
- Fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=204146
- Fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=204150

escape-200704130-6.fc8
----------------------
* Fri Oct 12 2007 Adam Goode <adam at spicenitz.org> - 200704130-6
- Fix update problem with symlinks

funtools-1.4.0-2.fc8
--------------------
* Sat Oct 13 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 1.4.0-2
- Fixing bug #329741
- Splitting libs in funtools-libs

jhead-2.7-2.fc8
---------------
* Sat Oct 13 2007 Adrian Reber <adrian at lisas.de> - 2.7-2
- rebuilt for BuildID

kdeaccessibility-1:3.5.8-2.fc8
------------------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 1:3.5.8-2
- Obsoletes: %name-devel

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 1:3.5.8-1
- kde-3.5.8
- omit -devel subpkg

kdeadmin-7:3.5.8-1.fc8
----------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-1
- kde-3.5.8

* Mon Aug 20 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.7-3
- License: GPLv2
- (Build)Requires: kdelibs3(-devel)
- drop Requires: kdebase

* Sat Jun 16 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.7-2
- update knetworkconf patch
- portability (rhel) bits

kdeedu-3.5.8-1.fc8
------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-1
- kde-3.5.8
- License: GPLv2
- libs subpkg (more multilib friendly)

kdegraphics-7:3.5.8-1.fc8
-------------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-1
- kde-3.5.8
- libs subpkg (more multilib friendly)

kdemultimedia-6:3.5.8-1.fc8
---------------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-1
- kde-3.5.8
- -libs, -extras-libs subpkg (more multilib friendly)

kdetoys-7:3.5.8-1.fc8
---------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 7:3.5.8-1
- kde-3.5.8

kdeutils-6:3.5.8-2.fc8
----------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-2
- kde-3.5.8
- omit -devel subpkg

libwpd-0.8.12-1.fc8
-------------------
* Sat Oct 13 2007 Caolan McNamara <caolanm at redhat.com> - 0.8.12-1
- next version

moodss-21.5-2.fc8
-----------------
* Sat Sep 29 2007 Jean-Luc Fontaine <jfontain at free.fr> 21.5-2
- moved to GPLv2 and require sqlite-tcl

nss_compat_ossl-0.9.2-3.fc8
---------------------------
* Sat Oct 13 2007 Rob Crittenden <rcritten at redhat.com> 0.9.2-3
- Bugzilla #330091, don't explicitly link with libsoftokn3.so

openoffice.org-1:2.3.0-6.3.fc8
------------------------------
* Fri Oct 12 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.3
- reenable prelink-optimized launchers
- rhbz#326161 make code compiled with icedtea compatible with 1.5.0 so libgcj
  can still be selected as a jvm
- add openoffice.org-2.3.0.ooo53885.raiseannotationpriority.sw.patch

* Sun Oct 07 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.2
- reenable visibility again now that guard visibility is sane again

python-alsa-1.0.15-0.4.rc2.fc8
------------------------------
* Sun Oct 14 2007 Andy Shevchenko <andy at smile.org.ua> 1.0.15-0.4.rc2
- require at least ALSA 1.0.15
rsync-2.6.9-3.2.fc8
-------------------
* Sat Oct 13 2007 Simo Sorce <ssorce at redhat.com> 2.6.9-3.2.fc8
- Add flags = IPv6 to rsync.xinetd (bz#330301)

selinux-policy-3.0.8-22.fc8
---------------------------
* Fri Oct 12 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-22
- Pass the UNK_PERMS param to makefile
- Fix gdm location

wine-docs-0.9.47-1.fc8
----------------------
* Sun Oct 14 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.47-1
- version upgrade

xlockmore-5.24-1.fc8
--------------------
* Sat Oct 13 2007 Adrian Reber <adrian at lisas.de> - 5.24-1
- updated to 5.24

xpa-2.1.7-0.3.b2.fc8
--------------------
* Sat Oct 13 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 2.1.7-0.3.b2
- Splitted libraries in a new package

Broken deps for i386
----------------------------------------------------------
	kdeaddons-extras - 3.5.7-6.fc8.i386 requires libnoatunarts.so
	kdemultimedia-extras - 6:3.5.8-1.fc8.i386 requires libnoatunarts.so
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.i386 requires libnoatunarts.so
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kdeaddons-extras - 3.5.7-6.fc8.x86_64 requires libnoatunarts.so()(64bit)
	kdemultimedia-extras - 6:3.5.8-1.fc8.x86_64 requires libnoatunarts.so()(64bit)
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.i386 requires libnoatunarts.so
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.x86_64 requires libnoatunarts.so()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kdeaddons-extras - 3.5.7-6.fc8.ppc requires libnoatunarts.so
	kdemultimedia-extras - 6:3.5.8-1.fc8.ppc requires libnoatunarts.so
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.ppc requires libnoatunarts.so
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.ppc64 requires libnoatunarts.so()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	python-vcpx - 0.9.28-4.fc8.noarch requires monotone
	wammu - 0.19-3.fc8.noarch requires python-gammu



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	kdeaddons-extras - 3.5.7-6.fc8.ppc64 requires libnoatunarts.so()(64bit)
	kdemultimedia-extras - 6:3.5.8-1.fc8.ppc64 requires libnoatunarts.so()(64bit)
	kdemultimedia-extras-libs - 6:3.5.8-1.fc8.ppc64 requires libnoatunarts.so()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	wammu - 0.19-3.fc8.noarch requires python-gammu
	xorg-x11-drivers - 7.2-8.fc8.ppc64 requires synaptics





From singularitaet at gmx.net  Sun Oct 14 17:53:34 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Sun, 14 Oct 2007 19:53:34 +0200
Subject: Network Manager 0.7.0-0.3.svn2970 broken?!
In-Reply-To: <ferboh$ok2$1@ger.gmane.org>
References: <200710111755.02714.singularitaet@gmx.net>
	<4c4ba1530710111059k1f39ea01yae4901cf67a68e9@mail.gmail.com>
	<ferboh$ok2$1@ger.gmane.org>
Message-ID: <200710141953.35033.singularitaet@gmx.net>

On Saturday 13 October 2007 11:02:09 pm sean darcy wrote:
> I do not see "networking" under system the the Configuration Editor. I
> have NM, NM-gnome, NM-glib installed.
>
> Am I missing something? Hope so, cause NM is really messing me up.

you do not need to edit there something. for me it worked to close nm-applet 
and then start it again manually. After having started it manually it did 
work for me. 

Stefan



From cmadams at hiwaay.net  Sun Oct 14 17:54:12 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 14 Oct 2007 12:54:12 -0500
Subject: gethostby* users
In-Reply-To: <47124C63.4090203@redhat.com>
References: <1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
	<4710F446.1000402@redhat.com> <20071013235755.GA1497083@hiwaay.net>
	<47124C63.4090203@redhat.com>
Message-ID: <20071014175412.GA1383702@hiwaay.net>

Once upon a time, Ulrich Drepper <drepper at redhat.com> said:
> Chris Adams wrote:
> > Have you read it?  Once again, it is about IPv6.  [...]
> 
> Everything, but really everything, you say is complete garbage.

Please point me to the section in the cited RFC that defines sorting
IPv4 addresses in an IPv4-only environment.

Please cite the part of ANY SUSv3 or OS man page that says anything
about address sorting.

> Go, dig a hole and sit in it.  It's a more
> worthwhile use of your time.

Now THERE's are useful comment.
-- 
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 fedora at leemhuis.info  Sun Oct 14 18:02:06 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 14 Oct 2007 20:02:06 +0200
Subject: EPEL report week 41 2007
Message-ID: <4712599E.30403@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week41

----
= Weekly EPEL Summary =

Week 41/2007

== Most important happenings ==

 * in the ongoing effort to do more on the list and less in the meeting
the EPEL SIG will switch to bi-weekly meetings; next meeting therefor
will be on 20071024 (e.g. 10 days from the time when this got published)!

== EPEL SIG Meeting ==

=== Attending ===

 * [:JeffSheltren:Jeff_S]
 * [:JeremyKatz:jeremy]
 * [:ThorstenLeemhuis:knurd]
 * [:MikeMcGrath:mmcgrath]
 * [:KevinFenzi:nirik]
 * [:SethVidal:skvidal]
 * [:MichaelStahnke:stahnma]

=== Summary ===


 * http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove --
unassigned; nirik?

  * mmcgrath will make sure will cron the script that checks for missing
deps in testing

  * nirik hasn't had a chance to look at testing lately but will do over
the next few days; the plan is to do the testing -> stable move on (or
around the) 21th this month

  * the big thing is that we want to get broken deps fixed up in testing
before any move; OTOH we can leave some things in testing if we want;
but we should work towards a proper testing repo without broken deps in
general as well, as broken deps look bad even in testing

 * http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51  -- knurd/nirik

  * we have no eta on 5.1 (well, we have one: jeremy> | "when it's done")

 * http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma

  * not much moving here; "stahnma_> | I will send out a query on list"

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- update.carefully
file in CVS?

  * we had a problem with sqlite -- the Fedora maintainer updated the
EL4 package; it would have replaced the CentOS package, which we try to
avoid; packages was withdrawn from push-queue; maintainer who did the
update was not aware of the "we ship sqlite in EL4 with a lower EVR then
in CentOS" agreement

  * Jeff_S  will place a file called "UPDATE-CAREFULLY" file with some
explanations in it in the CVS dir of that handful of packages that are
in CentOS-base and not in EL; that should serve as a hint for the
maintainers and hopefully avoid such things in the future.

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- yum-cron -- knurd

  * knurd talked to the CentOS maintainer of yum-cron; things hopefully
should be solved over the next few days

  * in case anybody wonders: yum-cron is in centos5-base similar to how
sqlite is in centos4-base (see above); but the situation is a bit
different here, as the Fedora package is kind of "upstream" for the
CentOS package afawcs; the Fedora package since CentOS took it got some
bugfixes and the maintainer and some other people think it would be best
for everyone if the improved version would make it into both CentoS as
update and into EPEL for those that want to use it on RHEL

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- permission to use
spec files in other projects

  * as said on the list: bring the issue up to the board again once F8
is out

 * a improved clamav for EPEL

  * nirik still considers to update clamav in EPEL (maybe use the one
from dag ["nirik> | the dag spec is much more sane than the fedora
one."] or a similar scheme); he just hasn't had time to move forward
with that...  Would anyone else be interested in working on that? Then
please speak up!

 * meetings

  * seem the meetings at 23:00 UTC don't work to well ("stahnma_> |
turns out, I like the daytime better; after all my complaining; :)")

  * maybe we should try to find a more dynamic schedule; maybe once a
month a later time; or something like that; and don't forget the general
target: do more on the list

  * we'll try meetings at 17:00 utc every second week for now; thus next
meeting on 20071024?

  * nevertheless do the status updates every week on the list, to make
sure things are moving forward

== Stats ==

=== General ===

Number of new EPEL Contributors: 0

=== EPEL 5 ===

Number of source packages: 690

Number of binary packages:  1333

There are 7 new Packages:

 * dirmngr | Client for Managing/Downloading CRLs
 * gnupg2 | Utility for secure communication and data storage
 * gpgme | GnuPG Made Easy - high level crypto API
 * libassuan | GnuPG IPC library
 * ntfs-config | A front-end to Enable/disable NTFS write support
 * pinentry | Collection of simple PIN or passphrase entry dialogs
 * pth | The GNU Portable Threads library

=== EPEL 4 ===

Number of source packages: 431

Number of binary packages:  874

There are 2 new Packages:

 * lyx | WYSIWYM (What You See Is What You Mean) document processor
 * pth | The GNU Portable Threads library

----
["CategoryEPELReports"]



From lesmikesell at gmail.com  Sun Oct 14 18:05:32 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 14 Oct 2007 13:05:32 -0500
Subject: gethostby* users
In-Reply-To: <1192348902.12099.1.camel@rousalka.dyndns.org>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>
	<1192348902.12099.1.camel@rousalka.dyndns.org>
Message-ID: <47125A6C.2020803@gmail.com>

Nicolas Mailhot wrote:
> Le samedi 13 octobre 2007 ? 19:46 -0500, Les Mikesell a ?crit :
>> David Woodhouse wrote:
>>> On Fri, 2007-10-12 at 08:02 -0500, Chris Adams wrote:
>>>> I know it is fun to pick on sendmail, but it works well and I can use
>>>> it to do things not easily done in some other MTAs.
>>> Examples?
>> Running MimeDefang is a good example.  MimeDefang runs as a milter
> 
> and other MTAs than sandmail support the milter interface (and they also
> have non-milter alternatives to MimeDefang)

As far as I know, none of the other MTA's are completely compatible with 
sendmail in the way (or whether) they expose details that the milter 
needs to know, like whether a message was accepted with smtp 
authentication and/or ssl encryption, so I don't think any will 
currently work with MimeDefang, although it might be possible with some 
work.   And the non-milter alternatives generally suffer from one or 
more of running under the mailer uid, starting a new process for each 
scan, making the whole process wait for slow operations, or only having 
the results after the smtp conversation is completed.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mclasen at redhat.com  Sun Oct 14 18:16:47 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Sun, 14 Oct 2007 14:16:47 -0400
Subject: Making PackageKit work with pirut and pup
In-Reply-To: <1192363009.24022.20.camel@hughsie-laptop>
References: <1192363009.24022.20.camel@hughsie-laptop>
Message-ID: <1192385807.2585.6.camel@localhost.localdomain>

On Sun, 2007-10-14 at 12:56 +0100, Richard Hughes wrote:
> I've come across a problem: The aim is for a user to be able to install
> either:
> 
> * system-config-printer, pirut and yum
> * system-config-printer, PackageKit and yum
> * system-config-printer, PackageKit, pirut and yum
> 
> Unfortunately system-config-printer hardcodes:
> 
> Requires: pirut
> 
> when it should probably either
> "Require: /usr/sbin/system-install-packages" or require some other
> identifier that both PackageKit and pirut could provide.
> 
> I don't think PackageKit can just "Provide: pirut 1.1.4" as this
> prevents us installing both pirut and PackageKit, nor can we just do
> "Obsoletes: pirut, Provides: Pirut" in the PackageKit spec file.
> 
> If system-config-printer requires /usr/sbin/system-install-packages then
> we should probably use alternatives so that PackageKit and pirut can
> both provide this file.
> 
> Advice on how to patch s-c-p and also how to setup alternatives is
> welcomed. I can't really submit PackageKit into the fedora repo until
> this issue is fixed.
> 

I think using alternatives is probably the best we can do for now.
Unfortunately, it seems that the packaging guidelines contain no details
on how to properly setup up a package for using alternatives (except for
a passing mention in
http://fedoraproject.org/wiki/Packaging/Conflicts ). One example I could
find quickly is in the cdrkit spec - I have no idea if it is a good
example, though.

But solving the system-install-packages problem should not block
PackageKit from entering the repo, I think. PackageKit is useful even if
it doesn't have system-install-packages yet.

Matthias



From lesmikesell at gmail.com  Sun Oct 14 18:20:58 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 14 Oct 2007 13:20:58 -0500
Subject: gethostby* users
In-Reply-To: <47124BE7.9070503@redhat.com>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>	<47112448.6010106@gmail.com>
	<47124BE7.9070503@redhat.com>
Message-ID: <47125E0A.1070403@gmail.com>

Ulrich Drepper wrote:

>> But, if they
>> resort the list, half of them will pick the wrong first choice even when
>> it is reachable.
> 
> No.  The sorting performed is not a universal and complete ordering.
> For once, it depends on the addresses of the client machines.  Second,
> if all target addresses are equally "bad" (i.e., for IPv4, all have the
> same matching prefix length)

I've not seen 'matching prefix length' to have anything to do with 
optimal route paths in practice other than the obvious case where one 
interface of a client is on the same subnet as one of the supplied IP's, 
which you can only determine by taking subnet masks into consideration.

 > the sorting will not change the order in
> which the entries are returned.  Hence the RR DNS will not lose its effect.

I don't object to putting same-subnet results first, but I'd want to see 
some real-world statistics before jumping to the conclusion that any 
other change is for the better.  I'd venture a guess that the majority 
of public DNS results are returned by 'intelligent' DNS servers that 
have already made some effort to give you the right choices in the right 
order.  Maybe we could at least ask someone at google if we need to 
second-guess their server results.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From joost at cnoc.nl  Sun Oct 14 18:32:25 2007
From: joost at cnoc.nl (Joost van der Sluis)
Date: Sun, 14 Oct 2007 20:32:25 +0200
Subject: Freepascal compiler inclusion of pre-build binary
Message-ID: <1192386745.22778.8.camel@wsjoost.cnoc.local>

Hi all,

When the fpc-package (Freepascal compiler) was approved, there were no
rules regarding pre-build binaries and compilers yet. But after some
discussion I got an approval to use them.

Now I want to add support for ppc64 but to do that, I need to use a
pre-build binary once more. The current packaging-guidelines state that
I need an approval from the packaging committee. 

So what should I do now, ask for an approval or isn't that necessary?

Regards,
Joost van der Sluis



From dennis at ausil.us  Sun Oct 14 18:45:28 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 14 Oct 2007 13:45:28 -0500
Subject: Freepascal compiler inclusion of pre-build binary
In-Reply-To: <1192386745.22778.8.camel@wsjoost.cnoc.local>
References: <1192386745.22778.8.camel@wsjoost.cnoc.local>
Message-ID: <200710141345.33285.dennis@ausil.us>

Once upon a time Sunday 14 October 2007, Joost van der Sluis wrote:
> Hi all,
>
> When the fpc-package (Freepascal compiler) was approved, there were no
> rules regarding pre-build binaries and compilers yet. But after some
> discussion I got an approval to use them.
>
> Now I want to add support for ppc64 but to do that, I need to use a
> pre-build binary once more. The current packaging-guidelines state that
> I need an approval from the packaging committee.
>
> So what should I do now, ask for an approval or isn't that necessary?
I think that since you initially got approval to use the prebuilt binary  to 
bootstrap fpc  that it should be ok.  What i would suggest though is putting 
the logic in the spec permanently to bootstrap other archs  and have a 
defines control that.  Once you have a build that has been bootstrapped.  
build a new version that is built against the fedora built fpc package.

Dennis

-------------- 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/20071014/99d03f5c/attachment.sig>

From joost at cnoc.nl  Sun Oct 14 19:34:24 2007
From: joost at cnoc.nl (Joost van der Sluis)
Date: Sun, 14 Oct 2007 21:34:24 +0200
Subject: Freepascal compiler inclusion of pre-build binary
In-Reply-To: <200710141345.33285.dennis@ausil.us>
References: <1192386745.22778.8.camel@wsjoost.cnoc.local>
	<200710141345.33285.dennis@ausil.us>
Message-ID: <1192390464.22778.11.camel@wsjoost.cnoc.local>

Op zondag 14-10-2007 om 13:45 uur [tijdzone -0500], schreef Dennis
Gilmore:
> Once upon a time Sunday 14 October 2007, Joost van der Sluis wrote:
> > Hi all,
> >
> > When the fpc-package (Freepascal compiler) was approved, there were no
> > rules regarding pre-build binaries and compilers yet. But after some
> > discussion I got an approval to use them.
> >
> > Now I want to add support for ppc64 but to do that, I need to use a
> > pre-build binary once more. The current packaging-guidelines state that
> > I need an approval from the packaging committee.
> >
> > So what should I do now, ask for an approval or isn't that necessary?
> I think that since you initially got approval to use the prebuilt binary  to 
> bootstrap fpc  that it should be ok.  What i would suggest though is putting 
> the logic in the spec permanently to bootstrap other archs  and have a 
> defines control that.  Once you have a build that has been bootstrapped.  
> build a new version that is built against the fedora built fpc package.

I deliberately removed all the prebuilt-binary stuff from the spec-file
after the first release. But maybe you're right. I can add it with a
define. That could be usefull in the future.

Joost



From dmc.fedora at filteredperception.org  Sun Oct 14 19:34:06 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 14 Oct 2007 14:34:06 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <m37ilp94wf.fsf@ursa.amorsen.dk>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<m3fy0e92wl.fsf@ursa.amorsen.dk>	<47113775.1090805@filteredperception.org>
	<m37ilp94wf.fsf@ursa.amorsen.dk>
Message-ID: <47126F2E.9070803@filteredperception.org>

Benny Amorsen wrote:
>>>>>> "DM" == Douglas McClendon <dmc.fedora at filteredperception.org> writes:
> 
> DM> I.e. on the simple end, would be turning the above process into an
> DM> easy to use GUI. On the more complex end, you could do something
> DM> like using grub2's loopback feature and modifications to the
> DM> install DVD's initramfs, to support something more like what you
> DM> were suggesting.
> 
> How about someone simply making a Fedora Everything spin for USB keys,
> and share that with bittorrent? Anyone up for it?

As the other responder mentioned, I'm assuming you don't really mean 
Everything (much as I was one of the longest hold-outs of keeping and 
using Everything installs).

But what I do think makes sense, is to have a LiveDVD spin that matches 
doing a * install of what is on the traditional install DVD spin.  And 
having a simple well advertised method for LiveCD-install users who have 
net access to upgrade to either that package set, or the 'defaults' 
package set from the traditional install DVD.  I.e. a button that says - 
change my system package set from the defaults that were chosen due to 
700MB livecd iso space constraint, to the package set from defaults that 
the smart fedora developers chose in a non 700MB space constrained 
situation.

> 
> Not a Live image, but a good old-fashioned installation image.

This is what I was discussing in part, and if I'm not mistaken, does 
require at least a bit of work to get working.  Certainly using the grub 
loopback feature is probably overkill since replicating the kernel and 
initrd in a usbstick situation is not a big deal.  But you do then still 
need to put smarts into the initramfs to deal with the fact that it may 
be looking for an iso on a vfat usbstick.  Not difficult by any means, 
but definitely a bit of work.

In general I agree that what you are asking for is worth doing for F9, 
and for F8 perhaps via tools that are available online.

-dmc



From j.w.r.degoede at hhs.nl  Sun Oct 14 19:44:52 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 14 Oct 2007 21:44:52 +0200
Subject: Freepascal compiler inclusion of pre-build binary
In-Reply-To: <1192390464.22778.11.camel@wsjoost.cnoc.local>
References: <1192386745.22778.8.camel@wsjoost.cnoc.local>	<200710141345.33285.dennis@ausil.us>
	<1192390464.22778.11.camel@wsjoost.cnoc.local>
Message-ID: <471271B4.6080905@hhs.nl>

Joost van der Sluis wrote:
> Op zondag 14-10-2007 om 13:45 uur [tijdzone -0500], schreef Dennis
> Gilmore:
>> Once upon a time Sunday 14 October 2007, Joost van der Sluis wrote:
>>> Hi all,
>>>
>>> When the fpc-package (Freepascal compiler) was approved, there were no
>>> rules regarding pre-build binaries and compilers yet. But after some
>>> discussion I got an approval to use them.
>>>
>>> Now I want to add support for ppc64 but to do that, I need to use a
>>> pre-build binary once more. The current packaging-guidelines state that
>>> I need an approval from the packaging committee.
>>>
>>> So what should I do now, ask for an approval or isn't that necessary?
>> I think that since you initially got approval to use the prebuilt binary  to 
>> bootstrap fpc  that it should be ok.  What i would suggest though is putting 
>> the logic in the spec permanently to bootstrap other archs  and have a 
>> defines control that.  Once you have a build that has been bootstrapped.  
>> build a new version that is built against the fedora built fpc package.
> 
> I deliberately removed all the prebuilt-binary stuff from the spec-file
> after the first release. But maybe you're right. I can add it with a
> define. That could be usefull in the future.
> 

This is what I've done to the (no binaries needed, but still a strange dance 
needed) bootstrap code for arm-gp2x-gcc & glibc. I think that this is best, as 
this for example will also allow the sparc people to boostrap it (well not in 
your case, but in mine).

Regards,

Hans



From debarshi.ray at gmail.com  Sun Oct 14 19:54:26 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 15 Oct 2007 01:24:26 +0530
Subject: PackageDB: mixed summary + description
Message-ID: <3170f42f0710141254v1bae8e37hfcabf71e4df79fe8@mail.gmail.com>

https://admin.fedoraproject.org/pkgdb/packages/name/catfish
https://admin.fedoraproject.org/pkgdb/packages/name/pinot

It seems that the summary and description are messed up with other packages.

Is this known or needs reporting?

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From louisg00 at bellsouth.net  Sun Oct 14 19:55:31 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 14 Oct 2007 15:55:31 -0400
Subject: libpciaccess in f8?
Message-ID: <1192391732.2688.5.camel@tiger>

Is libpciaccess a requirement in f8? Just did an update and libpciaccess
was pulled in by xorg-x11-drv-avivo. I thought avivo was superseded by
radeonhd?

-Louis



From nicolas.mailhot at laposte.net  Sun Oct 14 20:01:47 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 14 Oct 2007 22:01:47 +0200
Subject: gethostby* users
In-Reply-To: <47125A6C.2020803@gmail.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>
	<20071012130230.GA1451534@hiwaay.net>
	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>
	<1192348902.12099.1.camel@rousalka.dyndns.org>
	<47125A6C.2020803@gmail.com>
Message-ID: <1192392107.3133.1.camel@rousalka.dyndns.org>


Le dimanche 14 octobre 2007 ? 13:05 -0500, Les Mikesell a ?crit :

> As far as I know, none of the other MTA's are completely compatible with 
> sendmail in the way (or whether) they expose details that the milter 
> needs to know,

I won't pretend I know sendmail well enough to judge there?

> And the non-milter alternatives generally suffer from one or 
> more of 

? but you certainly do not know non-sendmail stuff either.

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

From dennis at ausil.us  Sun Oct 14 20:15:32 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 14 Oct 2007 15:15:32 -0500
Subject: Freepascal compiler inclusion of pre-build binary
In-Reply-To: <471271B4.6080905@hhs.nl>
References: <1192386745.22778.8.camel@wsjoost.cnoc.local>
	<1192390464.22778.11.camel@wsjoost.cnoc.local>
	<471271B4.6080905@hhs.nl>
Message-ID: <200710141515.39588.dennis@ausil.us>

Once upon a time Sunday 14 October 2007, Hans de Goede wrote:
> Joost van der Sluis wrote:

> >
> > I deliberately removed all the prebuilt-binary stuff from the spec-file
> > after the first release. But maybe you're right. I can add it with a
> > define. That could be usefull in the future.
>
> This is what I've done to the (no binaries needed, but still a strange
> dance needed) bootstrap code for arm-gp2x-gcc & glibc. I think that this is
> best, as this for example will also allow the sparc people to boostrap it
> (well not in your case, but in mine).
I already have it for sparc  but not sparc64,  alpha, arm, ia64  may want it 
also.

Dennis
-------------- 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/20071014/885e2997/attachment.sig>

From ssorce at redhat.com  Sun Oct 14 20:16:47 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 14 Oct 2007 16:16:47 -0400
Subject: gethostby* users
In-Reply-To: <47124A23.3080707@redhat.com>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net> <47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>
	<1192293287.20815.3.camel@localhost.localdomain>
	<4710F446.1000402@redhat.com>
	<1192296242.20815.29.camel@localhost.localdomain>
	<47124A23.3080707@redhat.com>
Message-ID: <1192393007.21735.12.camel@localhost.localdomain>

On Sun, 2007-10-14 at 09:56 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simo Sorce wrote:
> > Now if you reorder these addresses what happen is that the main site A
> > clients will always try to contact the branch office servers instead, as
> > they have 'site-local' ones.
> 
> Why would we reorder?  This is not a given.  First, if the local network
> addresses have a longer matching prefix it is automatically preferred.
> Second, even if somebody is in the situation where somebody bad a bad
> decision that this is not the case (e.g., always remember a machine can
> have more than one IP address) you can overwrite the default preferences
> getaddrinfo uses for sorting using /etc/gai.conf.

I wish you have read in full my email, but from your comment I see you
didn't :-(

I explained a very common situation and also explained you why gai.conf
is not a solution when you need different rules for different servers in
the same networks.

This was just an example that didn't involve Round Robin, as it is clear
that reordering just breaks any load balancer that uses DNS in a Round
Robin fashion ... and that should be enough to warrant _at least_ a way
to easily disable completely reordering for IPv4 addresses.

If you want getaddrinfo() to be adopted you need to help people use it,
forcibly reordering IPv4 addresses means a lot of clients simply can't
use it.

Simo.



From lesmikesell at gmail.com  Sun Oct 14 20:55:58 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 14 Oct 2007 15:55:58 -0500
Subject: gethostby* users
In-Reply-To: <1192392107.3133.1.camel@rousalka.dyndns.org>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>	<1192348902.12099.1.camel@rousalka.dyndns.org>	<47125A6C.2020803@gmail.com>
	<1192392107.3133.1.camel@rousalka.dyndns.org>
Message-ID: <4712825E.1040109@gmail.com>

Nicolas Mailhot wrote:
> Le dimanche 14 octobre 2007 ? 13:05 -0500, Les Mikesell a ?crit :
> 
>> As far as I know, none of the other MTA's are completely compatible with 
>> sendmail in the way (or whether) they expose details that the milter 
>> needs to know,
> 
> I won't pretend I know sendmail well enough to judge there?
> 
>> And the non-milter alternatives generally suffer from one or 
>> more of 
> 
> ? but you certainly do not know non-sendmail stuff either.

I used smail before it was abandoned; I've used qmail enough to hate it, 
tried postfix before it had anything resembling a milter, and always 
ended up going back to sendmail.  But, if anything else currently has 
the ability to manage customizable helper processes and multiplex jobs 
efficiently among them in a way that only requires mime and zip 
unpacking to be done onces even if you scan multiple times, I'd be happy 
to hear about it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From javert42 at cs.byu.edu  Sun Oct 14 21:15:52 2007
From: javert42 at cs.byu.edu (Topher)
Date: Sun, 14 Oct 2007 15:15:52 -0600
Subject: gethostby* users
In-Reply-To: <47124BE7.9070503@redhat.com>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>	<47112448.6010106@gmail.com>
	<47124BE7.9070503@redhat.com>
Message-ID: <47128708.2070104@cs.byu.edu>

Ulrich Drepper wrote:
> Les Mikesell wrote:
>> But, if they
>> resort the list, half of them will pick the wrong first choice even when
>> it is reachable.
> 
> No.  The sorting performed is not a universal and complete ordering.
> For once, it depends on the addresses of the client machines.  Second,
> if all target addresses are equally "bad" (i.e., for IPv4, all have the
> same matching prefix length) the sorting will not change the order in
> which the entries are returned.  Hence the RR DNS will not lose its effect.
> 

This debate has splintered a bit on the list, but it seems to me that
everybody's concern has to do with this unfamiliar sorting algorithm.
Am I right, or does somebody have another concern, unrelated to the
sorting algorithm?

Ulrich's last comment made me think that DNS results will be sorted a
lot less than people seem to think.  It also seems that the biggest
cause of this whole misunderstanding is that Ulrich appears to be the
only one who understands when and how this mysterious sorting algorithm
is applied.

Ulrich: Is there a clear spec that outlines the behavior of this
function, or will we just have to go examine the source code?  I think
that if we all had a more realistic and concrete idea about how this
function performs, that we'd all sleep better tonight. :)

I'm sorry if I've made any bad assumptions or generalizations in this
email.  This is just based on my personal point-of-view.

-- 
Topher Fischer
GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19  EFF5 2FC3 BE99 D123 6674
javert42 at cs.byu.edu | http://www.thetopher.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/958759e8/attachment.sig>

From hughsient at gmail.com  Sun Oct 14 21:44:04 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 14 Oct 2007 22:44:04 +0100
Subject: Making PackageKit work with pirut and pup
In-Reply-To: <1192385807.2585.6.camel@localhost.localdomain>
References: <1192363009.24022.20.camel@hughsie-laptop>
	<1192385807.2585.6.camel@localhost.localdomain>
Message-ID: <1192398244.3051.15.camel@hughsie-laptop>

On Sun, 2007-10-14 at 14:16 -0400, Matthias Clasen wrote:
> I think using alternatives is probably the best we can do for now.
> Unfortunately, it seems that the packaging guidelines contain no details
> on how to properly setup up a package for using alternatives (except for
> a passing mention in
> http://fedoraproject.org/wiki/Packaging/Conflicts ). One example I could
> find quickly is in the cdrkit spec - I have no idea if it is a good
> example, though.

Sure, cheers for confirming.

> But solving the system-install-packages problem should not block
> PackageKit from entering the repo, I think. PackageKit is useful even if
> it doesn't have system-install-packages yet.

Cool, thanks. There are no file conflicts, you just have to use
pk-install-package rather than system-install-packages.

Richard.




From lkundrak at redhat.com  Sun Oct 14 22:29:59 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 15 Oct 2007 00:29:59 +0200
Subject: Packing XPIs
Message-ID: <1192400999.8856.5.camel@localhost.localdomain>

Hi,

Any ideas how to pack a mozilla addon? Seamonkey does not include any
translations in the default package, so having translations packaged at
least separately would be useful.

XPI seems to be a ZIP file with a JS install script. I did use a
language addon packaged and installed using ugly unzip and sed script
with 1.0, but it seems to be impossible anymore. That was not very
clever anyways.

Anyone being aware of some magic seamonkey's comand line switch for
that, or anything else?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From mmcgrath at redhat.com  Sun Oct 14 22:37:56 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sun, 14 Oct 2007 17:37:56 -0500
Subject: intermittent fedora web service outages
In-Reply-To: <20071014051221.GA5135@crow.myhome.westell.com>
References: <20071014051221.GA5135@crow.myhome.westell.com>
Message-ID: <47129A44.4050000@redhat.com>

Luke Macken wrote:
> Mike is in the process of tracking down some issues with our database at
> the moment, so there may be some intermittent outages with some of our
> web services, including:
>
>     - bodhi
>     - koji
>     - pkgdb
>     - mirrormanager
>     - accounts system
>
>   


FYI All, this should be fixed now.  Those interested in the details 
(mostly postgresql stuff) please refer to ticket:

https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/190

   -Mike



From ssorce at redhat.com  Sun Oct 14 23:17:16 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 14 Oct 2007 19:17:16 -0400
Subject: gethostby* users
In-Reply-To: <47128708.2070104@cs.byu.edu>
References: <470F15B2.2020809@redhat.com>
	<1192230330.22759.8.camel@localhost6.localdomain6>
	<loom.20071013T051855-88@post.gmane.org>
	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>
	<1192287946.10852.83.camel@localhost.localdomain>
	<4710EEE9.7060109@redhat.com>	<47112448.6010106@gmail.com>
	<47124BE7.9070503@redhat.com>  <47128708.2070104@cs.byu.edu>
Message-ID: <1192403836.21735.17.camel@localhost.localdomain>

On Sun, 2007-10-14 at 15:15 -0600, Topher wrote:
> Ulrich Drepper wrote:
> > Les Mikesell wrote:
> >> But, if they
> >> resort the list, half of them will pick the wrong first choice even when
> >> it is reachable.
> > 
> > No.  The sorting performed is not a universal and complete ordering.
> > For once, it depends on the addresses of the client machines.  Second,
> > if all target addresses are equally "bad" (i.e., for IPv4, all have the
> > same matching prefix length) the sorting will not change the order in
> > which the entries are returned.  Hence the RR DNS will not lose its effect.
> > 
> 
> This debate has splintered a bit on the list, but it seems to me that
> everybody's concern has to do with this unfamiliar sorting algorithm.
> Am I right, or does somebody have another concern, unrelated to the
> sorting algorithm?

Sorting is the only point we are discussing.

> Ulrich's last comment made me think that DNS results will be sorted a
> lot less than people seem to think.  It also seems that the biggest
> cause of this whole misunderstanding is that Ulrich appears to be the
> only one who understands when and how this mysterious sorting algorithm
> is applied.

Not mysterious at all, read the RFC (easier) and glibc source code and
you'll know all about it.

> Ulrich: Is there a clear spec that outlines the behavior of this
> function, or will we just have to go examine the source code?  I think
> that if we all had a more realistic and concrete idea about how this
> function performs, that we'd all sleep better tonight. :)

I didn't see the code diverge much from the RFC, but I didn't do a
strict analysis either, just enough to be concerned about the artificial
(for IPv4) difference between site-local and global scope addresses
(which is dictated by the RFC). That's my principal concern, so far.

Simo.



From javert42 at cs.byu.edu  Sun Oct 14 23:54:53 2007
From: javert42 at cs.byu.edu (Topher)
Date: Sun, 14 Oct 2007 17:54:53 -0600
Subject: gethostby* users
In-Reply-To: <1192403836.21735.17.camel@localhost.localdomain>
References: <470F15B2.2020809@redhat.com>	<1192230330.22759.8.camel@localhost6.localdomain6>	<loom.20071013T051855-88@post.gmane.org>	<20071013055825.GA1192122@hiwaay.net>	<47106150.1090303@redhat.com>	<1192287946.10852.83.camel@localhost.localdomain>	<4710EEE9.7060109@redhat.com>	<47112448.6010106@gmail.com>	<47124BE7.9070503@redhat.com>
	<47128708.2070104@cs.byu.edu>
	<1192403836.21735.17.camel@localhost.localdomain>
Message-ID: <4712AC4D.5050308@cs.byu.edu>

Simo Sorce wrote:
[trimmed]
>> This debate has splintered a bit on the list, but it seems to me that
>> everybody's concern has to do with this unfamiliar sorting algorithm.
>> Am I right, or does somebody have another concern, unrelated to the
>> sorting algorithm?
> 
> Sorting is the only point we are discussing.
> 
>> Ulrich's last comment made me think that DNS results will be sorted a
>> lot less than people seem to think.  It also seems that the biggest
>> cause of this whole misunderstanding is that Ulrich appears to be the
>> only one who understands when and how this mysterious sorting algorithm
>> is applied.
> 
> Not mysterious at all, read the RFC (easier) and glibc source code and
> you'll know all about it.
> 
>> Ulrich: Is there a clear spec that outlines the behavior of this
>> function, or will we just have to go examine the source code?  I think
>> that if we all had a more realistic and concrete idea about how this
>> function performs, that we'd all sleep better tonight. :)
> 
> I didn't see the code diverge much from the RFC, but I didn't do a
> strict analysis either, just enough to be concerned about the artificial
> (for IPv4) difference between site-local and global scope addresses
> (which is dictated by the RFC). That's my principal concern, so far.
> 
> Simo.
> 

Thanks for the references.  I should have read through the RFC first.


-- 
Topher Fischer
GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19  EFF5 2FC3 BE99 D123 6674
javert42 at cs.byu.edu | http://www.thetopher.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071014/72e2bd55/attachment.sig>

From mattdm at mattdm.org  Mon Oct 15 00:27:28 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 14 Oct 2007 20:27:28 -0400
Subject: Ekiga working for anyone?
Message-ID: <20071015002728.GA3593@jadzia.bu.edu>

So, is Ekiga working for anyone? Whenever I connect, I immediately get a
crash with a floating point error and a message about something audio
related....


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jwboyer at jdub.homelinux.org  Mon Oct 15 01:06:14 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 14 Oct 2007 20:06:14 -0500
Subject: Orphaning some packages
Message-ID: <20071014200614.0c957e31@vader.jdub.homelinux.org>

Time for a little fall cleaning.  I'm orphaning the following packages
as I no longer have a use for them:

ddclient
tla
tcl-thread

josh



From jon.nettleton at gmail.com  Mon Oct 15 02:24:41 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Sun, 14 Oct 2007 22:24:41 -0400
Subject: Ekiga working for anyone?
In-Reply-To: <20071015002728.GA3593@jadzia.bu.edu>
References: <20071015002728.GA3593@jadzia.bu.edu>
Message-ID: <e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>

On 10/14/07, Matthew Miller <mattdm at mattdm.org> wrote:
> So, is Ekiga working for anyone? Whenever I connect, I immediately get a
> crash with a floating point error and a message about something audio
> related....

It is working for me.  I just used it earlier today.  I am on my
laptop with the newest rawhide using the internal VIA chipset
soundcard for playback and the USB mic from recording.

Jon



From mmcgrath at redhat.com  Mon Oct 15 02:46:10 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sun, 14 Oct 2007 21:46:10 -0500
Subject: Ekiga working for anyone?
In-Reply-To: <e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>
References: <20071015002728.GA3593@jadzia.bu.edu>
	<e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>
Message-ID: <4712D472.7050009@redhat.com>

Jon Nettleton wrote:
> On 10/14/07, Matthew Miller <mattdm at mattdm.org> wrote:
>   
>> So, is Ekiga working for anyone? Whenever I connect, I immediately get a
>> crash with a floating point error and a message about something audio
>> related....
>>     
>
> It is working for me.  I just used it earlier today.  I am on my
> laptop with the newest rawhide using the internal VIA chipset
> soundcard for playback and the USB mic from recording.
>   

WORKSFORME, what version/dist are you having problems on?

    -Mike



From dmc.fedora at filteredperception.org  Mon Oct 15 03:25:07 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 14 Oct 2007 22:25:07 -0500
Subject: Packing XPIs
In-Reply-To: <1192400999.8856.5.camel@localhost.localdomain>
References: <1192400999.8856.5.camel@localhost.localdomain>
Message-ID: <4712DD93.1060300@filteredperception.org>

Lubomir Kundrak wrote:
> Hi,
> 
> Any ideas how to pack a mozilla addon? Seamonkey does not include any
> translations in the default package, so having translations packaged at
> least separately would be useful.
> 
> XPI seems to be a ZIP file with a JS install script. I did use a
> language addon packaged and installed using ugly unzip and sed script
> with 1.0, but it seems to be impossible anymore. That was not very
> clever anyways.
> 
> Anyone being aware of some magic seamonkey's comand line switch for
> that, or anything else?

I too have searched for a method to do this.  In addition to rebootless 
livecd installation, I consider the firefox swiftabs extension to be a 
key feature of my personal fedora derived livecd - http://gzyx.org -

FWIW, on that livecd is some bash (and maybe perl) script which installs 
the swiftabs extention from the commandline for a specific user (from 
the swiftabs xpi).  It was a tad more complicated than just sed, but 
still doable.  (see /usr/bin/kablui if you are really interested).

I'm really hoping someone else answers this thread with better method 
though.  It certainly seems like it would be a handy feature to expose 
in some commandline tool that ships with firefox.  But I haven't found 
it yet.

-dmc



From wart at kobold.org  Mon Oct 15 03:39:49 2007
From: wart at kobold.org (Wart)
Date: Sun, 14 Oct 2007 20:39:49 -0700
Subject: Orphaning some packages
In-Reply-To: <20071014200614.0c957e31@vader.jdub.homelinux.org>
References: <20071014200614.0c957e31@vader.jdub.homelinux.org>
Message-ID: <4712E105.606@kobold.org>

Josh Boyer wrote:
> Time for a little fall cleaning.  I'm orphaning the following packages
> as I no longer have a use for them:
> 
> ddclient
> tla
> tcl-thread

I'll pick up tcl-thread.

--Wart



From a.badger at gmail.com  Mon Oct 15 03:44:08 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 14 Oct 2007 20:44:08 -0700
Subject: PackageDB: mixed summary + description
In-Reply-To: <3170f42f0710141254v1bae8e37hfcabf71e4df79fe8@mail.gmail.com>
References: <3170f42f0710141254v1bae8e37hfcabf71e4df79fe8@mail.gmail.com>
Message-ID: <4712E208.5080206@gmail.com>

Debarshi 'Rishi' Ray wrote:
> https://admin.fedoraproject.org/pkgdb/packages/name/catfish
> https://admin.fedoraproject.org/pkgdb/packages/name/pinot
> 
> It seems that the summary and description are messed up with other packages.
> 
> Is this known or needs reporting?

Needs reporting.  I've opened a ticket[1]_.  If you see any other 
packages with a problem please add any information you can to the ticket 
so I can see where things are going wrong.

https://hosted.fedoraproject.org/projects/packagedb/ticket/87

Thanks!
-Toshio



From louisg00 at bellsouth.net  Mon Oct 15 03:59:30 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 14 Oct 2007 23:59:30 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192204108.2492.7.camel@tiger>
References: <1192204108.2492.7.camel@tiger>
Message-ID: <1192420770.2612.2.camel@tiger>

On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> I put a pix of myself in the 'about me' capplet and have a .face in my
> home dir. Why doesn't gdm pick it up?
> 
> -Louis

Would this be the cause?

SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
(home_root_t).





From mike at miketc.com  Mon Oct 15 04:01:46 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 14 Oct 2007 23:01:46 -0500
Subject: Echo icons missing
In-Reply-To: <1192364763.14410.3.camel@scrappy.miketc.com>
References: <1192227128.2260.1.camel@scrappy.miketc.com>
	<1192260010.471071aae3ead@ssl.mecca.ca>
	<1192364763.14410.3.camel@scrappy.miketc.com>
Message-ID: <1192420906.2195.1.camel@scrappy.miketc.com>

On Sun, 2007-10-14 at 07:26 -0500, Mike Chambers wrote:
> On Sat, 2007-10-13 at 03:20 -0400, Luya Tshimbalanga wrote:
> > Quoting Mike Chambers <mike at miketc.com>:
> > 
> > > I noticed over the last couple days, a couple of icons from echo-theme
> > > have resorted back to the gnome icons?  The file manager and xchat icons
> > > changed it seems to the big two drawer cabinet and the big X.
> > >
> > > Any ideas?
> > 
> > Strange. I have not seen that problem with File Manager. I can't tell with xchat
> > icon. Both icons were not "echofied" yet. Could you post a screenshot?
> 
> File size little big, so go to the URL below to view the screen shot,
> notice bottom left as my panel isn't where the installed one is...
> 
> http://www.miketc.com/Screenshot.png

Welp, after today's rawhide updates and a reboot, it seems the two (if
not more) icons are fixed and back to normal.  No idea what happened.
*shrug*.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From Matt_Domsch at dell.com  Mon Oct 15 04:05:27 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 14 Oct 2007 23:05:27 -0500
Subject: Fedora x86_64 rawhide rebuild in mock status 2007-10-14
Message-ID: <20071014230527.A28488@humbolt.us.dell.com>

Fedora Rawhide-in-Mock Build Results for x86_64 Sun Oct 14 22:38:52 CDT 2007

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 4807
Number failed to build: 412
Number expected to fail due to ExclusiveArch or ExcludeArch: 32
Leaving:  380
(there may be some duplicates if rawhide has 2 versions of a package)

Of those expected to have worked...
Without a bug filed: 380
----------------------------------
Pixie-2.2.2-2.fc8 (build/make) kwizart
PolicyKit-gnome-0.6-1.fc8 (build/make) davidz
adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung
airsnort-0.2.7e-11.fc7 (build/make) awjb
alacarte-0.11.3-4.fc8 (build/make) rstrode,jpmahowa,sindrepb
amsn-0.96-7.fc7 (build/make) tjikkun
apt-0.5.15lorg3.93-2.fc8 (build/make) athimm,pmatilai
arts-1.5.7-6.fc8 (build/make) than,rdieter
atitvout-0.4-7 (buildroot) awjb
audacious-plugins-1.3.5-2.fc8 (buildroot) ertzing
audit-1.6.2-3.fc8 (build/make) sgrubb
avr-binutils-2.17-4.fc8 (build/make) jwrdegoede
awesfx-0.5.0d-4.fc7 (build/make) stransky
callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2
camstream-0.26.3-12.fc8 (open_missing_mode) nomis80
castor-0.9.5-1jpp.7 (build/make) pcheung
checkstyle-4.1-4jpp.1.fc7 (buildroot) rmyers
chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig
clips-6.24-22.fc7 (build/make) rvinyard
compat-erlang-R10B-10.7.fc7 (build/make) gemi
compat-gcc-32-3.2.3-62 (buildroot) jakub
compat-gcc-34-3.4.6-7 (build/make) jakub
conexus-0.5.3-2.fc8 (build/make) rvinyard
cpan2rpm-2.028-2.fc6 (needs_perl_ExtUtils_MakeMaker) ghenry,perl-sig
cryptix-3.2.0-9jpp.1 (build/make) mwringe
cryptix-asn1-20011119-7jpp.2 (build/make) vivekl
d4x-2.5.7.1-3.fc7 (build/make) thias
dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus
eclipse-emf-2.2.2-1.fc7 (build/make) overholt
eiciel-0.9.4-1.fc7 (build/make) cweyl
em8300-kmod-0.16.3-5.2.6.23_0.220.rc9.git2.fc8 (buildroot) scop
emelfm2-0.3.5-2.fc8 (build/make) cwickert
evolution-remove-duplicates-0.0.2-6.fc7 (build/make) salimma
fakechroot-2.5-12.fc7 (build/make) athimm
fluxstyle-1.0.1-2.fc7 (build/make) errr
fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig
freetennis-0.4.8-6.fc7 (build/make) orphan
gai-0.5.10-10.fc7 (build/make) salimma,mschwendt
gajim-0.11.1-1.fc7 (buildroot) gajownik
gdb-6.6-32.fc8 (buildroot) jkratoch
gdmap-0.7.5-6.fc6 (build/make) splinux
gedit-plugins-2.18.0-2.fc7 (build/make) trondd
genius-0.7.7-2.fc7 (build/make) gemi
gfa-0.4.1-4.fc7 (build/make) splinux
ghdl-0.25-0.89svn.5.fc8 (build/make) sailer
giggle-0.3-4.fc8 (build/make) jbowes
glipper-0.95.1-2.fc7 (build/make) splinux
gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak
gnome-specimen-0.3-1.fc8 (build/make) splinux
gnomescan-0.4.0.2-1.fc7 (build/make) deji
grub-0.97-19 (build/make) pjones
gstm-1.2-6.fc7 (build/make) splinux
gtk-sharp-1.0.10-12.fc7 (build/make) pfj
gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog
gtranslator-1.1.7-3.fc8 (build/make) sindrepb,roozbeh
htop-0.6.5-1.fc7 (build/make) gajownik
hunspell-1.1.12.2-2.fc8 (build/make) caolanm
inkscape-0.45.1-1.fc7 (needs_popt-devel) denis
jgroups-2.2.9.2-3jpp.2 (build/make) vivekl
jogl-1.0.0-5.7.beta5.fc6 (build/make) green
kawa-1.9.0-2.fc7 (build/make) green
kbibtex-0.1.5.52-10.fc7 (build/make) noltec
kdemultimedia-3.5.7-2.fc8 (open_missing_mode) than,rdieter
kdissert-1.0.7-1.fc7 (build/make) icon
kgtk-0.8-2.fc7 (open_missing_mode) faucamp
knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil,mmcgrath,liquidat
kvm-36-6.fc8 (buildroot) katzj,berrange
ladspa-1.12-8.fc7 (build/make) thomasvs
ldapjdk-4.17-1jpp.7 (build/make) vivekl
ldns-1.2.1-1.fc8 (build/make) pwouters
libprelude-0.9.13-1.fc7 (build/make) tscherf
libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf
liferea-1.2.23-1.fc8 (build/make) bpepple
lilypond-doc-2.10.13-1.fc7 (build/make) qspencer
lockdev-1.0.1-11.fc7 (needs_perl_ExtUtils_MakeMaker) kzak
ltrace-0.5-9.45svn.fc8 (build/make) pmachata
maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe
mbuffer-20070502-1.fc7 (open_missing_mode) adalloz
memtest86+-1.70-1.fc7 (buildroot) wtogami
mikmod-3.2.2-2.fc7 (build/make) jnovy
moto4lin-0.3-6.fc7 (build/make) jafo
muine-0.8.7-3.fc7 (build/make) sindrepb
mx4j-3.0.1-6jpp.4 (build/make) fnasser
nagios-2.9-3.fc8 (build/make) mmcgrath
nant-0.85-12.fc7 (build/make) pfj
nemiver-0.4.0-1.fc8 (build/make) pgordon
nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb
ntfs-config-1.0-0.5.rc5.fc8 (build/make) laxathom
ocsinventory-client-1.01-5.fc7 (needs_perl_ExtUtils_MakeMaker) remi
octave-forge-2006.07.09-9.fc7 (build/make) qspencer,alexlan
openais-0.80.1-6 (open_missing_mode) sdake,sdake
openmpi-1.2.3-4.fc8 (open_missing_mode) dledford,jvdias
orpie-1.4.3-5.fc6 (build/make) xris
pam_abl-0.2.3-3.fc7 (build/make) adalloz
pari-2.3.0-5.fc7 (build/make) gemi
pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo
perl-AnyData-0.10-4.fc8 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Apache-DBI-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) remi,perl-sig
perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,perl-sig,ghenry
perl-Authen-SASL-2.10-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Boulder-1.30-3.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig
perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig
perl-CGI-Simple-0.077-7.fc8 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Cache-2.04-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-Cache-Cache-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,perl-sig
perl-Chatbot-Eliza-1.04-3.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,perl-sig
perl-Class-InsideOut-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-MakeMethods-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-MethodMaker-2.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor
perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig
perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig
perl-Compress-Bzip2-2.09-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Config-IniFiles-2.39-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Config-Record-1.1.1-3.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor,perl-sig
perl-Convert-ASN1-0.21-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Crypt-Blowfish-2.10-2.fc6 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Crypt-CBC-2.22-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Crypt-PasswdMD5-1.3-2.fc7 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-DBD-CSV-0.22-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-DBD-MySQL-4.005-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-DBD-Pg-1.49-5.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-DBD-SQLite-1.12-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig,wtogami
perl-DBD-XBase-0.241-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Data-Compare-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Data-HexDump-0.02-3.fc6 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig
perl-Date-Calc-5.4-2 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Date-Pcalc-1.2-4.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,perl-sig
perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,perl-sig
perl-DateTime-Set-0.25-4.fc7 (build/make) steve,perl-sig
perl-Devel-Caller-0.11-1.fc7 (build/make) steve,perl-sig
perl-Devel-Cover-0.61-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Devel-Cycle-1.07-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Digest-MD4-1.5-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Digest-Nilsimsa-0.06-8.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-Exception-Class-1.23-3.fc7 (build/make) steve,perl-sig
perl-Expect-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Expect-Simple-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-CBuilder-0.19-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-Depends-0.205-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-ParseXS-2.18-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-PkgConfig-1.07-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-XSBuilder-0.28-2.fc6 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Feed-Find-0.06-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-BaseDir-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-DesktopEntry-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,perl-sig,laxathom
perl-File-NFSLock-1.20-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,perl-sig
perl-File-RsyncP-0.68-2.fc8 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-File-Tail-0.99.3-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-File-Type-0.22-4.fc7 (build/make) steve,perl-sig
perl-File-Which-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Finance-Quote-1.13-1.fc7 (needs_perl_ExtUtils_MakeMaker) notting,perl-sig
perl-Finance-YahooQuote-0.21-2.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-FreezeThaw-0.43-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GD-2.35-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDGraph-1.44-2.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDGraph3d-0.63-7.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDTextUtil-0.86-8.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GPS-0.15-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GPS-PRN-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Constants-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Ellipsoids-0.14-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Forward-0.11-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Functions-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Inverse-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Glib-1.144-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl,perl-sig
perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl,perl-sig
perl-HTML-Scrubber-0.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-HTML-Table-2.04a-1.fc7 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-HTML-Template-2.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,perl-sig
perl-HTTP-Request-Params-1.01-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Hook-LexWrap-0.20-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-All-0.38-1.fc7 (build/make) steve,perl-sig
perl-IO-Capture-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Interface-1.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Multiplex-1.08-5.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-IO-Socket-INET6-2.51-2.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami
perl-IO-Socket-SSL-1.02-1.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-IO-String-1.08-1.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig,jpo
perl-IO-Tty-1.07-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Zlib-1.04-4.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig,jpo
perl-IPC-Cmd-0.36-2.fc7 (build/make) steve,perl-sig
perl-IPC-SharedCache-1.3-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Base-1.07-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Xbm-1.08-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Xpm-1.09-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Inline-0.44-15.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Kwiki-0.39-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,perl-sig
perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig
perl-LWP-Authen-Wsse-0.05-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-List-Compare-0.33-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Dispatch-Config-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Log-Dispatch-FileRotate-1.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Log4perl-1.11-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Message-0.01-3.fc7 (build/make) steve,perl-sig
perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,perl-sig
perl-MD5-2.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-MIME-Lite-3.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-MLDBM-2.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mail-Sender-0.8.13-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mail-Sendmail-0.79-9.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Math-Round-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig
perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig
perl-Module-Install-0.67-1.fc8 (build/make) steve,perl-sig
perl-Module-Load-0.10-3.fc7 (build/make) steve,perl-sig
perl-Module-Loaded-0.01-3.fc7 (build/make) steve,perl-sig
perl-Module-Locate-1.7-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,perl-sig
perl-Module-Versions-Report-1.03-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mozilla-LDAP-1.5.2-2.fc8 (needs_perl_ExtUtils_MakeMaker) rmeggins,perl-sig
perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig
perl-Net-GPSD-0.35-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Net-Jabber-2.0-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Net-Patricia-1.014-4.fc8 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-Net-SNMP-5.2.0-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Net-SSLeay-1.30-5.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-Net-Telnet-3.03-5 (needs_perl_ExtUtils_MakeMaker) jkeating
perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,perl-sig
perl-Object-Accessor-0.32-2.fc7 (build/make) steve,perl-sig
perl-OpenFrame-3.05-6.fc7 (build/make) steve,perl-sig
perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,perl-sig
perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig
perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig
perl-PPI-Tester-0.06-2.fc6 (build/make) jpo,perl-sig
perl-Package-Constants-0.01-3.fc7 (build/make) steve,perl-sig
perl-PadWalker-1.5-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Params-Check-0.26-1.fc7 (build/make) steve,perl-sig
perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,perl-sig
perl-Parse-RecDescent-1.94-6.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Parse-Yapp-1.05-36.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-PatchReader-0.9.5-4.fc6 (needs_perl_ExtUtils_MakeMaker) pfrields,perl-sig
perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig
perl-Pipeline-3.12-4.fc7 (build/make) steve,perl-sig
perl-Pod-Escapes-1.04-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Pod-Simple-3.05-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Pod-Spell-1.01-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Proc-Daemon-0.03-1.fc7.1 (needs_perl_ExtUtils_MakeMaker) remi
perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig
perl-Readonly-1.03-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Readonly-XS-1.04-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-SNMP_Session-1.08-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-SOAP-Lite-0.68-2.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-SQL-Library-0.0.3-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-SQL-Statement-1.15-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-SUPER-1.16-1.fc7 (build/make) cweyl,perl-sig
perl-SVG-2.34-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan
perl-Scalar-Properties-0.12-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Set-Infinite-0.61-3.fc7 (build/make) steve,perl-sig
perl-Set-Scalar-1.20-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Socket6-0.19-4.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-Spiffy-0.30-7.fc7 (build/make) steve,perl-sig
perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters
perl-Statistics-Descriptive-2.6-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-String-Format-1.14-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Sub-Identify-0.02-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Sub-Name-0.02-3.fc8 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig
perl-TeX-Hyphen-0.140-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Term-UI-0.14-2.fc7 (build/make) steve,perl-sig
perl-TermReadKey-2.30-1.2.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Test-Cmd-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Test-Differences-0.47-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Test-Expect-0.30-1.fc6 (build/make) jpo,perl-sig
perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-CHM-0.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-Text-CharWidth-0.04-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm
perl-Text-Kakasi-2.04-5.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh,perl-sig
perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-Shellwords-1.08-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan
perl-Text-Template-1.44-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Text-Tree-1.0-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Text-Unidecode-0.04-4.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus
perl-Text-WrapI18N-0.06-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm
perl-Tie-IxHash-1.21-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Time-Period-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) robmv,perl-sig
perl-Time-Piece-1.09-2.fc6 (needs_perl_ExtUtils_MakeMaker) cgrau,perl-sig
perl-Time-modules-2003.1126-4.fc6 (needs_perl_ExtUtils_MakeMaker) kaboom,perl-sig
perl-Tk-804.027-12.fc8 (build/make) awjb,perl-sig
perl-Tree-DAG_Node-1.05-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo,perl-sig
perl-URI-1.35-3 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-WWW-Babelfish-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-WWW-Bugzilla-0.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-XML-DOM-1.44-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-XML-Dumper-0.81-2.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig
perl-XML-Grove-0.46alpha-29.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-LibXML-1.62001-2.fc7 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-LibXML-Common-0.13-8.2.2 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-NamespaceSupport-1.09-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-RegExp-0.03-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig
perl-XML-Stream-1.22-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig
perl-XML-XPath-1.13-4.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig
perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver
perl-bioperl-1.5.2_102-8.fc8 (build/make) alexlan
perl-libxml-perl-0.08-1.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-pmtools-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
pexpect-2.1-5.fc8 (build/make) toshio
pinot-0.76-2.fc8 (build/make) drago01
polyxmass-bin-0.9.3-2.fc6 (build/make) awjb
ppc64-utils-0.12-1.fc8 (buildroot) dcantrel,pnasrat
prelink-0.4.0-1 (build/make) jakub
prewikka-0.9.8-1.fc7 (build/make) tscherf
python-boto-0.9b-1.fc8 (build/make) robert
python-docs-2.5.1-1.fc8 (build/make) james,katzj
python-psyco-1.5.1-5.fc7 (buildroot) shahms
python-reportlab-2.1-1.fc8 (build/make) bpepple
python-tag-0.91-5 (build/make) thias
python-urljr-1.0.1-1.fc7 (build/make) jcollie
qa-assistant-0.4.90.5-2.fc6 (build/make) toshio
qpidc-0.2-5.fc7 (build/make) aconway,nsantos
rekall-2.4.5-6.fc8.1 (build/make) spot
renrot-0.25-2.fc7 (needs_perl_ExtUtils_MakeMaker) andriy
rhm-0.1-3.fc7 (build/make) aconway,nsantos
ruby-activerecord-1.15.1-1.fc7 (build/make) lutter
ruby-bdb-0.6.0-1.fc7 (build/make) errr
rxvt-unicode-8.3-1.fc8 (build/make) awjb
s3switch-0.0-9.20020912.fc6 (buildroot) pwouters
seahorse-1.0.1-9.fc8 (build/make) skvidal
shapelib-1.2.10-12.20060304cvs (build/make) smccann
swatch-3.2.1-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo
synce-software-manager-0.9.0-7.fc6 (build/make) awjb
synce-trayicon-0.9.0-8.fc6 (build/make) awjb
syslinux-3.36-6.fc8 (buildroot) pjones
syslog-ng-2.0.5-1.fc8 (build/make) jpo,pvrabec
sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu
tclabc-1.0.9-1.fc7 (build/make) gemi
tetex-3.0-41.fc8 (build/make) jnovy
udunits-1.12.4-11.fc8.2 (needs_perl_ExtUtils_MakeMaker) spot
unison-2.13.16-3.fc6 (build/make) gemi
util-linux-ng-2.13-2.fc8 (build/make) kzak
valgrind-3.2.3-6 (buildroot) jakub
velocity-1.4-6jpp.1 (build/make) vivekl
xaos-3.2.3-1.fc7 (build/make) gemi
xdaliclock-2.23-3.fc6 (build/make) kaboom
xen-3.1.0-12.fc8 (buildroot) xen-maint
xferstats-2.16-14.1 (build/make) than
xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser
xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung
xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint
xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint
xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint
xsri-2.1.0-12.fc8 (build/make) ssp
zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie

With bugs filed: 0
----------------------------------



-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From Matt_Domsch at dell.com  Mon Oct 15 04:06:13 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 14 Oct 2007 23:06:13 -0500
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-14
Message-ID: <20071014230613.A28552@humbolt.us.dell.com>

Fedora Rawhide-in-Mock Build Results for i386 Sun Oct 14 22:44:53 CDT 2007

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 4808
Number failed to build: 374
Number expected to fail due to ExclusiveArch or ExcludeArch: 10
Leaving:  364
(there may be some duplicates if rawhide has 2 versions of a package)

Of those expected to have worked...
Without a bug filed: 364
----------------------------------
Pixie-2.2.2-2.fc8 (build/make) kwizart
adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung
airsnort-0.2.7e-11.fc7 (build/make) awjb
amsn-0.96-7.fc7 (build/make) tjikkun
apt-0.5.15lorg3.93-2.fc8 (build/make) athimm,pmatilai
arts-1.5.7-6.fc8 (build/make) than,rdieter
athcool-0.3.11-5.fc6 (build/make) gajownik
audacious-plugins-1.3.5-2.fc8 (buildroot) ertzing
audit-1.6.2-3.fc8 (build/make) sgrubb
avr-binutils-2.17-4.fc8 (build/make) jwrdegoede
awesfx-0.5.0d-4.fc7 (build/make) stransky
callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2
camstream-0.26.3-12.fc8 (open_missing_mode) nomis80
castor-0.9.5-1jpp.7 (build/make) pcheung
checkstyle-4.1-4jpp.1.fc7 (buildroot) rmyers
chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig
clips-6.24-22.fc7 (build/make) rvinyard
compat-erlang-R10B-10.7.fc7 (build/make) gemi
compat-gcc-34-3.4.6-7 (build/make) jakub
conexus-0.5.3-2.fc8 (build/make) rvinyard
cpan2rpm-2.028-2.fc6 (needs_perl_ExtUtils_MakeMaker) ghenry,perl-sig
cryptix-3.2.0-9jpp.1 (build/make) mwringe
cryptix-asn1-20011119-7jpp.2 (build/make) vivekl
d4x-2.5.7.1-3.fc7 (build/make) thias
dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus
e2fsprogs-1.40.2-8.fc8 (build/make) sandeen,oliver,kzak
eclipse-emf-2.2.2-1.fc7 (build/make) overholt
eiciel-0.9.4-1.fc7 (build/make) cweyl
em8300-kmod-0.16.3-5.2.6.23_0.220.rc9.git2.fc8 (buildroot) scop
emelfm2-0.3.5-2.fc8 (build/make) cwickert
evolution-remove-duplicates-0.0.2-6.fc7 (build/make) salimma
fakechroot-2.5-12.fc7 (build/make) athimm
fluxstyle-1.0.1-2.fc7 (build/make) errr
fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig
freetennis-0.4.8-6.fc7 (build/make) orphan
gai-0.5.10-10.fc7 (build/make) salimma,mschwendt
gajim-0.11.1-1.fc7 (buildroot) gajownik
gdmap-0.7.5-6.fc6 (build/make) splinux
gedit-plugins-2.18.0-2.fc7 (build/make) trondd
genius-0.7.7-2.fc7 (build/make) gemi
gfa-0.4.1-4.fc7 (build/make) splinux
ghdl-0.25-0.89svn.5.fc8 (build/make) sailer
giggle-0.3-4.fc8 (build/make) jbowes
glipper-0.95.1-2.fc7 (build/make) splinux
gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak
gnomescan-0.4.0.2-1.fc7 (build/make) deji
gstm-1.2-6.fc7 (build/make) splinux
gtk-sharp-1.0.10-12.fc7 (build/make) pfj
gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog
gtranslator-1.1.7-3.fc8 (build/make) sindrepb,roozbeh
htop-0.6.5-1.fc7 (build/make) gajownik
hunspell-1.1.12.2-2.fc8 (build/make) caolanm
inkscape-0.45.1-1.fc7 (needs_popt-devel) denis
jgroups-2.2.9.2-3jpp.2 (build/make) vivekl
jogl-1.0.0-5.7.beta5.fc6 (build/make) green
kawa-1.9.0-2.fc7 (build/make) green
kbibtex-0.1.5.52-10.fc7 (build/make) noltec
kdemultimedia-3.5.7-2.fc8 (open_missing_mode) than,rdieter
kdissert-1.0.7-1.fc7 (build/make) icon
kgtk-0.8-2.fc7 (open_missing_mode) faucamp
knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil,mmcgrath,liquidat
ladspa-1.12-8.fc7 (build/make) thomasvs
ldapjdk-4.17-1jpp.7 (build/make) vivekl
ldns-1.2.1-1.fc8 (build/make) pwouters
libprelude-0.9.13-1.fc7 (build/make) tscherf
libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf
liferea-1.2.23-1.fc8 (build/make) bpepple
lilypond-doc-2.10.13-1.fc7 (build/make) qspencer
lockdev-1.0.1-11.fc7 (needs_perl_ExtUtils_MakeMaker) kzak
ltrace-0.5-9.45svn.fc8 (build/make) pmachata
maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe
mbuffer-20070502-1.fc7 (open_missing_mode) adalloz
mikmod-3.2.2-2.fc7 (build/make) jnovy
mosml-2.01-9.fc7 (build/make) gemi
moto4lin-0.3-6.fc7 (build/make) jafo
muine-0.8.7-3.fc7 (build/make) sindrepb
mx4j-3.0.1-6jpp.4 (build/make) fnasser
nagios-2.9-3.fc8 (build/make) mmcgrath
nant-0.85-12.fc7 (build/make) pfj
nemiver-0.4.0-1.fc8 (build/make) pgordon
nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb
ocsinventory-client-1.01-5.fc7 (needs_perl_ExtUtils_MakeMaker) remi
octave-forge-2006.07.09-9.fc7 (build/make) qspencer,alexlan
openais-0.80.1-6 (open_missing_mode) sdake,sdake
openmpi-1.2.3-4.fc8 (open_missing_mode) dledford,jvdias
orpie-1.4.3-5.fc6 (build/make) xris
pam_abl-0.2.3-3.fc7 (build/make) adalloz
pari-2.3.0-5.fc7 (build/make) gemi
pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo
perl-AnyData-0.10-4.fc8 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Apache-DBI-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) remi,perl-sig
perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,perl-sig,ghenry
perl-Authen-SASL-2.10-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Boulder-1.30-3.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig
perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig
perl-CGI-Simple-0.077-7.fc8 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Cache-2.04-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-Cache-Cache-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,perl-sig
perl-Chatbot-Eliza-1.04-3.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,perl-sig
perl-Class-InsideOut-1.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-MakeMethods-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Class-MethodMaker-2.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor
perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig
perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig
perl-Compress-Bzip2-2.09-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Config-IniFiles-2.39-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Config-Record-1.1.1-3.fc6 (needs_perl_ExtUtils_MakeMaker) dgregor,perl-sig
perl-Convert-ASN1-0.21-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Crypt-Blowfish-2.10-2.fc6 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Crypt-CBC-2.22-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Crypt-PasswdMD5-1.3-2.fc7 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-DBD-CSV-0.22-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-DBD-MySQL-4.005-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-DBD-Pg-1.49-5.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-DBD-SQLite-1.12-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig,wtogami
perl-DBD-XBase-0.241-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Data-Compare-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Data-HexDump-0.02-3.fc6 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig
perl-Date-Calc-5.4-2 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Date-Pcalc-1.2-4.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,perl-sig
perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,perl-sig
perl-DateTime-Set-0.25-4.fc7 (build/make) steve,perl-sig
perl-Devel-Caller-0.11-1.fc7 (build/make) steve,perl-sig
perl-Devel-Cover-0.61-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Devel-Cycle-1.07-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Digest-MD4-1.5-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Digest-Nilsimsa-0.06-8.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-Exception-Class-1.23-3.fc7 (build/make) steve,perl-sig
perl-Expect-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Expect-Simple-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-CBuilder-0.19-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-Depends-0.205-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-ParseXS-2.18-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-PkgConfig-1.07-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-ExtUtils-XSBuilder-0.28-2.fc6 (needs_perl_ExtUtils_MakeMaker) spot,perl-sig
perl-Feed-Find-0.06-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-BaseDir-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-DesktopEntry-0.02-1.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,perl-sig,laxathom
perl-File-NFSLock-1.20-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,perl-sig
perl-File-RsyncP-0.68-2.fc8 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-File-Tail-0.99.3-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-File-Type-0.22-4.fc7 (build/make) steve,perl-sig
perl-File-Which-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Finance-Quote-1.13-1.fc7 (needs_perl_ExtUtils_MakeMaker) notting,perl-sig
perl-Finance-YahooQuote-0.21-2.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-FreezeThaw-0.43-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GD-2.35-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDGraph-1.44-2.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDGraph3d-0.63-7.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GDTextUtil-0.86-8.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GPS-0.15-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-GPS-PRN-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Constants-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Ellipsoids-0.14-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Forward-0.11-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Functions-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Geo-Inverse-0.05-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Glib-1.144-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl,perl-sig
perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl,perl-sig
perl-HTML-Scrubber-0.08-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-HTML-Table-2.04a-1.fc7 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-HTML-Template-2.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,perl-sig
perl-HTTP-Request-Params-1.01-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Hook-LexWrap-0.20-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-All-0.38-1.fc7 (build/make) steve,perl-sig
perl-IO-Capture-0.05-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Interface-1.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Multiplex-1.08-5.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig
perl-IO-Socket-INET6-2.51-2.fc6 (needs_perl_ExtUtils_MakeMaker) wtogami
perl-IO-Socket-SSL-1.02-1.fc7 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-IO-String-1.08-1.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig,jpo
perl-IO-Tty-1.07-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-IO-Zlib-1.04-4.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig,jpo
perl-IPC-Cmd-0.36-2.fc7 (build/make) steve,perl-sig
perl-IPC-SharedCache-1.3-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Base-1.07-7.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Xbm-1.08-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Image-Xpm-1.09-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Inline-0.44-15.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Kwiki-0.39-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,perl-sig
perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig
perl-LWP-Authen-Wsse-0.05-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-List-Compare-0.33-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Locale-Maketext-Fuzzy-0.02-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Dispatch-Config-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Log-Dispatch-FileRotate-1.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Log4perl-1.11-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Log-Message-0.01-3.fc7 (build/make) steve,perl-sig
perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,perl-sig
perl-MD5-2.03-1.fc7 (needs_perl_ExtUtils_MakeMaker) ixs,perl-sig
perl-MIME-Lite-3.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-MLDBM-2.01-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mail-Sender-0.8.13-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mail-Sendmail-0.79-9.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Math-Round-0.06-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig
perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig
perl-Module-Install-0.67-1.fc8 (build/make) steve,perl-sig
perl-Module-Load-0.10-3.fc7 (build/make) steve,perl-sig
perl-Module-Loaded-0.01-3.fc7 (build/make) steve,perl-sig
perl-Module-Locate-1.7-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,perl-sig
perl-Module-Versions-Report-1.03-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Mozilla-LDAP-1.5.2-2.fc8 (needs_perl_ExtUtils_MakeMaker) rmeggins,perl-sig
perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig
perl-Net-GPSD-0.35-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Net-Jabber-2.0-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Net-Patricia-1.014-4.fc8 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-Net-SNMP-5.2.0-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Net-SSLeay-1.30-5.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-Net-Telnet-3.03-5 (needs_perl_ExtUtils_MakeMaker) jkeating
perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,perl-sig
perl-Object-Accessor-0.32-2.fc7 (build/make) steve,perl-sig
perl-OpenFrame-3.05-6.fc7 (build/make) steve,perl-sig
perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,perl-sig
perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig
perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig
perl-PPI-Tester-0.06-2.fc6 (build/make) jpo,perl-sig
perl-Package-Constants-0.01-3.fc7 (build/make) steve,perl-sig
perl-PadWalker-1.5-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Params-Check-0.26-1.fc7 (build/make) steve,perl-sig
perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,perl-sig
perl-Parse-RecDescent-1.94-6.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Parse-Yapp-1.05-36.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-PatchReader-0.9.5-4.fc6 (needs_perl_ExtUtils_MakeMaker) pfrields,perl-sig
perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig
perl-Pipeline-3.12-4.fc7 (build/make) steve,perl-sig
perl-Pod-Escapes-1.04-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Pod-Simple-3.05-1.fc8 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Pod-Spell-1.01-2.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Proc-Daemon-0.03-1.fc7.1 (needs_perl_ExtUtils_MakeMaker) remi
perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig
perl-Readonly-1.03-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Readonly-XS-1.04-7.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-SNMP_Session-1.08-3.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-SOAP-Lite-0.68-2.fc6 (needs_perl_ExtUtils_MakeMaker) mmcgrath,perl-sig
perl-SQL-Library-0.0.3-2.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-SQL-Statement-1.15-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-SUPER-1.16-1.fc7 (build/make) cweyl,perl-sig
perl-SVG-2.34-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan
perl-Scalar-Properties-0.12-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Set-Infinite-0.61-3.fc7 (build/make) steve,perl-sig
perl-Set-Scalar-1.20-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Socket6-0.19-4.fc8 (needs_perl_ExtUtils_MakeMaker) wtogami,perl-sig,jpo
perl-Spiffy-0.30-7.fc7 (build/make) steve,perl-sig
perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters
perl-Statistics-Descriptive-2.6-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-String-Format-1.14-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Sub-Identify-0.02-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Sub-Name-0.02-3.fc8 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig
perl-TeX-Hyphen-0.140-5.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Term-UI-0.14-2.fc7 (build/make) steve,perl-sig
perl-TermReadKey-2.30-1.2.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-Test-Cmd-1.05-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Test-Differences-0.47-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Test-Expect-0.30-1.fc6 (build/make) jpo,perl-sig
perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-CHM-0.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus,perl-sig
perl-Text-CharWidth-0.04-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm
perl-Text-Kakasi-2.04-5.fc8 (needs_perl_ExtUtils_MakeMaker) tagoh,perl-sig
perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-Shellwords-1.08-2.fc8 (needs_perl_ExtUtils_MakeMaker) alexlan
perl-Text-Template-1.44-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Text-Tree-1.0-2.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-Text-Unidecode-0.04-4.fc6 (needs_perl_ExtUtils_MakeMaker) pertusus
perl-Text-WrapI18N-0.06-2.fc7 (needs_perl_ExtUtils_MakeMaker) athimm
perl-Tie-IxHash-1.21-6.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-Time-Period-1.20-1.fc6 (needs_perl_ExtUtils_MakeMaker) robmv,perl-sig
perl-Time-Piece-1.09-2.fc6 (needs_perl_ExtUtils_MakeMaker) cgrau,perl-sig
perl-Time-modules-2003.1126-4.fc6 (needs_perl_ExtUtils_MakeMaker) kaboom,perl-sig
perl-Tk-804.027-12.fc8 (build/make) awjb,perl-sig
perl-Tree-DAG_Node-1.05-4.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo,perl-sig
perl-URI-1.35-3 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-WWW-Babelfish-0.16-1.fc7 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-WWW-Bugzilla-0.9-1.fc7 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
perl-XML-DOM-1.44-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-XML-Dumper-0.81-2.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig
perl-XML-Grove-0.46alpha-29.1.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-LibXML-1.62001-2.fc7 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-LibXML-Common-0.13-8.2.2 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-NamespaceSupport-1.09-2.fc8 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-XML-RegExp-0.03-2.fc6 (needs_perl_ExtUtils_MakeMaker) orion,perl-sig
perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig
perl-XML-Stream-1.22-6.fc6 (needs_perl_ExtUtils_MakeMaker) cweyl,perl-sig
perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig
perl-XML-XPath-1.13-4.fc6 (needs_perl_ExtUtils_MakeMaker) rnorwood,perl-sig
perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver
perl-bioperl-1.5.2_102-8.fc8 (build/make) alexlan
perl-libxml-perl-0.08-1.2.1 (needs_perl_ExtUtils_MakeMaker) rnorwood
perl-pmtools-1.01-2.fc6 (needs_perl_ExtUtils_MakeMaker) jpo,perl-sig
pinot-0.76-2.fc8 (build/make) drago01
polyxmass-bin-0.9.3-2.fc6 (build/make) awjb
ppc64-utils-0.12-1.fc8 (buildroot) dcantrel,pnasrat
prelink-0.4.0-1 (build/make) jakub
python-docs-2.5.1-1.fc8 (build/make) james,katzj
python-tag-0.91-5 (build/make) thias
python-urljr-1.0.1-1.fc7 (build/make) jcollie
qa-assistant-0.4.90.5-2.fc6 (build/make) toshio
qpidc-0.2-5.fc7 (build/make) aconway,nsantos
rekall-2.4.5-6.fc8.1 (build/make) spot
renrot-0.25-2.fc7 (needs_perl_ExtUtils_MakeMaker) andriy
rhm-0.1-3.fc7 (build/make) aconway,nsantos
ruby-activerecord-1.15.1-1.fc7 (build/make) lutter
ruby-bdb-0.6.0-1.fc7 (build/make) errr
rxvt-unicode-8.3-1.fc8 (build/make) awjb
seahorse-1.0.1-9.fc8 (build/make) skvidal
shapelib-1.2.10-12.20060304cvs (build/make) smccann
swatch-3.2.1-1.fc6 (needs_perl_ExtUtils_MakeMaker) jpo
synce-software-manager-0.9.0-7.fc6 (build/make) awjb
synce-trayicon-0.9.0-8.fc6 (build/make) awjb
syslog-ng-2.0.5-1.fc8 (build/make) jpo,pvrabec
sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (buildroot) giallu
tclabc-1.0.9-1.fc7 (build/make) gemi
tetex-3.0-41.fc8 (build/make) jnovy
udunits-1.12.4-11.fc8.2 (needs_perl_ExtUtils_MakeMaker) spot
unison-2.13.16-3.fc6 (build/make) gemi
util-linux-ng-2.13-2.fc8 (build/make) kzak
velocity-1.4-6jpp.1 (build/make) vivekl
xaos-3.2.3-1.fc7 (build/make) gemi
xdaliclock-2.23-3.fc6 (build/make) kaboom
xferstats-2.16-14.1 (build/make) than
xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser
xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung
xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint
xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint
xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint
xsri-2.1.0-12.fc8 (build/make) ssp
zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie

With bugs filed: 0
----------------------------------



-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From 440volt.tux at gmail.com  Mon Oct 15 04:16:31 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Mon, 15 Oct 2007 09:46:31 +0530
Subject: Orphaning some packages
In-Reply-To: <4712E105.606@kobold.org>
References: <20071014200614.0c957e31@vader.jdub.homelinux.org>
	<4712E105.606@kobold.org>
Message-ID: <539333cb0710142116k585aa31fg566bc0e2b9cf7600@mail.gmail.com>

i will pickup ddclient


> Josh Boyer wrote:
> > Time for a little fall cleaning.  I'm orphaning the following packages
> > as I no longer have a use for them:
> >
> > ddclient
> > tla
> > tcl-thread



-- 
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From debarshi.ray at gmail.com  Mon Oct 15 05:03:01 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 15 Oct 2007 10:33:01 +0530
Subject: Orphaning some packages
In-Reply-To: <20071014200614.0c957e31@vader.jdub.homelinux.org>
References: <20071014200614.0c957e31@vader.jdub.homelinux.org>
Message-ID: <3170f42f0710142203n714fb55enf894586ff91f4014@mail.gmail.com>

> Time for a little fall cleaning.  I'm orphaning the following packages
> as I no longer have a use for them:
>
> ddclient
> tla
> tcl-thread

I am interested in tla.

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From nicolas.mailhot at laposte.net  Mon Oct 15 08:08:56 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Oct 2007 10:08:56 +0200 (CEST)
Subject: Packing XPIs
Message-ID: <23308.192.54.193.51.1192435736.squirrel@rousalka.dyndns.org>

Hi,

Maybe there's enough firefox extensions to package a SIG dedicated to
defining extension packaging standards is in order?

And while we're at it, handling OO.o extensions would be nice too

Regards,

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Oct 15 08:11:23 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Oct 2007 10:11:23 +0200 (CEST)
Subject: gethostby* users
Message-ID: <36649.192.54.193.51.1192435883.squirrel@rousalka.dyndns.org>


Le Dim 14 octobre 2007 22:55, Les Mikesell a ?crit :
> Nicolas Mailhot wrote:

>> ? but you certainly do not know non-sendmail stuff either.
>
> I used smail before it was abandoned; I've used qmail enough to hate
> it, tried postfix before it had anything resembling a milter,

As someone already suggested, take a look at amavisd-new + postfix

-- 
Nicolas Mailhot



From lkundrak at redhat.com  Mon Oct 15 09:55:18 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 15 Oct 2007 11:55:18 +0200
Subject: Packing XPIs
In-Reply-To: <23308.192.54.193.51.1192435736.squirrel@rousalka.dyndns.org>
References: <23308.192.54.193.51.1192435736.squirrel@rousalka.dyndns.org>
Message-ID: <1192442118.8856.15.camel@localhost.localdomain>


On Mon, 2007-10-15 at 10:08 +0200, Nicolas Mailhot wrote:
> Hi,
> 
> Maybe there's enough firefox extensions to package a SIG dedicated to
> defining extension packaging standards is in order?

I'd prefer if the standard just said "do not do it" :) Imagine the
amount of poor quality extensions that might eventually hit fedora then
(trust me, there's a big amount of them :), which would need continuous
work of ensuring security and compatibility between updates, etc. etc.
Most of them would really be better installed on per-user basis, and
updates done by mozilla's (well, at least firefox does that) built in
update and compatibility check system.

While I am definitely against the idea of a dedicated SIG, some
extensions will still be nice in Fedora. This means some really popular
and well tested ones with good security track, and translations that
posses no security risk by its nature.

Probably if it were a way to convert them easily to RPMs for people that
deploy their own extensions via own repositories it would be superb. I
still do not know. Is this worth filing upstream as a feature request:
"A way to automate extension installation (from commandline)"?

> And while we're at it, handling OO.o extensions would be nice too

I was not even aware that OOo also support extensions :}

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicolas.mailhot at laposte.net  Mon Oct 15 10:36:51 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 15 Oct 2007 12:36:51 +0200 (CEST)
Subject: Packing XPIs
Message-ID: <34869.192.54.193.51.1192444611.squirrel@rousalka.dyndns.org>


Le Lun 15 octobre 2007 11:55, Lubomir Kundrak a ?crit :
>
> On Mon, 2007-10-15 at 10:08 +0200, Nicolas Mailhot wrote:
>> Hi,
>>
>> Maybe there's enough firefox extensions to package a SIG dedicated
>> to
>> defining extension packaging standards is in order?
>
> I'd prefer if the standard just said "do not do it" :) Imagine the
> amount of poor quality extensions that might eventually hit fedora
> then

Well if we don't do them they'll hit our users anyway, so I'd rather
have a SIG do the most popular right (and have users take the habit of
looking at rpms first) than have them download unknown code from the
internet and blame us if things go wrong.

And "most popular" is definitely enough volume for a SIG

>> And while we're at it, handling OO.o extensions would be nice too
>
> I was not even aware that OOo also support extensions :}

Because we've sucked at intagrating OO.o extensions, and we've not
provided a credible plugin deployment alternatives, so OO.o decided
going the firefox direct dowload way was their only solution.

-- 
Nicolas Mailhot



From pertusus at free.fr  Mon Oct 15 10:36:30 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 15 Oct 2007 12:36:30 +0200
Subject: Packing XPIs
In-Reply-To: <1192442118.8856.15.camel@localhost.localdomain>
References: <23308.192.54.193.51.1192435736.squirrel@rousalka.dyndns.org>
	<1192442118.8856.15.camel@localhost.localdomain>
Message-ID: <20071015103630.GE2858@free.fr>

On Mon, Oct 15, 2007 at 11:55:18AM +0200, Lubomir Kundrak wrote:
> 
> On Mon, 2007-10-15 at 10:08 +0200, Nicolas Mailhot wrote:
> > Hi,
> > 
> > Maybe there's enough firefox extensions to package a SIG dedicated to
> > defining extension packaging standards is in order?
> 
> I'd prefer if the standard just said "do not do it" :) 

This is not something that should be in the scope of the guidelines.
Guidelines should be as less as possible about what to package, but
about how (of course there is the legal stuff).
 
> some extensions will still be nice in Fedora. 

This is pretty inconsistent, isn't it? If there is to be some extensions
in fedora, and some things have to be in guidelines, they should be.

In any case I can't see what is different between a firefox extension
and any other software in fedora. A reviewer can always (and should) 
question the relevance to add a package to fedora if the package has a 
bad record or security issues, or even a bad design and so on and so forth, 
but it doesn't need anything to be in the guideliens for that. 

Also users are not forced to install anything.

> "A way to automate extension installation (from commandline)"?

Much inferior solution than 'package what should be packaged', in my
opinion.

--
Pat



From andy at warmcat.com  Mon Oct 15 10:50:29 2007
From: andy at warmcat.com (Andy Green)
Date: Mon, 15 Oct 2007 11:50:29 +0100
Subject: gethostby* users
In-Reply-To: <4712825E.1040109@gmail.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>	<1192348902.12099.1.camel@rousalka.dyndns.org>	<47125A6C.2020803@gmail.com>	<1192392107.3133.1.camel@rousalka.dyndns.org>
	<4712825E.1040109@gmail.com>
Message-ID: <471345F5.20106@warmcat.com>

Somebody in the thread at some point said:
> Nicolas Mailhot wrote:
>> Le dimanche 14 octobre 2007 ? 13:05 -0500, Les Mikesell a ?crit :
>>
>>> As far as I know, none of the other MTA's are completely compatible
>>> with sendmail in the way (or whether) they expose details that the
>>> milter needs to know,
>>
>> I won't pretend I know sendmail well enough to judge there?
>>
>>> And the non-milter alternatives generally suffer from one or more of 
>>
>> ? but you certainly do not know non-sendmail stuff either.
> 
> I used smail before it was abandoned; I've used qmail enough to hate it,
> tried postfix before it had anything resembling a milter, and always
> ended up going back to sendmail.  But, if anything else currently has
> the ability to manage customizable helper processes and multiplex jobs
> efficiently among them in a way that only requires mime and zip
> unpacking to be done onces even if you scan multiple times, I'd be happy
> to hear about it.

''Postfix before-queue Milter support

Introduction

 Postfix version 2.3 introduces support for the Sendmail version 8
Milter (mail filter) protocol. This protocol is used by applications
that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
SMTP commands (HELO, MAIL FROM, etc.) as well as mail content. All this
happens before mail is queued.

 The reason for adding Milter support to Postfix is that there exists a
large collection of applications, not only to block unwanted mail, but
also to verify authenticity (examples: Domain keys identified mail,
SenderID+SPF and Domain keys) or to digitally sign mail (examples:
Domain keys identified mail, Domain keys). Having yet another
Postfix-specific version of all that software is a poor use of human and
system resources.

 Postfix version 2.4 implements all the requests of Sendmail version 8
Milter protocols up to version 4, including message body replacement
(body replacement is not available with Postfix version 2.3). See,
however, the workarounds and limitations sections at the end of this
document.

...''

http://www.postfix.org/MILTER_README.html

I have been able to get Postfix to do what I want without too much of a
massive effort, whereas when I first tried to use Sendmail I though the
m4 config must be an April Fool's joke.  I guess if mail is a large part
of what you do, you can ride over that kind of quirk and become and
"sendmail expert" and get the job done.

-Andy



From lesmikesell at gmail.com  Mon Oct 15 12:55:11 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 15 Oct 2007 07:55:11 -0500
Subject: gethostby* users
In-Reply-To: <471345F5.20106@warmcat.com>
References: <45290.192.54.193.51.1192178487.squirrel@rousalka.dyndns.org>	<20071012130230.GA1451534@hiwaay.net>	<1192267734.13901.2.camel@pmac.infradead.org>	<47116702.10604@gmail.com>	<1192348902.12099.1.camel@rousalka.dyndns.org>	<47125A6C.2020803@gmail.com>	<1192392107.3133.1.camel@rousalka.dyndns.org>	<4712825E.1040109@gmail.com>
	<471345F5.20106@warmcat.com>
Message-ID: <4713632F.8010708@gmail.com>

Andy Green wrote:

>> But, if anything else currently has
>> the ability to manage customizable helper processes and multiplex jobs
>> efficiently among them in a way that only requires mime and zip
>> unpacking to be done onces even if you scan multiple times, I'd be happy
>> to hear about it.
> 
> ''Postfix before-queue Milter support
> 
> Introduction
> 
>  Postfix version 2.3 introduces support for the Sendmail version 8
> Milter (mail filter) protocol. This protocol is used by applications
> that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
> SMTP commands (HELO, MAIL FROM, etc.) as well as mail content. All this
> happens before mail is queued.
> 
>  The reason for adding Milter support to Postfix is that there exists a
> large collection of applications, not only to block unwanted mail, but
> also to verify authenticity (examples: Domain keys identified mail,
> SenderID+SPF and Domain keys) or to digitally sign mail (examples:
> Domain keys identified mail, Domain keys). Having yet another
> Postfix-specific version of all that software is a poor use of human and
> system resources.
> 
>  Postfix version 2.4 implements all the requests of Sendmail version 8
> Milter protocols up to version 4, including message body replacement
> (body replacement is not available with Postfix version 2.3). See,
> however, the workarounds and limitations sections at the end of this
> document.

I suspect those limitations include not passing info about 
authentication and encryption the same way as sendmail, and that would 
keep it from working out-of-the-box with MimeDefang.  At least I'm not 
aware of anyone making it work yet.  If I had a problem with sendmail 
I'd probably put some effort into that.

> I have been able to get Postfix to do what I want without too much of a
> massive effort, whereas when I first tried to use Sendmail I though the
> m4 config must be an April Fool's joke.  I guess if mail is a large part
> of what you do, you can ride over that kind of quirk and become and
> "sendmail expert" and get the job done.

The basic part of sendmail configuration has been solved by including 
the m4 macros for all the common situations that are invoked by a 
one-line entry in sendmail.mc. As shipped in fedora, changes to 
sendmail.mc will automatically rebuild sendmail.cf and take effect 
whenever sendmail is restarted.  And other than needing one change to 
accept outside mail, the stock config shipped with fedora is good for 
most internet situations.  The aliases, access, mailertable, etc. files 
are relatively straightforward to configure for your local situation. 
Using MimeDefang solves the rest of the problem for additional 
customization.  When using it, you can simply write your site-specific 
additions in a perl snippets that execute in the milter phases instead 
of having to mess with the mailer's internal language or limitations. 
Being able to verify recipients on a different machine via smtp before 
accepting a message is a good example of that kind of extension.


-- 
   Les Mikesell
    lesmikesell at gmail.com



From katzj at redhat.com  Mon Oct 15 13:19:09 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 15 Oct 2007 09:19:09 -0400
Subject: Packing XPIs
In-Reply-To: <34869.192.54.193.51.1192444611.squirrel@rousalka.dyndns.org>
References: <34869.192.54.193.51.1192444611.squirrel@rousalka.dyndns.org>
Message-ID: <1192454349.25568.6.camel@localhost.localdomain>

On Mon, 2007-10-15 at 12:36 +0200, Nicolas Mailhot wrote:
> Le Lun 15 octobre 2007 11:55, Lubomir Kundrak a ?crit :
> > On Mon, 2007-10-15 at 10:08 +0200, Nicolas Mailhot wrote:
> >> Maybe there's enough firefox extensions to package a SIG dedicated
> >> to
> >> defining extension packaging standards is in order?
> >
> > I'd prefer if the standard just said "do not do it" :) Imagine the
> > amount of poor quality extensions that might eventually hit fedora
> > then
> 
> Well if we don't do them they'll hit our users anyway, so I'd rather
> have a SIG do the most popular right (and have users take the habit of
> looking at rpms first) than have them download unknown code from the
> internet and blame us if things go wrong.

It'd also be interesting to look at some of the Ubuntu patches which
download extensions and plugins as packages.  Of course, the fun with
firefox is always their trademark guidelines so anythign along these
lines has to tread carefully.

Jeremy



From tjb at unh.edu  Mon Oct 15 13:35:38 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Mon, 15 Oct 2007 09:35:38 -0400
Subject: Ekiga working for anyone?
In-Reply-To: <20071015002728.GA3593@jadzia.bu.edu>
References: <20071015002728.GA3593@jadzia.bu.edu>
Message-ID: <1192455338.3757.1.camel@raptor.sr.unh.edu>


On Sun, 2007-10-14 at 20:27 -0400, Matthew Miller wrote:
> So, is Ekiga working for anyone? Whenever I connect, I immediately get a
> crash with a floating point error and a message about something audio
> related....

It works for me but I had to set the audio input and output to specific
devices instead of the "default" ones. With default, I got a dialog box
about not being able to use the audio device because it may be in use or
something along those lines. 

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From mattdm at mattdm.org  Mon Oct 15 13:53:45 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 15 Oct 2007 09:53:45 -0400
Subject: Ekiga working for anyone?
In-Reply-To: <4712D472.7050009@redhat.com>
References: <20071015002728.GA3593@jadzia.bu.edu>
	<e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>
	<4712D472.7050009@redhat.com>
Message-ID: <20071015135345.GA31484@jadzia.bu.edu>

On Sun, Oct 14, 2007 at 09:46:10PM -0500, Mike McGrath wrote:
> >>So, is Ekiga working for anyone? Whenever I connect, I immediately get a
> >>crash with a floating point error and a message about something audio
> >>related....
> >It is working for me.  I just used it earlier today.  I am on my
> >laptop with the newest rawhide using the internal VIA chipset
> >soundcard for playback and the USB mic from recording.
> WORKSFORME, what version/dist are you having problems on?

Rawhide. Talking to both Ekiga running on windows and to Xmeeting on a Mac.
I wonder if it's a problem with a specific codec -- I vaguely remember
vaguely reordering them when playing around with the settings, and maybe
something broken is coming up first.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From lkundrak at redhat.com  Mon Oct 15 14:47:04 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 15 Oct 2007 16:47:04 +0200
Subject: Ekiga working for anyone?
In-Reply-To: <20071015135345.GA31484@jadzia.bu.edu>
References: <20071015002728.GA3593@jadzia.bu.edu>
	<e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>
	<4712D472.7050009@redhat.com>  <20071015135345.GA31484@jadzia.bu.edu>
Message-ID: <1192459624.30612.4.camel@localhost.localdomain>


On Mon, 2007-10-15 at 09:53 -0400, Matthew Miller wrote:
> On Sun, Oct 14, 2007 at 09:46:10PM -0500, Mike McGrath wrote:
> > >>So, is Ekiga working for anyone? Whenever I connect, I immediately get a
> > >>crash with a floating point error and a message about something audio
> > >>related....
> > >It is working for me.  I just used it earlier today.  I am on my
> > >laptop with the newest rawhide using the internal VIA chipset
> > >soundcard for playback and the USB mic from recording.
> > WORKSFORME, what version/dist are you having problems on?
> 
> Rawhide. Talking to both Ekiga running on windows and to Xmeeting on a Mac.
> I wonder if it's a problem with a specific codec -- I vaguely remember
> vaguely reordering them when playing around with the settings, and maybe
> something broken is coming up first.

Could you please file a bug? Also, please install ekiga-debuginfo,
produce a stack trace and all that to the bug.

Maybe attach a configuration of ekiga (produced with something like
"gconftool-2 --dump /apps/ekiga", dunno if this one actually works) and
details about you audio hardware to the bug.

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From markg85 at gmail.com  Mon Oct 15 14:50:56 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 15 Oct 2007 16:50:56 +0200
Subject: Fedora caching suggestion
Message-ID: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>

Hey,

I've followed the discussion about readahead and it got disabled for
Fedora 8 (it wasn't benefiting at all (at least not for me)). Now i
wonder if it would be possible to pre cache the "all time using"
programs? With "all time using" i mean all the programs that are gonna
be started anyway and that are highly likely to be started. for gnome
it would be at least the following:

- Firefox
- gnome-panel
- GDM
- all the desktop wallpapers (the 24 hours wallpaper animation)
- the gnome menu
- all the echo icons (small sizes)

And probably a few more that i missed. All those applications get
started sooner or later anyway so i think it's best to cache as much
as possible of them to make them as fast as possible which will also
provide a better user experience.

Would this be possible to do for F8?
Or is this suggestion to late for F8?

Mark.



From ville.skytta at iki.fi  Mon Oct 15 14:57:57 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 15 Oct 2007 17:57:57 +0300
Subject: vdr-femon license change (GPL+ -> GPLv2+)
Message-ID: <200710151757.57995.ville.skytta@iki.fi>

The license of vdr-femon has been clarified to be GPLv2+ from 1.1.4 onwards 
(was GPL+ earlier).  vdr-femon is a plugin for VDR, nothing depends on it.



From oliver at linux-kernel.at  Mon Oct 15 15:04:27 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Mon, 15 Oct 2007 17:04:27 +0200
Subject: what the heck is going on with the kernel package?!
Message-ID: <4713817B.8050903@linux-kernel.at>

[root at sapporo ~]# rpm -qi kernel-2.6.22.9-91.fc7
Name        : kernel                       Relocations: (not relocatable)
Version     : 2.6.22.9                          Vendor: Fedora Project
Release     : 91.fc7                        Build Date: Fri 28 Sep 2007
06:07:15 AM CEST
Install Date: Mon 01 Oct 2007 09:37:43 AM CEST      Build Host:
xenbuilder1.fedora.redhat.com
Group       : System Environment/Kernel     Source RPM:
kernel-2.6.22.9-91.fc7.src.rpm
Size        : 49238647                         License: GPLv2
Signature   : DSA/SHA1, Fri 28 Sep 2007 09:04:42 PM CEST, Key ID
b44269d04f2a6fd2
Packager    : Fedora Project
Summary     : The Linux kernel (the core of the Linux operating system)
Description :
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system.  The kernel handles the basic functions
of the operating system:  memory allocation, process allocation, device
input and output, etc.


[root at tuborg ~]# rpm -qi kernel-2.6.22.9-91.fc7
Name        : kernel                       Relocations: (not relocatable)
Version     : 2.6.22.9                          Vendor: Fedora Project
Release     : 91.fc7                        Build Date: Fri 28 Sep 2007
02:55:44 AM CEST
Install Date: Mon 01 Oct 2007 09:27:49 AM CEST      Build Host:
xenbuilder2.fedora.redhat.com
Group       : System Environment/Kernel     Source RPM:
kernel-2.6.22.9-91.fc7.src.rpm
Size        : 47113673                         License: GPLv2
Signature   : DSA/SHA1, Fri 28 Sep 2007 09:04:46 PM CEST, Key ID
b44269d04f2a6fd2
Packager    : Fedora Project
Summary     : The Linux kernel (the core of the Linux operating system)
Description :
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system.  The kernel handles the basic functions
of the operating system:  memory allocation, process allocation, device
input and output, etc.




Can please someone explain this to me?

Thx,
 Oliver



From jima at beer.tclug.org  Mon Oct 15 15:11:06 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 15 Oct 2007 10:11:06 -0500 (CDT)
Subject: what the heck is going on with the kernel package?!
In-Reply-To: <4713817B.8050903@linux-kernel.at>
References: <4713817B.8050903@linux-kernel.at>
Message-ID: <Pine.LNX.4.64.0710151010460.4486@beer.tclug.org>

On Mon, 15 Oct 2007, Oliver Falk wrote:
> Can please someone explain this to me?

  Answered on IRC; i686 vs. i586. :-)

      Jima



From oliver at linux-kernel.at  Mon Oct 15 15:11:17 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Mon, 15 Oct 2007 17:11:17 +0200
Subject: what the heck is going on with the kernel package?!
In-Reply-To: <4713817B.8050903@linux-kernel.at>
References: <4713817B.8050903@linux-kernel.at>
Message-ID: <47138315.7090308@linux-kernel.at>

On 10/15/2007 05:04 PM, Oliver Falk wrote:

> Can please someone explain this to me?

Well. One's i586, one is i686..

-of



From jreiser at BitWagon.com  Mon Oct 15 15:14:37 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 15 Oct 2007 08:14:37 -0700
Subject: what the heck is going on with the kernel package?!
In-Reply-To: <4713817B.8050903@linux-kernel.at>
References: <4713817B.8050903@linux-kernel.at>
Message-ID: <471383DD.3010200@BitWagon.com>

Oliver Falk wrote:
> [root at sapporo ~]# rpm -qi kernel-2.6.22.9-91.fc7
[snip 18 lines]

> [root at tuborg ~]# rpm -qi kernel-2.6.22.9-91.fc7
[snip 18 lines, much the same]

> Can please someone explain this to me?

Your request should indicate specifically what you believe is wrong.
Expecting your readers to do a 'diff' of 18 lines is laziness on your part.

-- 



From dwalsh at redhat.com  Mon Oct 15 15:15:10 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 15 Oct 2007 11:15:10 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192420770.2612.2.camel@tiger>
References: <1192204108.2492.7.camel@tiger> <1192420770.2612.2.camel@tiger>
Message-ID: <471383FE.2070600@redhat.com>

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

Louis E Garcia II wrote:
> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
>> I put a pix of myself in the 'about me' capplet and have a .face in my
>> home dir. Why doesn't gdm pick it up?
>>
>> -Louis
> 
> Would this be the cause?
> 
> SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
> (home_root_t).
> 
> 
> 
Quite possibly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHE4P+rlYvE4MpobMRAm+5AJ4i/XdKx0bD9Tw+CVzPhMFwvO2yoACg11Yh
JsQNH6VPEKUsa4sfOGx9LQk=
=Hmkb
-----END PGP SIGNATURE-----



From ajackson at redhat.com  Mon Oct 15 14:57:36 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 15 Oct 2007 10:57:36 -0400
Subject: libpciaccess in f8?
In-Reply-To: <1192391732.2688.5.camel@tiger>
References: <1192391732.2688.5.camel@tiger>
Message-ID: <1192460256.9104.2.camel@localhost.localdomain>

On Sun, 2007-10-14 at 15:55 -0400, Louis E Garcia II wrote:
> Is libpciaccess a requirement in f8? Just did an update and libpciaccess
> was pulled in by xorg-x11-drv-avivo. I thought avivo was superseded by
> radeonhd?

It's a bit early to call either one a replacement for the other, since
neither one works.

- ajax



From k.georgiou at imperial.ac.uk  Mon Oct 15 15:29:02 2007
From: k.georgiou at imperial.ac.uk (Kostas Georgiou)
Date: Mon, 15 Oct 2007 16:29:02 +0100
Subject: gdm dosen't show my pix on the face greeter
In-Reply-To: <1192205994.19420.11.camel@oneill.fubar.dk>
References: <1192204108.2492.7.camel@tiger>
	<1192204588.16148.3.camel@cookie.hadess.net>
	<1192205994.19420.11.camel@oneill.fubar.dk>
Message-ID: <20071015152902.GA19001@imperial.ac.uk>

On Fri, Oct 12, 2007 at 12:19:54PM -0400, David Zeuthen wrote:

> 
> On Fri, 2007-10-12 at 16:56 +0100, Bastien Nocera wrote:
> > On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > > I put a pix of myself in the 'about me' capplet and have a .face in my
> > > home dir. Why doesn't gdm pick it up?
> > 
> > Check the permissions on your home directory and ~/.face.
> > 
> > If your home directory doesn't allow for the gdm user to access ~/.face,
> > then it won't work...
> 
> Actually it's supposed to work because the gdm greeter gets the faces
> through a pipe from the master gdm process which is running as root.

That it's running as root doesn't mean that it will always have access
to a home directory, the home might be on NFS or AFS for example.

Kostas 



From ville.skytta at iki.fi  Mon Oct 15 15:30:14 2007
From: ville.skytta at iki.fi (=?ISO-8859-1?Q?Ville_Skytt=E4?=)
Date: Mon, 15 Oct 2007 18:30:14 +0300
Subject: Ex-Core package Makefile.common problem in CVS
In-Reply-To: <200705121230.40181.ville.skytta@iki.fi>
References: <200705121230.40181.ville.skytta@iki.fi>
Message-ID: <8718ff870710150830k5a24318eo19506d54e7983402@mail.gmail.com>

On 5/12/07, Ville Skytt? <ville.skytta at iki.fi> wrote:
> Hi,
>
> After checking out "rpms" from cvs.fedora.redhat.com:/cvs/pkgs, ex-Core
> package branch Makefiles have issues finding Makefile.common.  Ex-Extras
> packages don't have that problem - looks like "find-makefile-common" stuff or
> something similar should be applied to ex-Core branch Makefiles too.
>
> For example:
> $ cd shadow-utils/devel
> $ make prep
> Makefile:6: ../common/Makefile.common: No such file or directory
> make: *** No rule to make target `../common/Makefile.common'.  Stop.

After 5 months, nothing has happened to this and the infrastructure
ticket [0] is unanswered as well, so I'm going to go ahead and start
fixing these Makefiles myself for packages whose ACLs allow it (yes,
will preserve possible maintainer additions to affected files).

[0] https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/42



From a.badger at gmail.com  Mon Oct 15 15:53:28 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 15 Oct 2007 08:53:28 -0700
Subject: Ex-Core package Makefile.common problem in CVS
In-Reply-To: <8718ff870710150830k5a24318eo19506d54e7983402@mail.gmail.com>
References: <200705121230.40181.ville.skytta@iki.fi>
	<8718ff870710150830k5a24318eo19506d54e7983402@mail.gmail.com>
Message-ID: <47138CF8.8020204@gmail.com>

Ville Skytt? wrote:

> After 5 months, nothing has happened to this and the infrastructure
> ticket [0] is unanswered as well, so I'm going to go ahead and start
> fixing these Makefiles myself for packages whose ACLs allow it (yes,
> will preserve possible maintainer additions to affected files).
> 
> [0] https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/42
> 
Sorry no one worked on that ticket and thanks for doing the work that 
you can!  Let me know if you need someone to run your scripts on the 
packages for which the acls aren't open to you.

/me CC's himself to ticket

-Toshio



From lkundrak at redhat.com  Mon Oct 15 16:02:47 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 15 Oct 2007 18:02:47 +0200
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192420770.2612.2.camel@tiger>
References: <1192204108.2492.7.camel@tiger>  <1192420770.2612.2.camel@tiger>
Message-ID: <1192464167.30612.20.camel@localhost.localdomain>


On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > I put a pix of myself in the 'about me' capplet and have a .face in my
> > home dir. Why doesn't gdm pick it up?
> > 
> > -Louis
> 
> Would this be the cause?
> 
> SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
> (home_root_t).

Aren'y you using the root account, are you? Where is your login picture
located? Have you tried runing restorecon on the image?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From oliver at linux-kernel.at  Mon Oct 15 16:11:14 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Mon, 15 Oct 2007 18:11:14 +0200
Subject: rpms/perl/devel perl.spec,1.136,1.137
In-Reply-To: <200710151600.l9FG03bf006271@cvs-int.fedora.redhat.com>
References: <200710151600.l9FG03bf006271@cvs-int.fedora.redhat.com>
Message-ID: <47139122.1080303@linux-kernel.at>

Spot, do you see and chance to Require db = x.x.x in perl spec? I
updated db4 today on one devel machine and what happens? Apache doesn't
start any more, because of DB_File, that wants older db4 :-(

Well, cpan is your friend and this is easily fixed...

However, the problem occurs every time you update db4 from one version
to another...

Best,
 Oliver

On 10/15/2007 06:00 PM, Tom Callaway (spot) wrote:
> Author: spot
> 
> Update of /cvs/pkgs/rpms/perl/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6182
> 
> Modified Files:
> 	perl.spec 
> Log Message:
> 
> Bump for db4 version change
> 
> 
> 
> Index: perl.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/perl/devel/perl.spec,v
> retrieving revision 1.136
> retrieving revision 1.137
> diff -u -r1.136 -r1.137
> --- perl.spec	3 Oct 2007 20:24:26 -0000	1.136
> +++ perl.spec	15 Oct 2007 15:59:25 -0000	1.137
> @@ -20,7 +20,7 @@
>  
>  Name:           perl
>  Version:        %{perl_version}
> -Release:        28%{?dist}.1
> +Release:        28%{?dist}.2
>  Epoch:          %{perl_epoch}
>  Summary:        The Perl programming language
>  Group:          Development/Languages
> @@ -778,6 +778,9 @@
>  # Nothing. Nada. Zilch. Zarro. Uh uh. Nope. Sorry.
>  
>  %changelog
> +* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.2
> +- bump again for db4 version increase
> +
>  * Mon Oct  1 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28
>  - update DB_File to 1.815
>  
> 


-- 
Oliver Falk
UNIX/Linux Systems Engineer
Mail: oliver at linux-kernel.at
Phone: +43 (664) 838 59 25



From louisg00 at bellsouth.net  Mon Oct 15 16:25:38 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Mon, 15 Oct 2007 12:25:38 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192420770.2612.2.camel@tiger>
References: <1192204108.2492.7.camel@tiger>  <1192420770.2612.2.camel@tiger>
Message-ID: <1192465539.2792.6.camel@tiger>

On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
> On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
> > On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > > I put a pix of myself in the 'about me' capplet and have a .face in my
> > > home dir. Why doesn't gdm pick it up?
> > > 
> > > -Louis
> > 
> > Would this be the cause?
> > 
> > SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
> > (home_root_t).
> > 
> > 
> 
> Aren'y you using the root account, are you? Where is your login
> picture located? Have you tried runing restorecon on the image?

No, this is a normal user account in /home a seperate partition.

$ls -Z .face
-rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face




From steve at silug.org  Mon Oct 15 18:28:14 2007
From: steve at silug.org (Steven Pritchard)
Date: Mon, 15 Oct 2007 13:28:14 -0500
Subject: perl-Apache-Session license change (Artistic -> GPL+ or Artistic)
Message-ID: <20071015182814.GA16581@osiris.silug.org>

The License tag on perl-Apache-Session has changed from "Artistic" to
"GPL+ or Artistic" with version 1.84.  Apparently the actual license
change happened some time in the distant past, but was somehow missed.

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)624-4440               Mobile: (618)567-7320



From notting at redhat.com  Mon Oct 15 18:31:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 15 Oct 2007 14:31:49 -0400
Subject: Ex-Core package Makefile.common problem in CVS
In-Reply-To: <47138CF8.8020204@gmail.com>
References: <200705121230.40181.ville.skytta@iki.fi>
	<8718ff870710150830k5a24318eo19506d54e7983402@mail.gmail.com>
	<47138CF8.8020204@gmail.com>
Message-ID: <20071015183149.GD17960@nostromo.devel.redhat.com>

Toshio Kuratomi (a.badger at gmail.com) said: 
> Sorry no one worked on that ticket and thanks for doing the work that you 
> can!  Let me know if you need someone to run your scripts on the packages 
> for which the acls aren't open to you.

Done (well, whenever CVS finishes committing. Could be hours!)

Bill



From dwalsh at redhat.com  Mon Oct 15 18:57:54 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 15 Oct 2007 14:57:54 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192465539.2792.6.camel@tiger>
References: <1192204108.2492.7.camel@tiger> <1192420770.2612.2.camel@tiger>
	<1192465539.2792.6.camel@tiger>
Message-ID: <4713B832.9020309@redhat.com>

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

Louis E Garcia II wrote:
> On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
>> On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
>>> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
>>>> I put a pix of myself in the 'about me' capplet and have a .face in my
>>>> home dir. Why doesn't gdm pick it up?
>>>>
>>>> -Louis
>>> Would this be the cause?
>>>
>>> SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
>>> (home_root_t).
>>>
>>>
>> Aren'y you using the root account, are you? Where is your login
>> picture located? Have you tried runing restorecon on the image?
> 
> No, this is a normal user account in /home a seperate partition.
> 
> $ls -Z .face
> -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
> 
> 
Thils looks like the wrong location for this file.

In my case it would be

/home/dwalsh/.face

And it would have a context of user_home_t?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHE7gyrlYvE4MpobMRAiCaAKCTw9jbt4A3bimilKZ8t2aT23NxFgCgoArw
gX/5s4eRcl0omHkEBL4uTpI=
=7rd+
-----END PGP SIGNATURE-----



From skvidal at fedoraproject.org  Mon Oct 15 18:57:16 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 15 Oct 2007 14:57:16 -0400
Subject: what the heck is going on with the kernel package?!
In-Reply-To: <47138315.7090308@linux-kernel.at>
References: <4713817B.8050903@linux-kernel.at>
	<47138315.7090308@linux-kernel.at>
Message-ID: <1192474636.2393.27.camel@cutter>


On Mon, 2007-10-15 at 17:11 +0200, Oliver Falk wrote:
> On 10/15/2007 05:04 PM, Oliver Falk wrote:
> 
> > Can please someone explain this to me?
> 
> Well. One's i586, one is i686..

yes - and the concern is why you now have an i586 kernel. Can you post
your yum.log for the last few updates?

thanks,
-sv




From denis at poolshark.org  Mon Oct 15 19:00:15 2007
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 15 Oct 2007 21:00:15 +0200
Subject: F7 koji build not present in build-current repo ?
Message-ID: <4713B8BF.9050907@poolshark.org>

I build hamlib 1.2.6.2 on koji for a F-7 update:

http://koji.fedoraproject.org/koji/buildinfo?buildID=20798

that was 3 days ago. I still don't see the new hamlib RPMs showing up on 
  the koji dist-fc7-build-current repo, and that's preventing me from 
doing rebuilds on a couple of packages that are affected by this update. 
  did something fall thru cracks ? :-)

-denis



From jkeating at redhat.com  Mon Oct 15 19:18:58 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 15 Oct 2007 15:18:58 -0400
Subject: F7 koji build not present in build-current repo ?
In-Reply-To: <4713B8BF.9050907@poolshark.org>
References: <4713B8BF.9050907@poolshark.org>
Message-ID: <20071015151858.515f93b0@redhat.com>

On Mon, 15 Oct 2007 21:00:15 +0200
Denis Leroy <denis at poolshark.org> wrote:

> I build hamlib 1.2.6.2 on koji for a F-7 update:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=20798
> 
> that was 3 days ago. I still don't see the new hamlib RPMs showing up
> on the koji dist-fc7-build-current repo, and that's preventing me
> from doing rebuilds on a couple of packages that are affected by this
> update. did something fall thru cracks ? :-)


Candidate update builds (and testing update builds) do not populate the
buildroot.  Only final updates or things requested to be tagged into
the buildroots for building update chains.  Request your build be
tagged for the buildroot via rel-eng at fedoraproject.org

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071015/a1f988f8/attachment.sig>

From buildsys at redhat.com  Mon Oct 15 19:24:12 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 15 Oct 2007 15:24:12 -0400
Subject: rawhide report: 20071015 changes
Message-ID: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>

New package archimedes
	2D Quantum Monte Carlo simulator for semiconductor devices

New package flawfinder
	Examines C/C++ source code for security flaws

New package gimp-resynthesizer
	Gimp plug-in for texture synthesis

New package ilmbase
	Abraction/convenience libraries

New package linuxdcpp
	Direct Connect client

New package opyum
	Offline package installation and update tools


 
Updated Packages:

OpenEXR-1.6.0-4.fc8
-------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-4
- -libs: %post/%postun -p /sbin/ldconfig

* Fri Oct 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-2
- openexr-1.6.0

allegro-4.2.2-6.fc8
-------------------
* Sun Oct 14 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 4.2.2-6
- Require timidity++-patches instead of timidity++ itself so that we don't
  drag in arts and through arts, qt and boost
- Add BuildRequires: glib2-devel to workaround RH bug 331841

* Wed Aug 22 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 4.2.2-5
- Update to pristine upstream sources instead of using allegro.cc pre-release

alsa-lib-1.0.15-0.3.rc3.fc8
---------------------------
* Mon Oct 15 2007 Martin Stransky <stransky at redhat.com> 1.0.15-0.3.rc3
- updated to 1.0.15rc3

anaconda-11.3.0.39-2
--------------------
* Sun Oct 14 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.39-2
- Fix build

* Fri Oct 12 2007 Chris Lumens <clumens at redhat.com> 11.3.0.39-1
- Detect PS3 disks (katzj, #325111).
- Fix lang setting for Romanian (#327431).
- Fix segfault in constructing HTTP headers in the loader (#328191).
- Remove ata_generic from the blacklist (katzj).
- Add dbus to upgrade remove blacklist (katzj).
- Extract firmware in mk-images (katzj).
- Write udev network device name rules (notting, #264901).
- Speed up upd-instroot quite a bit (Orion Poplawski).
- Fix formatting of /etc/hosts (katzj).
- Don't add labels to /etc/fstab for reused LVs (#216561).
- Allow liveinst on ppc (katzj).

arts-8:1.5.8-3.fc8
------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 8:1.5.8-3
- -devel: +Requires: glib2-deel (#331841)

blender-2.45-3.fc8
------------------
* Sun Oct 14 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.45-3
- Rebuild

buildbot-0.7.6-1.fc8
--------------------
* Mon Oct 15 2007 Gianluca Sforna <giallu gmail com> - 0.7.6-1
- new upstream release
- refreshed Patch0
- requires clean up
- License tag update (GPLv2)

* Sat Mar 17 2007 Gianluca Sforna <giallu gmail com>
- Silence rpmlint

dclib-0.3.11-1.fc8
------------------
* Sun Oct 14 2007 Luke Macken <lmacken at redhat.com> 0.3.11-1
- 0.3.11
- Remove patches:
    01-dclib-0.3.10-remove-cmd4.patch
    02-dclib-0.3.10-use-gnulib-md5.patch
    03-dclib-0.3.10-use-new-md5-api.patch
    04-dclib-0.3.10-gnulib-md5-configure-test.patch

gai-0.5.10-12.fc8
-----------------
* Mon Oct 15 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 0.5.10-12
- Patch gai/Makefile.in CFLAGS to find PangoFT2.

* Mon Sep 17 2007 Michel Salim <michel.sylvan at gmail.com> - 0.5.10-11
- License field updated

* Sun Jan 21 2007 Michel Salim <michel.salim at gmail.com>
- Remove unnecessary BR on mesa-libGLU-devel (added to gtkglext-devel)

gcin-1.3.5-2.fc8
----------------
* Mon Oct 15 2007 Chung-Yen Chang <candyz0416 at gmail.com> - 1.3.5-2
- update im-client.patch and newcj3.patch

* Sun Oct 14 2007 Chung-Yen Chang <candyz0416 at gmail.com> - 1.3.5-1
- update to 1.3.5

gdb-6.6-34.fc8
--------------
* Sun Oct 14 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-34
- Set the breakpoints always to all the ctors/dtors variants (BZ 301701).
- Fix non-threaded watchpoints CTRL-C regression on `set follow child'.
- Fix hardware watchpoints after inferior forks-off some process.

* Thu Oct 11 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-33
- Fix gdbserver for threaded applications and recent glibc (BZ 328021).

* Wed Oct 10 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-32
- Fix debug load for sparse assembler files (such as vDSO32 for i386-on-x86_64).
- Fix a TUI visual corruption due to the build-id warnings (BZ 320061).
- Fixed the kernel i386-on-x86_64 VDSO loading (producing `Lowest section in').

ghdl-0.25-0.89svn.6.fc8
-----------------------
* Mon Oct 08 2007 Thomas Sailer <t.sailer at alumni.ethz.ch> - 0.25-0.89svn.6
- ghdl-grt requires zlib-devel (rhbz 316311)
- make it build with makeinfo >= 4.10

giggle-0.3-5.fc8
----------------
* Sun Oct 14 2007 James Bowes <jbowes at redhat.com> 0.3-5
- Update gtksourceview2 patch to build against current code.

glibc-2.6.90-21
---------------
* Mon Oct 15 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-21
- fix getgr{name,gid}{,_r} with nscd

* Sun Oct 14 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-20
- install <bits/error.h> (#330031)
- disable -D_FORTIFY_SOURCE{,=2} support (with a warning) for
  GCC 3.4.x and earlier(#327641)
- pl_PL locale changes (BZ#4098, #242296)
- misc fixes (BZ#1140, BZ#3195, BZ#3242, BZ#4359)

hotwire-0.599-1.fc8
-------------------
* Sun Oct 14 2007 Colin Walters <walters at redhat.com> - 0.599-1
- new upstream

jasper-1.900.1-7.fc8
--------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.900.1-7
- -libs: %post/%postun -p /sbin/ldconfig

kdeartwork-3.5.8-1.fc8
----------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.5.8-1
- kde-3.5.8

kdebase-6:3.5.8-2.fc8
---------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-2
- update consolekit patch
- omit konsole-bz#244906 (doesn't build)
- --enable-final
- libs subpkg (more multilib friendly)

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-1
- kde-3.5.8

* Wed Oct 03 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.7-17
- Requires: findutils which (#312611)

kdebindings-3.5.8-1.fc8
-----------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-1
- kde-3.5.8

kdemultimedia-6:3.5.8-3.fc8
---------------------------
* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3
- -extras-libs: +%_libdir/libnoatunarts.*
- -libs,-extras-libs: %post/%postun -p /sbin/ldconfig

* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-2
- -extras-libs: +%defattr

kdepim-6:3.5.8-1.svn20071013.ent.fc8
------------------------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-1.20071013.ent
- kdepim-enterprise branch 20071013 snapshot (r724979)

* Wed Oct 03 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.7-10.20070926.ent
- xdg-open patch

kdesdk-3.5.8-1.fc8
------------------
* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-1
- kde-3.5.8
- libs subpkg (more multilib friendly)

kicad-2007.07.09-2.fc8
----------------------
* Mon Oct 15 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 2007.07.09-2
- Update desktop file

ksudoku-0.4-2.fc8
-----------------
* Sun Oct 14 2007 Rafa?? Psota <rafalzaq at gmail.com> - 0.4-2
- get rid of debug files in main package (#321811)

libtimidity-0.1.0-4.fc8
-----------------------
* Sun Oct 14 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.1.0-4
- Require timidity++-patches instead of timidity++ itself so that we don't
  drag in arts and through arts, qt and boost.
milter-greylist-4.0-0.2.rc1.fc8
-------------------------------
* Sun Oct 14 2007 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 4.0-0.2.rc1
- updated to 4.0rc1
- built with curl and GeoIP support

nspluginwrapper-0.9.91.5-7.fc8
------------------------------
* Mon Oct 15 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-7
- added a fix for #281061 - gnash fails when wrapped, works when native

perl-SVG-2.36-2.fc8
-------------------
* Sat Oct 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 2.36-2
- Add missing BR: perl(ExtUtils::MakeMaker)

* Sat Oct 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 2.36-1
- Update to 2.36

* Thu Aug 23 2007 Alex Lancaster <alexl at users.sourceforge.net> 2.34-2
- License tag to GPL+ or Artistic as per new guidelines.

perl-Text-Shellwords-1.08-3.fc8
-------------------------------
* Mon Oct 15 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.08-3
- Add missing BR: perl(ExtUtils::MakeMaker)

perl-bioperl-1.5.2_102-9.fc8
----------------------------
* Mon Oct 15 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.5.2_102-9
- Add missing BR: perl(ExtUtils::MakeMaker)
- Clarified license terms: GPL+ or Artistic

ppc64-utils-0.12-2.fc8
----------------------
* Sun Oct 14 2007 Jeremy Katz <katzj at redhat.com> - 0.12-2
- add files needed for creating bootable cds

python-cheetah-2.0-1.fc8
------------------------
* Mon Oct 15 2007 Mike Bonnet <mikeb at redhat.com> - 2.0-1
- update to the 2.0 release

ruby-1.8.6.110-2.fc8
--------------------
* Mon Oct 15 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.110-2
- Enable pthread support for ppc too. (#201452)
- Fix unexpected dependencies appears in ruby-libs. (#253325)

* Wed Oct 10 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.110-1
- New upstream release.
  - ruby-r12567.patch: removed.
- ruby-1.8.6-CVE-2007-5162.patch: security fix for Net::HTTP that is
  insufficient verification of SSL certificate.

* Thu Aug 23 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.36-4
- Rebuild

scim-python-0.1.4-2.fc8
-----------------------
* Mon Oct 15 2007 Huang Peng <shawn.p.huang at gmail.com> - 0.1.4-2
- Split this rpm. Package EnglishWriter in scim-python-english.rpm.

sepostgresql-8.2.5-1.31.fc8
---------------------------
* Mon Oct 15 2007 <kaigai at kaigai.gr.jp> - 8.2.5-1.31
- Fix bug: type definitions of security_label_to_text()
  and text_to_security_label() are mismatched.

system-config-network-1.4.3-1.fc8
---------------------------------
* Mon Oct 15 2007 Harald Hoyer <harald at redhat.com> - 1.4.3
- fixed /etc/hosts problem (rhbz#331451)

* Fri Oct 12 2007 Harald Hoyer <harald at redhat.com> - 1.4.3
- added version.py.in to POTFILES.in (rhbz#244053)
- corrected URL (rhbz#237717)

system-config-nfs-1.3.30-1.fc8
------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.30-1
- Merge review (#226465):
  - remove exports.py
  - remove "ExclusiveOS: Linux"
  - remove hicolor-icon-theme requirement, call gtk-update-icon-cache with full
    path

system-config-printer-0.7.74.4-3.fc8
------------------------------------
* Mon Oct 15 2007 Tim Waugh <twaugh at redhat.com> 0.7.74.4-3
- More fixes from stable branch:
  - More consistency and care in building command lines.
  - Do case-insensitive match when matching model word (Ubuntu #149264).
  - Set translation domain for applet (Ubuntu #149572).
  - Remove toolbar_style property so as not to over-ride the session
    preferences (Ubuntu #135844).

system-config-samba-1.2.56-1.fc8
--------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.56-1
- Merge review (#226468):
  - remove "ExclusiveOS: Linux"
  - remove hicolor-icon-theme requirement, call gtk-update-icon-cache with full
    path

system-config-services-0.9.15-1.fc8
-----------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.15-1
- Merge review (#226470):
  - remove hicolor-icon-theme, gtk2 requirements, call gtk-update-icon-cache
    with full path

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.14-1
- Merge review (#226470):
  - remove shebang line from nonblockingreader.py

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.13-1
- Merge review (#226470):
  - make obsoletes versioned
  - escape RPM macro in changelog
  - change license tag to GPLv2+
  - recoded documentation to UTF-8
  - install files with correct permissions
  - add release to changelog versions to appease rpmlint
  - use %config(noreplace)
  - use "make %{?_smp_mflags}"
  - use "%defattr(-,root,root,-)"
  - use xdg-open if available
- pick up updated translations

tailor-0.9.28-5.fc8
-------------------
* Sun Oct 14 2007 Dan Horak <dan[at]danny.cz> 0.9.28-5
- remove R: monotone (ppc), darcs (ppc64)
- remove ExcludeArch as it has no effect for noarch package

timidity++-2.13.2-4.fc8
-----------------------
* Sat Oct 13 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 2.13.2-4
- Split the patches of into a seperate sub package so that they can be used
  by other wavetable midi synthesizers, without dragging in a bunch of unwanted
  dependencies (bz 250735)
- There is no reason to install the icon in /usr/share/pixmaps if it also gets
  installed under /usr/share/icons
- Rewrite autodetection of wether to use esd, aRts or alsa as output patch,
  so that it actually works (bz 200688)

udev-116-1.fc8
--------------
* Mon Oct 15 2007 Harald Hoyer <harald at redhat.com> 116-1
- version 116

w3c-markup-validator-0.8.2-2.fc8
--------------------------------
* Sun Oct 14 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.8.2-2
- Apply upstream fix for missing form enctype in reupload form.

wildmidi-0.2.2-3.fc8
--------------------

xorg-x11-drv-i810-2.1.1-5.fc8
-----------------------------
* Mon Oct 15 2007 Dave Airlie <airlied at redhat.com> 2.1.1-5
- intel-2.1.1-fix-vt-switch.patch - Only restore paletter regs on enabled pipes
- intel-2.1.1-fix-xv-reset.patch - Reset XV after mode switch

xournal-0.4.1-3.fc8
-------------------
* Wed Oct 10 2007 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> 0.4.1-3
- Changed permission on xournal.png from 0755 to 0644

Broken deps for i386
----------------------------------------------------------
	Pixie - 2.2.2-2.fc8.i386 requires libImath.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libHalf.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libIlmImf.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libIex.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libImath.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libHalf.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libIlmImf.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libIex.so.4
	blender - 2.45-3.fc8.i386 requires libHalf.so.4
	blender - 2.45-3.fc8.i386 requires libImath.so.4
	blender - 2.45-3.fc8.i386 requires libIlmImf.so.4
	blender - 2.45-3.fc8.i386 requires libIex.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libHalf.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libImath.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libIlmImf.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libIex.so.4
	fyre - 1.0.1-3.fc8.i386 requires libImath.so.4
	fyre - 1.0.1-3.fc8.i386 requires libHalf.so.4
	fyre - 1.0.1-3.fc8.i386 requires libIlmImf.so.4
	fyre - 1.0.1-3.fc8.i386 requires libIex.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libImath.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libIlmImf.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libIex.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libHalf.so.4
	kdebase - 6:3.5.8-2.fc8.i386 requires libIlmImf.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libImath.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libHalf.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libIlmImf.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libIex.so.4
	kdegraphics - 7:3.5.8-1.fc8.i386 requires libIlmImf.so.4
	kdelibs - 6:3.5.8-2.fc8.i386 requires libIlmImf.so.4
	kdelibs - 6:3.5.8-2.fc8.i386 requires libHalf.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libImath.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libIlmImf.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libIex.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libHalf.so.4
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	koffice-krita - 1.6.3-11.fc8.i386 requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libImath.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libHalf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libIex.so.4
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	qtpfsgui - 1.8.12-1.fc8.i386 requires libImath.so.4
	qtpfsgui - 1.8.12-1.fc8.i386 requires libHalf.so.4
	qtpfsgui - 1.8.12-1.fc8.i386 requires libIlmImf.so.4
	qtpfsgui - 1.8.12-1.fc8.i386 requires libIex.so.4
	scim-python-english - 0.1.4-2.fc8.i386 requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	vips - 7.12.5-1.fc8.i386 requires libImath.so.4
	vips - 7.12.5-1.fc8.i386 requires libHalf.so.4
	vips - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	vips - 7.12.5-1.fc8.i386 requires libIex.so.4
	vips-python - 7.12.5-1.fc8.i386 requires libImath.so.4
	vips-python - 7.12.5-1.fc8.i386 requires libHalf.so.4
	vips-python - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	vips-python - 7.12.5-1.fc8.i386 requires libIex.so.4
	vips-tools - 7.12.5-1.fc8.i386 requires libImath.so.4
	vips-tools - 7.12.5-1.fc8.i386 requires libHalf.so.4
	vips-tools - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	vips-tools - 7.12.5-1.fc8.i386 requires libIex.so.4
	yafray - 0.0.9-3.fc8.i386 requires libImath.so.4
	yafray - 0.0.9-3.fc8.i386 requires libHalf.so.4
	yafray - 0.0.9-3.fc8.i386 requires libIlmImf.so.4
	yafray - 0.0.9-3.fc8.i386 requires libIex.so.4



Broken deps for x86_64
----------------------------------------------------------
	Pixie - 2.2.2-2.fc8.i386 requires libImath.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libHalf.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libIlmImf.so.4
	Pixie - 2.2.2-2.fc8.i386 requires libIex.so.4
	Pixie - 2.2.2-2.fc8.x86_64 requires libIex.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.x86_64 requires libHalf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.x86_64 requires libImath.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.i386 requires libImath.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libHalf.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libIlmImf.so.4
	aqsis - 1.2.0-5.fc8.i386 requires libIex.so.4
	aqsis - 1.2.0-5.fc8.x86_64 requires libHalf.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.x86_64 requires libIex.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.x86_64 requires libImath.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libHalf.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libIex.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libImath.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libHalf.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libImath.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libIlmImf.so.4
	cinepaint-libs - 0.22.1-4.fc8.i386 requires libIex.so.4
	cinepaint-libs - 0.22.1-4.fc8.x86_64 requires libIex.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.x86_64 requires libHalf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.x86_64 requires libImath.so.4()(64bit)
	fyre - 1.0.1-3.fc8.x86_64 requires libHalf.so.4()(64bit)
	fyre - 1.0.1-3.fc8.x86_64 requires libIex.so.4()(64bit)
	fyre - 1.0.1-3.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	fyre - 1.0.1-3.fc8.x86_64 requires libImath.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.x86_64 requires libImath.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.x86_64 requires libIex.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.x86_64 requires libHalf.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.i386 requires libImath.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libIlmImf.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libIex.so.4
	k3d - 0.6.7.0-3.fc8.i386 requires libHalf.so.4
	kdebase - 6:3.5.8-2.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.x86_64 requires libImath.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.x86_64 requires libIex.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.x86_64 requires libHalf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.i386 requires libImath.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libHalf.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libIlmImf.so.4
	kdebase4 - 3.93.0-5.fc8.i386 requires libIex.so.4
	kdegraphics - 7:3.5.8-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.i386 requires libIlmImf.so.4
	kdelibs - 6:3.5.8-2.fc8.i386 requires libHalf.so.4
	kdelibs - 6:3.5.8-2.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.x86_64 requires libHalf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.x86_64 requires libImath.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.x86_64 requires libIex.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.x86_64 requires libHalf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.i386 requires libImath.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libIlmImf.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libIex.so.4
	kdelibs4 - 3.93.0-11.fc8.i386 requires libHalf.so.4
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	koffice-krita - 1.6.3-11.fc8.x86_64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.i386 requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libIex.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libImath.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	qtpfsgui - 1.8.12-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.x86_64 requires libIex.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.x86_64 requires libImath.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	scim-python-english - 0.1.4-2.fc8.x86_64 requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	vips - 7.12.5-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	vips - 7.12.5-1.fc8.x86_64 requires libIex.so.4()(64bit)
	vips - 7.12.5-1.fc8.x86_64 requires libImath.so.4()(64bit)
	vips - 7.12.5-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	vips - 7.12.5-1.fc8.i386 requires libImath.so.4
	vips - 7.12.5-1.fc8.i386 requires libHalf.so.4
	vips - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	vips - 7.12.5-1.fc8.i386 requires libIex.so.4
	vips-python - 7.12.5-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.x86_64 requires libIex.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.x86_64 requires libImath.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.x86_64 requires libIex.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.x86_64 requires libImath.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.x86_64 requires libHalf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.x86_64 requires libIex.so.4()(64bit)
	yafray - 0.0.9-3.fc8.x86_64 requires libImath.so.4()(64bit)
	yafray - 0.0.9-3.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.i386 requires libImath.so.4
	yafray - 0.0.9-3.fc8.i386 requires libHalf.so.4
	yafray - 0.0.9-3.fc8.i386 requires libIlmImf.so.4
	yafray - 0.0.9-3.fc8.i386 requires libIex.so.4



Broken deps for ppc
----------------------------------------------------------
	Pixie - 2.2.2-2.fc8.ppc requires libImath.so.4
	Pixie - 2.2.2-2.fc8.ppc requires libHalf.so.4
	Pixie - 2.2.2-2.fc8.ppc requires libIlmImf.so.4
	Pixie - 2.2.2-2.fc8.ppc requires libIex.so.4
	Pixie - 2.2.2-2.fc8.ppc64 requires libIex.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libHalf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libImath.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc requires libImath.so.4
	aqsis - 1.2.0-5.fc8.ppc requires libHalf.so.4
	aqsis - 1.2.0-5.fc8.ppc requires libIlmImf.so.4
	aqsis - 1.2.0-5.fc8.ppc requires libIex.so.4
	aqsis - 1.2.0-5.fc8.ppc64 requires libHalf.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libIex.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libImath.so.4()(64bit)
	blender - 2.45-3.fc8.ppc requires libHalf.so.4
	blender - 2.45-3.fc8.ppc requires libImath.so.4
	blender - 2.45-3.fc8.ppc requires libIlmImf.so.4
	blender - 2.45-3.fc8.ppc requires libIex.so.4
	cinepaint-libs - 0.22.1-4.fc8.ppc requires libHalf.so.4
	cinepaint-libs - 0.22.1-4.fc8.ppc requires libImath.so.4
	cinepaint-libs - 0.22.1-4.fc8.ppc requires libIlmImf.so.4
	cinepaint-libs - 0.22.1-4.fc8.ppc requires libIex.so.4
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libIex.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libHalf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libImath.so.4()(64bit)
	fyre - 1.0.1-3.fc8.ppc requires libImath.so.4
	fyre - 1.0.1-3.fc8.ppc requires libHalf.so.4
	fyre - 1.0.1-3.fc8.ppc requires libIlmImf.so.4
	fyre - 1.0.1-3.fc8.ppc requires libIex.so.4
	k3d - 0.6.7.0-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libImath.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libIex.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc requires libImath.so.4
	k3d - 0.6.7.0-3.fc8.ppc requires libIlmImf.so.4
	k3d - 0.6.7.0-3.fc8.ppc requires libIex.so.4
	k3d - 0.6.7.0-3.fc8.ppc requires libHalf.so.4
	kdebase - 6:3.5.8-2.fc8.ppc requires libIlmImf.so.4
	kdebase4 - 3.93.0-5.fc8.ppc requires libImath.so.4
	kdebase4 - 3.93.0-5.fc8.ppc requires libHalf.so.4
	kdebase4 - 3.93.0-5.fc8.ppc requires libIlmImf.so.4
	kdebase4 - 3.93.0-5.fc8.ppc requires libIex.so.4
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libImath.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libIex.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdegraphics - 7:3.5.8-1.fc8.ppc requires libIlmImf.so.4
	kdelibs - 6:3.5.8-2.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.ppc requires libIlmImf.so.4
	kdelibs - 6:3.5.8-2.fc8.ppc requires libHalf.so.4
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libImath.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libIex.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc requires libImath.so.4
	kdelibs4 - 3.93.0-11.fc8.ppc requires libIlmImf.so.4
	kdelibs4 - 3.93.0-11.fc8.ppc requires libIex.so.4
	kdelibs4 - 3.93.0-11.fc8.ppc requires libHalf.so.4
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	koffice-krita - 1.6.3-11.fc8.ppc requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.ppc requires libIlmImf.so.4
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc requires libImath.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libHalf.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libIex.so.4
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	qtpfsgui - 1.8.12-1.fc8.ppc requires libImath.so.4
	qtpfsgui - 1.8.12-1.fc8.ppc requires libHalf.so.4
	qtpfsgui - 1.8.12-1.fc8.ppc requires libIlmImf.so.4
	qtpfsgui - 1.8.12-1.fc8.ppc requires libIex.so.4
	scim-python-english - 0.1.4-2.fc8.ppc requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	vips - 7.12.5-1.fc8.ppc requires libImath.so.4
	vips - 7.12.5-1.fc8.ppc requires libHalf.so.4
	vips - 7.12.5-1.fc8.ppc requires libIlmImf.so.4
	vips - 7.12.5-1.fc8.ppc requires libIex.so.4
	vips - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.ppc requires libImath.so.4
	vips-python - 7.12.5-1.fc8.ppc requires libHalf.so.4
	vips-python - 7.12.5-1.fc8.ppc requires libIlmImf.so.4
	vips-python - 7.12.5-1.fc8.ppc requires libIex.so.4
	vips-tools - 7.12.5-1.fc8.ppc requires libImath.so.4
	vips-tools - 7.12.5-1.fc8.ppc requires libHalf.so.4
	vips-tools - 7.12.5-1.fc8.ppc requires libIlmImf.so.4
	vips-tools - 7.12.5-1.fc8.ppc requires libIex.so.4
	wammu - 0.19-3.fc8.noarch requires python-gammu
	yafray - 0.0.9-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libIex.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libImath.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc requires libImath.so.4
	yafray - 0.0.9-3.fc8.ppc requires libHalf.so.4
	yafray - 0.0.9-3.fc8.ppc requires libIlmImf.so.4
	yafray - 0.0.9-3.fc8.ppc requires libIex.so.4



Broken deps for ppc64
----------------------------------------------------------
	Pixie - 2.2.2-2.fc8.ppc64 requires libIex.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libHalf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	Pixie - 2.2.2-2.fc8.ppc64 requires libImath.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libHalf.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libIex.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	aqsis - 1.2.0-5.fc8.ppc64 requires libImath.so.4()(64bit)
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	blender - 2.45-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libIex.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libImath.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libIex.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libHalf.so.4()(64bit)
	cinepaint-libs - 0.22.1-4.fc8.ppc64 requires libImath.so.4()(64bit)
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	fyre - 1.0.1-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	fyre - 1.0.1-3.fc8.ppc64 requires libIex.so.4()(64bit)
	fyre - 1.0.1-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	fyre - 1.0.1-3.fc8.ppc64 requires libImath.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libImath.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libIex.so.4()(64bit)
	k3d - 0.6.7.0-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdebase - 6:3.5.8-2.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libImath.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libIex.so.4()(64bit)
	kdebase4 - 3.93.0-5.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdegraphics - 7:3.5.8-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kdelibs - 6:3.5.8-2.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libImath.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libIex.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	kdelibs4 - 3.93.0-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	qtpfsgui - 1.8.12-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.ppc64 requires libIex.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.ppc64 requires libImath.so.4()(64bit)
	qtpfsgui - 1.8.12-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	scim-python-english - 0.1.4-2.fc8.ppc64 requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	vips - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	vips - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	vips-python - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	vips-tools - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	wammu - 0.19-3.fc8.noarch requires python-gammu
	xorg-x11-drivers - 7.2-8.fc8.ppc64 requires synaptics
	yafray - 0.0.9-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libIex.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libImath.so.4()(64bit)
	yafray - 0.0.9-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)





From florin at andrei.myip.org  Mon Oct 15 18:29:10 2007
From: florin at andrei.myip.org (Florin Andrei)
Date: Mon, 15 Oct 2007 11:29:10 -0700
Subject: disable cpuspeed while X session active and screensaver not
	running
In-Reply-To: <20071013080304.59991f7e@laptopd505.fenrus.org>
References: <470E5E47.4040006@andrei.myip.org>
	<20071013080304.59991f7e@laptopd505.fenrus.org>
Message-ID: <4713B176.5010802@andrei.myip.org>

Arjan van de Ven wrote:
> On Thu, 11 Oct 2007 10:32:55 -0700
> Florin Andrei <florin at andrei.myip.org> wrote:
> 
>> On Fedora 7, running on an AMD64 dual core 6400, I disabled cpuspeed.
>> The results are incredible. Because the CPU clock stays up all the
>> time at 3.2GHz, instead of being pushed down most of the time to
>> 1GHz, the system feels much faster. All desktop apps seem to react
>> 10x faster. It's like upgrading from 486 to P3
>> The difference in CPU temperature after stopping cpuspeed is barely 
>> noticeable.
> 
> are you using the ondemand governer?
> if so.. can you try the latest hal/gnome-power-manager? (they used to
> change some tunings that ended up not meaning what was intended)

I just use whatever's the default in F7

If the latest hal/gnome-power-manager are included in the F8 test 
releases, then I might be able to test that.

> I'm also surprised.. reaction time doesn't really depend on clock
> speed...

The difference is quite visible. This feels like a different system now.

-- 
Florin Andrei

http://florin.myip.org/



From astrand at lysator.liu.se  Mon Oct 15 17:32:49 2007
From: astrand at lysator.liu.se (=?UTF-8?Q?Peter_=C3=85strand?=)
Date: Mon, 15 Oct 2007 19:32:49 +0200 (CEST)
Subject: Add to wishlist
Message-ID: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>


I thought I should add a few packages to the Wishlist at 
http://fedoraproject.org/wiki/PackageMaintainers/WishList, but then I 
realized that getting edit access is a >10 step process. Gosh, does it 
really have to be this complicated? 

Anyway, can anyone with edit access add these two items to the Wishlist:

* unfs3 - user-space NFSv3 server implementation

* xclip - command line interface to the X11 clipboard, with file copy 
  support

Thanks, 
-- 
/Peter ?strand <astrand at lysator.liu.se>


From tjb at unh.edu  Mon Oct 15 20:26:54 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Mon, 15 Oct 2007 16:26:54 -0400
Subject: googleearth?
Message-ID: <1192480014.3757.37.camel@raptor.sr.unh.edu>

Anyone have any luck running googleearth on F8? It hangs at random
points and never gets past the server login attempt.

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From steve at silug.org  Mon Oct 15 20:36:58 2007
From: steve at silug.org (Steven Pritchard)
Date: Mon, 15 Oct 2007 15:36:58 -0500
Subject: perl-Unix-Syslog license change (Artistic -> Artistic 2.0)
Message-ID: <20071015203658.GA26144@osiris.silug.org>

The license of perl-Unix-Syslog has changed from Artistic v1 to
Artistic v2 with version 1.0.

It looks like mimedefang and amavisd-new are the only things that
require it, and both have compatible licenses (GPL in both cases).

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)624-4440               Mobile: (618)567-7320



From kzak at redhat.com  Mon Oct 15 20:39:24 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 15 Oct 2007 22:39:24 +0200
Subject: should readahead allow generic paths?
In-Reply-To: <470E311A.8020406@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
Message-ID: <20071015203924.GY6325@petra.dvoda.cz>

> without readahead (0:49):
> with tweaked readahead (updated/sorted lists, run earlier) (0:44):

> so, it's a small win for me.  The approach still feels a bit inelegant
> to me, but it does seem to save a bit if it's done properly.  But from
> above, if it's done wrong, it hurts a lot more than it helps.
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Yes, I agree ;-(

> Tossing a default list out there and hoping for the best probably won't
> work, at any rate.

 I'm going to generate new default lists and apply your patches
 tomorrow. I'll minimize number of files in these lists -- it means no
 more gnome and firefox.

 Thanks for your effort and enthusiasm! :-)

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From louisg00 at bellsouth.net  Mon Oct 15 20:39:38 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Mon, 15 Oct 2007 16:39:38 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192465539.2792.6.camel@tiger>
References: <1192204108.2492.7.camel@tiger>  <1192420770.2612.2.camel@tiger>
	<1192465539.2792.6.camel@tiger>
Message-ID: <1192480778.9477.7.camel@tiger>

On Mon, 2007-10-15 at 14:57 -0400, Daniel J Walsh wrote:
> On Mon, 2007-10-15 at 12:25 -0400, Louis E Garcia II wrote: 
> > On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
> > > On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
> > > > On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > > > > I put a pix of myself in the 'about me' capplet and have a .face in my
> > > > > home dir. Why doesn't gdm pick it up?
> > > > > 
> > > > > -Louis
> > > > 
> > > > Would this be the cause?
> > > > 
> > > > SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
> > > > (home_root_t).
> > > > 
> > > > 
> > > 
> > > Aren'y you using the root account, are you? Where is your login
> > > picture located? Have you tried runing restorecon on the image?
> > 
> > No, this is a normal user account in /home a seperate partition.
> > 
> > $ls -Z .face
> > -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
> > 
> Thils looks like the wrong location for this file. 
> 
> In my case it would be
> 
> /home/dwalsh/.face
> 
> And it would have a context of user_home_t?

$ls -Z /home/louisg00/.face
-rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face

Seems my entire /home dir is labeled home_root_t should I relabel it
to user_home_t? This is a seperate partition. I remember something like
putting .relabel in the root partition to have it relabel on boot?





From pertusus at free.fr  Mon Oct 15 20:43:35 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 15 Oct 2007 22:43:35 +0200
Subject: Add to wishlist
In-Reply-To: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
References: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
Message-ID: <20071015204335.GB2790@free.fr>

On Mon, Oct 15, 2007 at 07:32:49PM +0200, Peter ?strand wrote:
> 
> * unfs3 - user-space NFSv3 server implementation

It is free software, so there is no issue packaging it in fedora.
I would be interested, however, to know what specific use user
space nfs could have? Especially from a distro perspective.

--
Pat



From airlied at redhat.com  Mon Oct 15 20:53:29 2007
From: airlied at redhat.com (Dave Airlie)
Date: Tue, 16 Oct 2007 06:53:29 +1000
Subject: googleearth?
In-Reply-To: <1192480014.3757.37.camel@raptor.sr.unh.edu>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
Message-ID: <1192481609.3702.0.camel@optimus>

On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> Anyone have any luck running googleearth on F8? It hangs at random
> points and never gets past the server login attempt.
> 

Hi,

What graphics hardware you running it on?

Dave.



From kzak at redhat.com  Mon Oct 15 21:00:53 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 15 Oct 2007 23:00:53 +0200
Subject: remove readahead from default package set (was Re: should
	readahead allow generic paths?)
In-Reply-To: <470F008E.2080102@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]>
	<470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
	<20071011214903.GA32504@nostromo.devel.redhat.com>
	<470F008E.2080102@redhat.com>
Message-ID: <20071015210053.GZ6325@petra.dvoda.cz>

On Fri, Oct 12, 2007 at 01:05:18AM -0400, Warren Togami wrote:
> Bill Nottingham wrote:
> >Eric Sandeen (sandeen at redhat.com) said: 
> >>Matthias Clasen wrote:
> >>>On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> >>>
> >>>>Tossing a default list out there and hoping for the best probably won't
> >>>>work, at any rate.
> >>>So are we going to get your fixed lists into F8 ?
> >>>
> >>Well, part of the problem is that "my" fixed lists may not be everyone's
> >>fixed lists - I generated a custom list from *my* boot sequence.  Coming
> >>up with a good default list that actually speeds *everyone's* boot time
> >>is another issue.  If we think it's worth the 4 second or so boottime
> >>reduction, maybe some way to automatically generate the custom lists
> >>during firstboot might be an option.  But then, they will rot over time...
> >
> >Given that, is there any reason to ship it on by default at this point?
> >
> >Bill
> >
> 
> Relatively simple solution:
> 1) Ship readahead with template lists.  This includes a list of commonly 
> used stuff.  It could include wildcards like /usr/lib*/firefox*/foo in 
> order to handle multilib and version numbers changing.
> 2) During firstboot and occasionally after boot, something generates the 
> actual readahead file lists based upon several factors like:
>    - is the file actually installed?
>    - is the service enabled?
> Later improvement:
> 3) Sometime later, more intelligent software could be included to help a 
> user update their readahead lists based upon their own software usage 
> patterns.

 you needn't this scenario, you can simply boot with

    init=/sbin/readahead-collector

 it's probably better than develop and maintain something like
 template lists.

 The problem is something completely different than contents of
 /etc/readahead.d/. The problem is that readahead (also with perfect
 list of files) provides poor performance improvement.

 We need to spend time with more promising tasks like better init
 scripts, faster rhgb/X, swsuspend, fscache, ...

 IMHO, the readahead package is poor workaround with no future. (I'm
 author of more than 70% of the code.)

     Karel

-- 
 Karel Zak  <kzak at redhat.com>



From dwalsh at redhat.com  Mon Oct 15 21:10:20 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 15 Oct 2007 17:10:20 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192480778.9477.7.camel@tiger>
References: <1192204108.2492.7.camel@tiger>
	<1192420770.2612.2.camel@tiger>	<1192465539.2792.6.camel@tiger>
	<1192480778.9477.7.camel@tiger>
Message-ID: <4713D73C.8030301@redhat.com>

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

Louis E Garcia II wrote:
> On Mon, 2007-10-15 at 14:57 -0400, Daniel J Walsh wrote:
>> On Mon, 2007-10-15 at 12:25 -0400, Louis E Garcia II wrote: 
>>> On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
>>>> On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
>>>>> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
>>>>>> I put a pix of myself in the 'about me' capplet and have a .face in my
>>>>>> home dir. Why doesn't gdm pick it up?
>>>>>>
>>>>>> -Louis
>>>>> Would this be the cause?
>>>>>
>>>>> SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
>>>>> (home_root_t).
>>>>>
>>>>>
>>>> Aren'y you using the root account, are you? Where is your login
>>>> picture located? Have you tried runing restorecon on the image?
>>> No, this is a normal user account in /home a seperate partition.
>>>
>>> $ls -Z .face
>>> -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
>>>
>> Thils looks like the wrong location for this file. 
>>
>> In my case it would be
>>
>> /home/dwalsh/.face
>>
>> And it would have a context of user_home_t?
> 
> $ls -Z /home/louisg00/.face
> -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
> 
> Seems my entire /home dir is labeled home_root_t should I relabel it
> to user_home_t? This is a seperate partition. I remember something like
> putting .relabel in the root partition to have it relabel on boot?
> 
> 
> 
Yes,

restorecon -R -v /home

Should fix the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHE9c8rlYvE4MpobMRAh1FAJ48yT3Id6KwFIkDJCBqt4EaknyJAQCdFV/v
WWSaWEptKLbv7DaP4rqCf5Q=
=p18R
-----END PGP SIGNATURE-----



From lkundrak at redhat.com  Mon Oct 15 21:29:40 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 15 Oct 2007 23:29:40 +0200
Subject: googleearth?
In-Reply-To: <1192480014.3757.37.camel@raptor.sr.unh.edu>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
Message-ID: <1192483780.30612.29.camel@localhost.localdomain>


On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> Anyone have any luck running googleearth on F8? It hangs at random
> points and never gets past the server login attempt.

Randomly hanging (well, not so random, see strace :) with both fglrx and
intel hardware. A good explanation is "proprietary pile of crap" ;)

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From kzak at redhat.com  Mon Oct 15 21:31:17 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 15 Oct 2007 23:31:17 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <4710D754.2090101@redhat.com>
References: <4710D754.2090101@redhat.com>
Message-ID: <20071015213117.GA6325@petra.dvoda.cz>

On Sat, Oct 13, 2007 at 10:33:56AM -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> If the location of the executable changes,
> for example from /usr/bin to /usr/sbin.  Please make sure the SELinux
> context is correct in the new location
> 
> matchpathcon /usr/bin/MYAPP
> matchpathcon /ust/sbin/MYAPP
> 
> If they aren't the same, then SELinux might have a problem.

 Couldn't be better to maintain default selinux labels like others
 file attributes?

     %attr(4755,root,root) %selinux(foo_t)  /bin/foo

> Changing this could cause a security vulnerabilty, an confined
> application can go to unconfined if it moves to a bin_t labeling.

 Arjan is right, it sounds like pretty important to test it for
 regressions.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct 15 21:35:33 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 15 Oct 2007 23:35:33 +0200
Subject: rawhide report: 20071015 changes
In-Reply-To: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
Message-ID: <20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 15 Oct 2007 15:24:12 -0400, Build System wrote:

> OpenEXR-1.6.0-4.fc8
> -------------------
> * Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-4
> - -libs: %post/%postun -p /sbin/ldconfig
> 
> * Fri Oct 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-2
> - openexr-1.6.0

Fight the freeze! ;-)

Further, lots of redundancy has appeared in the KDE pkgs recently:

kdebase provides libkonsolepart.so
kdebase4 provides libkonsolepart.so
  required by: PyKDE - 3.16.0-7.fc8.i386


kdegraphics-extras provides libkpovmodeler.so.0
kdegraphics-libs provides libkpovmodeler.so.0
  required by: kdegraphics-devel - 7:3.5.8-1.fc8.i386
  required by: kdegraphics-libs - 7:3.5.8-1.fc8.i386
  required by: kdegraphics-extras - 7:3.5.8-1.fc8.i386

kdemultimedia provides libartsmodulessynth.so.0
kdemultimedia-libs provides libartsmodulessynth.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libarts_akode.so.0
kdemultimedia-libs provides libarts_akode.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmidi.so.0
kdemultimedia-libs provides libartsmidi.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmidi_idl.so.0
kdemultimedia-libs provides libartsmidi_idl.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libkmidlib.so.0
kdemultimedia-libs provides libkmidlib.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsbuilder.so.0
kdemultimedia-libs provides libartsbuilder.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartscontrolsupport.so.1
kdemultimedia-libs provides libartscontrolsupport.so.1
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartscontrolapplet.so.1
kdemultimedia-libs provides libartscontrolapplet.so.1
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libkcddb.so.1
kdemultimedia-libs provides libkcddb.so.1
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: tellico - 1.2.14-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmoduleseffects.so.0
kdemultimedia-libs provides libartsmoduleseffects.so.0
  required by: kdeaddons-extras - 3.5.7-6.fc8.i386
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmodulesmixers.so.0
kdemultimedia-libs provides libartsmodulesmixers.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libarts_audiofile.so.0
kdemultimedia-libs provides libarts_audiofile.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmodulescommon.so.0
kdemultimedia-libs provides libartsmodulescommon.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsgui.so.0
kdemultimedia-libs provides libartsgui.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libaudiocdplugins.so.1
kdemultimedia-libs provides libaudiocdplugins.so.1
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsmodules.so.0
kdemultimedia-libs provides libartsmodules.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsgui_idl.so.0
kdemultimedia-libs provides libartsgui_idl.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-extras - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-extras-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386

kdemultimedia provides libartsgui_kde.so.0
kdemultimedia-libs provides libartsgui_kde.so.0
  required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-extras-libs - 6:3.5.8-3.fc8.i386
  required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
  required by: taxipilot - 0.9.2-2.fc8.i386
  required by: kdemultimedia - 6:3.5.8-3.fc8.i386





From louisg00 at bellsouth.net  Mon Oct 15 21:40:33 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Mon, 15 Oct 2007 17:40:33 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192480778.9477.7.camel@tiger>
References: <1192204108.2492.7.camel@tiger>  <1192420770.2612.2.camel@tiger>
	<1192465539.2792.6.camel@tiger>  <1192480778.9477.7.camel@tiger>
Message-ID: <1192484433.2486.10.camel@tiger>

On Mon, 2007-10-15 at 17:10 -0400, Daniel J Walsh wrote:
> On Mon, 2007-10-15 at 16:39 -0400, Louis E Garcia II wrote:
> > On Mon, 2007-10-15 at 14:57 -0400, Daniel J Walsh wrote:
> > > On Mon, 2007-10-15 at 12:25 -0400, Louis E Garcia II wrote: 
> > > > On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
> > > > > On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
> > > > > > On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
> > > > > > > I put a pix of myself in the 'about me' capplet and have a .face in my
> > > > > > > home dir. Why doesn't gdm pick it up?
> > > > > > > 
> > > > > > > -Louis
> > > > > > 
> > > > > > Would this be the cause?
> > > > > > 
> > > > > > SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
> > > > > > (home_root_t).
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Aren'y you using the root account, are you? Where is your login
> > > > > picture located? Have you tried runing restorecon on the image?
> > > > 
> > > > No, this is a normal user account in /home a seperate partition.
> > > > 
> > > > $ls -Z .face
> > > > -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
> > > > 
> > > Thils looks like the wrong location for this file. 
> > > 
> > > In my case it would be
> > > 
> > > /home/dwalsh/.face
> > > 
> > > And it would have a context of user_home_t?
> > 
> > $ls -Z /home/louisg00/.face
> > -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
> > 
> > Seems my entire /home dir is labeled home_root_t should I relabel it
> > to user_home_t? This is a seperate partition. I remember something like
> > putting .relabel in the root partition to have it relabel on boot?
> Yes,
> 
> restorecon -R -v /home
> 
> Should fix the problem.

Yes it did and a few other problems I had, thanks.

One more thing, everything under /home is user_home_t but /home itself is
still home_root_t. Is this correct?

$ls -Z /home
drwx------  root     root  system_u:object_r:lost_found_t:s0 lost+found
drwx------  louisg00 users system_u:object_r:user_home_dir_t:s0 louisg00

$ls -Zd /home
drwxr-xr-x  root root system_u:object_r:home_root_t:s0 /home




From jos at xos.nl  Mon Oct 15 21:44:21 2007
From: jos at xos.nl (Jos Vos)
Date: Mon, 15 Oct 2007 23:44:21 +0200
Subject: googleearth?
In-Reply-To: <1192483780.30612.29.camel@localhost.localdomain>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
Message-ID: <20071015214421.GA31570@jasmine.xos.nl>

On Mon, Oct 15, 2007 at 11:29:40PM +0200, Lubomir Kundrak wrote:

> Randomly hanging (well, not so random, see strace :) with both fglrx and
> intel hardware. A good explanation is "proprietary pile of crap" ;)

What is proprietary?  Isn't the Intel driver open source?

But doesn't adding

	Option     "DRI" "false"

(Section "Device") make it stable (and a lot slower, of course)?
On F7 (Intel 965GM) this seems to work.

-- 
--    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 vpivaini at cs.helsinki.fi  Mon Oct 15 22:06:15 2007
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Tue, 16 Oct 2007 01:06:15 +0300
Subject: vdr-skinsoppalusikka license change from GPL+ to GPLv2+
Message-ID: <200710160106.15386.vpivaini@cs.helsinki.fi>

Hi,

I'm following Ville Skytt?'s example here ;)

vdr-skinsoppalusikka is a new package and my first Fedora package. It's a 
standalone skin for the VDR. Its license was changed from GPL+ to GPLv2+ in 
version 1.0.5.

Unfortunately I made a mistake and changed the license to GPLv2 only in 
vdr-skinsoppalusikka-1.0.5-1, which was just pushed to F-7 updates-testing, 
sorry. That's why vdr-skinsoppalusikka-1.0.5-2 is currently building in koji.

-- 
Ville-Pekka Vainio
vpivaini at cs.helsinki.fi



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct 15 22:13:42 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 16 Oct 2007 00:13:42 +0200
Subject: New conflicts =?utf-8?b?wrc=?= Re: rawhide report: 20071015 changes
In-Reply-To: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
Message-ID: <20071016001342.05e250f8.mschwendt.tmp0701.nospam@arcor.de>

bluecurve-gdm-theme - 1.0.0-1.fc8.noarch
  File conflict with: fedora-logos - 7.94.0-1.fc8.noarch
     /usr/share/gdm/themes/Bluecurve/rh_logo-header.png
     /usr/share/gdm/themes/Bluecurve/screenshot.png

bluecurve-kdm-theme - 1.0.0-1.fc8.noarch
  File conflict with: fedora-logos - 7.94.0-1.fc8.noarch
     /usr/share/apps/kdm/themes/Bluecurve/rh_logo-header.png
     /usr/share/apps/kdm/themes/Bluecurve/screenshot.png

cyrus-imapd - 2.3.9-7.fc8.i386
  File conflict with: uw-imap - 2006k-0.1.0709171900.fc8.i386
     /etc/pam.d/imap
     /etc/pam.d/pop
     /usr/share/man/man8/imapd.8.gz

nmh - 1.2-20070115cvs.4.fc8.i386
  File conflict with: Pixie - 2.2.2-2.fc8.i386
     /usr/bin/show

qwt-doc - 5.0.2-4.fc8.noarch
  File conflict with: QuantLib-doc - 0.8.1-3.fc8.i386
     /usr/share/man/man3/deprecated.3.gz
     /usr/share/man/man3/todo.3.gz



From ben.lewis at benl.co.uk  Mon Oct 15 22:27:18 2007
From: ben.lewis at benl.co.uk (Benjamin Lewis)
Date: Mon, 15 Oct 2007 23:27:18 +0100
Subject: googleearth?
In-Reply-To: <1192483780.30612.29.camel@localhost.localdomain>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
Message-ID: <200710152327.30017.ben.lewis@benl.co.uk>

On Monday 15 October 2007 10:29:40 pm Lubomir Kundrak wrote:
> On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> > Anyone have any luck running googleearth on F8? It hangs at random
> > points and never gets past the server login attempt.
>
> Randomly hanging (well, not so random, see strace :) with both fglrx and
> intel hardware. A good explanation is "proprietary pile of crap" ;)
>
> --
> Lubomir Kundrak (Red Hat Security Response Team)

FWIW, it hasn't worked for me since the star viewing stuff came along. Looking 
at strace it always hangs in the same place:

there are a few thousand of:
futex(0x8e1a714, FUTEX_WAKE, 1)         = 0

then about 20 or so (with different libraries):
open("./tls/i686/sse2/libCg.so", O_RDONLY) = -1 ENOENT (No such file or 
directory)

then another 100 or so :
futex(0x8e1a714, FUTEX_WAKE, 1)         = 0

before hanging here:
ioctl(7, 0x4008642a, 0xbfe1d49c)        = 0
ioctl(7, 0xc00c645c <unfinished ...>

The full strace is absolutly huge, but you can find it at 
http://benl.co.uk/files/googleearth.strace .

Doubt its of any help though, since both it and fglrx are closed source :(.
-- 

Benjamin Lewis
Fedora Ambassador
ben.lewis at benl.co.uk

-----------------------------------------------------------------------
http://benl.co.uk./                                 PGP Key: 0x647E480C

"In cases of major discrepancy, it is always reality that got it wrong"
                                                        -- RFC 1118
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071015/b762444e/attachment.sig>

From tjb at unh.edu  Tue Oct 16 01:06:34 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Mon, 15 Oct 2007 21:06:34 -0400
Subject: googleearth?
In-Reply-To: <1192483780.30612.29.camel@localhost.localdomain>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
Message-ID: <1192496794.617.0.camel@neuromancer>

On Mon, 2007-10-15 at 23:29 +0200, Lubomir Kundrak wrote:
> On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> > Anyone have any luck running googleearth on F8? It hangs at random
> > points and never gets past the server login attempt.
> 
> Randomly hanging (well, not so random, see strace :) with both fglrx and
> intel hardware. A good explanation is "proprietary pile of crap" ;)
> 

Not disagreeing! Intel and nvidia for me.

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From airlied at redhat.com  Tue Oct 16 01:23:57 2007
From: airlied at redhat.com (Dave Airlie)
Date: Tue, 16 Oct 2007 11:23:57 +1000
Subject: googleearth?
In-Reply-To: <1192496794.617.0.camel@neuromancer>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
	<1192496794.617.0.camel@neuromancer>
Message-ID: <1192497837.18611.1.camel@optimus>

On Mon, 2007-10-15 at 21:06 -0400, Thomas J. Baker wrote:
> On Mon, 2007-10-15 at 23:29 +0200, Lubomir Kundrak wrote:
> > On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> > > Anyone have any luck running googleearth on F8? It hangs at random
> > > points and never gets past the server login attempt.
> > 
> > Randomly hanging (well, not so random, see strace :) with both fglrx and
> > intel hardware. A good explanation is "proprietary pile of crap" ;)
> > 
> 
> Not disagreeing! Intel and nvidia for me.
> 

Anyone got any idea when it last worked? like test1,2,3??

I'm between blaming glibc and libX11/xcb/xtrans/ICE...

I've just built some of those X.org library bits on my F7 machine though
and LD_LIBRARY_PATHed them in and it works fine..

Dave.



From chris.stone at gmail.com  Tue Oct 16 01:45:21 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 15 Oct 2007 18:45:21 -0700
Subject: nucleo version problem
In-Reply-To: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
References: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
Message-ID: <d9c612bf0710151845vf07f538t2b32fafbd23aeac4@mail.gmail.com>

On 10/14/07, subhodip biswas <440volt.tux at gmail.com> wrote:
> Hi !
>
> I was thinking of packaging nucleo
> [http://insitu.lri.fr/~roussel/projects/nucleo/]
> First ..Is anybody working on this already??
> Second... Nucleo comes in Nucleo-2007-XX-XX format. how to resolve this ??

I packaged nucleo a while back and orphaned it, it should still be
there in CVS.  Others have worked on packaging it since, but nothing
has been officially added back to Fedora AFAIK.



From airlied at redhat.com  Tue Oct 16 01:49:00 2007
From: airlied at redhat.com (Dave Airlie)
Date: Tue, 16 Oct 2007 11:49:00 +1000
Subject: glibc breaks googleearth?
In-Reply-To: <1192497837.18611.1.camel@optimus>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
	<1192496794.617.0.camel@neuromancer> <1192497837.18611.1.camel@optimus>
Message-ID: <1192499340.18611.5.camel@optimus>

On Tue, 2007-10-16 at 11:23 +1000, Dave Airlie wrote:
> On Mon, 2007-10-15 at 21:06 -0400, Thomas J. Baker wrote:
> > On Mon, 2007-10-15 at 23:29 +0200, Lubomir Kundrak wrote:
> > > On Mon, 2007-10-15 at 16:26 -0400, Thomas J. Baker wrote:
> > > > Anyone have any luck running googleearth on F8? It hangs at random
> > > > points and never gets past the server login attempt.
> > > 
> > > Randomly hanging (well, not so random, see strace :) with both fglrx and
> > > intel hardware. A good explanation is "proprietary pile of crap" ;)
> > > 
> > 
> > Not disagreeing! Intel and nvidia for me.
> > 
> 
> Anyone got any idea when it last worked? like test1,2,3??
> 
> I'm between blaming glibc and libX11/xcb/xtrans/ICE...
> 
> I've just built some of those X.org library bits on my F7 machine though
> and LD_LIBRARY_PATHed them in and it works fine..
> 

Okay I've installed the latest glibc from F7 updates (in a separate
directory on my F8 box, and ran

LD_LIBRARY_PATH=.:/home/airlied/test/lib /home/airlied/test/lib//ld-2.6.so ./googleearth-bin

and it appears to start and work.. so what changed in glibc that annoys
it?

Dave.





From marc at mwiriadi.id.au  Tue Oct 16 02:23:48 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Tue, 16 Oct 2007 10:23:48 +0800
Subject: Yum upgrade
Message-ID: <1192501428.5202.7.camel@strikeforce.mwiriadi.id.au>

Hey all,

Just thought I would post some feedback. Going from F7 -> to the current
development using yum -y upgrade seems to have gone pretty smooth so
far.  I'll list the issues I've got at the moment.

NetworkManager died on reboot when I clicked to select a wired
connection.

irqbalance is dead no real information in dmesg or /var/log/messages
CPU 0 irqstacks, hard=c0814000 soft=c07f4000
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
report
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

preload works which is a package that I made for fedora on my own
machine. 

My desktop didn't show icons after I upgraded so I deleted ~/.Xauthority
and ~/.xsession-errors since I couldn't remember which one would reset
my interface.  After doing that it all works.

Good work to the devs by the way on a damn good upgrade process that
isn't supported but works anyway.

My Smolt:
http://smolt.fedoraproject.org/show?UUID=8086cad9-77e1-4087-8100-7552054d5d07
as a reference.

Cheers,

Marc Wiriadisastra



From kagesenshi.87 at gmail.com  Tue Oct 16 05:06:34 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Tue, 16 Oct 2007 12:36:34 +0730
Subject: weird problem with NM
Message-ID: <c44298520710152206x54ac9d70ga7274f1f976381c@mail.gmail.com>

i'm getting a weird problem with today's rawhide update

whenever I'm connected to my wifi network, iwlist eth1 scan shows no
scan results.. plus .. every 5-15 minutes i got disconnected from the
network .. iwlist scan back returning scan results right after the
disconnect ..

anybody else experiencing this?

-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From petersen at redhat.com  Tue Oct 16 06:12:08 2007
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 16 Oct 2007 16:12:08 +1000
Subject: [koji] problems building gettext for f7 update
Message-ID: <47145638.1070403@redhat.com>

Hi,

I am having trouble building a simple gettext bugfix update for F7.

My first job hung on i386 for about 20 hours:
	http://koji.fedoraproject.org/koji/taskinfo?taskID=195033
before I cancelled it and the second submission to koji appeared to hang 
on ppc: http://koji.fedoraproject.org/koji/taskinfo?taskID=197240 .

Currently http://koji.fedoraproject.org/koji/taskinfo?taskID=197502
has running for well over an hour and it seems to be hanging again in 
%check on ppc. :-(

Any ideas?

Jens



From kevin.kofler at chello.at  Tue Oct 16 06:20:31 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Oct 2007 06:20:31 +0000 (UTC)
Subject: rawhide report: 20071015 changes
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <loom.20071016T061751-628@post.gmane.org>

Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
> Fight the freeze!

Don't panic. I've already rebuilt kdelibs4 and kdebase4, Rex is doing most of 
the others, all the other maintainers have been informed (well in advance), and 
worst case things can just be rebuilt by rel-eng (a rebuilt should be all 
that's needed).

> kdebase provides libkonsolepart.so
> kdebase4 provides libkonsolepart.so
>   required by: PyKDE - 3.16.0-7.fc8.i386

Oops, sounds like I have to filter Provides here (kdebase4).
They're actually both in private directories (KParts are supposed to be 
dlopened only), so I'm not sure how PyKDE ends up with an autoreq on this.

        Kevin Kofler



From andy at warmcat.com  Tue Oct 16 06:27:36 2007
From: andy at warmcat.com (Andy Green)
Date: Tue, 16 Oct 2007 07:27:36 +0100
Subject: weird problem with NM
In-Reply-To: <c44298520710152206x54ac9d70ga7274f1f976381c@mail.gmail.com>
References: <c44298520710152206x54ac9d70ga7274f1f976381c@mail.gmail.com>
Message-ID: <471459D8.4010001@warmcat.com>

Somebody in the thread at some point said:
> i'm getting a weird problem with today's rawhide update
> 
> whenever I'm connected to my wifi network, iwlist eth1 scan shows no
> scan results.. plus .. every 5-15 minutes i got disconnected from the
> network .. iwlist scan back returning scan results right after the
> disconnect ..
> 
> anybody else experiencing this?

I don't have the latest rawhide, but I do know something to try.  Intel
thought it would be a good idea to complicate their firmware with what
they called "hardware scan".  It doesn't offer any significant advantage
over the mac80211-driven scan, it might be worth trying turning it off
and using the mac80211 one:

alias wlan0 iwl3945 disable_hw_scan=1

-Andy



From kevin.kofler at chello.at  Tue Oct 16 06:25:08 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Oct 2007 06:25:08 +0000 (UTC)
Subject: googleearth?
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
	<20071015214421.GA31570@jasmine.xos.nl>
Message-ID: <loom.20071016T062433-493@post.gmane.org>

Jos Vos <jos <at> xos.nl> writes:
> On Mon, Oct 15, 2007 at 11:29:40PM +0200, Lubomir Kundrak wrote:
> > Randomly hanging (well, not so random, see strace :) with both fglrx and
> > intel hardware. A good explanation is "proprietary pile of crap" ;)
> 
> What is proprietary?  Isn't the Intel driver open source?

Google Earth is proprietary.

        Kevin Kofler



From dgboles at gmail.com  Tue Oct 16 06:36:21 2007
From: dgboles at gmail.com (David Boles)
Date: Tue, 16 Oct 2007 02:36:21 -0400
Subject: googleearth?
In-Reply-To: <loom.20071016T062433-493@post.gmane.org>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>	<1192483780.30612.29.camel@localhost.localdomain>	<20071015214421.GA31570@jasmine.xos.nl>
	<loom.20071016T062433-493@post.gmane.org>
Message-ID: <47145BE5.7000201@gmail.com>

on 10/16/2007 2:25 AM, Kevin Kofler wrote:
> Jos Vos <jos <at> xos.nl> writes:
>> On Mon, Oct 15, 2007 at 11:29:40PM +0200, Lubomir Kundrak wrote:
>>> Randomly hanging (well, not so random, see strace :) with both fglrx and
>>> intel hardware. A good explanation is "proprietary pile of crap" ;)
>> What is proprietary?  Isn't the Intel driver open source?
> 
> Google Earth is proprietary.
> 
>         Kevin Kofler


Good show Kevin!!!   ;-)  I wondered just how long it would take before
someone else noticed, and actually said something. My I gather that you
noticed at once and only now replied?  <big> <smile.
-- 

  David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/7e4a840d/attachment.sig>

From dmc.fedora at filteredperception.org  Tue Oct 16 06:45:58 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Tue, 16 Oct 2007 01:45:58 -0500
Subject: googleearth?
In-Reply-To: <47145BE5.7000201@gmail.com>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>	<1192483780.30612.29.camel@localhost.localdomain>	<20071015214421.GA31570@jasmine.xos.nl>	<loom.20071016T062433-493@post.gmane.org>
	<47145BE5.7000201@gmail.com>
Message-ID: <47145E26.7010300@filteredperception.org>

David Boles wrote:
> on 10/16/2007 2:25 AM, Kevin Kofler wrote:
>> Jos Vos <jos <at> xos.nl> writes:
>>> On Mon, Oct 15, 2007 at 11:29:40PM +0200, Lubomir Kundrak wrote:
>>>> Randomly hanging (well, not so random, see strace :) with both fglrx and
>>>> intel hardware. A good explanation is "proprietary pile of crap" ;)
>>> What is proprietary?  Isn't the Intel driver open source?
>> Google Earth is proprietary.
>>
>>         Kevin Kofler
> 
> 
> Good show Kevin!!!   ;-)  I wondered just how long it would take before
> someone else noticed, and actually said something. My I gather that you
> noticed at once and only now replied?  <big> <smile.

So who is working on porting/packaging NASA whirlwind/worldwind, 
optionally with the dataset as a 1GB+ rpm instead of streaming from online?

Or at least, kmarble runnable under gnome (I dunno, does it work for f8 
already?)?

-dmc



From kevin.kofler at chello.at  Tue Oct 16 06:52:12 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Oct 2007 06:52:12 +0000 (UTC)
Subject: googleearth?
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>	<1192483780.30612.29.camel@localhost.localdomain>	<20071015214421.GA31570@jasmine.xos.nl>	<loom.20071016T062433-493@post.gmane.org>
	<47145BE5.7000201@gmail.com>
	<47145E26.7010300@filteredperception.org>
Message-ID: <loom.20071016T065009-55@post.gmane.org>

Douglas McClendon <dmc.fedora <at> filteredperception.org> writes:
> Or at least, kmarble runnable under gnome (I dunno, does it work for f8 
> already?)?

Marble should be running fine, even if you're using GNOME, you only need qt4 
installed as a dependency. (Well, future versions will probably require 
kdelibs4 too.)

It doesn't have all that fancy 3D stuff though.

        Kevin Kofler



From andy at warmcat.com  Tue Oct 16 07:08:35 2007
From: andy at warmcat.com (Andy Green)
Date: Tue, 16 Oct 2007 08:08:35 +0100
Subject: weird problem with NM
In-Reply-To: <471459D8.4010001@warmcat.com>
References: <c44298520710152206x54ac9d70ga7274f1f976381c@mail.gmail.com>
	<471459D8.4010001@warmcat.com>
Message-ID: <47146373.7080002@warmcat.com>

Somebody in the thread at some point said:
> Somebody in the thread at some point said:
>> i'm getting a weird problem with today's rawhide update
>>
>> whenever I'm connected to my wifi network, iwlist eth1 scan shows no
>> scan results.. plus .. every 5-15 minutes i got disconnected from the
>> network .. iwlist scan back returning scan results right after the
>> disconnect ..
>>
>> anybody else experiencing this?
> 
> I don't have the latest rawhide, but I do know something to try.  Intel

Gah... apologies, you didn't even mention iwl3945, it seems my
coffee-starved just woken brain interpolated it :-(  Please ignore
unless it is iwl3945 by chance.

-Andy



From oliver at linux-kernel.at  Tue Oct 16 07:08:52 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 16 Oct 2007 09:08:52 +0200
Subject: rpms/perl/devel perl.spec,1.137,1.138
In-Reply-To: <200710151814.l9FIE0Nd003815@cvs-int.fedora.redhat.com>
References: <200710151814.l9FIE0Nd003815@cvs-int.fedora.redhat.com>
Message-ID: <47146384.9080703@linux-kernel.at>

On 10/15/2007 08:14 PM, Tom Callaway (spot) wrote:
> Author: spot
> 
> Update of /cvs/pkgs/rpms/perl/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3749
> 
> Modified Files:
> 	perl.spec 
> Log Message:
> 
> Requires db4-devel with version, scraped from db.h, so that we detect when db4 has gone astray from us.

Great. Thx Spot!

-of



From oliver at linux-kernel.at  Tue Oct 16 07:10:49 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 16 Oct 2007 09:10:49 +0200
Subject: what the heck is going on with the kernel package?!
In-Reply-To: <1192474636.2393.27.camel@cutter>
References: <4713817B.8050903@linux-kernel.at>	<47138315.7090308@linux-kernel.at>
	<1192474636.2393.27.camel@cutter>
Message-ID: <471463F9.8010507@linux-kernel.at>

On 10/15/2007 08:57 PM, seth vidal wrote:
> On Mon, 2007-10-15 at 17:11 +0200, Oliver Falk wrote:
>> On 10/15/2007 05:04 PM, Oliver Falk wrote:
>>
>>> Can please someone explain this to me?
>> Well. One's i586, one is i686..
> 
> yes - and the concern is why you now have an i586 kernel. Can you post
> your yum.log for the last few updates?

As already discussed on on IRC, this machine might have been updated
from FC6 to F7, and FC6 used to install the 'wrong' kernel :-(

Best,
 Oliver



From benny+usenet at amorsen.dk  Tue Oct 16 08:15:45 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 16 Oct 2007 10:15:45 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
	<47113775.1090805@filteredperception.org>
	<m37ilp94wf.fsf@ursa.amorsen.dk> <4712525E.2010906@gmail.com>
Message-ID: <m3d4vf4gr2.fsf@ursa.amorsen.dk>

>>>>> "DB" == David Boles <dgboles at gmail.com> writes:

DB> I don't know that I have ever seen a 9 Gig USB keys. Where did you
DB> get yours?

I have never seen a 9GB USB key either, but 16GB ones are easy to get.
Models from Corsair, TwinMos and Transcend are available around here.


/Benny




From benny+usenet at amorsen.dk  Tue Oct 16 08:28:17 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 16 Oct 2007 10:28:17 +0200
Subject: CDs DVDs or netboot.  Oh my!
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<20071011095545.GB19149@devserv.devel.redhat.com>
	<m3fy0e92wl.fsf@ursa.amorsen.dk>
	<47113775.1090805@filteredperception.org>
	<m37ilp94wf.fsf@ursa.amorsen.dk>
	<47126F2E.9070803@filteredperception.org>
Message-ID: <m38x634g66.fsf@ursa.amorsen.dk>

>>>>> "DM" == Douglas McClendon <dmc.fedora at filteredperception.org> writes:

DM> As the other responder mentioned, I'm assuming you don't really
DM> mean Everything (much as I was one of the longest hold-outs of
DM> keeping and using Everything installs).

I mean what I say. I don't want to actually install everything; it
should just be available on the stick so I can use kickstart files to
pick and choose.

DM> But you do then still need to put smarts into the initramfs to
DM> deal with the fact that it may be looking for an iso on a vfat
DM> usbstick. Not difficult by any means, but definitely a bit of
DM> work.

If it's just an image to dd, you can keep everything in whichever file
format you want.

I must admit I'm at bit surprised at all the complexity. All I want is
to dd DVD.iso to a USB stick, but the DVD.iso is not in a format which
BIOS's know how to boot from. With the right boot record, everything
should be in place.

Alternatively, if I knew how to partition the device so that boot.img
could fit before an ext2 partition, I could just put the DVD.iso there
and that should work too.


/Benny




From kwizart at gmail.com  Tue Oct 16 08:38:15 2007
From: kwizart at gmail.com (KH KH)
Date: Tue, 16 Oct 2007 10:38:15 +0200
Subject: nucleo version problem
In-Reply-To: <d9c612bf0710151845vf07f538t2b32fafbd23aeac4@mail.gmail.com>
References: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
	<d9c612bf0710151845vf07f538t2b32fafbd23aeac4@mail.gmail.com>
Message-ID: <e1760170710160138o79031291g4c7d5228df6d8b95@mail.gmail.com>

2007/10/16, Christopher Stone <chris.stone at gmail.com>:
>
> On 10/14/07, subhodip biswas <440volt.tux at gmail.com> wrote:
> > Hi !
> >
> > I was thinking of packaging nucleo
> > [http://insitu.lri.fr/~roussel/projects/nucleo/]
> > First ..Is anybody working on this already??
> > Second... Nucleo comes in Nucleo-2007-XX-XX format. how to resolve this
> ??
>
> I packaged nucleo a while back and orphaned it, it should still be
> there in CVS.  Others have worked on packaging it since, but nothing
> has been officially added back to Fedora AFAIK.



I don't know if it worth packaging nucleo for Fedora... May be possible but
it will miss a dependency (ffmpeg)... Packaging Metisse seems harder since
it will have the same problems as packaging XGL (as Metisse isn't modular as
AIGLX - and use it owns fvwm that will conflict the Fedora version)...

Nicolas (kwizart)

--
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/bcf46af0/attachment.htm>

From lkundrak at redhat.com  Tue Oct 16 08:59:12 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 16 Oct 2007 10:59:12 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <20071015213117.GA6325@petra.dvoda.cz>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
Message-ID: <1192525152.30612.32.camel@localhost.localdomain>


On Mon, 2007-10-15 at 23:31 +0200, Karel Zak wrote:
>  Couldn't be better to maintain default selinux labels like others
>  file attributes?
> 
>      %attr(4755,root,root) %selinux(foo_t)  /bin/foo

I was thinking many times why don't we already do it this way. Much more
elegant and maintainable than restorecon in scriptlets.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From tmraz at redhat.com  Tue Oct 16 09:12:48 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 16 Oct 2007 11:12:48 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192525152.30612.32.camel@localhost.localdomain>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<1192525152.30612.32.camel@localhost.localdomain>
Message-ID: <1192525968.22253.60.camel@vespa.kabelta.loc>


On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
> On Mon, 2007-10-15 at 23:31 +0200, Karel Zak wrote:
> >  Couldn't be better to maintain default selinux labels like others
> >  file attributes?
> > 
> >      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
> 
> I was thinking many times why don't we already do it this way. Much more
> elegant and maintainable than restorecon in scriptlets.
And how does that take care of updating file_contexts so the labels are
not lost on the next filesystem relabel? This only means that the
initial labelling information is duplicated on two places and that
doesn't seem to me like a good idea.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From nicolas.mailhot at laposte.net  Tue Oct 16 09:36:03 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Oct 2007 11:36:03 +0200 (CEST)
Subject: If you are maintinaing of developing a Fedora Package.
Message-ID: <27182.192.54.193.51.1192527363.squirrel@rousalka.dyndns.org>


Le Mar 16 octobre 2007 11:12, Tomas Mraz a ?crit :
>
> On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
>> On Mon, 2007-10-15 at 23:31 +0200, Karel Zak wrote:
>> >  Couldn't be better to maintain default selinux labels like others
>> >  file attributes?
>> >
>> >      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
>>
>> I was thinking many times why don't we already do it this way. Much
>> more
>> elegant and maintainable than restorecon in scriptlets.
> And how does that take care of updating file_contexts so the labels
> are not lost on the next filesystem relabel?

>From a packager POW, ideally rpm would turn %selinux spec annotations
in a selinux policy file installed at the right place so relabel
works. That's plumbing your typical packager wants no part of.

Regards,

-- 
Nicolas Mailhot



From kzak at redhat.com  Tue Oct 16 09:39:57 2007
From: kzak at redhat.com (Karel Zak)
Date: Tue, 16 Oct 2007 11:39:57 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192525968.22253.60.camel@vespa.kabelta.loc>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<1192525152.30612.32.camel@localhost.localdomain>
	<1192525968.22253.60.camel@vespa.kabelta.loc>
Message-ID: <20071016093957.GC6325@petra.dvoda.cz>

On Tue, Oct 16, 2007 at 11:12:48AM +0200, Tomas Mraz wrote:
> 
> On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
> > On Mon, 2007-10-15 at 23:31 +0200, Karel Zak wrote:
> > >  Couldn't be better to maintain default selinux labels like others
> > >  file attributes?
> > > 
> > >      %attr(4755,root,root) %selinux(foo_t)  /bin/foo

 we have more policies, so probably:

 %selinux(policynameA, context_t), %selinux(policynameB, context_t),

> > 
> > I was thinking many times why don't we already do it this way. Much more
> > elegant and maintainable than restorecon in scriptlets.
> And how does that take care of updating file_contexts so the labels are
> not lost on the next filesystem relabel? This only means that the

 I'm talking about labels distribution only. You can locally at your
 system extract these information from .rpm and add/update/delete your
 local label database.

  package.rpm  --> rpm -i  --> add labels to label DB
               --> rpm -U  --> update label DB
               --> rpm -e  --> delete from DB

 The label DB is source for all relabel operations.

 My $0.02..

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From giallu at gmail.com  Tue Oct 16 09:40:49 2007
From: giallu at gmail.com (Gianluca Sforna)
Date: Tue, 16 Oct 2007 11:40:49 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192525968.22253.60.camel@vespa.kabelta.loc>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<1192525152.30612.32.camel@localhost.localdomain>
	<1192525968.22253.60.camel@vespa.kabelta.loc>
Message-ID: <d5ad21470710160240x5063f0acwb20a13f8efb0fd06@mail.gmail.com>

On 10/16/07, Tomas Mraz <tmraz at redhat.com> wrote:
>
> On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
> >
> > I was thinking many times why don't we already do it this way. Much more
> > elegant and maintainable than restorecon in scriptlets.
> And how does that take care of updating file_contexts so the labels are
> not lost on the next filesystem relabel? This only means that the
> initial labelling information is duplicated on two places and that
> doesn't seem to me like a good idea.

Also, I'm sure you don't want Joe sub-average packager (that is... me)
to mess around with SELinux contexts...



From denis at poolshark.org  Tue Oct 16 09:43:48 2007
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 16 Oct 2007 11:43:48 +0200
Subject: rawhide report: 20071015 changes
In-Reply-To: <loom.20071016T061751-628@post.gmane.org>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071016T061751-628@post.gmane.org>
Message-ID: <471487D4.7070906@poolshark.org>

Kevin Kofler wrote:
> Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
>> Fight the freeze!
> 
> Don't panic. I've already rebuilt kdelibs4 and kdebase4, Rex is doing most of 
> the others, all the other maintainers have been informed (well in advance),

hmm, i wasn't informed of the OpenEXR update...



From joost at cnoc.nl  Tue Oct 16 10:06:57 2007
From: joost at cnoc.nl (Joost van der Sluis)
Date: Tue, 16 Oct 2007 12:06:57 +0200
Subject: "ERROR: No build ID note found in" while building fpc (Freepascal
	compiler)
Message-ID: <1192529217.613.22.camel@wsjoost.cnoc.local>

Hi all,

I got this problem on Koji wile compiling fpc:

extracting debug info 
from /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
*** ERROR: No build ID note found in /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
error: Bad exit status from /var/tmp/rpm-tmp.37361 (%install)

I've read this message: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00141.html 
and it gives some hints, but they are useless for Freepascal. ;) 

h2pas is static-linked, could that be the problem? (all files in this packages are)

Freepascal directly calls ld, so that could be the issue. But changing
it in $(CC) -shared is simply not an option. ;) Besides, gcc should also
call ld, so how does it do that, what is the difference?

Who can help me with this?

Joost.



From roland at redhat.com  Tue Oct 16 10:13:34 2007
From: roland at redhat.com (Roland McGrath)
Date: Tue, 16 Oct 2007 03:13:34 -0700 (PDT)
Subject: "ERROR: No build ID note found in" while building fpc
	(Freepascal compiler)
In-Reply-To: Joost van der Sluis's message of  Tuesday,
	16 October 2007 12:06:57 +0200
	<1192529217.613.22.camel@wsjoost.cnoc.local>
References: <1192529217.613.22.camel@wsjoost.cnoc.local>
Message-ID: <20071016101334.A81D44D04E1@magilla.localdomain>

> h2pas is static-linked, could that be the problem? (all files in this packages are)

That is not a problem by itself.  It's some details of the linking ld
command that matter, ones that work the same for static or dynamic linking.

> Freepascal directly calls ld, so that could be the issue. But changing
> it in $(CC) -shared is simply not an option. ;) Besides, gcc should also
> call ld, so how does it do that, what is the difference?

When gcc runs ld it knows to pass the --build-id option when doing a final
link.  Any other compiler driver that runs ld should do the same thing.
It is probably straightforward to find where its source or configuration
chooses options to pass ld on Linux, and insert --build-id in there.
Then every program produced by this compiler will have an ID on F8, like
all other programs do.


Thanks,
Roland



From jakub at redhat.com  Tue Oct 16 10:16:30 2007
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 16 Oct 2007 06:16:30 -0400
Subject: "ERROR: No build ID note found in" while building fpc
	(Freepascal compiler)
In-Reply-To: <1192529217.613.22.camel@wsjoost.cnoc.local>
References: <1192529217.613.22.camel@wsjoost.cnoc.local>
Message-ID: <20071016101630.GJ5451@devserv.devel.redhat.com>

On Tue, Oct 16, 2007 at 12:06:57PM +0200, Joost van der Sluis wrote:
> I got this problem on Koji wile compiling fpc:
> 
> extracting debug info 
> from /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
> *** ERROR: No build ID note found in /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
> error: Bad exit status from /var/tmp/rpm-tmp.37361 (%install)
> 
> I've read this message: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00141.html 
> and it gives some hints, but they are useless for Freepascal. ;) 

You need to arrange for the compiler to pass --build-id option to the
linker when it invokes it.  In gcc that's done through spec change, how to
in freepascal it is probably done differently.  While at it, make sure e.g.
--eh-frame-hdr is passed to the linker as well for non-static links.

> h2pas is static-linked, could that be the problem? (all files in this packages are)

If all programs in freepascal are statically linked, then I wonder how this
package ever could get through review.

	Jakub



From joost at cnoc.nl  Tue Oct 16 10:17:28 2007
From: joost at cnoc.nl (Joost van der Sluis)
Date: Tue, 16 Oct 2007 12:17:28 +0200
Subject: "ERROR: No build ID note found in" while building fpc
	(Freepascal compiler)
In-Reply-To: <1192529217.613.22.camel@wsjoost.cnoc.local>
References: <1192529217.613.22.camel@wsjoost.cnoc.local>
Message-ID: <1192529848.613.29.camel@wsjoost.cnoc.local>

Op dinsdag 16-10-2007 om 12:06 uur [tijdzone +0200], schreef Joost van
der Sluis:
> Hi all,
> 
> I got this problem on Koji wile compiling fpc:
> 
> extracting debug info 
> from /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
> *** ERROR: No build ID note found in /var/tmp/fpc-2.2.0-3.fc8-root-kojibuilder/usr/bin/h2pas
> error: Bad exit status from /var/tmp/rpm-tmp.37361 (%install)
> 
> I've read this message: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00141.html 
> and it gives some hints, but they are useless for Freepascal. ;) 
> 
> h2pas is static-linked, could that be the problem? (all files in this packages are)
> 
> Freepascal directly calls ld, so that could be the issue. But changing
> it in $(CC) -shared is simply not an option. ;) Besides, gcc should also
> call ld, so how does it do that, what is the difference?
> 
> Who can help me with this?

I've found this http://fedoraproject.org/wiki/Releases/FeatureBuildId
and now I understand where this is all about.

But in my case is't simple: fpc doesn't support the .note.gnu.build-id
section for now. It's not an official section, so that's not that
strange. Support for it can be added, offcourse. But not in the current
release i'm packaging.

Maybe I could add a parameter to fpc so that it uses the --build-id
parameter when calling ld. I'll try that solution.

But as a consequence all fpc-programs in Fedora should add that
parameter to their build-scripts. I don't really like that solution...

Btw: the problem to identify binaries which you want to solve with this
trick, doesn't exist with fpc-binaries. What you're trying to solve is a
real gcc-problem only. So if this can be disabled in some way for
fpc-programs, that would be great.

Joost 




From kevin.kofler at chello.at  Tue Oct 16 09:52:55 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Oct 2007 09:52:55 +0000 (UTC)
Subject: rawhide report: 20071015 changes
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071016T061751-628@post.gmane.org>
	<471487D4.7070906@poolshark.org>
Message-ID: <loom.20071016T095152-867@post.gmane.org>

Denis Leroy <denis <at> poolshark.org> writes:
> hmm, i wasn't informed of the OpenEXR update...

Are you maintaining a package which depends on OpenEXR? Rex tried to e-mail all 
the maintainers affected by the soname bump.

        Kevin Kofler



From roland at redhat.com  Tue Oct 16 10:35:37 2007
From: roland at redhat.com (Roland McGrath)
Date: Tue, 16 Oct 2007 03:35:37 -0700 (PDT)
Subject: "ERROR: No build ID note found in" while building fpc
	(Freepascal compiler)
In-Reply-To: Joost van der Sluis's message of  Tuesday,
	16 October 2007 12:17:28 +0200
	<1192529848.613.29.camel@wsjoost.cnoc.local>
References: <1192529217.613.22.camel@wsjoost.cnoc.local>
	<1192529848.613.29.camel@wsjoost.cnoc.local>
Message-ID: <20071016103537.95CFF4D04E2@magilla.localdomain>

> I've found this http://fedoraproject.org/wiki/Releases/FeatureBuildId
> and now I understand where this is all about.
> 
> But in my case is't simple: fpc doesn't support the .note.gnu.build-id
> section for now. It's not an official section, so that's not that
> strange. 

It's not something a compiler supports.  It just has to invoke the linker.

> Support for it can be added, offcourse. But not in the current
> release i'm packaging.

It's a trivial change to the linker options the compiler runs.
It's mandatory for a compiler package in F8.

> Maybe I could add a parameter to fpc so that it uses the --build-id
> parameter when calling ld. I'll try that solution.
> 
> But as a consequence all fpc-programs in Fedora should add that
> parameter to their build-scripts. I don't really like that solution...

Nonsense.  fpc should pass --build-id to ld by default just like gcc does.
Of course we didn't change every C program's build command for this either.

> Btw: the problem to identify binaries which you want to solve with this
> trick, doesn't exist with fpc-binaries. What you're trying to solve is a
> real gcc-problem only. So if this can be disabled in some way for
> fpc-programs, that would be great.

You misunderstand the feature.  If you produce ELF binaries, it applies to
you no different than anything else.  If you didn't produce ELF binaries,
you wouldn't have gotten the build error, so we know you do.  It applies.


Thanks,
Roland



From buildsys at redhat.com  Tue Oct 16 10:35:47 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 16 Oct 2007 06:35:47 -0400
Subject: rawhide report: 20071016 changes
Message-ID: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>

New package rats
	Rough Auditing Tool for Security

New package syncevolution
	SyncML client for evolution


 
Updated Packages:

GConf2-2.20.1-1.fc8
-------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- 2.20.1 (translation and documentation updates)

ORBit2-2.14.10-1.fc8
--------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.14.10-1
- Update to 2.14.10 (bug fixes)

Pixie-2.2.2-3.fc8
-----------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 2.2.2-3
- Rebuild

SDL_mixer-1.2.8-3.fc8
---------------------
* Mon Oct 15 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.2.8-3
- Change requires to timidity++-patches. (#331431)

aqsis-1.2.0-6.fc8
-----------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 1.2.0-6
- Rebuild

at-spi-1.20.1-1.fc8
-------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1.20.1-1
- Update to 1.20.1

audacious-plugins-1.3.5-3.fc8
-----------------------------
* Mon Oct 15 2007 Lubomir Kundrak <lkundrak at redhat.com 1.3.5-3
- Change BuildReq pulseaudio-devel to pulseaudio-libs-devel
- Fix the License tag

cinepaint-0.22.1-5.fc8
----------------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 0.22.1-5
- Rebuild to new OpenEXR

control-center-1:2.20.1-1.fc8
-----------------------------
* Mon Oct 15 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-1
- Update to 2.20.1

cpan2rpm-2.028-2.fc8.1
----------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.028-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

dasher-4.6.1-1.fc8
------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 4.6.1-1
- Update to 4.6.1 (bug fixes)

deskbar-applet-2.20.1-1.fc8
---------------------------
* Mon Oct 15 2007 Luke Macken <lmacken at redhat.com> - 2.20.1-1
- 2.20.1
- Add dbus-python-devel to BuildRequires

e2fsprogs-1.40.2-9.fc8
----------------------
* Mon Oct 15 2007 Eric Sandeen <esandeen at redhat.com> 1.40.2-9
- Detect big-endian squashfs filesystems in libblkid (#305151)

eog-2.20.1-1.fc8
----------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (bug fixes and translation updates)

epiphany-2.20.1-1.fc8
---------------------
* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Fix network status monitoring with new NM (#332771)

* Mon Sep 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-1
- Update to 2.20.0

evince-2.20.1-1.fc8
-------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (bug fixes and translation updates)

evolution-2.12.1-2.fc8
----------------------
* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.1-2.fc8
- Fix a broken zoom icon.

* Mon Oct 15 2007 Milan Crha <mcrha at redhat.com> - 2.12.1-1.fc8
- Update to 2.12.1
- Add files for the new backup-restore plugin.

* Tue Oct 09 2007 Matthew Barnes <mbarnes at redhat.com. - 2.12.0-8.fc8
- Sync version requirements up with configure.in.

evolution-data-server-1.12.1-1.fc8
----------------------------------
* Mon Oct 15 2007 Milan Crha <mcrha at redhat.com> - 1.12.1-1.fc8
- Update to 1.12.1

evolution-exchange-2.12.1-1.fc8
-------------------------------
* Mon Oct 15 2007 Milan Crha <mcrha at redhat.com> - 2.12.1-1.fc8
- Update to 2.12.1
- Removed evolution-exchange-2.11.92-compilation-breakage.patch (fixed upstream).
- Removed evolution-exchange-2.12.0-warnings.patch (fixed upstream).

evolution-remove-duplicates-0.0.3-1.fc8
---------------------------------------
* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 0.0.3-1.fc8
- Update to 0.0.3

file-roller-2.20.1-1.fc8
------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (crash fix)

fyre-1.0.1-4.fc8
----------------
* Mon Oct 15 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.0.1-4
- Rebuild for new OpenEXR-devel.

gai-pal-0.7-12.fc8
------------------
* Mon Oct 15 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 0.7-12
- set large font to size 24 instead of 26
- empty stdout of fortune program must not crash xosd either
- clarify licence: GPLv2

* Thu May 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net>
- substitute /lib/ with /%_lib/ not just for x86_64 (fixes ppc64 build)

* Mon Oct 02 2006 Michael Schwendt <mschwendt[AT]users.sf.net> - 0.7-11
- rebuilt

gail-1.20.1-1.fc8
-----------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1.20.1-1
- Update to 1.20.1

gcalctool-5.20.2-1.fc8
----------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 5.20.2-1
- 5.20.2 (fix accuracy setting)

gdm-1:2.20.1-1.fc8
------------------
* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.1-1
- Update to 2.20.1

* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.0-16
- make fedorainfinity-gdm-theme requires be versioned

* Fri Oct 05 2007 Dan Walsh <dwalsh at redhat.com> - 1:2.20.0-14
- Added pam_selinux_permit and pam_namespace to gdm-pam
  * This pam module allows user without a password to login when selinux is in enforcing mode
- Added pam_namespace to gdm-autologin-pam
- These changes were made to make it easier to setup the xguest user account

gedit-1:2.20.2-1.fc8
--------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.2-1
- Update to 2.20.2 (bug fixes and translation updates)
gnome-desktop-2.20.1-1.fc8
--------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (bug fixes and translation updates)

gnome-games-1:2.20.1-1.fc8
--------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.1-1
- Update to 2.20.1 (bug fixes)
- Drop obsolete patch

* Tue Oct 09 2007 Hans de Goede <j.w.r.degoede at hhs.nl> - 1:2.20.0.1-2
- Fix gnobots from crashing with certain combinations of options (bz 324221)

* Tue Sep 18 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0.1-1
- Update to 2.20.0.1

gnome-menus-2.20.1-1.fc8
------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

gnome-panel-2.20.1-1.fc8
------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

gnome-session-2.20.1-1.fc8
--------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

gnome-spell-1.0.8-1.fc8
-----------------------
* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 1.0.8-1.fc8
- Update to 1.0.8

gnome-system-monitor-2.20.1-1.fc8
---------------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1

gok-1.3.7-1.fc8
---------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1.3.7-1
- Update to 1.3.7

gthumb-2.10.7-1.fc8
-------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.10.7-1
- Update to 2.10.7 (bug fixes)

* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 2.10.6-2
- Fix rotation of images with # in their name (#248708)

gtk2-engines-2.12.2-1.fc8
-------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.2-1
- Update to 2.12.2 (bug fixes and translation updates)

gtkhtml3-3.16.1-1.fc8
---------------------
* Mon Oct 15 2007 Milan Crha <mcrha at redhat.com> - 3.16.1-1.fc8
- Update to 3.16.1

* Mon Sep 17 2007 Matthew Barnes <mbarnes at redhat.com> - 3.16.0-1.fc8
- Update to 3.16.0

* Thu Sep 13 2007 Matthew Barnes <mbarnes at redhat.com> - 3.15.92-2.fc8
- Add patch for GNOME bug #443850 (fix cursor position after typing halant).

hwbrowser-0.39-1.fc8
--------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.39-1
- add release tags to changelog versions to appease rpmlint
- add blurb about this being upstream before source file
- use "make %{?_smp_mflags}"
- use "%defattr(-,root,root,-)"

java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8
------------------------------------------------
* Mon Oct 15 2007 Lillian Angel <langel at redhat.com> - 1.7.0.0-0.19.b21.snapshot
- Updated release.

* Fri Oct 12 2007 Lillian Angel <langel at redhat.com> - 1.7.0.0-0.18.b21.snapshot
- Updated release.

* Fri Oct 12 2007 Lillian Angel <langel at redhat.com> - 1.7.0.0-0.17.b21.snapshot
- Added jhat patch back in.

k3d-0.6.7.0-4.fc8
-----------------
* Mon Oct 15 2007 Denis Leroy <denis at poolshark.org> - 0.6.7.0-4
- Rebuild for OpenEXR 1.6

kawa-1:1.9.1-3.fc8
------------------
* Mon Oct 15 2007 Anthony Green <green at redhat.com> - 1:1.9.1-3
- Don't build with icedtea, as it's not portable.
- Build .class files with gcj to work around ecj bug.

* Mon Oct 15 2007 Anthony Green <green at redhat.com> - 1:1.9.1-2
- Oops.  Change %License to MIT.

* Mon Oct 15 2007 Anthony Green <green at redhat.com> - 1:1.9.1-1
- BuildRequire java-1.7.0-icedtea-devel, since that's what we'll build
  with now.
- Upgrade to 1.9.1.
- Change %License to BSD.

kbd-1.12-26.fc8
---------------
* Mon Oct 15 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.12-26
- Fix ro.map to generate right unicode for s, S, t, T with comma
- Fix LatArCyrHeb-16 unicode mapping table to show comma-version
  of s, S, t, T and cedilla-version of s, S, t, T as the same glyph
  (because there is no font in kbd for comma-version)
  Resolves: #329071

kdebase-6:3.5.8-3.fc8
---------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3
- respin (for openexr-1.6.0)
- -libs: %post/%postun /sbin/ldconfig

kdebase4-3.93.0-6.fc8
---------------------
* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-6
- rebuild for new OpenEXR

kdegraphics-7:3.5.8-2.fc8
-------------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-2
- respin (for openexr-1.6.0)
- -libs: %post/%postun -p /sbin/ldconfig

kdelibs-6:3.5.8-3.fc8
---------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-3
- respin (for openexr-1.6.0)

* Fri Oct 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-2
- kde-3.5.8

* Tue Sep 25 2007 Than Ngo <than at redhat.com> - 6:3.5.7-23
- fix rh#243611, autostart from XDG_CONFIG_DIRS

kdelibs4-3.93.0-12.fc8
----------------------
* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-12
- rebuild for new OpenEXR

kudzu-1.2.79-1
--------------
* Mon Oct 15 2007 Bill Nottingham <notting at redhat.com> 1.2.79-1
- apparently the PS3 net module changed names

kvm-36-7.fc8
------------
* Mon Oct 15 2007 Daniel P. Berrange <berrange at redhat.com> - 36-7.fc8
- Fixed PXE boot when KVM is enabled (rhbz #331191)

libbonobo-2.20.1-1.fc8
----------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (memory leak fixes, translation updates)
- Drop upstreamed patches

libgnome-2.20.1-1.fc8
---------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation update)

* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-4
- Add Requires: fedora-gnome-theme >= 8.0.0

* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-3
- Add Requires: fedora-gnome-theme

libgnomecanvas-2.20.1-1.fc8
---------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> 2.20.1-1
- Update to 2.20.1 (translation updates)

* Tue Oct 09 2007 Matthias Clasen <mclasen at redhat.com> 2.20.0-2
- Take out the scrolling patch, since it causes redraw problems (#289281)

* Mon Sep 17 2007 Matthias Clasen <mclasen at redhat.com> 2.20.0-1
- Update to 2.20.0

libgnomeui-2.20.1-1.fc8
-----------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates, file chooser improvements)

* Wed Sep 19 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-1
- Update to 2.20.0

* Thu Aug 23 2007 Adam Jackson <ajax at redhat.com> - 2.19.1-3
- Rebuild for ppc toolchain bug

libgpg-error-1.5-6
------------------
* Mon Oct 15 2007 Nalin Dahyabhai <nalin at redhat.com> - 1.5-6
- use ldconfig to make the soname symlink so that it gets packaged (#331241)

libtirpc-0.1.7-11.fc8
---------------------
* Mon Oct 15 2007 Steve Dickson  <steved at redhat.com> 0.1.7-11
- Made tcp6/udp6 network ids no longer visible in the netconfig
  file since the ipv6 code is not fully baked yet in rpcbind. (bz 249121)

libvirt-0.3.3-2.fc8
-------------------
* Mon Oct 15 2007 Daniel P. Berrange <berrange at redhat.com> - 0.3.3-2.fc8
- Added QEMU driver config file support
- Added example config files

libvorbis-1:1.2.0-1.fc8
-----------------------
* Mon Oct 15 2007 Behdad Esfahbod <besfahbo at redhat.com> - 1:1.2.0-1
- Update to 1.2.0
- Resolves: #250115

libwnck-2.20.1-1.fc8
--------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (crash fixes, translation updates)

lockdev-1.0.1-11.fc8.1
----------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.1-11.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

mksh-31d-1.fc8
--------------
* Mon Oct 15 2007 Robert Scheck <robert at fedoraproject.org> 31d-1
- Upgrade to 31d

mrtg-2.15.1-6.fc8
-----------------
* Mon Oct 15 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2.15.1-6
- Fix another two bad perl provides

ocsinventory-client-1.01-6.fc8
------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.01-6
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

octave-6:2.9.15-1.fc8
---------------------
* Mon Oct 15 2007 Quentin Spencer <qspencer at users.sourceforge.net> 2.9.15-1
- New release. Remove old patch.

openssl-0.9.8b-17.fc8
---------------------
* Mon Oct 15 2007 Joe Orton <jorton at redhat.com> 0.9.8b-17
- update to new CA bundle from mozilla.org

orca-2.20.0.1-1.fc8
-------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0.1-1
- Update to 2.20.0.1 (bug fixes and translation updates)

pango-1.18.3-1.fc8
------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 1.18.3-1
- Update to 1.18.3 (make Nafees Nastaliq font work)

perl-4:5.8.8-28.fc8.3
---------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.3
- add versioned Requires for db4-devel that we built against (resolves 144672)
perl-AnyData-0.10-4.fc8.1
-------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.10-4.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Apache-DBI-1.06-1.fc8.2
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.06-1.2
- add BR: perl(Test::More)
perl-Apache-Session-1.84-1.fc8
------------------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 1.84-1
- Update to 1.84.
- License changed to GPL+ or Artistic.
- Package Contributing.txt doc.

perl-Authen-SASL-2.10-1.fc8.1
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.10-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Boulder-1.30-4.fc8.1
-------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.30-4.1
- missing BR
perl-CGI-Simple-0.077-8.fc8
---------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.077-8
- add BR: perl(ExtUtils::MakeMaker)

perl-Cache-2.04-2.fc8.2
-----------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.04-2.2
- add BR: perl(Test::More)
perl-Cache-Cache-1.05-1.fc8.1
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.05-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Chatbot-Eliza-1.04-3.fc8.1
-------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.04-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-Class-InsideOut-1.06-1.fc8.2
---------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.06-1.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.06-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Class-MakeMethods-1.01-2.fc8.2
-----------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.01-2.2
- add BR: perl(Test::More)
perl-Class-MethodMaker-2.08-4.fc8.1
-----------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.08-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Class-Singleton-1.4-1.fc8
------------------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 1.4-1
- Update to 1.4.
- Update License tag.
- Drop our copy of the license text.
- Improve Summary.
- Make description match cpanspec output.
- BR Test::More.

perl-Config-IniFiles-2.39-5.fc8.1
---------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.39-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Config-Record-1.1.1-3.fc8.2
--------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.1.1-3.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.1.1-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Convert-ASN1-0.21-2.fc8.1
------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.21-2.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Crypt-Blowfish-2.10-2.fc8.1
--------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.10-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Crypt-CBC-2.22-1.fc8.1
---------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.22-1.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Crypt-PasswdMD5-1.3-2.fc8.1
--------------------------------

perl-DBD-CSV-0.22-5.fc8.1
-------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.22-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-DBD-MySQL-4.005-2.fc8.1
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4.005-2.1
- add BR: perl(ExtUtils::MakeMaker)

perl-DBD-Pg-1.49-5.fc8.1
------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.49-5.1
- add BR: perl(ExtUtils::MakeMaker)

perl-DBD-SQLite-1.12-2.fc8.1
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.12-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-DBD-XBase-0.241-5.fc8.1
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.241-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Data-Compare-0.16-1.fc8.2
------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.16-1.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.16-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Data-HexDump-0.02-3.fc8.1
------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.02-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-Date-Calc-5.4-2.1
----------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 5.4-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Date-Pcalc-1.2-4.fc8.1
---------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.2-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Devel-Cover-0.61-1.fc8.1
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.61-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Devel-Cycle-1.07-1.fc8.2
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-1.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Digest-MD4-1.5-3.fc8.1
---------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.5-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-Digest-Nilsimsa-0.06-8.fc8.1
---------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.06-8.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Expect-1.20-1.fc8.1
------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.20-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-Expect-Simple-0.02-1.fc8.1
-------------------------------

perl-ExtUtils-CBuilder-0.19-1.fc8.1
-----------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.19-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-ExtUtils-Depends-0.205-5.fc8.1
-----------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.205-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-ExtUtils-ParseXS-2.18-1.fc8.1
----------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.18-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-ExtUtils-XSBuilder-0.28-3.fc8.1
------------------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.28-3.1
- add BR: perl(ExtUtils::MakeMaker)

* Sun Aug 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.28-3
- license tag fix

perl-Feed-Find-0.06-2.fc8.1
---------------------------

perl-File-Fetch-0.12-1.fc8
--------------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 0.12-1
- Update to 0.12.
- Update License tag.
- Update BR IPC::Cmd to >= 0.36.

perl-File-NFSLock-1.20-2.fc8.1
------------------------------

perl-File-RsyncP-0.68-2.fc8.1
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.68-2.1
- add BR: perl(ExtUtils::MakeMaker)

perl-File-Tail-0.99.3-5.fc8.1
-----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.99.3-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-File-Which-0.05-2.fc8.1
----------------------------

perl-Finance-Quote-1.13-1.fc8
-----------------------------
* Wed Sep 26 2007 Bill Nottingham <notting at redhat.com>
- add perl(ExtUtils::MakeMaker) buildreq

* Tue Sep 18 2007 Bill Nottingham <notting at redhat.com>
- fix source download URL

* Fri Aug 03 2007 Bill Nottingham <notting at redhat.com>
- tweak license tag

perl-Finance-YahooQuote-0.21-2.fc8.1
------------------------------------

perl-FreezeThaw-0.43-5.fc8.1
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.43-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-GD-2.35-2.fc8.1
--------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.35-2.1
- add BR: perl(ExtUtils::MakeMaker)
perl-GDGraph3d-0.63-7.fc8.1
---------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.63-7.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-GDTextUtil-0.86-8.fc8.1
----------------------------
* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.86-8.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IPC-Cmd-0.38-1.fc8
-----------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 0.38-1
- Update to 0.38.
- Update License tag.
- BR Test::More.

perl-Module-Load-0.12-1.fc8
---------------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 0.12-1
- Update to 0.12.
- Update License tag.
- Include CHANGES doc.
- BR Test::More.
perl-Text-Kakasi-2.04-6.fc8
---------------------------
* Tue Oct 16 2007 Akira TAGOH <tagoh at redhat.com> - 2.04-6
- Add BR perl(ExtUtils::MakeMaker)

perl-Unix-Syslog-1.0-1.fc8
--------------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 1.0-1
- Update to 1.0.
- Update License.
- Reformat a little to match cpanspec output.

policycoreutils-2.0.31-2.fc8
----------------------------
* Mon Oct 15 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-1
- Remove no.po
- Update to upstream
	* Fix semodule option handling from Dan Walsh.
	* Add deleteall support for ports and fcontexts in semanage from Dan Walsh.

* Thu Oct 11 2007 Dan Walsh <dwalsh at redhat.com> 2.0.29-2
- Fix semodule parameter checking

qt4-theme-quarticurve-0.0-0.5.beta4.fc8
---------------------------------------
* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.5.beta4
- Update to beta 4 (updated readme, fixed QPushButton::iconSize being ignored).

qtpfsgui-1.8.12-2.fc8
---------------------
* Mon Oct 15 2007 Douglas E. Warner <silfreed at silfreed.net> 1.8.12-2
- new OpenEXR version

rasqal-0.9.14-2.fc8
-------------------
* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.9.14-2
- Update minimum raptor version

* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.9.14-1
- Update to 0.9.14 (for redland 1.0.6, also lots of bugfixes)
- Specify LGPL version in License tag

rhgb-8.0.0-1.fc8
----------------
* Mon Oct 15 2007 Ray Strode <rstrode at redhat.com> 8.0.0-1
- update to 8.0.0
- buffer init messages while X starts to slightly improve boot time

rpcbind-0.1.4-9.fc8
-------------------
* Mon Oct 15 2007 Steve Dickson <steved at redhat.com> 0.1.4-9
- Fixed typo in Summary (bz 331811)
- Corrected init script (bz 247046)

samba-0:3.0.26a-5.fc8
---------------------
* Sun Oct 14 2007 Simo Sorce <ssorce at redhat.com> 3.0.26a-5.fc8
- Fix default domain patch turned out to be incomplete, fixed

* Thu Oct 11 2007 Simo Sorce <ssorce at redhat.com> 3.0.26a-4.fc8
- Fix idmap_rid module with compatible config syntax

sound-juicer-2.20.1-1.fc8
-------------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (crash fixes)

synaptics-0.14.4-11.fc8
-----------------------
* Mon Oct 15 2007 Adam Jackson <ajax at redhat.com> 0.14.4-11
- Back to ExclusiveArch, buildsystem is a disaster.

* Wed Oct 03 2007 Adam Jackson <ajax at redhat.com> 0.14.4-10
- ExclusiveArch -> ExcludeArch.

system-config-date-1.9.14-1.fc8
-------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.14-1
- avoid traceback when neither xdg-open nor htmlview is found

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.13-1
- change hicolor-icon-theme requirement to be "uncolored" (without
  "(post)"/"(postun)")
- use full path to call gtk-update-icon-cache
- don't let gtk-update-icon-cache fail scriptlets
- use "make %{?_smp_mflags}"
- remove "ExclusiveOS: Linux"
- remove obsolete no.po translation file
- use "%defattr(-,root,root,-)"
- add release tags to changelog versions to appease rpmlint

* Tue Oct 09 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.12-1
- use xdg-open if available
- don't throw exceptions when selecting non-geographic time zones (#293241)
- fix permissions of timeconfig tool (#241737)

system-config-nfs-1.3.32-1.fc8
------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.32-1
- fix some typos
- avoid traceback when neither xdg-open nor htmlview is found

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.3.31-1
- Merge review (#226465):
  - remove duplicate file from %files
  - re-add plain hicolor-icon-theme requirement to avoid unowned directories
- remove obsolete no.po translation file (#332481)
- don't let gtk-update-icon-cache fail scriptlets

system-config-samba-1.2.58-1.fc8
--------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.58-1
- avoid traceback when neither xdg-open nor htmlview is found

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.57-1
- re-add plain hicolor-icon-theme requirement to avoid unowned directories
- don't let gtk-update-icon-cache fail scriptlets
- remove obsolete no.po translation file (#332471)

system-config-services-0.9.17-1.fc8
-----------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.17-1
- avoid traceback when neither xdg-open nor htmlview is found

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.9.16-1
- add release tag to remaining changelog versions to appease rpmlint
- don't let gtk-update-icon-cache fail scriptlets
- re-add plain hicolor-icon-theme requirement to avoid unowned directories
- remove obsolete no.po translation file (#332411)

system-config-users-1.2.71-1.fc8
--------------------------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.71-1
- add release tags to changelog entries to appease rpmlint
- remove "ExclusiveOS: Linux"
- use xdg-open if available
- change hicolor-icon-theme requirement to be "uncolored" (without
  "(post)"/"(postun)")
- obsolete explicit version of redhat-config-users
- use "%defattr(-,root,root,-)"
- don't use %attr
- use "%config(noreplace)"
- use macros instead of hardcoded directories
- don't let gtk-update-icon-cache fail scriptlets
- remove obsolete no.po translation file (#332431)
- use "make %{?_smp_mflags}"

* Mon Oct 08 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.70-1
- add "make diff" ("dif") and "make shortdiff" ("sdif")
- pull in updated translations

* Tue Oct 02 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.69-1
- prohibit home directories which are not absolute paths or contain path
  components which are empty, ".", ".." or too long (#303971)

tomboy-0.8.1-1.fc8
------------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 0.8.1-1
- Update to 0.8.1 (bug fixes)

vdr-femon-1.1.4-1.fc8
---------------------
* Mon Oct 15 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.1.4-1
- 1.1.4.
- License changed to GPLv2+.

vdr-skinsoppalusikka-1.0.5-2.fc8
--------------------------------
* Tue Oct 16 2007 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 1.0.5-2
- License is actually GPLv2 _or later_, I missed that, fixed now.

vdr-ttxtsubs-0.0.5-2.fc8
------------------------
* Mon Oct 15 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.5-2
- Rebuild.

vino-2.20.1-1.fc8
-----------------
* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

vips-7.12.5-2.fc8
-----------------
* Mon Oct 15 2007 Adam Goode <adam at spicenitz.org> - 7.12.5-2
- Rebuild for OpenEXR update

virt-manager-0.5.2-2.fc8
------------------------
* Mon Oct 15 2007 Daniel P. Berrange <berrange at redhat.com> - 0.5.2-2.fc8
- Change TLS x509 credential name to sync with libvirt

virt-viewer-0.0.2-2.fc8
-----------------------
* Mon Oct 15 2007 Daniel P. Berrange <berrange at redhat.com> - 0.0.2-2.fc8
- Change TLS x509 credential name to sync with libvirt
xorg-x11-drivers-7.2-9.fc8
--------------------------
* Mon Oct 15 2007 Adam Jackson <ajax at redhat.com> 7.2-9
- Archify synaptics, it's not buildable most places.

xorg-x11-drv-ati-6.7.195-3.fc8
------------------------------
* Tue Oct 16 2007 Dave Airlie <airlied at redhat.com> 6.7.195-3
- upstream fixes including previous patches + attempted mac detection

xscreensaver-1:5.03-11.fc8
--------------------------
* Mon Oct 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-11
- Suppress compiler warning

yafray-0.0.9-4.fc8
------------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 0.0.9-4
- Rebuild

Broken deps for i386
----------------------------------------------------------
	blender - 2.45-3.fc8.i386 requires libHalf.so.4
	blender - 2.45-3.fc8.i386 requires libImath.so.4
	blender - 2.45-3.fc8.i386 requires libIlmImf.so.4
	blender - 2.45-3.fc8.i386 requires libIex.so.4
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	koffice-krita - 1.6.3-11.fc8.i386 requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libImath.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libHalf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.i386 requires libIex.so.4
	octave-forge - 2006.07.09-9.fc7.i386 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.i386 requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	scim-python-english - 0.1.4-2.fc8.i386 requires scim-python = 0:%{epoch}:0.1.4-2.fc8



Broken deps for x86_64
----------------------------------------------------------
	blender - 2.45-3.fc8.x86_64 requires libHalf.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libIex.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	blender - 2.45-3.fc8.x86_64 requires libImath.so.4()(64bit)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	koffice-krita - 1.6.3-11.fc8.x86_64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.i386 requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.i386 requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.x86_64 requires libHalf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libIex.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libImath.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.x86_64 requires libIlmImf.so.4()(64bit)
	octave-forge - 2006.07.09-9.fc7.x86_64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.x86_64 requires libginac-1.3.so.2()(64bit)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	scim-python-english - 0.1.4-2.fc8.x86_64 requires scim-python = 0:%{epoch}:0.1.4-2.fc8



Broken deps for ppc
----------------------------------------------------------
	blender - 2.45-3.fc8.ppc requires libHalf.so.4
	blender - 2.45-3.fc8.ppc requires libImath.so.4
	blender - 2.45-3.fc8.ppc requires libIlmImf.so.4
	blender - 2.45-3.fc8.ppc requires libIex.so.4
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	koffice-krita - 1.6.3-11.fc8.ppc requires libHalf.so.4
	koffice-krita - 1.6.3-11.fc8.ppc requires libIlmImf.so.4
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc requires libImath.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libHalf.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libIlmImf.so.4
	nip2 - 7.12.5-1.fc8.ppc requires libIex.so.4
	octave-forge - 2006.07.09-9.fc7.ppc requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc requires libginac-1.3.so.2
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	scim-python-english - 0.1.4-2.fc8.ppc requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	wammu - 0.19-3.fc8.noarch requires python-gammu



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	blender - 2.45-3.fc8.ppc64 requires libHalf.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libIex.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	blender - 2.45-3.fc8.ppc64 requires libImath.so.4()(64bit)
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libHalf.so.4()(64bit)
	koffice-krita - 1.6.3-11.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libHalf.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libIex.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libImath.so.4()(64bit)
	nip2 - 7.12.5-1.fc8.ppc64 requires libIlmImf.so.4()(64bit)
	octave-forge - 2006.07.09-9.fc7.ppc64 requires octave(api) = 0:api-v22
	octave-forge - 2006.07.09-9.fc7.ppc64 requires libginac-1.3.so.2()(64bit)
	scim-python-english - 0.1.4-2.fc8.ppc64 requires scim-python = 0:%{epoch}:0.1.4-2.fc8
	wammu - 0.19-3.fc8.noarch requires python-gammu





From roland at redhat.com  Tue Oct 16 10:54:53 2007
From: roland at redhat.com (Roland McGrath)
Date: Tue, 16 Oct 2007 03:54:53 -0700 (PDT)
Subject: "ERROR: No build ID note found in" while building fpc
	(Freepascal compiler)
In-Reply-To: Roland McGrath's message of  Tuesday,
	16 October 2007 03:35:37 -0700
	<20071016103537.95CFF4D04E2@magilla.localdomain>
References: <1192529217.613.22.camel@wsjoost.cnoc.local>
	<1192529848.613.29.camel@wsjoost.cnoc.local>
	<20071016103537.95CFF4D04E2@magilla.localdomain>
Message-ID: <20071016105453.53A434D04E2@magilla.localdomain>

This looks like it might be a sufficient hack, not that I really know this code.

--- fpcbuild-2.2.0/fpcsrc/compiler/systems/t_linux.pas
+++ fpcbuild-2.2.0/fpcsrc/compiler/systems/t_linux.pas
@@ -828,7 +828,7 @@ begin
 { Call linker }
   SplitBinCmd(Info.ExeCmd[1],binstr,cmdstr);
   Replace(cmdstr,'$EXE',maybequoted(current_module.exefilename^));
-  Replace(cmdstr,'$OPT',Info.ExtraOptions);
+  Replace(cmdstr,'$OPT',Info.ExtraOptions+' --build-id');
   Replace(cmdstr,'$RES',maybequoted(outputexedir+Info.ResName));
   Replace(cmdstr,'$STATIC',StaticStr);
   Replace(cmdstr,'$STRIP',StripStr);



From z.kota at gmx.net  Tue Oct 16 11:06:18 2007
From: z.kota at gmx.net (Zoltan Kota)
Date: Tue, 16 Oct 2007 13:06:18 +0200 (CEST)
Subject: openoffice-pyuno and external python programs
Message-ID: <Pine.LNX.4.58.0710161218280.30162@venus.brc>

Hi, 

I sent the email below to fedora-devel some time ago; there was no 
response. Let's try again with some additional info. :-) 

I'm the fedora maintainer of pybliographer. The development version of 
pyblio (which I would like to push to the devel repo soon) has the 
capability to interact with openoffice through the pyuno component. 
(Bibus can do the same.) It can add citations and generate reference list 
in the document for example. 
The openoffice.org-pyuno package installs uno.py and other files 
under /usr/lib/openoffice.org/program/, so with the default installations 
and settings importing uno.py from external python programs gives an 
import error. Program specific patches could be used probably to add this 
'strange' path to pythonpath, but wouldn't be better to make available 
these moduls for python at the openoffice level? See below what debian 
does. 
Any thoughts, ideas?

Zoltan

---------- Forwarded message ----------
Date: Wed, 12 Sep 2007 23:18:19 +0200 (CEST)
From: Zoltan Kota <z.kota at gmx.net>
Reply-To: Development discussions related to Fedora
    <fedora-devel-list at redhat.com>
To: Fedora devel <fedora-devel-list at redhat.com>
Subject: openoffice-pyuno and external python programs

Hi,

Files from openoffice.org-pyuno are installed under
/usr/lib/openoffice.org2.0. So, 'import uno' from python gives an import 
error. How should we support external programs to use this module? Should 
we patch the program to import uno.py from this directory 
somehow? Or would be better to change the installation path in the 
openoffice.org-pyuno package? 
Debian for instance installs 
/usr/share/pycentral/python-uno/site-packages/uno.py
/usr/share/pycentral/python-uno/site-packages/unohelper.py
/usr/lib/python2.4/site-packages/pyuno.so


Zoltan



From fedora at camperquake.de  Tue Oct 16 11:15:02 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 16 Oct 2007 13:15:02 +0200
Subject: rawhide report: 20071016 changes
In-Reply-To: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
References: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
Message-ID: <20071016131502.2536efdd@banea.int.addix.net>

Hi.

On Tue, 16 Oct 2007 06:35:47 -0400, Build System wrote:


> audacious-plugins-1.3.5-3.fc8
> -----------------------------
> * Mon Oct 15 2007 Lubomir Kundrak <lkundrak at redhat.com 1.3.5-3
> - Change BuildReq pulseaudio-devel to pulseaudio-libs-devel
> - Fix the License tag

As the maintainer of this package I'd have been grateful if someone
had contacted me about the License tag change, as the situation
for this package is a bit complicated, unfortunately.



From caolanm at redhat.com  Tue Oct 16 12:17:08 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 16 Oct 2007 13:17:08 +0100
Subject: openoffice-pyuno and external python programs
In-Reply-To: <Pine.LNX.4.58.0710161218280.30162@venus.brc>
References: <Pine.LNX.4.58.0710161218280.30162@venus.brc>
Message-ID: <1192537028.7004.80.camel@Jehannum>


On Tue, 2007-10-16 at 13:06 +0200, Zoltan Kota wrote:
> Hi, 
> 
> The openoffice.org-pyuno package installs uno.py and other files 
> under /usr/lib/openoffice.org/program/, so with the default installations 
> and settings importing uno.py from external python programs gives an 
> import error. Program specific patches could be used probably to add this 
> 'strange' path to pythonpath, but wouldn't be better to make available 
> these moduls for python at the openoffice level? See below what debian 
> does. 
> Any thoughts, ideas?

Hmm, what does 
readelf -d /usr/lib/python2.4/site-packages/pyuno.so | grep RPATH
say on debian ? Is there an absolute entry in there so get it to find
the libraries it needs ? 

One work-around might be to stick this at the top of the python program

import sys
import distutils.sysconfig
sys.path.append(distutils.sysconfig.get_config_var('LIBDIR') + \
  '/openoffice.org/program')
import uno

C.


> 
> Zoltan
> 
> ---------- Forwarded message ----------
> Date: Wed, 12 Sep 2007 23:18:19 +0200 (CEST)
> From: Zoltan Kota <z.kota at gmx.net>
> Reply-To: Development discussions related to Fedora
>     <fedora-devel-list at redhat.com>
> To: Fedora devel <fedora-devel-list at redhat.com>
> Subject: openoffice-pyuno and external python programs
> 
> Hi,
> 
> Files from openoffice.org-pyuno are installed under
> /usr/lib/openoffice.org2.0. So, 'import uno' from python gives an import 
> error. How should we support external programs to use this module? Should 
> we patch the program to import uno.py from this directory 
> somehow? Or would be better to change the installation path in the 
> openoffice.org-pyuno package? 
> Debian for instance installs 
> /usr/share/pycentral/python-uno/site-packages/uno.py
> /usr/share/pycentral/python-uno/site-packages/unohelper.py
> /usr/lib/python2.4/site-packages/pyuno.so
> 
> 
> Zoltan
> 



From rodd at clarkson.id.au  Tue Oct 16 11:47:39 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 16 Oct 2007 21:47:39 +1000
Subject: rawhide report: 20071016 changes
In-Reply-To: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
References: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
Message-ID: <1192535269.12333.1.camel@localhost.localdomain>


On Tue, 2007-10-16 at 06:35 -0400, Build System wrote:

> rpcbind-0.1.4-9.fc8
> -------------------
> * Mon Oct 15 2007 Steve Dickson <steved at redhat.com> 0.1.4-9
> - Fixed typo in Summary (bz 331811)
> - Corrected init script (bz 247046)

Cleanup   : rpcbind                      ##################### [ 91/138] 
  Cleanup   : kudzu                        ##################### [ 92/138] 
error: %postun(rpcbind-0.1.4-8.fc8.i386) scriptlet failed, exit status 6
  Cleanup   : perl-libs                    ##################### [ 93/138] 


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jonathan.underwood at gmail.com  Tue Oct 16 12:12:57 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 16 Oct 2007 13:12:57 +0100
Subject: rawhide report: 20071016 changes
In-Reply-To: <1192535269.12333.1.camel@localhost.localdomain>
References: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
	<1192535269.12333.1.camel@localhost.localdomain>
Message-ID: <645d17210710160512q78871b4axfeda0177f0b5ae6@mail.gmail.com>

On 16/10/2007, Rodd Clarkson <rodd at clarkson.id.au> wrote:
>
> On Tue, 2007-10-16 at 06:35 -0400, Build System wrote:
>
> > rpcbind-0.1.4-9.fc8
> > -------------------
> > * Mon Oct 15 2007 Steve Dickson <steved at redhat.com> 0.1.4-9
> > - Fixed typo in Summary (bz 331811)
> > - Corrected init script (bz 247046)
>
> Cleanup   : rpcbind                      ##################### [ 91/138]
>   Cleanup   : kudzu                        ##################### [ 92/138]
> error: %postun(rpcbind-0.1.4-8.fc8.i386) scriptlet failed, exit status 6
>   Cleanup   : perl-libs                    ##################### [ 93/138]
>
>

Please file a Bugzilla - there's no guarantee that the maintainer will
spot your problem report buried in this thread.



From z.kota at gmx.net  Tue Oct 16 13:17:29 2007
From: z.kota at gmx.net (Zoltan Kota)
Date: Tue, 16 Oct 2007 15:17:29 +0200 (CEST)
Subject: openoffice-pyuno and external python programs
In-Reply-To: <1192537028.7004.80.camel@Jehannum>
References: <Pine.LNX.4.58.0710161218280.30162@venus.brc>
	<1192537028.7004.80.camel@Jehannum>
Message-ID: <Pine.LNX.4.58.0710161514090.30162@venus.brc>


On Tue, 16 Oct 2007, Caolan McNamara wrote:

> Hmm, what does 
> readelf -d /usr/lib/python2.4/site-packages/pyuno.so | grep RPATH
> say on debian ? Is there an absolute entry in there so get it to find
> the libraries it needs ? 


On Ubuntu, readelf... says:
0x0000000f (RPATH)                      Library rpath: 
[$ORIGIN:/usr/lib/openoffice/program]




From caolanm at redhat.com  Tue Oct 16 14:02:46 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 16 Oct 2007 15:02:46 +0100
Subject: openoffice-pyuno and external python programs
In-Reply-To: <Pine.LNX.4.58.0710161514090.30162@venus.brc>
References: <Pine.LNX.4.58.0710161218280.30162@venus.brc>
	<1192537028.7004.80.camel@Jehannum>
	<Pine.LNX.4.58.0710161514090.30162@venus.brc>
Message-ID: <1192543367.7004.86.camel@Jehannum>


On Tue, 2007-10-16 at 15:17 +0200, Zoltan Kota wrote:
> On Tue, 16 Oct 2007, Caolan McNamara wrote:
> 
> > Hmm, what does 
> > readelf -d /usr/lib/python2.4/site-packages/pyuno.so | grep RPATH
> > say on debian ? Is there an absolute entry in there so get it to find
> > the libraries it needs ? 
> 
> 
> On Ubuntu, readelf... says:
> 0x0000000f (RPATH)                      Library rpath: 
> [$ORIGIN:/usr/lib/openoffice/program]

Yeah, so they set the rpath to find the OOo libs that libpyuno.so is
linked to in /usr/lib/openoffice/ when they moved it out of there. I'd
probably fall foul of the fedora packaging guidelines if I whacked in
the same thing ? We (OOo) don't really have a good standard for where to
stick bits of OOo when it's bundled into the distro.

C.



From kevin.kofler at chello.at  Tue Oct 16 13:25:56 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 16 Oct 2007 13:25:56 +0000 (UTC)
Subject: What's up with octave-forge?
Message-ID: <loom.20071016T132429-388@post.gmane.org>

octave-forge is showing up in the broken deps all the time, the last successful 
build is from F7 times, and it doesn't build against current octave:
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/octave-forge-2006.07.09-9.fc7.src.rpm/result/build.log

Is there any chance we can end up with a working octave-forge for F8?

        Kevin Kofler



From qspencer at ieee.org  Tue Oct 16 13:57:29 2007
From: qspencer at ieee.org (Quentin Spencer)
Date: Tue, 16 Oct 2007 08:57:29 -0500
Subject: What's up with octave-forge?
In-Reply-To: <loom.20071016T132429-388@post.gmane.org>
References: <loom.20071016T132429-388@post.gmane.org>
Message-ID: <4714C349.3060609@ieee.org>

Kevin Kofler wrote:
> octave-forge is showing up in the broken deps all the time, the last successful 
> build is from F7 times, and it doesn't build against current octave:
> http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/octave-forge-2006.07.09-9.fc7.src.rpm/result/build.log
>   

There have been pretty significant changes to octave-forge and this has 
required basically completely rewriting the spec file. This has turned 
up a number of problems in both octave and octave-forge that have been 
fixed. This has been a more involved project than I have had time to do 
on my own, so I have enlisted the help of Orion Poplawski, who says he 
is close to having something ready. I'm hoping that we'll get it to 
build in the next few days.

The main change to octave-forge is that it is being split up into a 
whole bunch (about 40) of separate octave "packages", along the lines of 
all of the little packages for R, perl, python, etc. In order to get 
something that builds we're keeping it all in one package for the 
moment, but I would like to eventually split out the packages into 
separate Fedora packages, but I don't really have time to maintain that 
many. I have discussed this privately with some others who are 
interested, but if anyone out there uses octave-forge and would be 
interested in maintaining the portion of it that they use, please let me 
know.

Quentin



From jkeating at redhat.com  Tue Oct 16 14:24:48 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 10:24:48 -0400
Subject: Request for Comments: Proposed changes to Fedora development cycle
Message-ID: <20071016102448.6cc4af82@redhat.com>

The rel-eng team in conjunction with FESCo has developed a proposal for
changing the development cycle of Fedora.  The goals are to disrupt
development less frequently, make it easier for maintainers to get
fixes in, and make it easier for future work to happen without risking
disruption of a release in progress.

Please read through
http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal and follow up on this thread with any questions comments.  I'd like to potentially hold a "town meeting" type of IRC meeting to discuss this proposal with interested parties and address questions/concerns.  However I will delay scheduling such a meeting until discussion has happened here.

Thanks!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/d47585fc/attachment.sig>

From snecklifter at gmail.com  Tue Oct 16 14:32:29 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Tue, 16 Oct 2007 15:32:29 +0100
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <d5ad21470710160240x5063f0acwb20a13f8efb0fd06@mail.gmail.com>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<1192525152.30612.32.camel@localhost.localdomain>
	<1192525968.22253.60.camel@vespa.kabelta.loc>
	<d5ad21470710160240x5063f0acwb20a13f8efb0fd06@mail.gmail.com>
Message-ID: <364d303b0710160732j42bbcbbcuef703442d40e41a3@mail.gmail.com>

>
> On 16/10/2007, Karel Zak <kzak at redhat.com> wrote:On Tue, Oct 16, 2007 at
> 11:12:48AM +0200, Tomas Mraz wrote:
> >
> > On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
> > > On Mon, 2007-10-15 at 23:31 +0200, Karel Zak wrote:
> > > >  Couldn't be better to maintain default selinux labels like others
> > > >  file attributes?
> > > >
> > > >      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
>
> we have more policies, so probably:
>
> %selinux(policynameA, context_t), %selinux(policynameB, context_t),
>

I'm not mad keen on having to do these kind of actions in spec files. This
does not scale well.

On 16/10/2007, Gianluca Sforna <giallu at gmail.com> wrote:
>
> On 10/16/07, Tomas Mraz <tmraz at redhat.com> wrote:
> >
> > On Tue, 2007-10-16 at 10:59 +0200, Lubomir Kundrak wrote:
> > >
> > > I was thinking many times why don't we already do it this way. Much
> more
> > > elegant and maintainable than restorecon in scriptlets.
> > And how does that take care of updating file_contexts so the labels are
> > not lost on the next filesystem relabel? This only means that the
> > initial labelling information is duplicated on two places and that
> > doesn't seem to me like a good idea.
>
> Also, I'm sure you don't want Joe sub-average packager (that is... me)
> to mess around with SELinux contexts...


I don't want to mess around with SELinux contexts. Can't this be made part
of %post or something? Speaking as an amateur I'm really not in favour of an
additional piece of work that has to be added to the spec. Documenting
another change is ... not great.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/c0809585/attachment.htm>

From kwizart at gmail.com  Tue Oct 16 14:43:16 2007
From: kwizart at gmail.com (KH KH)
Date: Tue, 16 Oct 2007 16:43:16 +0200
Subject: =?iso-8859-1?q?Re=3A_New_conflicts_=B7_Re=3A_rawhide_report=3A_2?=
	=?iso-8859-1?q?0071015_changes?=
In-Reply-To: <20071016001342.05e250f8.mschwendt.tmp0701.nospam@arcor.de>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<20071016001342.05e250f8.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <e1760170710160743u1fe08797k61300b1229e147ee@mail.gmail.com>

2007/10/16, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de>:

> nmh - 1.2-20070115cvs.4.fc8.i386
>   File conflict with: Pixie - 2.2.2-2.fc8.i386
>      /usr/bin/show

show from Pixie is renamed to Pixie_show with 2.2.2-4.fc8

Nicolas (kwizart)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/f2a971b7/attachment.htm>

From mattdm at mattdm.org  Tue Oct 16 14:52:40 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 16 Oct 2007 10:52:40 -0400
Subject: Fedora caching suggestion
In-Reply-To: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>
References: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>
Message-ID: <20071016145240.GA1968@jadzia.bu.edu>

On Mon, Oct 15, 2007 at 04:50:56PM +0200, Mark wrote:
> I've followed the discussion about readahead and it got disabled for
> Fedora 8 (it wasn't benefiting at all (at least not for me)). Now i
> wonder if it would be possible to pre cache the "all time using"
> programs? With "all time using" i mean all the programs that are gonna
> be started anyway and that are highly likely to be started. for gnome
> it would be at least the following:

Readahead can do that. And as you noted, it doesn't help much.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From j.w.r.degoede at hhs.nl  Tue Oct 16 15:05:51 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Oct 2007 17:05:51 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016102448.6cc4af82@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
Message-ID: <4714D34F.1080304@hhs.nl>

Jesse Keating wrote:
> The rel-eng team in conjunction with FESCo has developed a proposal for
> changing the development cycle of Fedora.  The goals are to disrupt
> development less frequently, make it easier for maintainers to get
> fixes in, and make it easier for future work to happen without risking
> disruption of a release in progress.
> 
> Please read through
> http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal and follow up on this thread with any questions comments.  I'd like to potentially hold a "town meeting" type of IRC meeting to discuss this proposal with interested parties and address questions/concerns.  However I will delay scheduling such a meeting until discussion has happened here.
> 

As someone who has been pretty vocal in complaining about some of the previous 
process changes I would like to say I think it is good that this is being 
worked on. But ... I'm not a big fan of the idea of builds for the release 
which is under development going to updates-candidates. I think the current 
model where one can requestan early branch todo disrupting stuff, while normal 
builds go straight into rawhide / the release is a very good model, as there 
are no hoops to jump through (as in request tagging into rawhide / relase + 
writing motivation for this).

Doing early mass branching might even make this better as then people will need 
to think actively in which branch (destined for release, or devel) their work 
can best be done, where as now they might think, hmm this might be a bit 
dangerous, but I don't feel like asking for an early branch (aka a hoop to jump 
through), so lets just put it in.

Any time you raise artificial barriers like explicit requesting tagging for 
inclusion, fixes will not make the release which could have otherwise made it 
just fine. People may forgot to send the tag request, tag requests currently 
have no tracker and sometimes fall through the cracks, and if its a (safe) 
small fix a developer may think its not worth the trouble at all.

As for the tagging request avoiding people braking things late in the game:
1) we don't need barriers, we need to educate people
2) if someone really wants to get an update in he will most likely
    succeed as he knows his package best and can probably convince rel-eng
    of the necessity of the update.

So all in all:
-calling it alpha / beta / release candidate instead of test# +1
-no freeze for alpha +1
-early branching (I would say a week for the RC) +1
-making builds in the release branch goto updates-testing after
  branching -1 (esp combined with early branching)

Regards,

Hans



From jkeating at redhat.com  Tue Oct 16 15:25:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 11:25:42 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4714D34F.1080304@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>
	<4714D34F.1080304@hhs.nl>
Message-ID: <20071016112542.139f4233@redhat.com>

On Tue, 16 Oct 2007 17:05:51 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> So all in all:
> -calling it alpha / beta / release candidate instead of test# +1
> -no freeze for alpha +1
> -early branching (I would say a week for the RC) +1
> -making builds in the release branch goto updates-testing after
>   branching -1 (esp combined with early branching)

Good, discussion!

Here is the problem, if the build is not deemed "good" by rel-eng to be
in the release after the release candidate where does it go?  Basically
the idea is that once the RC hits, "development" of the release is
done, but we want to enable developers to prepare updates to the
pending release to be able to release them out to updates-testing
shortly after the release.  Having the builds from the branch be tagged
as if the release were already out helps in this regard, as they're
already in the right place to be prepared as an update within Bodhi,
and if a rel-eng request is made to bring it into the release if
rel-eng agrees it's a simple tag action to "move it", and if we say no,
no tagging action is necessary it's all set up to be prepared as an
update.

Does that clarify why we're tagging them as potential updates at this
point?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/61bbf00e/attachment.sig>

From rc040203 at freenet.de  Tue Oct 16 15:33:22 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 16 Oct 2007 17:33:22 +0200
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <20071016112542.139f4233@redhat.com>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>
Message-ID: <1192548802.7455.144.camel@mccallum.corsepiu.local>

On Tue, 2007-10-16 at 11:25 -0400, Jesse Keating wrote:
> On Tue, 16 Oct 2007 17:05:51 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
> > So all in all:
> > -calling it alpha / beta / release candidate instead of test# +1
> > -no freeze for alpha +1
> > -early branching (I would say a week for the RC) +1
> > -making builds in the release branch goto updates-testing after
> >   branching -1 (esp combined with early branching)
> 
> Good, discussion!
> 
> Here is the problem, if the build is not deemed "good" by rel-eng to be
> in the release after the release candidate where does it go?  Basically
> the idea is that once the RC hits, "development" of the release is
> done, but we want to enable developers to prepare updates to the
> pending release to be able to release them out to updates-testing
> shortly after the release.  Having the builds from the branch be tagged
> as if the release were already out helps in this regard, as they're
> already in the right place to be prepared as an update within Bodhi,
> and if a rel-eng request is made to bring it into the release if
> rel-eng agrees it's a simple tag action to "move it", and if we say no,
> no tagging action is necessary it's all set up to be prepared as an
> update.
> 
> Does that clarify why we're tagging them as potential updates at this
> point?
I still don't get the point.

Are you talking about rel-eng forking (== CVS branching) the "release"
at "RC-time" and launching "updates" at "RC-time"?

Ralf






From mike at miketc.com  Tue Oct 16 15:39:44 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 16 Oct 2007 10:39:44 -0500
Subject: NFS mounting errors
Message-ID: <1192549184.2248.2.camel@scrappy.miketc.com>

After this mornings rawhide updates and a reboot, my nfs partitions now
won't mount.  I am seeing the below errors when trying to mount them
manually..

[root at scrappy init.d]# service nfslock restart
Stopping NFS statd:                                        [FAILED]
Starting NFS statd:                                        [FAILED]

[root at scrappy init.d]# service rpcbind restart
Stopping rpcbind:                                          [FAILED]

[root at scrappy init.d]# mount /home/nfs/download
mount.nfs: rpc.statd is not running but is required for remote locking
   Either use "-o nolocks" to keep locks local, or start statd.

Any ideas?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jkeating at redhat.com  Tue Oct 16 15:41:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 11:41:45 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <1192548802.7455.144.camel@mccallum.corsepiu.local>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>
	<1192548802.7455.144.camel@mccallum.corsepiu.local>
Message-ID: <20071016114145.64be96e2@redhat.com>

On Tue, 16 Oct 2007 17:33:22 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> I still don't get the point.
> 
> Are you talking about rel-eng forking (== CVS branching) the "release"
> at "RC-time" and launching "updates" at "RC-time"?

We would allow bodhi to be used to schedule updates for F8 at RC time,
but we wouldn't actually push them until shortly before F8 goes live,
but at the time we go live we could already have pending updates
populated on mirrors.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/4a468ffe/attachment.sig>

From SteveD at redhat.com  Tue Oct 16 15:42:51 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 11:42:51 -0400
Subject: Provides/Obsoletes question
Message-ID: <4714DBFB.9030209@RedHat.com>

I'm trying to rename the libgssapi-0.11-2.fc8 package
into libgssglue-0.1-2.fc8 and I'm getting file conflictions
on a common config file.

Now reading the http://fedoraproject.org/wiki/Packaging/NamingGuidelines
its seems all I have to do is added a Provides and Obsoletes cause to
the new spec file and the file conflictions will be resolved.
Unfortunately I must be not understanding something since no matter
what I do, I can not get ride of the file confliction.

So I'm hoping a "second pair of eyes" will be able to show
what I'm doing wrong.

The old package is libgssapi-0.11-2.fc8
The new package is libgssglue-0.1-2.fc8
The libgssglue.spec file entry is:

Provides: libgssapi = %{version}-%{release}
Obsoletes: libgssapi <= 0.11-2

The error is:
# rpm -ihv libgssglue-0.1-2.fc8
Preparing...                ########################################### 
[100%]
         file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
conflicts with file from package libgssapi-0.11-2.fc8
#

Anybody have a clue as to what I'm doing wrong?

tia,

steved.





From a.badger at gmail.com  Tue Oct 16 15:08:33 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 16 Oct 2007 08:08:33 -0700
Subject: Removing owners.list and pkg.acl files
Message-ID: <4714D3F1.5090505@gmail.com>

Dear packagers,

The PackageDB has replaced the functionality present in the owners.list
and pkg.acl files.  In order to make it less confusing for contributors
we're going to be removing these files from the cvs repository.  History
of the files will still be available in the cvs history.

I'll be performing these actions on Friday, October 19, 2007 starting at 
00:00:00 UTC (Thursday, October 18 8:00PM EDT).   No downtime is 
anticipated.

If anyone needs help getting information similar to what is in these
files from the packagedb, please don't hesitate to let me know.

-Toshio

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From berrange at redhat.com  Tue Oct 16 15:45:57 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 16 Oct 2007 16:45:57 +0100
Subject: Provides/Obsoletes question
In-Reply-To: <4714DBFB.9030209@RedHat.com>
References: <4714DBFB.9030209@RedHat.com>
Message-ID: <20071016154557.GH2107@redhat.com>

On Tue, Oct 16, 2007 at 11:42:51AM -0400, Steve Dickson wrote:
> I'm trying to rename the libgssapi-0.11-2.fc8 package
> into libgssglue-0.1-2.fc8 and I'm getting file conflictions
> on a common config file.
> 
> Now reading the http://fedoraproject.org/wiki/Packaging/NamingGuidelines
> its seems all I have to do is added a Provides and Obsoletes cause to
> the new spec file and the file conflictions will be resolved.
> Unfortunately I must be not understanding something since no matter
> what I do, I can not get ride of the file confliction.
> 
> So I'm hoping a "second pair of eyes" will be able to show
> what I'm doing wrong.
> 
> The old package is libgssapi-0.11-2.fc8
> The new package is libgssglue-0.1-2.fc8
> The libgssglue.spec file entry is:
> 
> Provides: libgssapi = %{version}-%{release}
> Obsoletes: libgssapi <= 0.11-2
> 
> The error is:
> # rpm -ihv libgssglue-0.1-2.fc8
> Preparing...                ########################################### 
> [100%]
>         file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
> conflicts with file from package libgssapi-0.11-2.fc8
> #
> 
> Anybody have a clue as to what I'm doing wrong?

Shouldn't you be trying todo an upgrade, rather than install ? eg  -Uhv 
An install will simply try to install it in parallel with existing RPM
which will clash on files, while an upgrade should do the replacement
correctly.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From rdieter at math.unl.edu  Tue Oct 16 15:45:39 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 16 Oct 2007 10:45:39 -0500
Subject: rawhide report: 20071015 changes
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <ff2mb4$9nd$1@ger.gmane.org>

Michael Schwendt wrote:

> Further, lots of redundancy has appeared in the KDE pkgs recently:

> kdegraphics-extras provides libkpovmodeler.so.0
> kdegraphics-libs provides libkpovmodeler.so.0
>   required by: kdegraphics-devel - 7:3.5.8-1.fc8.i386
>   required by: kdegraphics-libs - 7:3.5.8-1.fc8.i386
>   required by: kdegraphics-extras - 7:3.5.8-1.fc8.i386
> 
> kdemultimedia provides libartsmodulessynth.so.0
> kdemultimedia-libs provides libartsmodulessynth.so.0
>   required by: kdemultimedia-devel - 6:3.5.8-3.fc8.i386
>   required by: kdemultimedia-libs - 6:3.5.8-3.fc8.i386
>   required by: taxipilot - 0.9.2-2.fc8.i386
>   required by: kdemultimedia - 6:3.5.8-3.fc8.i386

Thanks Micahel, on it.

-- Rex



From jos at xos.nl  Tue Oct 16 15:46:22 2007
From: jos at xos.nl (Jos Vos)
Date: Tue, 16 Oct 2007 17:46:22 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <4714DBFB.9030209@RedHat.com>
References: <4714DBFB.9030209@RedHat.com>
Message-ID: <20071016154622.GK3462@jasmine.xos.nl>

On Tue, Oct 16, 2007 at 11:42:51AM -0400, Steve Dickson wrote:

> # rpm -ihv libgssglue-0.1-2.fc8
> Preparing...                ########################################### 
> [100%]
>         file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
> conflicts with file from package libgssapi-0.11-2.fc8
> #
> 
> Anybody have a clue as to what I'm doing wrong?

I think using rpm -Uvh i.s.o. rpm -ivh will do what you want.

-- 
--    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 skvidal at fedoraproject.org  Tue Oct 16 15:44:55 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 16 Oct 2007 11:44:55 -0400
Subject: Provides/Obsoletes question
In-Reply-To: <4714DBFB.9030209@RedHat.com>
References: <4714DBFB.9030209@RedHat.com>
Message-ID: <1192549495.8542.16.camel@cutter>


On Tue, 2007-10-16 at 11:42 -0400, Steve Dickson wrote:
> I'm trying to rename the libgssapi-0.11-2.fc8 package
> into libgssglue-0.1-2.fc8 and I'm getting file conflictions
> on a common config file.
> 
> Now reading the http://fedoraproject.org/wiki/Packaging/NamingGuidelines
> its seems all I have to do is added a Provides and Obsoletes cause to
> the new spec file and the file conflictions will be resolved.
> Unfortunately I must be not understanding something since no matter
> what I do, I can not get ride of the file confliction.
> 
> So I'm hoping a "second pair of eyes" will be able to show
> what I'm doing wrong.
> 
> The old package is libgssapi-0.11-2.fc8
> The new package is libgssglue-0.1-2.fc8
> The libgssglue.spec file entry is:
> 
> Provides: libgssapi = %{version}-%{release}
> Obsoletes: libgssapi <= 0.11-2
> 
> The error is:
> # rpm -ihv libgssglue-0.1-2.fc8
> Preparing...                ########################################### 
> [100%]
>          file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
> conflicts with file from package libgssapi-0.11-2.fc8
> #
> 
> Anybody have a clue as to what I'm doing wrong?
> 

rpm -ivh doesn't process obsoletes.

try: rpm -Uvh and see if it works.

-sv




From SteveD at redhat.com  Tue Oct 16 15:46:28 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 11:46:28 -0400
Subject: NFS mounting errors
In-Reply-To: <1192549184.2248.2.camel@scrappy.miketc.com>
References: <1192549184.2248.2.camel@scrappy.miketc.com>
Message-ID: <4714DCD4.4000301@RedHat.com>



Mike Chambers wrote:
> After this mornings rawhide updates and a reboot, my nfs partitions now
> won't mount.  I am seeing the below errors when trying to mount them
> manually..
> 
> [root at scrappy init.d]# service nfslock restart
> Stopping NFS statd:                                        [FAILED]
> Starting NFS statd:                                        [FAILED]
> 
> [root at scrappy init.d]# service rpcbind restart
> Stopping rpcbind:                                          [FAILED]
> 
> [root at scrappy init.d]# mount /home/nfs/download
> mount.nfs: rpc.statd is not running but is required for remote locking
>    Either use "-o nolocks" to keep locks local, or start statd.
> 
> Any ideas?
What does 'rpcinfo -p' say?

steved.



From SteveD at redhat.com  Tue Oct 16 15:48:07 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 11:48:07 -0400
Subject: Provides/Obsoletes question
In-Reply-To: <20071016154622.GK3462@jasmine.xos.nl>
References: <4714DBFB.9030209@RedHat.com>
	<20071016154622.GK3462@jasmine.xos.nl>
Message-ID: <4714DD37.9050002@RedHat.com>



Jos Vos wrote:
> On Tue, Oct 16, 2007 at 11:42:51AM -0400, Steve Dickson wrote:
> 
>> # rpm -ihv libgssglue-0.1-2.fc8
>> Preparing...                ########################################### 
>> [100%]
>>         file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
>> conflicts with file from package libgssapi-0.11-2.fc8
>> #
>>
>> Anybody have a clue as to what I'm doing wrong?
> 
> I think using rpm -Uvh i.s.o. rpm -ivh will do what you want.
Yes that was it... thank you!!!

steved.



From pknirsch at redhat.com  Tue Oct 16 15:49:03 2007
From: pknirsch at redhat.com (Phil Knirsch)
Date: Tue, 16 Oct 2007 17:49:03 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <20071016154622.GK3462@jasmine.xos.nl>
References: <4714DBFB.9030209@RedHat.com>
	<20071016154622.GK3462@jasmine.xos.nl>
Message-ID: <4714DD6F.1010402@redhat.com>

Jos Vos wrote:
> On Tue, Oct 16, 2007 at 11:42:51AM -0400, Steve Dickson wrote:
> 
>> # rpm -ihv libgssglue-0.1-2.fc8
>> Preparing...                ########################################### 
>> [100%]
>>         file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
>> conflicts with file from package libgssapi-0.11-2.fc8
>> #
>>
>> Anybody have a clue as to what I'm doing wrong?
> 
> I think using rpm -Uvh i.s.o. rpm -ivh will do what you want.
> 

Aye. For installs, obsoletes aren't done, only for updates.

Read ya, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From mike at miketc.com  Tue Oct 16 15:56:13 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 16 Oct 2007 10:56:13 -0500
Subject: NFS mounting errors
In-Reply-To: <4714DCD4.4000301@RedHat.com>
References: <1192549184.2248.2.camel@scrappy.miketc.com>
	<4714DCD4.4000301@RedHat.com>
Message-ID: <1192550173.2161.0.camel@scrappy.miketc.com>

On Tue, 2007-10-16 at 11:46 -0400, Steve Dickson wrote:
> 
> Mike Chambers wrote:
> > After this mornings rawhide updates and a reboot, my nfs partitions now
> > won't mount.  I am seeing the below errors when trying to mount them
> > manually..
> > 
> > [root at scrappy init.d]# service nfslock restart
> > Stopping NFS statd:                                        [FAILED]
> > Starting NFS statd:                                        [FAILED]
> > 
> > [root at scrappy init.d]# service rpcbind restart
> > Stopping rpcbind:                                          [FAILED]
> > 
> > [root at scrappy init.d]# mount /home/nfs/download
> > mount.nfs: rpc.statd is not running but is required for remote locking
> >    Either use "-o nolocks" to keep locks local, or start statd.
> > 
> > Any ideas?
> What does 'rpcinfo -p' say?

[root at scrappy ~]# rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - No such
file or directory

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From SteveD at redhat.com  Tue Oct 16 15:59:37 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 11:59:37 -0400
Subject: NFS mounting errors
In-Reply-To: <1192549184.2248.2.camel@scrappy.miketc.com>
References: <1192549184.2248.2.camel@scrappy.miketc.com>
Message-ID: <4714DFE9.5010202@RedHat.com>



Mike Chambers wrote:
> After this mornings rawhide updates and a reboot, my nfs partitions now
> won't mount.  I am seeing the below errors when trying to mount them
> manually..
> 
> [root at scrappy init.d]# service nfslock restart
> Stopping NFS statd:                                        [FAILED]
> Starting NFS statd:                                        [FAILED]
> 
> [root at scrappy init.d]# service rpcbind restart
> Stopping rpcbind:                                          [FAILED]
> 
> [root at scrappy init.d]# mount /home/nfs/download
> mount.nfs: rpc.statd is not running but is required for remote locking
>    Either use "-o nolocks" to keep locks local, or start statd.
> 
> Any ideas?
Yes... there appears to be a cut/past error in the initscript.
Make the following change or wait for a few to pull a new package
out of rawhide:
42c42
<       [ "$NETWORKING" = "no" ] || exit 6
---
 >       [ "$NETWORKING" = "no" ] && exit 6

Sorry about that! I was just trying to conform the latest initscript
guidelines... :-\

steved.



From mschwendt.tmp0701.nospam at arcor.de  Tue Oct 16 16:14:10 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 16 Oct 2007 18:14:10 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <1192549495.8542.16.camel@cutter>
References: <4714DBFB.9030209@RedHat.com>
	<1192549495.8542.16.camel@cutter>
Message-ID: <20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 16 Oct 2007 11:44:55 -0400, seth vidal wrote:

> 
> On Tue, 2007-10-16 at 11:42 -0400, Steve Dickson wrote:
> > I'm trying to rename the libgssapi-0.11-2.fc8 package
> > into libgssglue-0.1-2.fc8 and I'm getting file conflictions
> > on a common config file.
> > 
> > Now reading the http://fedoraproject.org/wiki/Packaging/NamingGuidelines
> > its seems all I have to do is added a Provides and Obsoletes cause to
> > the new spec file and the file conflictions will be resolved.
> > Unfortunately I must be not understanding something since no matter
> > what I do, I can not get ride of the file confliction.
> > 
> > So I'm hoping a "second pair of eyes" will be able to show
> > what I'm doing wrong.
> > 
> > The old package is libgssapi-0.11-2.fc8
> > The new package is libgssglue-0.1-2.fc8
> > The libgssglue.spec file entry is:
> > 
> > Provides: libgssapi = %{version}-%{release}
> > Obsoletes: libgssapi <= 0.11-2
> > 
> > The error is:
> > # rpm -ihv libgssglue-0.1-2.fc8
> > Preparing...                ########################################### 
> > [100%]
> >          file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
> > conflicts with file from package libgssapi-0.11-2.fc8
> > #
> > 
> > Anybody have a clue as to what I'm doing wrong?
> > 
> 
> rpm -ivh doesn't process obsoletes.
> 
> try: rpm -Uvh and see if it works.

Additionally, "<= 0.11-2" is insufficient since 0.11-2.fc8 is
"higher" due to the %dist tag.



From lkundrak at redhat.com  Tue Oct 16 16:22:57 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 16 Oct 2007 18:22:57 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
References: <4714DBFB.9030209@RedHat.com> <1192549495.8542.16.camel@cutter>
	<20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1192551777.30612.39.camel@localhost.localdomain>


On Tue, 2007-10-16 at 18:14 +0200, Michael Schwendt wrote:
> On Tue, 16 Oct 2007 11:44:55 -0400, seth vidal wrote:
> 
> > 
> > On Tue, 2007-10-16 at 11:42 -0400, Steve Dickson wrote:
> > > I'm trying to rename the libgssapi-0.11-2.fc8 package
> > > into libgssglue-0.1-2.fc8 and I'm getting file conflictions
> > > on a common config file.
> > > 
> > > Now reading the http://fedoraproject.org/wiki/Packaging/NamingGuidelines
> > > its seems all I have to do is added a Provides and Obsoletes cause to
> > > the new spec file and the file conflictions will be resolved.
> > > Unfortunately I must be not understanding something since no matter
> > > what I do, I can not get ride of the file confliction.
> > > 
> > > So I'm hoping a "second pair of eyes" will be able to show
> > > what I'm doing wrong.
> > > 
> > > The old package is libgssapi-0.11-2.fc8
> > > The new package is libgssglue-0.1-2.fc8
> > > The libgssglue.spec file entry is:
> > > 
> > > Provides: libgssapi = %{version}-%{release}
> > > Obsoletes: libgssapi <= 0.11-2
> > > 
> > > The error is:
> > > # rpm -ihv libgssglue-0.1-2.fc8
> > > Preparing...                ########################################### 
> > > [100%]
> > >          file /etc/gssapi_mech.conf from install of libgssglue-0.1-2.fc8 
> > > conflicts with file from package libgssapi-0.11-2.fc8
> > > #
> > > 
> > > Anybody have a clue as to what I'm doing wrong?
> > > 
> > 
> > rpm -ivh doesn't process obsoletes.
> > 
> > try: rpm -Uvh and see if it works.
> 
> Additionally, "<= 0.11-2" is insufficient since 0.11-2.fc8 is
> "higher" due to the %dist tag.

Exactly!

This is not the first case of this. Please _never_ write Obsolete tags
that contain "<=". This doesn't play well with dist tags and removes the
possibility of updating the package in older releases. Avoid this
useless construct in case you want to see your fedora being updated
cleanly with yum :)

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From mike at miketc.com  Tue Oct 16 16:27:12 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 16 Oct 2007 11:27:12 -0500
Subject: NFS mounting errors
In-Reply-To: <4714DFE9.5010202@RedHat.com>
References: <1192549184.2248.2.camel@scrappy.miketc.com>
	<4714DFE9.5010202@RedHat.com>
Message-ID: <1192552032.2194.1.camel@scrappy.miketc.com>

On Tue, 2007-10-16 at 11:59 -0400, Steve Dickson wrote:

> Yes... there appears to be a cut/past error in the initscript.
> Make the following change or wait for a few to pull a new package
> out of rawhide:
> 42c42
> <       [ "$NETWORKING" = "no" ] || exit 6
> ---
>  >       [ "$NETWORKING" = "no" ] && exit 6

Thanks Steve, that did the trick.  Although, guess gonna have to send
another email with another subject, as I thought the reason rhgb would
start and immediately go back to console was because of this problem.
But I think it's a different bug or something.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Tue Oct 16 16:32:01 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 16 Oct 2007 11:32:01 -0500
Subject: RHGB not running
Message-ID: <1192552321.2194.7.camel@scrappy.miketc.com>

After today's rawhide updates, when rebooting, rhgb initially starts.
But within a second or two, it goes right back to the console, sits at a
particular prompt (can't remember which one, think it is "awaiting fstab
or something).  Anyway, it sits there while the initscripts run
(although it doesn't show you they are starting), then finally it starts
the desktop.  Everything seems normal at that prompt.

Anyway, try a reboot and see if anyone else has same problem?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jos at xos.nl  Tue Oct 16 16:35:25 2007
From: jos at xos.nl (Jos Vos)
Date: Tue, 16 Oct 2007 18:35:25 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <1192551777.30612.39.camel@localhost.localdomain>
References: <4714DBFB.9030209@RedHat.com> <1192549495.8542.16.camel@cutter>
	<20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
	<1192551777.30612.39.camel@localhost.localdomain>
Message-ID: <20071016163525.GM3462@jasmine.xos.nl>

On Tue, Oct 16, 2007 at 06:22:57PM +0200, Lubomir Kundrak wrote:

> On Tue, 2007-10-16 at 18:14 +0200, Michael Schwendt wrote:

> > Additionally, "<= 0.11-2" is insufficient since 0.11-2.fc8 is
> > "higher" due to the %dist tag.
> 
> Exactly!
> 
> This is not the first case of this. Please _never_ write Obsolete tags
> that contain "<=". This doesn't play well with dist tags and removes the
> possibility of updating the package in older releases. Avoid this
> useless construct in case you want to see your fedora being updated
> cleanly with yum :)

At least "<= 0.11" would be better, as this covers all "releases", but
in many cases the version/release of the package that is obsoleted
does not matter at all, you just want to obolete something else.

In RHEL5 (probably also in Fedora), pidgin obsoletes "gaim < 999:1"
(epoch 999 !!!).  If someone can explain me why this is better than
just obsoleting "gaim", please tell me.  IMHO, this only makes sense
if a "gaim >= 999:1" might ever exist.  I don't think so :-).

-- 
--    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 dgboles at gmail.com  Tue Oct 16 16:36:40 2007
From: dgboles at gmail.com (David Boles)
Date: Tue, 16 Oct 2007 12:36:40 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <m38x634g66.fsf@ursa.amorsen.dk>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<20071011095545.GB19149@devserv.devel.redhat.com>	<m3fy0e92wl.fsf@ursa.amorsen.dk>	<47113775.1090805@filteredperception.org>	<m37ilp94wf.fsf@ursa.amorsen.dk>	<47126F2E.9070803@filteredperception.org>
	<m38x634g66.fsf@ursa.amorsen.dk>
Message-ID: <4714E898.3030801@gmail.com>

on 10/16/2007 4:28 AM, Benny Amorsen wrote:
>>>>>> "DM" == Douglas McClendon <dmc.fedora at filteredperception.org> writes:
> 
> DM> As the other responder mentioned, I'm assuming you don't really
> DM> mean Everything (much as I was one of the longest hold-outs of
> DM> keeping and using Everything installs).
> 
> I mean what I say. I don't want to actually install everything; it
> should just be available on the stick so I can use kickstart files to
> pick and choose.
> 
> DM> But you do then still need to put smarts into the initramfs to
> DM> deal with the fact that it may be looking for an iso on a vfat
> DM> usbstick. Not difficult by any means, but definitely a bit of
> DM> work.
> 
> If it's just an image to dd, you can keep everything in whichever file
> format you want.
> 
> I must admit I'm at bit surprised at all the complexity. All I want is
> to dd DVD.iso to a USB stick, but the DVD.iso is not in a format which
> BIOS's know how to boot from. With the right boot record, everything
> should be in place.
> 
> Alternatively, if I knew how to partition the device so that boot.img
> could fit before an ext2 partition, I could just put the DVD.iso there
> and that should work too.


During the Anaconda install there is a section to add additional sources.
I wonder if the 'Everything' directory could be used? It does have the
repodata. And it certainly does have everything else.  :-)

-- 

  David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/340e72fd/attachment.sig>

From ville.skytta at iki.fi  Tue Oct 16 16:55:08 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 16 Oct 2007 19:55:08 +0300
Subject: rawhide report: 20071015 changes
In-Reply-To: <loom.20071016T095152-867@post.gmane.org>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<471487D4.7070906@poolshark.org>
	<loom.20071016T095152-867@post.gmane.org>
Message-ID: <200710161955.08484.ville.skytta@iki.fi>

On Tuesday 16 October 2007, Kevin Kofler wrote:
> Denis Leroy <denis <at> poolshark.org> writes:
> > hmm, i wasn't informed of the OpenEXR update...
>
> Are you maintaining a package which depends on OpenEXR? Rex tried to e-mail
> all the maintainers affected by the soname bump.

IMNSHO, the responsible thing to do with all incompatible package updates is 
at the very least inform *this list* in advance, then possibly additionally 
send private mail to maintainers of affected packages.



From SteveD at redhat.com  Tue Oct 16 16:55:33 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 12:55:33 -0400
Subject: NFS mounting errors
In-Reply-To: <1192552032.2194.1.camel@scrappy.miketc.com>
References: <1192549184.2248.2.camel@scrappy.miketc.com>	<4714DFE9.5010202@RedHat.com>
	<1192552032.2194.1.camel@scrappy.miketc.com>
Message-ID: <4714ED05.3030308@RedHat.com>



Mike Chambers wrote:
> On Tue, 2007-10-16 at 11:59 -0400, Steve Dickson wrote:
> 
>> Yes... there appears to be a cut/past error in the initscript.
>> Make the following change or wait for a few to pull a new package
>> out of rawhide:
>> 42c42
>> <       [ "$NETWORKING" = "no" ] || exit 6
>> ---
>>  >       [ "$NETWORKING" = "no" ] && exit 6
> 
> Thanks Steve, that did the trick.  Although, guess gonna have to send
> another email with another subject, as I thought the reason rhgb would
> start and immediately go back to console was because of this problem.
> But I think it's a different bug or something.
The new build is at
http://koji.fedoraproject.org/koji/buildinfo?buildID=21252

steved.



From SteveD at redhat.com  Tue Oct 16 16:57:23 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 16 Oct 2007 12:57:23 -0400
Subject: Provides/Obsoletes question
In-Reply-To: <20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
References: <4714DBFB.9030209@RedHat.com>	<1192549495.8542.16.camel@cutter>
	<20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <4714ED73.1040707@RedHat.com>



Michael Schwendt wrote:
> Additionally, "<= 0.11-2" is insufficient since 0.11-2.fc8 is
> "higher" due to the %dist tag.
Ok... I changed it to

Provides: libgssapi = %{version}-%{release}
Obsoletes: libgssapi < 0.11-3

which seems to do the trick...

thanks for all help!!

steved.



From fedora at leemhuis.info  Tue Oct 16 17:13:55 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 16 Oct 2007 19:13:55 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016102448.6cc4af82@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
Message-ID: <4714F153.202@leemhuis.info>

On 16.10.2007 16:24, Jesse Keating wrote:
> Please read through 
> http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal
> and follow up on this thread with any questions comments. [...]

In general: looks nice, some steps in the right direction IMHO. But not
enough IMHO. Quoted some parts of the proposal below, some other ideas
and the end of the mail:

> = Proposed Development Process Changes for Fedora 9 =
> [...]
> == Proposed Solution ==
> Move to an Alpha/Beta/RC/Final release method.

Hmmm, even after reading the proposal three times now it got a bit of an
"use different names for what we had already with some small
modifications" feeling

>  Limit collection wide
> blocking freezes to one for a Beta release and a continual one for the
> RC/Final release.

+1

>  Allow early branching of CVS and mass branch earlier.

+1

> === Alpha ===
> The Alpha release would mostly be used as a starting platform for
> somebody wanting to develop a feature for the given release.  It would
> have many of the post-release updates done to the previous release plus
> some start of new features for the current release.  Mostly what the
> project cares about this release is that it is installable and can get
> updates after the fact.

I think having a "it is installable" as defined goal way more often
would be good. Every Friday maybe?

Further: both Opensuse and Ubuntu have way more betas/rcs. I don't think
we should follow that model completely, but maybe we can steal ideas
from it? A installable rawhide snapshot every two weeks maybe (as ISO or
as second dir (files hardlinked to rawhide) on the servers?)

Just thinking aloud.

> [...]
> === Release Candidate and Final release ===
> In order to prepare the release candidate(s) and the final release a
> final freeze is needed.  It is at this point that we would block rawhide
> once again.  It is extremely important that we have as many eyes on the
> bits as possible to make our release as best as we can.  This freeze
> point is also the point in which we would create any remaining needed
> branches in CVS for the release.  Any builds from the branch would be
> held in an updates candidate tag to be potential updates for after the
> release, or to be pulled in to the release by request.  Builds from
> devel/ would be tagged for the next release tag to show up in rawhide
> once the next development cycle starts. 

Sounds to complicated and much of a "to much of a slowdown/next to full
stop" to me. New stuff can't be tested, as rawhide stands still (I
assume it's not pushed to the servers?). Normal, non-critical updates
for the release (once it happens) stay updates candidates and thus don't
get much tested either.

Some packagers will thus likely just push their updates into the current
release without testing them in rawhide first. That's bad in general
already; but it's even more bad here, as it also create EVR-update
troubles once the release is done.

> In order to accommodate a
> release candidate set plus the final release creation the freeze point
> for this should happen between the current Test3 dates and the final
> deep freeze dates.

This proposal would IMHO be a bit easier to understand if you could
write a potential F9 schedule with release, freeze and branching dates.

> === CVS Branching ===
> At some point in the tail end of development, either right after Beta
> release or sometime between Beta and RC release, we allow for early
> branching of software.  This allows developers to check in new features
> and otherwise unstable changes that would not be suitable to introduce
> to the current release.  At Release Candidate / Final freeze time all
> unbranched packages will be branched.

I'd say we should split up rawhide and way to final release a bit
earlier. See below.

> == Discussion ==
> Questions or comments regarding this proposed change should be directed
> to the [https://www.redhat.com/mailman/listinfo/fedora-devel-list
> fedora-devel-list] mailing list.  The ReleaseEngineering team is driving
> this proposal.

Thx again for this.

What I further like to see: get test-releases (and maybe also the
releases itself) out more quickly; currently we release only on Tuesday,
Wednesday and Thursday; the target being a Thursday. That afaics lead to
a delay of multiple days sometimes -- e.g. release was targeted for
Thursday but was delayed by one day due to problem; that meant a five
day delay till next Tuesday to get that release out to the testers --
way to long IMHO...

IOW: if a test-release is ready wait max. 24 hours and then get that
thing out. Maybe even release new test-versions as bittorrent only the
first 24 hours and then open the normal mirrors?

Yes, sure, I know out mirrors are important, but not that important to
delay the release that 5 days when the test window is four weeks (the
usual cycle we had between test releases up to now).


Further: I know multiple people that don't run rawhide because we always
tell everyone "once rawhide always rawhide" and "rawhide easts babies".
That' IMHO are our biggest problems. Thus i suggest:

- work hard to make rawhide not eat babies and kill kittens in the 5
weeks approaching a release. Tell the developers so they are more
careful during that timeframe (e.g. as careful as they would be for a
update for a released version) and send ninjas if they are not.

- we need a way for testers that want to test the release that they want
to continue to run afterwards without reinstalling it. Two ideas follow,
I think we should do both:

(1.) support and document the "rawhide -> stable" way -- e.g. at the
point where rawhide on the servers becomes targeting the next Fedora
version give users the choice "Do you want to continue using rawhide or
stick to the release that is happening now?".

(2.) create a "Fedora <N> Early Adapters Release (EAR)"  which uses the
final directory structure and a Release for "early adapters". E.g. what
I mean is something like this:

T-30 days before official release
 * publish a test3 (or call it RC if you like)
 * hard free for rawhide -- just like the two/three lasts week before
the release now

T-18 days before official release
 * branch rawhide and release;
 * create the final directory structure on the servers with what's in
rawhide
 * create and publish "Fedora <N> Early Adapters Release (EAR)" from
that tree; its yum  configs point to that tree and not to rawhide
 * open rawhide for release +1 -- rawhide users had enough time to
report bugs; they won't find any new bugs anymore, thus we need a
different kind of testers now which we get with that Fedora <N> EAR

T-18 until T-7 days
* fix important stuff only like we in the past often did in the first
ten days after a Fedora release; ship that as updates

T-7 days
* respin the tree  on the servers, including all updates that happened
over the past 10 days

T-4 days
* prepare the final release

T-0
* release

= EOF =

Just my 2 cent.

Cu
knurd



From jkeating at redhat.com  Tue Oct 16 17:38:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 13:38:28 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4714F153.202@leemhuis.info>
References: <20071016102448.6cc4af82@redhat.com> <4714F153.202@leemhuis.info>
Message-ID: <20071016133828.1a1c4cb5@redhat.com>

On Tue, 16 Oct 2007 19:13:55 +0200
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> I think having a "it is installable" as defined goal way more often
> would be good. Every Friday maybe?
> 
> Further: both Opensuse and Ubuntu have way more betas/rcs. I don't
> think we should follow that model completely, but maybe we can steal
> ideas from it? A installable rawhide snapshot every two weeks maybe
> (as ISO or as second dir (files hardlinked to rawhide) on the
> servers?)
> 
> Just thinking aloud.

While it wasn't stated in the proposal, and I should add it, we
definitely want to do more "snapshot" like releases for testing, like
what Jeremy has been doing with rawhide live snapshots.  They won't be
as heavily tested as even the "Alpha" release, but will still be made
sure to be mostly bootable and installable.  However the timing of
these would depend on changes in the tree and should target significant
changes and not just be a ticking clock, where as Alpha/Beta/RC/Final
are time based, the other snapshots can be feature or change based.

> 
> > [...]
> > === Release Candidate and Final release ===
> > In order to prepare the release candidate(s) and the final release a
> > final freeze is needed.  It is at this point that we would block
> > rawhide once again.  It is extremely important that we have as many
> > eyes on the bits as possible to make our release as best as we
> > can.  This freeze point is also the point in which we would create
> > any remaining needed branches in CVS for the release.  Any builds
> > from the branch would be held in an updates candidate tag to be
> > potential updates for after the release, or to be pulled in to the
> > release by request.  Builds from devel/ would be tagged for the
> > next release tag to show up in rawhide once the next development
> > cycle starts.   
> 
> Sounds to complicated and much of a "to much of a slowdown/next to
> full stop" to me.

Well it pretty much is.  We have to stop changes in order to finalize
the release and get it out the door.  I can't think of any way to stop
changes but let developers prepare updates for the release (and use
updates testing to get them tested!!)

> New stuff can't be tested, as rawhide stands still
> (I assume it's not pushed to the servers?). 

I'm still trying to come up with some scheme that would open a second
rawhide for the next release, or someway to have a nightly tree
somewhere of the pending release that is still seen and used by the
majority of our testers.  It's essential we get their feedback on the
tree until such time as we won't take in fixes they've found.

> Normal, non-critical
> updates for the release (once it happens) stay updates candidates and
> thus don't get much tested either.

They can be pushed to updates-testing at the 0day mark and thus get
testing there.

> 
> Some packagers will thus likely just push their updates into the
> current release without testing them in rawhide first. 

But rawhide isn't the place to test them, as we're using rawhide as the
most convenient method to get the majority of our community users to
test the bits that will be the release, not the release + potential
updates, the actual release.  After that rawhide would be the /next/
release and also not suitable as a testing ground for updates to a
release.

> That's bad in
> general already; but it's even more bad here, as it also create
> EVR-update troubles once the release is done.

How can it create EVR-update troubles?  Only if maintainers push
updates to previous releases before pushing them for the pending
release, and even so this is not a new problem, as updates to previous
releases happen all the time while the release is a static package set
that quickly has "lower" nvrs than the fully updated previous release.
Not a new problem, and no real solution other than using network at
upgrade time to reach the released updates for the release you're
upgrading to.

> 
> > In order to accommodate a
> > release candidate set plus the final release creation the freeze
> > point for this should happen between the current Test3 dates and
> > the final deep freeze dates.  
> 
> This proposal would IMHO be a bit easier to understand if you could
> write a potential F9 schedule with release, freeze and branching
> dates.

I can add some example dates, but they shouldn't be counted on until
the Board and FESCo et al set the schedule.

> > === CVS Branching ===
> > At some point in the tail end of development, either right after
> > Beta release or sometime between Beta and RC release, we allow for
> > early branching of software.  This allows developers to check in
> > new features and otherwise unstable changes that would not be
> > suitable to introduce to the current release.  At Release
> > Candidate / Final freeze time all unbranched packages will be
> > branched.  
> 
> I'd say we should split up rawhide and way to final release a bit
> earlier. See below.
> 
> > == Discussion ==
> > Questions or comments regarding this proposed change should be
> > directed to the
> > [https://www.redhat.com/mailman/listinfo/fedora-devel-list
> > fedora-devel-list] mailing list.  The ReleaseEngineering team is
> > driving this proposal.  
> 
> Thx again for this.
> 
> What I further like to see: get test-releases (and maybe also the
> releases itself) out more quickly; currently we release only on
> Tuesday, Wednesday and Thursday; the target being a Thursday. That
> afaics lead to a delay of multiple days sometimes -- e.g. release was
> targeted for Thursday but was delayed by one day due to problem; that
> meant a five day delay till next Tuesday to get that release out to
> the testers -- way to long IMHO...
> 
> IOW: if a test-release is ready wait max. 24 hours and then get that
> thing out. Maybe even release new test-versions as bittorrent only the
> first 24 hours and then open the normal mirrors?
> 
> Yes, sure, I know out mirrors are important, but not that important to
> delay the release that 5 days when the test window is four weeks (the
> usual cycle we had between test releases up to now).
> 

That puts an extreme pressure on the mirrors that I'd not like to do.
We've frequently seen feedback from them that if we just do torrent
first and delay the mirrors that they'd just as likely stop mirroring
us which doesn't help anybody.  The only /real/ way to get releases out
there quicker is to not have unstable trees all the time.  If people
were more careful about what they put into rawhide or more reactive to
broken deps reports or did more communication when they introduce wide
reaching changes we'd have less unstable trees and be able to produce
functional releases in quicker fashion and be able to get them to
mirrors on time.  We did a pretty good job with test3, and I hope it
continues with the final, and into next development cycle.

> Further: I know multiple people that don't run rawhide because we
> always tell everyone "once rawhide always rawhide"

Where exactly do "we" tell everyone this?

> and "rawhide easts
> babies". That' IMHO are our biggest problems. Thus i suggest:
> 
> - work hard to make rawhide not eat babies and kill kittens in the 5
> weeks approaching a release. Tell the developers so they are more
> careful during that timeframe (e.g. as careful as they would be for a
> update for a released version) and send ninjas if they are not.

Why 5 weeks, why not just all the time?

> - we need a way for testers that want to test the release that they
> want to continue to run afterwards without reinstalling it. Two ideas
> follow, I think we should do both:
> 
> (1.) support and document the "rawhide -> stable" way -- e.g. at the
> point where rawhide on the servers becomes targeting the next Fedora
> version give users the choice "Do you want to continue using rawhide
> or stick to the release that is happening now?".

Not sure how to "give them the choice" but we certainly can document
how to switch to the final release.  A good "Using Rawhide" page would
list this, and would fall inline with the other changes we want to make
to lead to rawhide being easier and more friendly to use (and thus more
used).

> 
> (2.) create a "Fedora <N> Early Adapters Release (EAR)"  which uses
> the final directory structure and a Release for "early adapters".
> E.g. what I mean is something like this:
> 
> T-30 days before official release
>  * publish a test3 (or call it RC if you like)
>  * hard free for rawhide -- just like the two/three lasts week before
> the release now
> 
> T-18 days before official release
>  * branch rawhide and release;
>  * create the final directory structure on the servers with what's in
> rawhide
>  * create and publish "Fedora <N> Early Adapters Release (EAR)" from
> that tree; its yum  configs point to that tree and not to rawhide
>  * open rawhide for release +1 -- rawhide users had enough time to
> report bugs; they won't find any new bugs anymore, thus we need a
> different kind of testers now which we get with that Fedora <N> EAR
> 
> T-18 until T-7 days
> * fix important stuff only like we in the past often did in the first
> ten days after a Fedora release; ship that as updates
> 
> T-7 days
> * respin the tree  on the servers, including all updates that happened
> over the past 10 days
> 
> T-4 days
> * prepare the final release
> 
> T-0
> * release
> 
> = EOF =
> 
> Just my 2 cent.

I had thought about this too.  It is challenging from an infrastructure
standpoint to manage the bits in this way, due to the permissions
typically on the release directories.  However it's not impossible and
could be a solution to the "second rawhide" type thing.  I'm certainly
open to discussing this more, but I'm not comfortable adding it to the
proposal just yet.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/b7307539/attachment.sig>

From j.w.r.degoede at hhs.nl  Tue Oct 16 17:45:56 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Oct 2007 19:45:56 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016112542.139f4233@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>
Message-ID: <4714F8D4.60603@hhs.nl>

Jesse Keating wrote:
> On Tue, 16 Oct 2007 17:05:51 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> So all in all:
>> -calling it alpha / beta / release candidate instead of test# +1
>> -no freeze for alpha +1
>> -early branching (I would say a week for the RC) +1
>> -making builds in the release branch goto updates-testing after
>>   branching -1 (esp combined with early branching)
> 
> Good, discussion!
> 
> Here is the problem, if the build is not deemed "good" by rel-eng to be
> in the release after the release candidate where does it go?

Why does this deeming good have to be done by rel-eng? Thats creating both a 
bottle-neck and a hoop to jump through.

> Basically
> the idea is that once the RC hits, "development" of the release is
> done, but we want to enable developers to prepare updates to the
> pending release to be able to release them out to updates-testing
> shortly after the release.  Having the builds from the branch be tagged
> as if the release were already out helps in this regard, as they're
> already in the right place to be prepared as an update within Bodhi,
> and if a rel-eng request is made to bring it into the release if
> rel-eng agrees it's a simple tag action to "move it", and if we say no,
> no tagging action is necessary it's all set up to be prepared as an
> update.
> 

Thanks for the explanation I now better understand the problem, so when 
continual frozen prepering for the gold release after an RC, we really want to 
have 3 different options for rawhide builds:
1) Its a benign simple fix, with little chance to regressions, or a fix for a
    blocker bug -> should go into the release
2) Its not next devel cycle material, but it would be better to have it in
    updates-testing when we go gold, then to put it in the release aka
    update-candidate
3) Its next devel cycle material

And the proposed scheme only has 2 exit points, the branch for the release and 
a devel branch. This IMHO is a problem which we should not try to solve by 
introducing human intervention. But rather by a technical solution.

And yes I want to see "benign simple fixes, with little chance to regressions" 
go into the release even once we've released an RC, that way we the actual 
release will be better (less bugs) and we avoid having a slew of updates right 
after the release.

I know some people are very much against this and want only critical fixes at 
this point, to them I say stop thinking Fedora Core and start thinking Fedora 
Extras. For core components like kernel and glibc and xorg I fully agree to the 
only critical fixes stance, but I also fully trust their very capable 
maintainers to only do critical fixes!

So there is no reason why some club should be designated to decide wether or 
not a fix is critical enough. Esp since "wether or not a fix is critical 
enough" is not the only metric to take into account here. The decision should 
be based on weighing the benefits of the bugfix versus the chance of regression 
"multiplied" by the impact of a potential regression. And the person who can 
best judge this balance is the maintainer.

Isn't our new slogan "freedom is a feature", then I say no to a small club 
making the decisions, thats an autocracy. I say power to the people (power to 
the maintainers).

Regards,

Hans



From bpepple at fedoraproject.org  Tue Oct 16 17:55:51 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 16 Oct 2007 13:55:51 -0400
Subject: rawhide report: 20071015 changes
In-Reply-To: <471487D4.7070906@poolshark.org>
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071016T061751-628@post.gmane.org>
	<471487D4.7070906@poolshark.org>
Message-ID: <c6534ba10710161055p2a7c2a90q19921d2e3d19da0d@mail.gmail.com>

On 10/16/07, Denis Leroy <denis at poolshark.org> wrote:
> Kevin Kofler wrote:
> > Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
> >> Fight the freeze!
> >
> > Don't panic. I've already rebuilt kdelibs4 and kdebase4, Rex is doing most of
> > the others, all the other maintainers have been informed (well in advance),
>
> hmm, i wasn't informed of the OpenEXR update...

Yeah, I don't remember being informed either.



From halfline at gmail.com  Tue Oct 16 17:59:16 2007
From: halfline at gmail.com (Ray Strode)
Date: Tue, 16 Oct 2007 13:59:16 -0400
Subject: RHGB not running
In-Reply-To: <1192552321.2194.7.camel@scrappy.miketc.com>
References: <1192552321.2194.7.camel@scrappy.miketc.com>
Message-ID: <45abe7d80710161059ie4a3deod436f8e612702215@mail.gmail.com>

Hi,

On 10/16/07, Mike Chambers <mike at miketc.com> wrote:
> After today's rawhide updates, when rebooting, rhgb initially starts.
> But within a second or two, it goes right back to the console, sits at a
> particular prompt (can't remember which one, think it is "awaiting fstab
> or something).  Anyway, it sits there while the initscripts run
> (although it doesn't show you they are starting), then finally it starts
> the desktop.  Everything seems normal at that prompt.
>
> Anyway, try a reboot and see if anyone else has same problem?
This should be fixed in tomorrow's rawhide.

--Ray



From mmcgrath at redhat.com  Tue Oct 16 17:51:43 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 16 Oct 2007 12:51:43 -0500
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4714F8D4.60603@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>
	<4714F8D4.60603@hhs.nl>
Message-ID: <4714FA2F.4090505@redhat.com>

Hans de Goede wrote:
> Jesse Keating wrote:
>> On Tue, 16 Oct 2007 17:05:51 +0200
>> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>>
>>> So all in all:
>>> -calling it alpha / beta / release candidate instead of test# +1
>>> -no freeze for alpha +1
>>> -early branching (I would say a week for the RC) +1
>>> -making builds in the release branch goto updates-testing after
>>>   branching -1 (esp combined with early branching)
>>
>> Good, discussion!
>>
>> Here is the problem, if the build is not deemed "good" by rel-eng to be
>> in the release after the release candidate where does it go?
>
> Why does this deeming good have to be done by rel-eng? Thats creating 
> both a bottle-neck and a hoop to jump through.

Someone has to do it, who?

    -Mike



From mclasen at redhat.com  Tue Oct 16 18:02:57 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 16 Oct 2007 14:02:57 -0400
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <4714F153.202@leemhuis.info>
References: <20071016102448.6cc4af82@redhat.com> <4714F153.202@leemhuis.info>
Message-ID: <1192557777.3761.3.camel@localhost.localdomain>


On Tue, 2007-10-16 at 19:13 +0200, Thorsten Leemhuis wrote:
> On 16.10.2007 16:24, Jesse Keating wrote:
> > Please read through 
> > http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal
> > and follow up on this thread with any questions comments. [...]
> 
> In general: looks nice, some steps in the right direction IMHO. But not
> enough IMHO. Quoted some parts of the proposal below, some other ideas
> and the end of the mail:
> 
> > = Proposed Development Process Changes for Fedora 9 =
> > [...]
> > == Proposed Solution ==
> > Move to an Alpha/Beta/RC/Final release method.
> 
> Hmmm, even after reading the proposal three times now it got a bit of an
> "use different names for what we had already with some small
> modifications" feeling

The different names should give an indication that we want to treat the
various snapshots differently. The uniform test1/test2/test3 naming
scheme doesn't really get that point across.





From jkeating at redhat.com  Tue Oct 16 18:05:01 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 14:05:01 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4714F8D4.60603@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com> <4714F8D4.60603@hhs.nl>
Message-ID: <20071016140501.54b60d88@redhat.com>

On Tue, 16 Oct 2007 19:45:56 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Why does this deeming good have to be done by rel-eng? Thats creating
> both a bottle-neck and a hoop to jump through.

Because past has proven that given our huge number of maintainers that
not everybody notices we're in a freeze, or cares, and leads to broken
trees.  QA/Releng wants some ability to prevent that from happening
down the final stretch to get the release out.  This is something
common to distributions, not just Fedora.  In fact, the model we're
using is closely modeled after the FreeBSD development cycle.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html#RELEASE-PROC

> 
> > Basically
> > the idea is that once the RC hits, "development" of the release is
> > done, but we want to enable developers to prepare updates to the
> > pending release to be able to release them out to updates-testing
> > shortly after the release.  Having the builds from the branch be
> > tagged as if the release were already out helps in this regard, as
> > they're already in the right place to be prepared as an update
> > within Bodhi, and if a rel-eng request is made to bring it into the
> > release if rel-eng agrees it's a simple tag action to "move it",
> > and if we say no, no tagging action is necessary it's all set up to
> > be prepared as an update.
> >   
> 
> Thanks for the explanation I now better understand the problem, so
> when continual frozen prepering for the gold release after an RC, we
> really want to have 3 different options for rawhide builds:
> 1) Its a benign simple fix, with little chance to regressions, or a
> fix for a blocker bug -> should go into the release
> 2) Its not next devel cycle material, but it would be better to have
> it in updates-testing when we go gold, then to put it in the release
> aka update-candidate
> 3) Its next devel cycle material
> 
> And the proposed scheme only has 2 exit points, the branch for the
> release and a devel branch. This IMHO is a problem which we should
> not try to solve by introducing human intervention. But rather by a
> technical solution.
> 
> And yes I want to see "benign simple fixes, with little chance to
> regressions" go into the release even once we've released an RC, that
> way we the actual release will be better (less bugs) and we avoid
> having a slew of updates right after the release.
> 
> I know some people are very much against this and want only critical
> fixes at this point, to them I say stop thinking Fedora Core and
> start thinking Fedora Extras. For core components like kernel and
> glibc and xorg I fully agree to the only critical fixes stance, but I
> also fully trust their very capable maintainers to only do critical
> fixes!
> 
> So there is no reason why some club should be designated to decide
> wether or not a fix is critical enough. Esp since "wether or not a
> fix is critical enough" is not the only metric to take into account
> here. The decision should be based on weighing the benefits of the
> bugfix versus the chance of regression "multiplied" by the impact of
> a potential regression. And the person who can best judge this
> balance is the maintainer.
> 
> Isn't our new slogan "freedom is a feature", then I say no to a small
> club making the decisions, thats an autocracy. I say power to the
> people (power to the maintainers).

The past has burned me on having that much trust in /every/ maintainer
thinking that deeply into every change they make at the end game.  More
often than not I just see blanket "build for new upstream release"
happening across every active branch at any time during the process
with no thought to freezes or release cycles.  That's the type of thing
we just don't want to land in our trees during the final stages.

The process /does/ have 3 exit points.  There is a devel/ branch to
build things for the next release, there is the release branch which by
default is used for updates to the release, and if the maintainer is
actually making a thought as to this is a fix they want /in/ the
release they can alert the releng team to this and releng can do the
necessary work (calling a koji command to tag the package, calling the
signing commands to sign the package, making sure there is time to get
it in and actually be picked up in a compose, etc...) to get the build
pulled into the release.

I'm more than happy to add more people to the releng team that would be
willing to make these kinds of decisions so that we have round the
clock/world coverage.  I'm just not ready to leave the collection open
for joe random builder to build things in when we're trying to get a
release out.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/61f29f1b/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Oct 16 18:12:18 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Oct 2007 20:12:18 +0200
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <4714F8D4.60603@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>  <4714F8D4.60603@hhs.nl>
Message-ID: <1192558338.29450.8.camel@rousalka.dyndns.org>


Le mardi 16 octobre 2007 ? 19:45 +0200, Hans de Goede a ?crit :
> Jesse Keating wrote:

> > Here is the problem, if the build is not deemed "good" by rel-eng to be
> > in the release after the release candidate where does it go?
> 
> Why does this deeming good have to be done by rel-eng? Thats creating both a 
> bottle-neck and a hoop to jump through.

Because ultimately rel-eng is the Fedora entity responsible for making
good releases, because everyone will blame them if things go wrong, so I
sure hope they have veto power at critical release time

> And yes I want to see "benign simple fixes, with little chance to regressions" 
> go into the release even once we've released an RC, that way we the actual 
> release will be better (less bugs) and we avoid having a slew of updates right 
> after the release.

Join rel-eng, you want a share of the power, get a share of the blame.

> I know some people are very much against this and want only critical fixes at 
> this point, to them I say stop thinking Fedora Core and start thinking Fedora 
> Extras.

This is not FE vs FC, this is having someone in charge at release time
and you won't find a lot of people here to say rel-eng or Jesse is
abusing this power.

Many thanks to the rel-eng team! Many thanks for herding ungrateful
cats!

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

From a.badger at gmail.com  Tue Oct 16 18:13:13 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 16 Oct 2007 11:13:13 -0700
Subject: openoffice-pyuno and external python programs
In-Reply-To: <1192543367.7004.86.camel@Jehannum>
References: <Pine.LNX.4.58.0710161218280.30162@venus.brc>	<1192537028.7004.80.camel@Jehannum>	<Pine.LNX.4.58.0710161514090.30162@venus.brc>
	<1192543367.7004.86.camel@Jehannum>
Message-ID: <4714FF39.5080209@gmail.com>

Caolan McNamara wrote:
> On Tue, 2007-10-16 at 15:17 +0200, Zoltan Kota wrote:
>> On Tue, 16 Oct 2007, Caolan McNamara wrote:
>>
>>> Hmm, what does 
>>> readelf -d /usr/lib/python2.4/site-packages/pyuno.so | grep RPATH
>>> say on debian ? Is there an absolute entry in there so get it to find
>>> the libraries it needs ? 
>>
>> On Ubuntu, readelf... says:
>> 0x0000000f (RPATH)                      Library rpath: 
>> [$ORIGIN:/usr/lib/openoffice/program]
> 
> Yeah, so they set the rpath to find the OOo libs that libpyuno.so is
> linked to in /usr/lib/openoffice/ when they moved it out of there. I'd
> probably fall foul of the fedora packaging guidelines if I whacked in
> the same thing ? We (OOo) don't really have a good standard for where to
> stick bits of OOo when it's bundled into the distro.
> 
If it's exporting an interface that it expects others to use (like the 
pythonuno bindings), it should be put into %{_libdir} directly....

Is this doable or are there things that make it non-trivial?

-Toshio



From mschwendt.tmp0701.nospam at arcor.de  Tue Oct 16 18:19:08 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 16 Oct 2007 20:19:08 +0200
Subject: Provides/Obsoletes question
In-Reply-To: <20071016163525.GM3462@jasmine.xos.nl>
References: <4714DBFB.9030209@RedHat.com> <1192549495.8542.16.camel@cutter>
	<20071016181410.3532dc75.mschwendt.tmp0701.nospam@arcor.de>
	<1192551777.30612.39.camel@localhost.localdomain>
	<20071016163525.GM3462@jasmine.xos.nl>
Message-ID: <20071016201908.24f2c316.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 16 Oct 2007 18:35:25 +0200, Jos Vos wrote:

> In RHEL5 (probably also in Fedora), pidgin obsoletes "gaim < 999:1"
> (epoch 999 !!!).  If someone can explain me why this is better than
> just obsoleting "gaim", please tell me.  IMHO, this only makes sense
> if a "gaim >= 999:1" might ever exist.  I don't think so :-).

Versioned Obsoletes are superior, because they occupy only a specific
EVR range of a package namespace. For your example of "gaim < 999:1",
you can reintroduce a package with the name "gaim" (suppose it's a
different piece of software) by giving it an EVR higher than 999:1.
On the contrary, the unversioned "Obsoletes: gaim" blocks re-entry
of a package with the name "gaim", regardless of its EVR.



From j.w.r.degoede at hhs.nl  Tue Oct 16 18:26:35 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Oct 2007 20:26:35 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4714FA2F.4090505@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>
	<4714FA2F.4090505@redhat.com>
Message-ID: <4715025B.4000304@hhs.nl>

Mike McGrath wrote:
> Hans de Goede wrote:
>> Jesse Keating wrote:
>>> On Tue, 16 Oct 2007 17:05:51 +0200
>>> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>>>
>>>> So all in all:
>>>> -calling it alpha / beta / release candidate instead of test# +1
>>>> -no freeze for alpha +1
>>>> -early branching (I would say a week for the RC) +1
>>>> -making builds in the release branch goto updates-testing after
>>>>   branching -1 (esp combined with early branching)
>>>
>>> Good, discussion!
>>>
>>> Here is the problem, if the build is not deemed "good" by rel-eng to be
>>> in the release after the release candidate where does it go?
>>
>> Why does this deeming good have to be done by rel-eng? Thats creating 
>> both a bottle-neck and a hoop to jump through.
> 
> Someone has to do it, who?
> 

How about the maintainer?

Regards,

Hans



From tmus at tmus.dk  Tue Oct 16 17:29:59 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Tue, 16 Oct 2007 15:29:59 -0200
Subject: Add to wishlist
In-Reply-To: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
References: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
Message-ID: <ff2sen$uud$2@ger.gmane.org>

Peter ?strand wrote:
> I thought I should add a few packages to the Wishlist at 
> http://fedoraproject.org/wiki/PackageMaintainers/WishList, but then I 
> realized that getting edit access is a >10 step process. Gosh, does it 
> really have to be this complicated? 
> 
> Anyway, can anyone with edit access add these two items to the Wishlist:
> 
> * unfs3 - user-space NFSv3 server implementation
> 
> * xclip - command line interface to the X11 clipboard, with file copy 
>   support
> 
xclip is in F7 at least - dunno 'bout F8...

/Thomas



From tmus at tmus.dk  Tue Oct 16 17:29:03 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Tue, 16 Oct 2007 15:29:03 -0200
Subject: Add to wishlist
In-Reply-To: <20071015204335.GB2790@free.fr>
References: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
	<20071015204335.GB2790@free.fr>
Message-ID: <ff2scv$uud$1@ger.gmane.org>

Patrice Dumas wrote:
> On Mon, Oct 15, 2007 at 07:32:49PM +0200, Peter ?strand wrote:
>> * unfs3 - user-space NFSv3 server implementation
> 
Why not let the developers answer that question: 
http://unfs3.sourceforge.net/

/Thomas



From nicolas.mailhot at laposte.net  Tue Oct 16 18:33:16 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Oct 2007 20:33:16 +0200
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <4715025B.4000304@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>
	<4714FA2F.4090505@redhat.com>  <4715025B.4000304@hhs.nl>
Message-ID: <1192559596.29450.10.camel@rousalka.dyndns.org>


Le mardi 16 octobre 2007 ? 20:26 +0200, Hans de Goede a ?crit :
> Mike McGrath wrote:
> > Hans de Goede wrote:

> >> Why does this deeming good have to be done by rel-eng? Thats creating 
> >> both a bottle-neck and a hoop to jump through.
> > 
> > Someone has to do it, who?

> How about the maintainer?

The  maintainer will always put his package before the distro as a whole
-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/fcee3f27/attachment.sig>

From caolanm at redhat.com  Tue Oct 16 19:10:18 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 16 Oct 2007 20:10:18 +0100
Subject: openoffice-pyuno and external python programs
In-Reply-To: <4714FF39.5080209@gmail.com>
References: <Pine.LNX.4.58.0710161218280.30162@venus.brc>
	<1192537028.7004.80.camel@Jehannum>
	<Pine.LNX.4.58.0710161514090.30162@venus.brc>
	<1192543367.7004.86.camel@Jehannum>  <4714FF39.5080209@gmail.com>
Message-ID: <1192561818.7004.94.camel@Jehannum>

On Tue, 2007-10-16 at 11:13 -0700, Toshio Kuratomi wrote:
> Is this doable or are there things that make it non-trivial?

There are things that make it non-trivial for now, when the 
OOo/URE split is complete then it becomes a good bit easier.

C.



From rdieter at math.unl.edu  Tue Oct 16 18:04:31 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 16 Oct 2007 13:04:31 -0500
Subject: rawhide report: 20071015 changes
References: <200710151924.l9FJOCnD032392@porkchop.devel.redhat.com>
	<20071015233533.aeb677b8.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071016T061751-628@post.gmane.org>
	<471487D4.7070906@poolshark.org>
	<c6534ba10710161055p2a7c2a90q19921d2e3d19da0d@mail.gmail.com>
Message-ID: <ff2ufg$6ch$1@ger.gmane.org>

Brian Pepple wrote:

> On 10/16/07, Denis Leroy <denis at poolshark.org> wrote:
>> Kevin Kofler wrote:
>> > Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
>> >> Fight the freeze!
>> >
>> > Don't panic. I've already rebuilt kdelibs4 and kdebase4, Rex is doing
>> > most of the others, all the other maintainers have been informed (well
>> > in advance),
>>
>> hmm, i wasn't informed of the OpenEXR update...
> 
> Yeah, I don't remember being informed either.

I sent the messages to primary maintainers addresses listed in owners.list.
I should have sent notice here too, sorry.

-- Rex



From louisg00 at bellsouth.net  Tue Oct 16 18:39:47 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Tue, 16 Oct 2007 14:39:47 -0400
Subject: gnome keyring always needs to be unlocked
Message-ID: <1192559987.2807.3.camel@tiger>

when logging on I need to give gnome-keyring the password to unlock even
though I check it so it unlocks automatically. What gives?

-Louis



From j.w.r.degoede at hhs.nl  Tue Oct 16 18:44:03 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Oct 2007 20:44:03 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016140501.54b60d88@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>
	<4714F8D4.60603@hhs.nl> <20071016140501.54b60d88@redhat.com>
Message-ID: <47150673.5050600@hhs.nl>

Jesse Keating wrote:
> On Tue, 16 Oct 2007 19:45:56 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Why does this deeming good have to be done by rel-eng? Thats creating
>> both a bottle-neck and a hoop to jump through.
> 
> Because past has proven that given our huge number of maintainers that
> not everybody notices we're in a freeze, or cares, and leads to broken
> trees.

Broken as in not depclosing / containing conflicts I assume? That can be 
checked with scripts, why not revert the process and allow rel-eng to kick out 
bad builds instead of make all the good people suffer because of a few bad apples?

>> Isn't our new slogan "freedom is a feature", then I say no to a small
>> club making the decisions, thats an autocracy. I say power to the
>> people (power to the maintainers).
> 
> The past has burned me on having that much trust in /every/ maintainer
> thinking that deeply into every change they make at the end game.  More
> often than not I just see blanket "build for new upstream release"
> happening across every active branch at any time during the process
> with no thought to freezes or release cycles.  That's the type of thing
> we just don't want to land in our trees during the final stages.
> 

I say that depends on the package, for an obscure package the latest upstream 
might be the best, even if that means it replaces a much better tested release. 
For example today I've been preparing a new scorched3d release, based on a 
brand new upstream release, and after some quick testing I will build this for 
the F-8 release tree. Why? Because its a network based multiplayer only game, 
which changes its network protocol each release (GRRRR), and all the official 
servers update to the latest release pretty quickly, so unless users set up a 
private server anything but the latest upstream is useless.

Vavoom on the other hand tends to new upstream releases with a rough edge, and 
the current release is working fine, so there I've requested early branching 
and only build the new upstream for what will become rawhide after F-8 release.

You see, the maintainer knows best. Currently we have near 5000 packages, if we 
grow like Debian has, we might end up with 20000, you really cannot expect a 
small team to handle all the updates which are "good enough" for release 
inclusion, unless they will blindly believe what the maintainer says, and then 
you might as well get rid of the man in the middle.

> The process /does/ have 3 exit points.

No it doesn't it has 2 exit points where one is multiplexed, with the 
multiplexing requiring human interaction. One might as well argue that windows 
3.11 had no stability issues, because as long as a human was present to press 
the reset button when it hang, it would be back up in no time.

> I'm more than happy to add more people to the releng team that would be
> willing to make these kinds of decisions so that we have round the
> clock/world coverage.  I'm just not ready to leave the collection open
> for joe random builder to build things in when we're trying to get a
> release out.

We do not have joe random builder, we only have sponsored contributers, who 
during the sponsor process have had to prove their packaging skills. We may 
need to educate them further, calling them "joe random builder" is not going to 
help them become better, nor will it help us grow our community.

All in all to me it looks like we need more automated checks, where a package 
which fails them gets a special tag and needs manual tagging during the whole 
cycle. I know depclosing the whole of Fedora takes ages, but how about a script 
which looks at the current provides for a package, and compares them to the 
provides of a new version, if some provides go away (say a .soname) the script 
would disallow automatic pushing and give the package a special tag. After this 
the maintainer would need to ask rel-eng to re-tag it with the normal tag, 
explaining why the provides is gone.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Tue Oct 16 18:46:21 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 16 Oct 2007 20:46:21 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <1192559596.29450.10.camel@rousalka.dyndns.org>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>	<4714FA2F.4090505@redhat.com>
	<4715025B.4000304@hhs.nl>
	<1192559596.29450.10.camel@rousalka.dyndns.org>
Message-ID: <471506FD.7030300@hhs.nl>

Nicolas Mailhot wrote:
> Le mardi 16 octobre 2007 ? 20:26 +0200, Hans de Goede a ?crit :
>> Mike McGrath wrote:
>>> Hans de Goede wrote:
> 
>>>> Why does this deeming good have to be done by rel-eng? Thats creating 
>>>> both a bottle-neck and a hoop to jump through.
>>> Someone has to do it, who?
> 
>> How about the maintainer?
> 
> The  maintainer will always put his package before the distro as a whole
> 

If that is how people here think about maintainers, or worse what they expect 
of maintainers I think I need to look for another community to start 
contributing too.

Regards,

Hans



From zcerza at redhat.com  Tue Oct 16 19:01:39 2007
From: zcerza at redhat.com (Zack Cerza)
Date: Tue, 16 Oct 2007 15:01:39 -0400
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <1192559987.2807.3.camel@tiger>
References: <1192559987.2807.3.camel@tiger>
Message-ID: <47150A93.2090608@redhat.com>

Louis E Garcia II wrote:
> when logging on I need to give gnome-keyring the password to unlock even
> though I check it so it unlocks automatically. What gives?
> 
> -Louis

 From what I understand, the feature isn't complete and depends on [0]. 
Matthias said in [1] that he removed the checkboxes until that work is 
finished.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=250147
[1] https://bugzilla.redhat.com/show_bug.cgi?id=312531

Zack



From jkeating at redhat.com  Tue Oct 16 19:05:59 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 15:05:59 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <47150673.5050600@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com> <4714F8D4.60603@hhs.nl>
	<20071016140501.54b60d88@redhat.com> <47150673.5050600@hhs.nl>
Message-ID: <20071016150559.5d3be8d4@redhat.com>

On Tue, 16 Oct 2007 20:44:03 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> > Because past has proven that given our huge number of maintainers
> > that not everybody notices we're in a freeze, or cares, and leads
> > to broken trees.  
> 
> Broken as in not depclosing / containing conflicts I assume? That can
> be checked with scripts, why not revert the process and allow rel-eng
> to kick out bad builds instead of make all the good people suffer
> because of a few bad apples?

Because usually it's too late after the brokenness is detected.  We
have such a huge number of packages that the time it takes to fully
multilib out our set and depsolve it is in the order of hours.  It's
quite costly and certainly can't be ran for every single build that
hits.  There is a certain amount of hardware that can be thrown at the
problem but resources are finite.  I'd prefer to avoid the problem in
the first place than to play clean up, repeatedly.  If we ever get out
of the situation where we are pre-calculating multilib and can do more
accurate automated post-build validation before tagging I would be more
than happy to revisit this item.

> 
> >> Isn't our new slogan "freedom is a feature", then I say no to a
> >> small club making the decisions, thats an autocracy. I say power
> >> to the people (power to the maintainers).  
> > 
> > The past has burned me on having that much trust in /every/
> > maintainer thinking that deeply into every change they make at the
> > end game.  More often than not I just see blanket "build for new
> > upstream release" happening across every active branch at any time
> > during the process with no thought to freezes or release cycles.
> > That's the type of thing we just don't want to land in our trees
> > during the final stages. 
> 
> I say that depends on the package, for an obscure package the latest
> upstream might be the best, even if that means it replaces a much
> better tested release. For example today I've been preparing a new
> scorched3d release, based on a brand new upstream release, and after
> some quick testing I will build this for the F-8 release tree. Why?
> Because its a network based multiplayer only game, which changes its
> network protocol each release (GRRRR), and all the official servers
> update to the latest release pretty quickly, so unless users set up a
> private server anything but the latest upstream is useless.
> 
> Vavoom on the other hand tends to new upstream releases with a rough
> edge, and the current release is working fine, so there I've
> requested early branching and only build the new upstream for what
> will become rawhide after F-8 release.
> 
> You see, the maintainer knows best. 

When they are actively considering the release processes, the freezes
(soft or hard) and the current schedules yes.  When they are just using
their 5 minutes of free time a week to quickly slap out new versions of
all their packages, not so much.  I'm trying to prevent people from
shooting themselves in the foot (due to ignorance to the current status
of things rather than malice).

> Currently we have near 5000
> packages, if we grow like Debian has, we might end up with 20000, you
> really cannot expect a small team to handle all the updates which are
> "good enough" for release inclusion, unless they will blindly believe
> what the maintainer says, and then you might as well get rid of the
> man in the middle.

Other distributions deal with this with sufficiently large package
sets, I think we can to, or as I wrote above work on tools to obviate
the process.  The tools aren't here today, so releng gets to /be/ the
tool.

> 
> > The process /does/ have 3 exit points.  
> 
> No it doesn't it has 2 exit points where one is multiplexed, with the 
> multiplexing requiring human interaction. One might as well argue
> that windows 3.11 had no stability issues, because as long as a human
> was present to press the reset button when it hang, it would be back
> up in no time.

We're off in the weeds here.

> 
> > I'm more than happy to add more people to the releng team that
> > would be willing to make these kinds of decisions so that we have
> > round the clock/world coverage.  I'm just not ready to leave the
> > collection open for joe random builder to build things in when
> > we're trying to get a release out.  
> 
> We do not have joe random builder, we only have sponsored
> contributers, 

With no real guideline behind /who/ get sponsored, other than "hey I
have the rights to sponsor somebody".

> who during the sponsor process have had to prove their
> packaging skills.

And while packaging skills are important, it has absolutely nothing to
do with cluefullness to the release process and what freezes mean and
how to plan package updates around these constraints.  We have /no/
training regarding this that we give to new users, nor very much good
documentation.  It's growing over time but I'm not likely to want to
let chaos reign until we get these things in place.

>  We may need to educate them further, calling them
> "joe random builder" is not going to help them become better, nor
> will it help us grow our community.

I didn't think "joe random builder" was derogatory in any manner.  I
will immediately stop using that phrase.  I meant to convey the idea of
a packager who maybe has one or two packages they maintain, not a lot
of time to work on Fedora, just doing work whenever possible, not able
to follow complicated things like release schedules and freezes, etc...
and may not be taking these things into consideration when they're
using their limited free time to process new releases or builds of
their packages.

> 
> All in all to me it looks like we need more automated checks, where a
> package which fails them gets a special tag and needs manual tagging
> during the whole cycle. I know depclosing the whole of Fedora takes
> ages, but how about a script which looks at the current provides for
> a package, and compares them to the provides of a new version, if
> some provides go away (say a .soname) the script would disallow
> automatic pushing and give the package a special tag. After this the
> maintainer would need to ask rel-eng to re-tag it with the normal
> tag, explaining why the provides is gone.

We just don't have that in place, and I don't expect to have much of it
in place before we'll need it for F9.  I'm not saying to not work on
it, however I don't have the bandwidth to work on it right now.  I have
too much other equally important pieces of infrastructure to work on.
What I'm trying to provide is a working development model in absence of
these things so that we can continue on, and as these things show up
adjust our development model to take advantage of them.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/3e67e9eb/attachment.sig>

From jkeating at redhat.com  Tue Oct 16 19:07:29 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 15:07:29 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <1192557777.3761.3.camel@localhost.localdomain>
References: <20071016102448.6cc4af82@redhat.com> <4714F153.202@leemhuis.info>
	<1192557777.3761.3.camel@localhost.localdomain>
Message-ID: <20071016150729.50b1725e@redhat.com>

On Tue, 16 Oct 2007 14:02:57 -0400
Matthias Clasen <mclasen at redhat.com> wrote:

> The different names should give an indication that we want to treat
> the various snapshots differently. The uniform test1/test2/test3
> naming scheme doesn't really get that point across.

I like this info.  I'll add it to the proposal.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/81aa61cc/attachment.sig>

From markg85 at gmail.com  Tue Oct 16 19:29:31 2007
From: markg85 at gmail.com (Mark)
Date: Tue, 16 Oct 2007 21:29:31 +0200
Subject: Fedora caching suggestion
In-Reply-To: <20071016145240.GA1968@jadzia.bu.edu>
References: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>
	<20071016145240.GA1968@jadzia.bu.edu>
Message-ID: <6e24a8e80710161229s296c304q2c664843099957d4@mail.gmail.com>

2007/10/16, Matthew Miller <mattdm at mattdm.org>:
> On Mon, Oct 15, 2007 at 04:50:56PM +0200, Mark wrote:
> > I've followed the discussion about readahead and it got disabled for
> > Fedora 8 (it wasn't benefiting at all (at least not for me)). Now i
> > wonder if it would be possible to pre cache the "all time using"
> > programs? With "all time using" i mean all the programs that are gonna
> > be started anyway and that are highly likely to be started. for gnome
> > it would be at least the following:
>
> Readahead can do that. And as you noted, it doesn't help much.

Well, readahead didn't seem to do a good job at it.. i wasn't noticing
any changes with all the echo icons cached in the menu.. it still
looked like the icons still had to be loaded (they didn't appear any
faster at all and all icons where in the readahead list).



From nicolas.mailhot at laposte.net  Tue Oct 16 19:30:25 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 16 Oct 2007 21:30:25 +0200
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <471506FD.7030300@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>
	<4714FA2F.4090505@redhat.com> <4715025B.4000304@hhs.nl>
	<1192559596.29450.10.camel@rousalka.dyndns.org>
	<471506FD.7030300@hhs.nl>
Message-ID: <1192563025.29450.18.camel@rousalka.dyndns.org>


Le mardi 16 octobre 2007 ? 20:46 +0200, Hans de Goede a ?crit :
> Nicolas Mailhot wrote:
> > Le mardi 16 octobre 2007 ? 20:26 +0200, Hans de Goede a ?crit :
> >> Mike McGrath wrote:
> >>> Hans de Goede wrote:
> > 
> >>>> Why does this deeming good have to be done by rel-eng? Thats creating 
> >>>> both a bottle-neck and a hoop to jump through.
> >>> Someone has to do it, who?
> > 
> >> How about the maintainer?
> > 
> > The  maintainer will always put his package before the distro as a whole
> > 
> 
> If that is how people here think about maintainers, or worse what they expect 
> of maintainers I think I need to look for another community to start 
> contributing too.

It's a realistic assessment of normal human beings. Even Linus has to
scold his elite lieutenants to get a release out and they move in more
rarefied circles circles than your average Fedora maintainer.

(hell Alan Cox scolded Linus back when one managed the stable tree and
the other the developement tree)

Sometimes stuff has to be done and a Fedora-wide release committee does
not strike me as a good idea.

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

From mmcgrath at redhat.com  Tue Oct 16 19:27:43 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 16 Oct 2007 14:27:43 -0500
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <471506FD.7030300@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>	<4714FA2F.4090505@redhat.com>	<4715025B.4000304@hhs.nl>	<1192559596.29450.10.camel@rousalka.dyndns.org>
	<471506FD.7030300@hhs.nl>
Message-ID: <471510AF.20009@redhat.com>

Hans de Goede wrote:
> Nicolas Mailhot wrote:
>> Le mardi 16 octobre 2007 ? 20:26 +0200, Hans de Goede a ?crit :
>>> Mike McGrath wrote:
>>>> Hans de Goede wrote:
>>
>>>>> Why does this deeming good have to be done by rel-eng? Thats 
>>>>> creating both a bottle-neck and a hoop to jump through.
>>>> Someone has to do it, who?
>>
>>> How about the maintainer?
>>
>> The  maintainer will always put his package before the distro as a whole
>>
>
> If that is how people here think about maintainers, or worse what they 
> expect of maintainers I think I need to look for another community to 
> start contributing too.

The fact is the maintainers are a collective.  And as a collective there 
is just no reasonable way for them to all communicate all changes to 
each other while at the same time make decisions/be responsible for 
those changes.  It's a massive moving cloud, there are hundreds of us.  
Many of which don't participate on the lists what-so-ever.  It's just a 
practical matter of the right hand not knowing what the left hand is 
doing... and there are hundreds of hands.

Someone needs to oversee that cloud's changes during a release to make 
sure that what we call Fedora X is valid and working.

    -Mike



From mmcgrath at redhat.com  Tue Oct 16 19:32:42 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 16 Oct 2007 14:32:42 -0500
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <47150673.5050600@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com>	<4714D34F.1080304@hhs.nl>	<20071016112542.139f4233@redhat.com>	<4714F8D4.60603@hhs.nl>
	<20071016140501.54b60d88@redhat.com> <47150673.5050600@hhs.nl>
Message-ID: <471511DA.1020004@redhat.com>

Hans de Goede wrote:
>
> Regards,

You seem to have a completely different vision of how a release should 
be, why not create a 
http://fedoraproject.org/wiki/HansdeGoede/DevelopmentChangesProposal If 
your vision is so different it may not be possible to replace individual 
pieces of your ideas with someone else's vision.  Put the whole thing 
down from start to finish so we can comment on your proposal as well.  
Since we're talking about drastic changes, I don't know why there can't 
be multiple proposals if people are willing to take the time to write them.

    -Mike



From jspaleta at gmail.com  Tue Oct 16 19:56:48 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 16 Oct 2007 11:56:48 -0800
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <471506FD.7030300@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
	<20071016112542.139f4233@redhat.com> <4714F8D4.60603@hhs.nl>
	<4714FA2F.4090505@redhat.com> <4715025B.4000304@hhs.nl>
	<1192559596.29450.10.camel@rousalka.dyndns.org>
	<471506FD.7030300@hhs.nl>
Message-ID: <604aa7910710161256i2b07dfe9q519454ed0c872f96@mail.gmail.com>

On 10/16/07, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> If that is how people here think about maintainers, or worse what they expect
> of maintainers I think I need to look for another community to start
> contributing too.

I think its best to think of the release-eng and maintainers
relationship as somewhat analogous to editors and writers for a brick
and mortar periodical.  It's not a perfect analogy, but i think it
captures the inherent conflict of priorities which don't require the
existence of ill-will or malice felt by one group for the other.

-jef"would release-eng feel more cuddly if we re-branded it as a SIG?"spaleta



From wtogami at redhat.com  Tue Oct 16 19:58:29 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 16 Oct 2007 15:58:29 -0400
Subject: s/libgssapi/libgssglue/ now? 
Message-ID: <471517E5.7040304@redhat.com>

http://koji.fedoraproject.org/koji/buildinfo?buildID=21262

First ever build of libgssglue which seems to replace libgssapi happened 
today, one day before the freeze of F8.  In addition to replacing 
libgssapi it seems to bump soname.

---> Package libgssglue.x86_64 0:0.1-2.fc8 set to be updated
---> Package libgssglue.i386 0:0.1-2.fc8 set to be updated
--> Running transaction check
--> Processing Dependency: libgssapi.so.2()(64bit) for package: libtirpc
--> Processing Dependency: libgssapi.so.2()(64bit) for package: nfs-utils
--> Processing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) for 
package: libtirpc
--> Processing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) for 
package: nfs-utils
---> Package libgssapi.i386 0:0.11-2.fc8 set to be updated
--> Finished Dependency Resolution
Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
libtirpc
Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
needed by package nfs-utils
Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
needed by package libtirpc
Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
nfs-utils

Was this planned for?
Even if everything is rebuilt against it, is this sufficient testing for 
  release?

Warren Togami
wtogami at redhat.com



From jkeating at redhat.com  Tue Oct 16 20:03:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 16:03:37 -0400
Subject: s/libgssapi/libgssglue/ now?
In-Reply-To: <471517E5.7040304@redhat.com>
References: <471517E5.7040304@redhat.com>
Message-ID: <20071016160337.44c8653f@redhat.com>

On Tue, 16 Oct 2007 15:58:29 -0400
Warren Togami <wtogami at redhat.com> wrote:

> First ever build of libgssglue which seems to replace libgssapi
> happened today, one day before the freeze of F8.  In addition to
> replacing libgssapi it seems to bump soname.

Hrm, when I was contacted about this I was told it was just a package
rename, not a soname rename too.  This is a much bigger change than I
expected.  With the freeze tomorrow and the sluggishness of koji lately
I'm reluctant to let this go through.

Steve?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/56a932b1/attachment.sig>

From dmc.fedora at filteredperception.org  Tue Oct 16 20:20:05 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Tue, 16 Oct 2007 15:20:05 -0500
Subject: Fedora caching suggestion
In-Reply-To: <6e24a8e80710161229s296c304q2c664843099957d4@mail.gmail.com>
References: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>	<20071016145240.GA1968@jadzia.bu.edu>
	<6e24a8e80710161229s296c304q2c664843099957d4@mail.gmail.com>
Message-ID: <47151CF5.8080407@filteredperception.org>

Mark wrote:
> 2007/10/16, Matthew Miller <mattdm at mattdm.org>:
>> On Mon, Oct 15, 2007 at 04:50:56PM +0200, Mark wrote:
>>> I've followed the discussion about readahead and it got disabled for
>>> Fedora 8 (it wasn't benefiting at all (at least not for me)). Now i
>>> wonder if it would be possible to pre cache the "all time using"
>>> programs? With "all time using" i mean all the programs that are gonna
>>> be started anyway and that are highly likely to be started. for gnome
>>> it would be at least the following:
>> Readahead can do that. And as you noted, it doesn't help much.
> 
> Well, readahead didn't seem to do a good job at it.. i wasn't noticing
> any changes with all the echo icons cached in the menu.. it still
> looked like the icons still had to be loaded (they didn't appear any
> faster at all and all icons where in the readahead list).

I have a hunch what you are describing might be the result of the menu 
stuff getting pushed out of cache.  Certainly the idea to pin/weight 
things like the menu stuff in cache must have been discussed before, 
though I couldn't immediately find such a thread via google.  I have 
vague memories of being annoyed by slow menus and googling and 
discovering that windows provides a method to tag some stuff in cache as 
more important, and thus less likely to be pushed out of cache.

-dmc




From jkeating at redhat.com  Tue Oct 16 20:44:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 16 Oct 2007 16:44:24 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016102448.6cc4af82@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
Message-ID: <20071016164424.327508c3@redhat.com>

On Tue, 16 Oct 2007 10:24:48 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal

I have updated this with a mockup Fedora 9 schedule following the new
development cycle.  I've also added some info as to why the pre-release
names have changed and added info regarding non-time based snapshot
releases.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071016/03cb0630/attachment.sig>

From chris.stone at gmail.com  Tue Oct 16 20:51:52 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 16 Oct 2007 13:51:52 -0700
Subject: nucleo version problem
In-Reply-To: <e1760170710160138o79031291g4c7d5228df6d8b95@mail.gmail.com>
References: <539333cb0710140203n6486b99eqac444d062065fb8b@mail.gmail.com>
	<d9c612bf0710151845vf07f538t2b32fafbd23aeac4@mail.gmail.com>
	<e1760170710160138o79031291g4c7d5228df6d8b95@mail.gmail.com>
Message-ID: <d9c612bf0710161351t412fa40as67f9fd6bd15f72fe@mail.gmail.com>

On 10/16/07, KH KH <kwizart at gmail.com> wrote:
> 2007/10/16, Christopher Stone <chris.stone at gmail.com>:
>
> > On 10/14/07, subhodip biswas <440volt.tux at gmail.com> wrote:
> > > Hi !
> > >
> > > I was thinking of packaging nucleo
> > > [ http://insitu.lri.fr/~roussel/projects/nucleo/]
> > > First ..Is anybody working on this already??
> > > Second... Nucleo comes in Nucleo-2007-XX-XX format. how to resolve this
> ??
> >
> > I packaged nucleo a while back and orphaned it, it should still be
> > there in CVS.  Others have worked on packaging it since, but nothing
> > has been officially added back to Fedora AFAIK.
>
>
> I don't know if it worth packaging nucleo for Fedora... May be possible but
> it will miss a dependency (ffmpeg)... Packaging Metisse seems harder since
> it will have the same problems as packaging XGL (as Metisse isn't modular as
> AIGLX - and use it owns fvwm that will conflict the Fedora version)...

I should also note that I currently maintain the xwnc package in
Fedora.  xwnc is part of metisse.  My patched version of xwnc is
functional on 64bit systems, and I should have a package in Fedora
that makes use of it within the coming weeks.



From pertusus at free.fr  Tue Oct 16 21:01:31 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 16 Oct 2007 23:01:31 +0200
Subject: Add to wishlist
In-Reply-To: <ff2scv$uud$1@ger.gmane.org>
References: <Pine.LNX.4.64.0710151922490.16362@sofie.homeip.net>
	<20071015204335.GB2790@free.fr> <ff2scv$uud$1@ger.gmane.org>
Message-ID: <20071016210131.GA2717@free.fr>

On Tue, Oct 16, 2007 at 03:29:03PM -0200, Thomas M Steenholdt wrote:
> Patrice Dumas wrote:
>> On Mon, Oct 15, 2007 at 07:32:49PM +0200, Peter ?strand wrote:
>>> * unfs3 - user-space NFSv3 server implementation
> Why not let the developers answer that question: 
> http://unfs3.sourceforge.net/

There is nothing on that page answering my question...

--
Pat



From debarshi.ray at gmail.com  Tue Oct 16 21:38:21 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 17 Oct 2007 03:08:21 +0530
Subject: PackageDB: mixed summary + description
In-Reply-To: <4712E208.5080206@gmail.com>
References: <3170f42f0710141254v1bae8e37hfcabf71e4df79fe8@mail.gmail.com>
	<4712E208.5080206@gmail.com>
Message-ID: <3170f42f0710161438o4c7373afv72bf756c9a147ef8@mail.gmail.com>

https://admin.fedoraproject.org/pkgdb/packages/name/archimedes

This one does not have the description stanza in PackageDB. Is this a
related issue and needs reporting? Or is it just that something has
not synced up yet?

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jon.nettleton at gmail.com  Tue Oct 16 21:58:48 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Tue, 16 Oct 2007 17:58:48 -0400
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <47150A93.2090608@redhat.com>
References: <1192559987.2807.3.camel@tiger> <47150A93.2090608@redhat.com>
Message-ID: <e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>

On 10/16/07, Zack Cerza <zcerza at redhat.com> wrote:
> Louis E Garcia II wrote:
> > when logging on I need to give gnome-keyring the password to unlock even
> > though I check it so it unlocks automatically. What gives?
> >
> > -Louis
>
>  From what I understand, the feature isn't complete and depends on [0].
> Matthias said in [1] that he removed the checkboxes until that work is
> finished.
>

We decided yesterday it would definitely be better to turn that off
rather than feel the wrath of thousands of people checking that box
and it not doing anything.  If you don't use a smart card reader or a
biometric authentication device, you can edit /etc/pam.d/gdm and move
the
auth line for pam_gnome_keyring above the system auth include.
However I take no responsibility for what it could possibly break in
the future ;-).

Jon



From orion at cora.nwra.com  Tue Oct 16 22:31:09 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 16 Oct 2007 16:31:09 -0600
Subject: What's up with octave-forge? - HELP WANTED
In-Reply-To: <4714C349.3060609@ieee.org>
References: <loom.20071016T132429-388@post.gmane.org>
	<4714C349.3060609@ieee.org>
Message-ID: <47153BAD.9090306@cora.nwra.com>


I'm currently building a new octave and octave-forge that should give us 
a working octave and octave packages for F8.  The octave-forge package 
ships Provides for all of the individual packages  in an attempt to make 
upgrading from octave-forge to the octave-packages work.  If anyone 
forsees any problems with this strategy, please let me know.   One 
concern is if we end up shipping fewer packages in F-9 than the current 
octave-forge package provides.

Where do we go from here (post-F8)?  Well, we need to start packaging 
all of the individual octave-forge provided packages individually. 
Currently there are 60 of them.  I have an initial packaging draft here:

http://fedoraproject.org/wiki/PackagingDrafts/Octave

that should be used when producing these packages.  We'll modify it as 
needed as issues arise, then once it seems good put it up for official 
status.

So, everyone out there who uses octave, pick a few packages that they 
use or like and submit them for review!

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From abartlet at samba.org  Tue Oct 16 22:35:38 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 17 Oct 2007 08:35:38 +1000
Subject: s/libgssapi/libgssglue/ now?
In-Reply-To: <20071016160337.44c8653f@redhat.com>
References: <471517E5.7040304@redhat.com> <20071016160337.44c8653f@redhat.com>
Message-ID: <1192574138.4206.3.camel@naomi>


On Tue, 2007-10-16 at 16:03 -0400, Jesse Keating wrote:
> On Tue, 16 Oct 2007 15:58:29 -0400
> Warren Togami <wtogami at redhat.com> wrote:
> 
> > First ever build of libgssglue which seems to replace libgssapi
> > happened today, one day before the freeze of F8.  In addition to
> > replacing libgssapi it seems to bump soname.
> 
> Hrm, when I was contacted about this I was told it was just a package
> rename, not a soname rename too.  This is a much bigger change than I
> expected.  With the freeze tomorrow and the sluggishness of koji lately
> I'm reluctant to let this go through.

The problem is that in both namespaces, libgssapi is a confusing name
for what is really just glue between the kernel and userspace, and not a
gssapi implementation.

Particularly when (in Fedora) libgssapi_krb5 is the mechglue library
provided by the MIT krb5 package, and elsewhere libgssapi is a name much
more traditionally associated (such as in Heimdal Kerberos) with real
GSSAPI implementations. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071017/3dc944c0/attachment.sig>

From buildsys at fedoraproject.org  Tue Oct 16 22:53:36 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue, 16 Oct 2007 18:53:36 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-16
Message-ID: <20071016225336.3AF2E15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 7

    mksh-31d-1.fc6
    plone-3.0.2-1.fc6
    postgresql-pgpool-3.4.1-1.fc6
    qt4-theme-quarticurve-0.0-0.5.beta4.fc6
    smolt-0.9.9-1.fc6
    xclip-0.10-1.fc6
    yum-cron-0.6-1.fc6


Changes in Fedora Extras 6: 


mksh-31d-1.fc6
--------------
* Mon Oct 15 2007 Robert Scheck <robert at fedoraproject.org> 31d-1
- Upgrade to 31d

plone-3.0.2-1.fc6
-----------------
* Tue Oct 16 2007 Jonathan Steffan <jon a fedoraunity.org> 3.0.2-1
- Update to Plone 3.0.2

postgresql-pgpool-3.4.1-1.fc6
-----------------------------
* Tue Oct 16 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4.1-1
- Update to 3.4.1

* Sun Aug 05 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4-2
- Added an init script for pgpool
- Added /etc/sysconfig/pgpool

* Wed Aug 01 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4-1
- Update to 3.4
- Removed patches, they are now in upstream

qt4-theme-quarticurve-0.0-0.5.beta4.fc6
---------------------------------------
* Mon Oct 15 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.5.beta4
- Update to beta 4 (updated readme, fixed QPushButton::iconSize being ignored).

* Wed Aug 22 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 0.0-0.4.beta3
- respin (BuildID)

* Fri Aug 03 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.3.beta3
- Specify GPL version in License tag.

smolt-0.9.9-1.fc6
-----------------
* Tue Oct 16 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9-1
- Upstream released new version

* Fri Sep 28 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.8.4-8
- Fixed Selinux

* Thu Sep 27 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.8.4-6
- Added translations

* Fri Sep 21 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.8.4-5
- Fixed firstboot issues

xclip-0.10-1.fc6
----------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.10-1
- bump to 0.10
- new URL

* Mon Aug 27 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.08-4
- license tag fix
- rebuild for BuildID

yum-cron-0.6-1.fc6
------------------
* Mon Oct 15 2007 Alec Habig <ahabig at umn.edu> - 0.6-1
- Fixes for bug 327401: checkonly formatting fix and make lockfile
  grabbing an atomic action using mkdir instead of touch
- Added downloadonly option (bug 333131)
- Don't update yum if set to checkonly (bug 333111)



From louisg00 at bellsouth.net  Tue Oct 16 23:04:11 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Tue, 16 Oct 2007 19:04:11 -0400
Subject: 1680 x 1050 with intel driver?
Message-ID: <1192575852.6439.13.camel@tiger>

I asked this question on the Xorg list:

The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
Integrated Graphics Controller (rev 03) with vga out. Can my video chip
power this monitor?

I got an answer that Xorg server-1.4 with the latest intel driver has
more chances of working with this setup. I know fedora 8 includes
server-1.3 with a bunch of back ports from 1.4. Will F8 work with this
setup?

-Thanks



From orion at cora.nwra.com  Tue Oct 16 23:08:19 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 16 Oct 2007 17:08:19 -0600
Subject: Looking for help with my packages
Message-ID: <47154463.5070108@cora.nwra.com>

I've acquired a moderately large stable of packages that is starting to 
consume too much of my time.  I'm looking for people interesting in 
either taking over or co-maintaining any of the following.  Don't worry, 
I won't be dropping anything in any case.


     * apcupsd -- APC UPS Power Control Daemon for Linux

     * cmake -- Cross-platform make system

     * environment-modules -- Provides dynamic modification of a user's 
environment

     * freefont -- Free UCS Outline Fonts

     * ftnchek -- Static analyzer for Fortran 77 programs

     * gdl -- GNU Data Language

     * gifsicle -- Powerful program for manipulating GIF images and 
animations

     * gocr -- GNU Optical Character Recognition program

     * gv -- A X front-end for the Ghostscript PostScript(TM) interpreter

     * hdf -- A general purpose library and file format for storing 
scientific data

     * hdf5 -- A general purpose library and file format for storing 
scientific data

     * kdesvn -- A subversion client for KDE

     * kompose -- Provides a full screen view of all open windows

     * ksynaptics -- KDE configuration for synaptics module

     * lasi -- C++ library for creating Postscript documents

     * libsynaptics -- Synaptics touchpad driver library

     * ncarg -- A Fortran and C based software package for scientific 
visualization

     * netcdf-decoders -- Converts WMO GRIB products into NetCDF files

     * netcdf-perl -- Perl extension module for scientific data access 
via the netCDF API

     * paraview -- Parallel visualization application

     * perl-Astro-FITS-CFITSIO -- Perl extension for using the cfitsio 
library

     * perl-Boulder -- An API for hierarchical tag/value structures

     * perl-Cflow -- Find flows in flow files

     * perl-Device-SerialPort -- Linux/POSIX emulation of 
Win32::SerialPort functions

     * perl-ExtUtils-F77 -- Simple interface to F77 libs

     * perl-HTML-Table -- Create HTML tables using simple interface

     * perl-Net-IP-CMatch -- Efficiently match IP addresses against IP 
ranges with C

     * perl-Net-Patricia -- Patricia Trie perl module for fast IP 
address lookups

     * perl-String-Approx -- Perl extension for approximate matching 
(fuzzy matching)

     * perl-XML-DOM -- DOM extension to XML::Parser

     * perl-XML-RegExp -- Regular expressions for XML tokens

     * plplot -- Library of functions for making scientific plots

     * python-basemap -- Plots data on map projections (with continental 
and political boundaries)

     * python-basemap-data -- Data for python-basemap

     * python-dateutil -- Powerful extensions to the standard datetime 
module

     * python-matplotlib -- Python plotting library

     * python-numarray -- Python array manipulation and computational 
library

     * pytz -- World Timezone Definitions for Python

     * R-multcomp -- Simultaneous inference for general linear 
hypotheses R Package

     * R-mvtnorm -- Multivariate normal and T distribution R Package

     * R-systemfit -- Simultaneous Equation Estimation R Package

     * ruby-mysql -- A Ruby interface to MySQL

     * wgrib -- Manipulate, inventory and decode GRIB files


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From buildsys at fedoraproject.org  Tue Oct 16 23:15:19 2007
From: buildsys at fedoraproject.org (Fedora Extras repoclosure)
Date: Tue, 16 Oct 2007 23:15:19 -0000
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
Message-ID: <20071016231519.3262.27912@extras64.linux.duke.edu>

======================================================================
The results in this summary consider Test Updates!
======================================================================
Summary of broken packages (by owner):

    andreas.bierfert AT lowlatency.de
        koffice-karbon - 1.6.2-3.fc7.i386    (61 days)
        koffice-kivio - 1.6.2-3.fc7.i386    (61 days)
        koffice-kspread - 1.6.2-3.fc7.i386    (61 days)

    bjohnson AT symetrix.com
        dbmail - 2.2.4-4.fc7.i386    (103 days)

    denis AT poolshark.org
        grig - 0.7.2-1.fc7.i386     
        grig - 0.7.2-1.fc7.ppc     
        grig - 0.7.2-1.fc7.x86_64     

    extras-orphan AT fedoraproject.org
        ktrack - 0.3.0-15.rc1.fc6.i386     
        ktrack - 0.3.0-15.rc1.fc6.ppc     
        ktrack - 0.3.0-15.rc1.fc6.x86_64     

    gauret AT free.fr
        glest-data - 2.0.0-2.fc7.noarch    (57 days)

    lxtnow AT gmail.com
        python-gammu - 0.20-1.fc7.i386    (74 days)
        python-gammu - 0.20-1.fc7.ppc    (74 days)
        python-gammu - 0.20-1.fc7.x86_64    (74 days)

    tcallawa AT redhat.com
        compat-wxGTK-devel - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.ppc    (92 days)
        compat-wxGTK-devel - 2.4.2-21.fc6.x86_64    (92 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.ppc    (92 days)
        compat-wxGTK-gl - 2.4.2-21.fc6.x86_64    (92 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.ppc    (92 days)
        compat-wxGTK-stc - 2.4.2-21.fc6.x86_64    (92 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.i386    (92 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.ppc    (92 days)
        compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64    (92 days)


======================================================================
Broken packages in fedora-7-i386:

    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-gl-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    ktrack-0.3.0-15.rc1.fc6.i386  requires  libhamlib-1.2.5.so.2


======================================================================
Broken packages in fedora-7-ppc:

    compat-wxGTK-devel-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.ppc  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-gl-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.ppc  requires  compat-wxGTK = 0:2.4.2-21.fc6
    glest-data-2.0.0-2.fc7.noarch  requires  glest = 0:2.0.0
    ktrack-0.3.0-15.rc1.fc6.ppc  requires  libhamlib-1.2.5.so.2


======================================================================
Broken packages in fedora-7-x86_64:

    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.i386  requires  libwx_gtk-2.4.so.0
    compat-wxGTK-devel-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-devel-2.4.2-21.fc6.x86_64  requires  libwx_gtk-2.4.so.0()(64bit)
    compat-wxGTK-gl-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-gl-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-stc-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.i386  requires  compat-wxGTK = 0:2.4.2-21.fc6
    compat-wxGTK-xrc-2.4.2-21.fc6.x86_64  requires  compat-wxGTK = 0:2.4.2-21.fc6
    dbmail-2.2.4-4.fc7.i386  requires  dbmail-database-driver = 0:2.2.4-4.fc7
    koffice-karbon-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7
    koffice-kivio-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7
    koffice-kspread-1.6.2-3.fc7.i386  requires  koffice-core = 0:1.6.2-3.fc7
    ktrack-0.3.0-15.rc1.fc6.x86_64  requires  libhamlib-1.2.5.so.2()(64bit)


======================================================================
Broken packages in fedora-updates-7-i386:

    grig-0.7.2-1.fc7.i386  requires  libhamlib-1.2.5.so.2
    python-gammu-0.20-1.fc7.i386  requires  libGammu.so.1


======================================================================
Broken packages in fedora-updates-7-ppc:

    grig-0.7.2-1.fc7.ppc  requires  libhamlib-1.2.5.so.2
    python-gammu-0.20-1.fc7.ppc  requires  libGammu.so.1


======================================================================
Broken packages in fedora-updates-7-x86_64:

    grig-0.7.2-1.fc7.x86_64  requires  libhamlib-1.2.5.so.2()(64bit)
    python-gammu-0.20-1.fc7.x86_64  requires  libGammu.so.1()(64bit)



From pertusus at free.fr  Tue Oct 16 23:14:54 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 17 Oct 2007 01:14:54 +0200
Subject: Looking for help with my packages
In-Reply-To: <47154463.5070108@cora.nwra.com>
References: <47154463.5070108@cora.nwra.com>
Message-ID: <20071016231454.GB2717@free.fr>

On Tue, Oct 16, 2007 at 05:08:19PM -0600, Orion Poplawski wrote:
>

I can be comaintainer of the following, though I don't have that much
time and I also have quite a lot of packages:

>     * cmake -- Cross-platform make system
>     * ftnchek -- Static analyzer for Fortran 77 programs
>     * gocr -- GNU Optical Character Recognition program
>     * gv -- A X front-end for the Ghostscript PostScript(TM) interpreter
>     * hdf5 -- A general purpose library and file format for storing 
> scientific data
>     * ncarg -- A Fortran and C based software package for scientific 
> visualization
>     * netcdf-decoders -- Converts WMO GRIB products into NetCDF files
>     * netcdf-perl -- Perl extension module for scientific data access via 
> the netCDF API
>     * paraview -- Parallel visualization application
>     * wgrib -- Manipulate, inventory and decode GRIB files

I am already comaintainer, but the more the better:
>     * hdf -- A general purpose library and file format for storing 
> scientific data

--
Pat



From devrim at CommandPrompt.com  Tue Oct 16 23:16:29 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Tue, 16 Oct 2007 16:16:29 -0700
Subject: Want to get PostgreSQL related packages out of the door
Message-ID: <1192576589.7950.37.camel@localhost.localdomain>

Hi,

I have some packages (all of them are PostgreSQL related) waiting for
review. I also have a few of them which are waiting for submission.

All of them are upstream packages, and being used for some time. Also
some packages, like postgresql-plr and postgresql-ip4r requires very
little work to review...

Since I want to concentrate on packaging more stuff for PostgreSQL, I'd
like to get all of my packages out of Fedora's door.

So, I need reviewers for those packages. Any volunteers?

Regards,
-- 
Devrim G?ND?Z
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.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/20071016/8363e6de/attachment.sig>

From jspaleta at gmail.com  Tue Oct 16 23:23:08 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 16 Oct 2007 15:23:08 -0800
Subject: Looking for help with my packages
In-Reply-To: <47154463.5070108@cora.nwra.com>
References: <47154463.5070108@cora.nwra.com>
Message-ID: <604aa7910710161623s509addfcvc290dbc6fb40a8ac@mail.gmail.com>

On 10/16/07, Orion Poplawski <orion at cora.nwra.com> wrote:
>      * python-basemap -- Plots data on map projections (with continental
> and political boundaries)
>
>      * python-basemap-data -- Data for python-basemap
>
>      * python-dateutil -- Powerful extensions to the standard datetime
> module
>
>      * python-matplotlib -- Python plotting library
>
>      * python-numarray -- Python array manipulation and computational
> library
>
>      * pytz -- World Timezone Definitions for Python

I'm going to have to take all of these over.  Most of this stuff is
associated with matplotlib. Is there anything currently which needs
python-numarray? Does it do anything that numpy doesn't take care of
now?  I might decide to let this one expire if its there only for
backwards compatibility.

-jef



From otto_rey at yahoo.com.ar  Tue Oct 16 23:30:12 2007
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Tue, 16 Oct 2007 16:30:12 -0700 (PDT)
Subject: Anybody see my wine 0.9.47???
Message-ID: <358207.61361.qm@web52411.mail.re2.yahoo.com>

I'm looking on Andreas Bierfert wine wiki (http://fedoraproject.org/wiki/AndreasBierfert/Wine), but i can't find wine 0.9.47 in updates-testing or in updates-testing-source (Fedora 7). Is there any schedule to sync testing repos with new packages?

Thanks a lot




      Las ?ltimas noticias sobre el Mundial de Rugby 2007 est?n en Yahoo! Deportes. ?Conocelas!
http://ar.sports.yahoo.com/mundialderugby



From denis at poolshark.org  Tue Oct 16 23:31:11 2007
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 17 Oct 2007 01:31:11 +0200
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates
	-	2007-10-16
In-Reply-To: <20071016231519.3262.27912@extras64.linux.duke.edu>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
Message-ID: <471549BF.6010109@poolshark.org>

Fedora Extras repoclosure wrote:
>     denis AT poolshark.org
>         grig - 0.7.2-1.fc7.i386     
>         grig - 0.7.2-1.fc7.ppc     
>         grig - 0.7.2-1.fc7.x86_64

Build is pending.

> 
>     extras-orphan AT fedoraproject.org
>         ktrack - 0.3.0-15.rc1.fc6.i386     
>         ktrack - 0.3.0-15.rc1.fc6.ppc     
>         ktrack - 0.3.0-15.rc1.fc6.x86_64     

Caused by my hamlib update, but ktrack is an orphaned package, and I'm 
not interested in maintaining it. What's the way to go here ?
May I do a one-time rebuild of ktrack for F-7 only ?



From peter at thecodergeek.com  Tue Oct 16 23:38:49 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 16 Oct 2007 16:38:49 -0700
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates
	-	2007-10-16
In-Reply-To: <471549BF.6010109@poolshark.org>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
Message-ID: <1192577929.3409.20.camel@localhost.localdomain>

On Wed, 2007-10-17 at 01:31 +0200, Denis Leroy wrote:
> >     extras-orphan AT fedoraproject.org
> >         ktrack - 0.3.0-15.rc1.fc6.i386     
> >         ktrack - 0.3.0-15.rc1.fc6.ppc     
> >         ktrack - 0.3.0-15.rc1.fc6.x86_64     
> 
> Caused by my hamlib update, but ktrack is an orphaned package, and I'm 
> not interested in maintaining it. What's the way to go here ?
> May I do a one-time rebuild of ktrack for F-7 only ?

As an orphaned package I think it's best to remove it from the repos
entirely. It has no active maintainer in Fedora and according to their
website, upstream seems to have died more than one year ago.

However, if you want to temporarily take ownership of it just to push an
updated build, please be aware that a rebuild against new libraries can
sometimes cause weird and crazy bugs to arise from the updated libs,
depending on API/ABI usage and such, especially if the code depends on
various quirks or tweaks in the library which have since been fixed or
removed.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071016/d8c320df/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Tue Oct 16 23:41:09 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 17 Oct 2007 01:41:09 +0200
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
 2007-10-16
In-Reply-To: <471549BF.6010109@poolshark.org>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
Message-ID: <20071017014109.a19a2692.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 17 Oct 2007 01:31:11 +0200, Denis Leroy wrote:

> >     extras-orphan AT fedoraproject.org
> >         ktrack - 0.3.0-15.rc1.fc6.i386     
> >         ktrack - 0.3.0-15.rc1.fc6.ppc     
> >         ktrack - 0.3.0-15.rc1.fc6.x86_64     
> 
> Caused by my hamlib update, but ktrack is an orphaned package, and I'm 
> not interested in maintaining it. What's the way to go here ?
> May I do a one-time rebuild of ktrack for F-7 only ?
 
It's orphaned, still offered in F7, not included in rawhide, but still
available in CVS. What are FESCo's latest words on orphans?



From katzj at redhat.com  Tue Oct 16 22:08:40 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 16 Oct 2007 18:08:40 -0400
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <20071016164424.327508c3@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
	<20071016164424.327508c3@redhat.com>
Message-ID: <1192572520.23960.0.camel@localhost.localdomain>

On Tue, 2007-10-16 at 16:44 -0400, Jesse Keating wrote:
> On Tue, 16 Oct 2007 10:24:48 -0400
> Jesse Keating <jkeating at redhat.com> wrote:
> 
> > http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal
> 
> I have updated this with a mockup Fedora 9 schedule following the new
> development cycle.  I've also added some info as to why the pre-release
> names have changed and added info regarding non-time based snapshot
> releases.

And if we can get better information on when features are landing, we
can try to line up some of these snapshots with specific features
landing

Jeremy



From denis at poolshark.org  Wed Oct 17 00:01:08 2007
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 17 Oct 2007 02:01:08 +0200
Subject: Summary - Broken dependencies in Fedora 7 + Test
	Updates	-	2007-10-16
In-Reply-To: <1192577929.3409.20.camel@localhost.localdomain>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
Message-ID: <471550C4.5090704@poolshark.org>

Peter Gordon wrote:
> On Wed, 2007-10-17 at 01:31 +0200, Denis Leroy wrote:
>>>     extras-orphan AT fedoraproject.org
>>>         ktrack - 0.3.0-15.rc1.fc6.i386     
>>>         ktrack - 0.3.0-15.rc1.fc6.ppc     
>>>         ktrack - 0.3.0-15.rc1.fc6.x86_64     
>> Caused by my hamlib update, but ktrack is an orphaned package, and I'm 
>> not interested in maintaining it. What's the way to go here ?
>> May I do a one-time rebuild of ktrack for F-7 only ?
> 
> As an orphaned package I think it's best to remove it from the repos
> entirely. It has no active maintainer in Fedora and according to their
> website, upstream seems to have died more than one year ago.
> 
> However, if you want to temporarily take ownership of it just to push an
> updated build, please be aware that a rebuild against new libraries can
> sometimes cause weird and crazy bugs to arise from the updated libs,
> depending on API/ABI usage and such, especially if the code depends on
> various quirks or tweaks in the library which have since been fixed or
> removed.

There's a risk yes, but it's easy enough to test I think. If the app 
seems healthy, I'd go ahead and do a rebuild so that I least we don't 
break the updates of people who have ktrack already installed. Removing 
it from the repo wouldn't solve their problem.




From jima at beer.tclug.org  Wed Oct 17 00:02:42 2007
From: jima at beer.tclug.org (Jima)
Date: Tue, 16 Oct 2007 19:02:42 -0500 (CDT)
Subject: Looking for help with my packages
In-Reply-To: <47154463.5070108@cora.nwra.com>
References: <47154463.5070108@cora.nwra.com>
Message-ID: <Pine.LNX.4.64.0710161901090.4486@beer.tclug.org>

On Tue, 16 Oct 2007, Orion Poplawski wrote:
>    * perl-Device-SerialPort -- Linux/POSIX emulation of Win32::SerialPort 
> functions

  I maintained this in my personal repo before you got it into Fedora, so 
I'm willing to step up as a comaintainer. :-)
  Not really too familiar with any of the others. :-|

      Jima



From rodd at clarkson.id.au  Wed Oct 17 00:09:09 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 17 Oct 2007 10:09:09 +1000
Subject: rawhide report: 20071016 changes
In-Reply-To: <645d17210710160512q78871b4axfeda0177f0b5ae6@mail.gmail.com>
References: <200710161035.l9GAZlkK020129@porkchop.devel.redhat.com>
	<1192535269.12333.1.camel@localhost.localdomain>
	<645d17210710160512q78871b4axfeda0177f0b5ae6@mail.gmail.com>
Message-ID: <1192579759.13945.3.camel@localhost.localdomain>


On Tue, 2007-10-16 at 13:12 +0100, Jonathan Underwood wrote:
> On 16/10/2007, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> >
> > On Tue, 2007-10-16 at 06:35 -0400, Build System wrote:
> >
> > > rpcbind-0.1.4-9.fc8
> > > -------------------
> > > * Mon Oct 15 2007 Steve Dickson <steved at redhat.com> 0.1.4-9
> > > - Fixed typo in Summary (bz 331811)
> > > - Corrected init script (bz 247046)
> >
> > Cleanup   : rpcbind                      ##################### [ 91/138]
> >   Cleanup   : kudzu                        ##################### [ 92/138]
> > error: %postun(rpcbind-0.1.4-8.fc8.i386) scriptlet failed, exit status 6
> >   Cleanup   : perl-libs                    ##################### [ 93/138]
> >
> >
> 
> Please file a Bugzilla - there's no guarantee that the maintainer will
> spot your problem report buried in this thread.

bz'd: https://bugzilla.redhat.com/show_bug.cgi?id=335491


R.


-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jspaleta at gmail.com  Wed Oct 17 00:22:05 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 16 Oct 2007 16:22:05 -0800
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
In-Reply-To: <471550C4.5090704@poolshark.org>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
Message-ID: <604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>

On 10/16/07, Denis Leroy <denis at poolshark.org> wrote:
> There's a risk yes, but it's easy enough to test I think. If the app
> seems healthy, I'd go ahead and do a rebuild so that I least we don't
> break the updates of people who have ktrack already installed. Removing
> it from the repo wouldn't solve their problem.

Gee that sounds suspiciously like you're offering to maintain this package.

I don't think just one-off rebuilding it "solves" the problem either.

What we really really need in these sorts of situation is have
client-side notice that a package has been orphaned/expired via the
package management tools, letting all users of that package know via
their repository aware tools that the package is orphaned/removed and
will no longer be receiving updates unless a maintainer shows up. At
which point the users can choose to uninstall the package or perhaps
step up and offer to be the maintainer of it.  I think users of
orphaned packages deserve a chance to state an interest in maintaining
packages when they get orphaned/removed. If we are only announcing
orphaned status in channels that other current contributors are
watching we are sacrificing an opportunity to add contributors to
spread the workload around.

-jef"Of course it'd help if we had a mentored probational contributor
period for users who want to take over orphaned packages in lieu of
the standard package submission review/sponsorship process"spaleta



From wtogami at redhat.com  Wed Oct 17 03:29:05 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 16 Oct 2007 23:29:05 -0400
Subject: s/libgssapi/libgssglue/ now?
In-Reply-To: <20071016160337.44c8653f@redhat.com>
References: <471517E5.7040304@redhat.com> <20071016160337.44c8653f@redhat.com>
Message-ID: <47158181.7020009@redhat.com>

Jesse Keating wrote:
> On Tue, 16 Oct 2007 15:58:29 -0400
> Warren Togami <wtogami at redhat.com> wrote:
> 
>> First ever build of libgssglue which seems to replace libgssapi
>> happened today, one day before the freeze of F8.  In addition to
>> replacing libgssapi it seems to bump soname.
> 
> Hrm, when I was contacted about this I was told it was just a package
> rename, not a soname rename too.  This is a much bigger change than I
> expected.  With the freeze tomorrow and the sluggishness of koji lately
> I'm reluctant to let this go through.
> 
> Steve?
> 
> 

Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
libtirpc
Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
needed by package nfs-utils
Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
needed by package libtirpc
Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
nfs-utils

No answer, and 11:25pm with tomorrow's rawhide still with broken deps. 
Given the serious need for a working and installable rawhide tree I 
think I will untag the package.  We can sort this out in the morning.

Warren Togami
wtogami at redhat.com



From wtogami at redhat.com  Wed Oct 17 03:33:50 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 16 Oct 2007 23:33:50 -0400
Subject: Untagged libgssglue Re: s/libgssapi/libgssglue/ now?
In-Reply-To: <47158181.7020009@redhat.com>
References: <471517E5.7040304@redhat.com> <20071016160337.44c8653f@redhat.com>
	<47158181.7020009@redhat.com>
Message-ID: <4715829E.8050800@redhat.com>

Warren Togami wrote:
> Jesse Keating wrote:
>> On Tue, 16 Oct 2007 15:58:29 -0400
>> Warren Togami <wtogami at redhat.com> wrote:
>>
>>> First ever build of libgssglue which seems to replace libgssapi
>>> happened today, one day before the freeze of F8.  In addition to
>>> replacing libgssapi it seems to bump soname.
>>
>> Hrm, when I was contacted about this I was told it was just a package
>> rename, not a soname rename too.  This is a much bigger change than I
>> expected.  With the freeze tomorrow and the sluggishness of koji lately
>> I'm reluctant to let this go through.
>>
>> Steve?
>>
>>
> 
> Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
> libtirpc
> Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
> needed by package nfs-utils
> Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2)(64bit) is 
> needed by package libtirpc
> Error: Missing Dependency: libgssapi.so.2()(64bit) is needed by package 
> nfs-utils
> 
> No answer, and 11:25pm with tomorrow's rawhide still with broken deps. 
> Given the serious need for a working and installable rawhide tree I 
> think I will untag the package.  We can sort this out in the morning.
> 
> Warren Togami
> wtogami at redhat.com
> 

I have untagged libgssglue-0.1-2.fc8 because it will cause breakage in 
tonight's rawhide build that we cannot afford during this critical time. 
    Please communicate with Fedora rel-eng on Wednesday regarding this 
package.

Warren Togami
wtogami at redhat.com



From wtogami at redhat.com  Wed Oct 17 03:39:02 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 16 Oct 2007 23:39:02 -0400
Subject: Small Fonts in Firefox and Thunderbird
Message-ID: <471583D6.6070904@redhat.com>

I upgraded to some package built during Tuesday (should be in 
Wednesday's rawhide) that suddenly changed the menu and dialog fonts in 
both Firefox and Thunderbird.  In Thunderbird the fonts of the title 
bar, menus, mail listings, To, From all became smaller and difficult to 
read.  The font size and appearance within reading e-mail and composer 
hasn't changed.  In Firefox the menus and URL bar became similarly 
small, while web pages haven't changed in appearance.

I'm guessing some font rendering thing changed?
Was this intentional or a bug?

Warren Togami
wtogami at redhat.com



From tmz at pobox.com  Wed Oct 17 03:56:27 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 16 Oct 2007 23:56:27 -0400
Subject: libgpod update for Fedora 7
Message-ID: <20071017035627.GC596@psilocybe.teonanacatl.org>

Hi all,

I'd like to (finally) update libgpod to 0.5.2 for F-7.  I'll rebuild
the needed packages[1] and push them to -testing so no one else has to
do anymore work.  Please speak up if that isn't alright.  If not, I'd
like to do this late Wednesday evening (EDT) or Thursday.

(And no spot, this isn't the libgpod with the code to work with newer
iPod's.  It's just the same version that's been in devel for a while.
But let me know if you've heard anything from legal on the new code.)

[1] Packages that need a rebuild: amarok, gtkpod, kipi-plugins,
quodlibet, and rhythmbox.  If I've missed any, please let me know.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For a list of all the ways technology has failed to improve the
quality of life, please press three.
    -- Alice Kahn, writer

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

From jeff at ocjtech.us  Wed Oct 17 05:42:39 2007
From: jeff at ocjtech.us (Jeffrey C. Ollie)
Date: Wed, 17 Oct 2007 00:42:39 -0500
Subject: libgpod update for Fedora 7
In-Reply-To: <20071017035627.GC596@psilocybe.teonanacatl.org>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
Message-ID: <1192599759.10684.0.camel@lt21223.campus.dmacc.edu>

On Tue, 2007-10-16 at 23:56 -0400, Todd Zullinger wrote:
> 
> I'd like to (finally) update libgpod to 0.5.2 for F-7.  I'll rebuild
> the needed packages[1] and push them to -testing so no one else has to
> do anymore work.  Please speak up if that isn't alright.  If not, I'd
> like to do this late Wednesday evening (EDT) or Thursday.
> 
> [1] Packages that need a rebuild: amarok, gtkpod, kipi-plugins,
> quodlibet, and rhythmbox.  If I've missed any, please let me know.

Fine by me...

Jeff
-------------- 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/20071017/9c7dfd9b/attachment.sig>

From fedora at leemhuis.info  Wed Oct 17 05:55:28 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 17 Oct 2007 07:55:28 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016133828.1a1c4cb5@redhat.com>
References: <20071016102448.6cc4af82@redhat.com> <4714F153.202@leemhuis.info>
	<20071016133828.1a1c4cb5@redhat.com>
Message-ID: <4715A3D0.4000109@leemhuis.info>

On 16.10.2007 19:38, Jesse Keating wrote:
> On Tue, 16 Oct 2007 19:13:55 +0200
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> I think having a "it is installable" as defined goal way more often
>> would be good. Every Friday maybe?
>> Further: both Opensuse and Ubuntu have way more betas/rcs. I don't
>> think we should follow that model completely, but maybe we can steal
>> ideas from it? A installable rawhide snapshot every two weeks maybe
>> (as ISO or as second dir (files hardlinked to rawhide) on the
>> servers?)
>> Just thinking aloud.
> While it wasn't stated in the proposal, and I should add it, we
> definitely want to do more "snapshot" like releases for testing, like
> what Jeremy has been doing with rawhide live snapshots. [...]

k, thx

>>> [...]
>>> === Release Candidate and Final release ===
>>> In order to prepare the release candidate(s) and the final release a
>>> final freeze is needed.  It is at this point that we would block
>>> rawhide once again.  It is extremely important that we have as many
>>> eyes on the bits as possible to make our release as best as we
>>> can.  This freeze point is also the point in which we would create
>>> any remaining needed branches in CVS for the release.  Any builds
>>> from the branch would be held in an updates candidate tag to be
>>> potential updates for after the release, or to be pulled in to the
>>> release by request.  Builds from devel/ would be tagged for the
>>> next release tag to show up in rawhide once the next development
>>> cycle starts.   
>> Sounds to complicated and much of a "to much of a slowdown/next to
>> full stop" to me.
> Well it pretty much is.

That's IMHO a problem -- the world rotates. Sure, it's not that bad to
let it rotating for a week, stop Fedora then try to catch up. But I'd
say it becomes really problematic when it's more then a week.

>  We have to stop changes in order to finalize
> the release and get it out the door.

A week IMHO should suffice. If it doesn't I'd say we need more point in
the middle to bring rawhide at least in a better shape beforehand.

> [...]
>> Normal, non-critical
>> updates for the release (once it happens) stay updates candidates and
>> thus don't get much tested either.
> They can be pushed to updates-testing at the 0day mark and thus get
> testing there.

Depends on how much lands into updates-testing over those weeks (and how
many weeks we are taking of; three to four afaics). IOW: it IMHO looks
bad to do a release and have more than <n> updates in updates-proper and
<n> in updates testing (<n> something like 10 or 20 each in both cases).

>> Some packagers will thus likely just push their updates into the
>> current release without testing them in rawhide first. 
> But rawhide isn't the place to test them,

Sure it is -- at least for me. Here is what I do when I get a new
upstream release in Fedora:

- test locally (but that's of course always limited, as apps get used
differently by different people)
- update cvs for devel and build for rawhide, as rawhide users are those
that won't yell to much if upstream released something new with multiple
bugs in it
- leave it there -- depending how crucial the package is for a few days
a week some weeks
- if nothing bad turned up in rawhide (e.g. if the new upstream release
didn't contain any new bugs) I ship it in F7 updates-testing for some days
- if nothing bad turns up move it to F7 updates proper
- if that package would be of interest for F6 I would put it in
updates-testing for F6 at this point (if one would exist)
- if nothing bad turned some days later up push to F6 updates proper

Shipping a update in multiple branches at the same time or in F7 earlier
then in rawhide (because it is blocked for release) seems like a bad
idea to me (I know, that's the standard behavior for a lot of people) --
if upstream got a bad bug in it all our users are effected by it and
that can easily be prevented by above scheme.

>> That's bad in
>> general already; but it's even more bad here, as it also create
>> EVR-update troubles once the release is done.
> How can it create EVR-update troubles?  Only if maintainers push
> updates to previous releases before pushing them for the pending
> release, and even so this is not a new problem, as updates to previous
> releases happen all the time while the release is a static package set
> that quickly has "lower" nvrs than the fully updated previous release.
> Not a new problem, [...]

No, but with the new scheme it becomes bigger afaics.

>>> In order to accommodate a
>>> release candidate set plus the final release creation the freeze
>>> point for this should happen between the current Test3 dates and
>>> the final deep freeze dates.  
>> This proposal would IMHO be a bit easier to understand if you could
>> write a potential F9 schedule with release, freeze and branching
>> dates.
> I can add some example dates, but they shouldn't be counted on until
> the Board and FESCo et al set the schedule.

thx for doing that!

> [...]
>> Yes, sure, I know out mirrors are important, but not that important to
>> delay the release that 5 days when the test window is four weeks (the
>> usual cycle we had between test releases up to now).
> That puts an extreme pressure on the mirrors that I'd not like to do.
> We've frequently seen feedback from them that if we just do torrent
> first and delay the mirrors that they'd just as likely stop mirroring
> us which doesn't help anybody.  The only /real/ way to get releases out
> there quicker is to not have unstable trees all the time.

I strongly disagree with the "only" in that sentence. OpenSuse and
Ubuntu afaics seem to get their test-release out way more quickly. We
should be as well for *test*releases. For the final, yeah, the old
behavior might fine. I'd say most mirror admins will understand that we
need to get test releases out more quickly.

>> Further: I know multiple people that don't run rawhide because we
>> always tell everyone "once rawhide always rawhide"
> Where exactly do "we" tell everyone this?

It's in peoples heads afaics and they mention it on the list if
questions come up "can I run a test release and later the final without
reinstalling?" -> "No".

Of did we document somewhere in between how to switch from rawhide to
release before rawhide moves on? If yes please point me to, then I'll
blog about it to get the old scheme out of peoples head.

>> and "rawhide easts
>> babies". That' IMHO are our biggest problems. Thus i suggest:
>> - work hard to make rawhide not eat babies and kill kittens in the 5
>> weeks approaching a release. Tell the developers so they are more
>> careful during that timeframe (e.g. as careful as they would be for a
>> update for a released version) and send ninjas if they are not.
> Why 5 weeks, why not just all the time?

Well, that's what we tried. Seemed it didn't work to well -- see for
example OpenEXR.

>> - we need a way for testers that want to test the release that they
>> want to continue to run afterwards without reinstalling it. Two ideas
>> follow, I think we should do both:
>> (1.) support and document the "rawhide -> stable" way -- e.g. at the
>> point where rawhide on the servers becomes targeting the next Fedora
>> version give users the choice "Do you want to continue using rawhide
>> or stick to the release that is happening now?".
> Not sure how to "give them the choice"

Yum-Plugin? Or something that disables all repos and asks which ones to
activate again: rawhide or release.

> but we certainly can document
> how to switch to the final release. 

thx -- in the past it seemed that was discouraged.

> A good "Using Rawhide" page would
> list this, and would fall inline with the other changes we want to make
> to lead to rawhide being easier and more friendly to use (and thus more
> used).

Sounds good. But it's nevertheless easy to miss the point, and then you
have a problem.

>> (2.) create a "Fedora <N> Early Adapters Release (EAR)"  which uses
>> the final directory structure and a Release for "early adapters".
>> E.g. what I mean is something like this:
>>
>> T-30 days before official release
>>  * publish a test3 (or call it RC if you like)
>>  * hard free for rawhide -- just like the two/three lasts week before
>> the release now
>>
>> T-18 days before official release
>>  * branch rawhide and release;
>>  * create the final directory structure on the servers with what's in
>> rawhide
>>  * create and publish "Fedora <N> Early Adapters Release (EAR)" from
>> that tree; its yum  configs point to that tree and not to rawhide
>>  * open rawhide for release +1 -- rawhide users had enough time to
>> report bugs; they won't find any new bugs anymore, thus we need a
>> different kind of testers now which we get with that Fedora <N> EAR
>>
>> T-18 until T-7 days
>> * fix important stuff only like we in the past often did in the first
>> ten days after a Fedora release; ship that as updates
>>
>> T-7 days
>> * respin the tree  on the servers, including all updates that happened
>> over the past 10 days
>>
>> T-4 days
>> * prepare the final release
>>
>> T-0
>> * release
>>
>> = EOF =
>>
>> Just my 2 cent.
> 
> I had thought about this too.  It is challenging from an infrastructure
> standpoint to manage the bits in this way, due to the permissions
> typically on the release directories.  However it's not impossible and
> could be a solution to the "second rawhide" type thing.  I'm certainly
> open to discussing this more, but I'm not comfortable adding it to the
> proposal just yet.

thx for considering something like this.

CU
knurd



From sundaram at fedoraproject.org  Wed Oct 17 06:22:23 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 17 Oct 2007 12:52:23 +0630
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4715A3D0.4000109@leemhuis.info>
References: <20071016102448.6cc4af82@redhat.com>
	<4714F153.202@leemhuis.info>	<20071016133828.1a1c4cb5@redhat.com>
	<4715A3D0.4000109@leemhuis.info>
Message-ID: <4715AA1F.8010109@fedoraproject.org>

Thorsten Leemhuis wrote:

> It's in peoples heads afaics and they mention it on the list if
> questions come up "can I run a test release and later the final without
> reinstalling?" -> "No".

This is slowly getting changed. For Fedora 7, there was some effort into 
providing a "supported" path from Fedora 7 test 3 to the general 
release. This could certainly be changed to cover all the test releases 
with some more testing and proper messaging.

> Of did we document somewhere in between how to switch from rawhide to
> release before rawhide moves on? If yes please point me to, then I'll
> blog about it to get the old scheme out of peoples head.

http://fedoraproject.org/wiki/YumUpgradeFaq

Feel free to add any missing information. It should be easier to switch 
to and away from rawhide though.

Rahul



From fedora at leemhuis.info  Wed Oct 17 06:43:24 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 17 Oct 2007 08:43:24 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4715AA1F.8010109@fedoraproject.org>
References: <20071016102448.6cc4af82@redhat.com>	<4714F153.202@leemhuis.info>	<20071016133828.1a1c4cb5@redhat.com>	<4715A3D0.4000109@leemhuis.info>
	<4715AA1F.8010109@fedoraproject.org>
Message-ID: <4715AF0C.1000401@leemhuis.info>

On 17.10.2007 08:22, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
> [...]
>> Of did we document somewhere in between how to switch from rawhide to
>> release before rawhide moves on? If yes please point me to, then I'll
>> blog about it to get the old scheme out of peoples head.
>
> http://fedoraproject.org/wiki/YumUpgradeFaq
> Feel free to add any missing information. It should be easier to switch 
> to and away from rawhide though.

That page talks about updating from F<n> -> F<(n+(1|2))>, not how to
disable rawhide before it moves on ;-)

Cu
knurd

P.S.: The YumUpgradeFaq likely should contain some general informations
about the yum shell, as that makes thing like this possible:

$ yum shell
update
remove dbus.i386
run

I needed exactly that some minutes ago when updating a machine to
rawhide, you could not do "$ yum remove dbus.i386; yum update", as
installed packages still depended on dbus.i386 (which doesn#t exist
anymore in rawhide iirc)

I'll see if I can add a few words about the benefits of the shell there
over the next few days...



From sundaram at fedoraproject.org  Wed Oct 17 06:48:26 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 17 Oct 2007 13:18:26 +0630
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4715AF0C.1000401@leemhuis.info>
References: <20071016102448.6cc4af82@redhat.com>	<4714F153.202@leemhuis.info>	<20071016133828.1a1c4cb5@redhat.com>	<4715A3D0.4000109@leemhuis.info>	<4715AA1F.8010109@fedoraproject.org>
	<4715AF0C.1000401@leemhuis.info>
Message-ID: <4715B03A.707@fedoraproject.org>

Thorsten Leemhuis wrote:
> On 17.10.2007 08:22, Rahul Sundaram wrote:
>> Thorsten Leemhuis wrote:
>> [...]
>>> Of did we document somewhere in between how to switch from rawhide to
>>> release before rawhide moves on? If yes please point me to, then I'll
>>> blog about it to get the old scheme out of peoples head.
>> http://fedoraproject.org/wiki/YumUpgradeFaq
>> Feel free to add any missing information. It should be easier to switch 
>> to and away from rawhide though.
> 
> That page talks about updating from F<n> -> F<(n+(1|2))>, not how to
> disable rawhide before it moves on ;-)

> anymore in rawhide iirc)
> 
> I'll see if I can add a few words about the benefits of the shell there
> over the next few days...

Those are the sort of missing information that can be added by anyone. 
It beats the discussions.

Rahul




From nicolas.mailhot at laposte.net  Wed Oct 17 07:11:15 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 17 Oct 2007 09:11:15 +0200 (CEST)
Subject: Looking for help with my packages
Message-ID: <32882.192.54.193.51.1192605075.squirrel@rousalka.dyndns.org>


Le Mer 17 octobre 2007 01:08, Orion Poplawski a ?crit :
> I've acquired a moderately large stable of packages that is starting
> to
> consume too much of my time.  I'm looking for people interesting in
> either taking over or co-maintaining any of the following.
>
>      * freefont -- Free UCS Outline Fonts

Post this one on the fonts list


-- 
Nicolas Mailhot



From jcm at redhat.com  Wed Oct 17 07:34:45 2007
From: jcm at redhat.com (Jon Masters)
Date: Wed, 17 Oct 2007 03:34:45 -0400
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <20071016102448.6cc4af82@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
Message-ID: <1192606486.4204.167.camel@perihelion>


On Tue, 2007-10-16 at 10:24 -0400, Jesse Keating wrote:
> The rel-eng team in conjunction with FESCo has developed a proposal for
> changing the development cycle of Fedora.  The goals are to disrupt
> development less frequently, make it easier for maintainers to get
> fixes in, and make it easier for future work to happen without risking
> disruption of a release in progress.

My number one pet peeve with how Fedora development works is that
there's no equivalent of the "testing" Debian release. It's one of the
things that I *really* think they get right, and we don't.

Personally, I'd bite the bullet and adopt an interim release methodology
so there's always a week-two week lag behind "known good" base platform
that can be used to do most package tests without worrying something
unrelated has broken today, or the whole thing won't install, or...

But that's just me ;-)

Jon.




From tsmetana at redhat.com  Wed Oct 17 07:52:06 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Wed, 17 Oct 2007 09:52:06 +0200
Subject: Looking for help with my packages
In-Reply-To: <47154463.5070108@cora.nwra.com>
References: <47154463.5070108@cora.nwra.com>
Message-ID: <20071017095206.e0eb2b3e.tsmetana@redhat.com>

Hello.

Since I maintain NUT I can help you with this one.  Even take it over.
>      * apcupsd -- APC UPS Power Control Daemon for Linux

I would be interested in this one as well (maintain/co-maintain):
>      * gocr -- GNU Optical Character Recognition program

Regards.

-- 
Tom?? Smetana
Base OS Software Engineer, Red Hat
RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel



From bruno at wolff.to  Wed Oct 17 08:05:54 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 17 Oct 2007 03:05:54 -0500
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <358207.61361.qm@web52411.mail.re2.yahoo.com>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
Message-ID: <20071017080554.GA13285@wolff.to>

On Tue, Oct 16, 2007 at 16:30:12 -0700,
  Otto Rey <otto_rey at yahoo.com.ar> wrote:
> I'm looking on Andreas Bierfert wine wiki (http://fedoraproject.org/wiki/AndreasBierfert/Wine), but i can't find wine 0.9.47 in updates-testing or in updates-testing-source (Fedora 7). Is there any schedule to sync testing repos with new packages?

There is typically a bit of delay before new wine packages show up.
Someitmes particular releases get skipped. (I don't why; that's just what
I have observed.)



From markg85 at gmail.com  Wed Oct 17 08:34:07 2007
From: markg85 at gmail.com (Mark)
Date: Wed, 17 Oct 2007 10:34:07 +0200
Subject: Fedora caching suggestion
In-Reply-To: <47151CF5.8080407@filteredperception.org>
References: <6e24a8e80710150750o14e6648ew6f6120b6c5bb02d3@mail.gmail.com>
	<20071016145240.GA1968@jadzia.bu.edu>
	<6e24a8e80710161229s296c304q2c664843099957d4@mail.gmail.com>
	<47151CF5.8080407@filteredperception.org>
Message-ID: <6e24a8e80710170134od3abf39l8441fee5f591b3e7@mail.gmail.com>

> I have a hunch what you are describing might be the result of the menu
> stuff getting pushed out of cache.  Certainly the idea to pin/weight
> things like the menu stuff in cache must have been discussed before,
> though I couldn't immediately find such a thread via google.  I have
> vague memories of being annoyed by slow menus and googling and
> discovering that windows provides a method to tag some stuff in cache as
> more important, and thus less likely to be pushed out of cache.

A fix for that would be good.



From pbrobinson at gmail.com  Wed Oct 17 08:34:26 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 17 Oct 2007 09:34:26 +0100
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <1192575852.6439.13.camel@tiger>
References: <1192575852.6439.13.camel@tiger>
Message-ID: <5256d0b0710170134w44dd7667r25923ef3c3689601@mail.gmail.com>

Well as per your subject line my HP nx7400 is doing 1680x1050 with no
problems. It should be able to do 1920x1200 too I think. You should
also be able to get the latest version of the intel driver from the
freedesktop.org git repo and compile it against the Fedora x-server
with no problems if you want some of the later changes to the driver.
I did so about a month or so ago without major issues.

Peter

On 10/17/07, Louis E Garcia II <louisg00 at bellsouth.net> wrote:
> I asked this question on the Xorg list:
>
> The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
> laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
> Integrated Graphics Controller (rev 03) with vga out. Can my video chip
> power this monitor?
>
> I got an answer that Xorg server-1.4 with the latest intel driver has
> more chances of working with this setup. I know fedora 8 includes
> server-1.3 with a bunch of back ports from 1.4. Will F8 work with this
> setup?
>
> -Thanks
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From choeger at cs.tu-berlin.de  Wed Oct 17 09:23:29 2007
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 17 Oct 2007 11:23:29 +0200
Subject: packaging eclipse plugin
Message-ID: <1192613009.7882.6.camel@s5.math.tu-berlin.de>

hey there,
        
ive got some questions about packaging my eclipse plugin (Opalipse, an
IDE for Opal) (cs.tu-berlin.de/~choeger):
        
1. what is the default fedora way to install eclipse features? What do i
have to put where? Are there .spec templates (apart the default one
which comes with rpmdevtools)?
        
2. could such a package (Opal is a relatively uncommon language and
nearly only used in the TU-Berlin) make its way into the fedora
repositories?
        
regards
        
christoph 
        
        



From denis at poolshark.org  Wed Oct 17 09:30:26 2007
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 17 Oct 2007 11:30:26 +0200
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates
	-	2007-10-16
In-Reply-To: <604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>	<471549BF.6010109@poolshark.org>	<1192577929.3409.20.camel@localhost.localdomain>	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
Message-ID: <4715D632.80403@poolshark.org>

Jeff Spaleta wrote:
> Gee that sounds suspiciously like you're offering to maintain this package.

No waitaminute :-) No, I said I'd try to build it and check whether it's 
working or not. I can already say that it doesn't work at all on 
rawhide. However I have no intention of ever fixing or updating it, or 
processing its bugzilla tickets. As was said in previous msg, upstream 
is long dead.

> I don't think just one-off rebuilding it "solves" the problem either.

Agreed, but we need a short-term solution.

> What we really really need in these sorts of situation is have
> client-side notice that a package has been orphaned/expired via the
> package management tools, letting all users of that package know via
> their repository aware tools that the package is orphaned/removed and
> will no longer be receiving updates unless a maintainer shows up. At
> which point the users can choose to uninstall the package or perhaps
> step up and offer to be the maintainer of it.  I think users of
> orphaned packages deserve a chance to state an interest in maintaining
> packages when they get orphaned/removed. If we are only announcing
> orphaned status in channels that other current contributors are
> watching we are sacrificing an opportunity to add contributors to
> spread the workload around.

A good idea, but not a simple one to implement. How would you 
communicate the information to the package management tool ? The tool 
couldn't distinguish between an Obsolete caused by an orphan versus one 
caused by, say, a package rename. Maybe a RSS feed of some sort ?



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 17 09:40:43 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 17 Oct 2007 11:40:43 +0200
Subject: rpms/rpcbind/devel rpcbind.init,1.7,1.8 rpcbind.spec,1.21,1.22
In-Reply-To: <200710161612.l9GGCQ9H031104@cvs-int.fedora.redhat.com>
References: <200710161612.l9GGCQ9H031104@cvs-int.fedora.redhat.com>
Message-ID: <20071017114043.257c7adf.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 16 Oct 2007 12:12:26 -0400, Steve Dickson (steved) wrote:

> Author: steved
> 
> Update of /cvs/pkgs/rpms/rpcbind/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31038
> 
> Modified Files:
> 	rpcbind.init rpcbind.spec 
> Log Message:
> Corrected a typo in the initscript from previous commit.

>  	# Check that networking is up.
> -	[ "$NETWORKING" = "no" ] || exit 6
> +	[ "$NETWORKING" = "no" ] && exit 6
>  	[ -f /sbin/$prog ] || exit 5

Isn't

	[ "$NETWORKING" = "yes" ] || exit 6

preferred, so the service is off by default unless networking
is turnt on explicitly?

You already do

	if [ -f /etc/sysconfig/network ]; then
		. /etc/sysconfig/network
	else
		exit 6
	fi

which means that a missing definition of $NETWORKING in an
empty /etc/sysconfig/network would not cause the rpcbind service
script to exit 6.



From green at redhat.com  Wed Oct 17 09:52:10 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 17 Oct 2007 02:52:10 -0700
Subject: packaging eclipse plugin
In-Reply-To: <1192613009.7882.6.camel@s5.math.tu-berlin.de>
References: <1192613009.7882.6.camel@s5.math.tu-berlin.de>
Message-ID: <4715DB4A.8000505@redhat.com>

Christoph H?ger wrote:
> hey there,
>         
> ive got some questions about packaging my eclipse plugin (Opalipse, an
> IDE for Opal) (cs.tu-berlin.de/~choeger):
>         
> 1. what is the default fedora way to install eclipse features? What do i
> have to put where? Are there .spec templates (apart the default one
> which comes with rpmdevtools)?

I recommend asking on fedora-devel-java-list.

> 2. could such a package (Opal is a relatively uncommon language and
> nearly only used in the TU-Berlin) make its way into the fedora
> repositories?

Yes, as long as it passes the package review process.

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/cc5b383d/attachment.vcf>

From bnocera at redhat.com  Wed Oct 17 10:17:38 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 17 Oct 2007 11:17:38 +0100
Subject: libgpod update for Fedora 7
In-Reply-To: <20071017035627.GC596@psilocybe.teonanacatl.org>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
Message-ID: <1192616258.4729.1.camel@cookie.hadess.net>


On Tue, 2007-10-16 at 23:56 -0400, Todd Zullinger wrote:
> Hi all,
> 
> I'd like to (finally) update libgpod to 0.5.2 for F-7.  I'll rebuild
> the needed packages[1] and push them to -testing so no one else has to
> do anymore work.  Please speak up if that isn't alright.  If not, I'd
> like to do this late Wednesday evening (EDT) or Thursday.
> 
> (And no spot, this isn't the libgpod with the code to work with newer
> iPod's.  It's just the same version that's been in devel for a while.
> But let me know if you've heard anything from legal on the new code.)
> 
> [1] Packages that need a rebuild: amarok, gtkpod, kipi-plugins,
> quodlibet, and rhythmbox.  If I've missed any, please let me know.

You can't get updates-testing packages in the buildroots, so you'd be
breaking everything in there, unless there's no soname changes.

Is this a wise thing to do at this stage?



From mike.cohler at gmail.com  Wed Oct 17 10:58:37 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 17 Oct 2007 10:58:37 +0000 (UTC)
Subject: Question on wireless module
Message-ID: <loom.20071017T105100-379@post.gmane.org>

I have recently been testing the rt2x00 driver and specifically the rt73usb
component with a usb wireless adapter, using the test kernels currently
available for F7 in updates-testing.

However the wireless link is very unstable and throws streams of messages at the
terminal as well as in the alternative consoles. I reported this in bugzilla.

The question I have is whether the version of rt2x00 (and rt73usb) in rawhide is
nearer to being usable than the driver in the F7 kernels? Therefore another
question is whether it would be likely to work if I simply installed the rawhide
current kernel into F7 (and maybe the rawhide wpa_supplicant also?) and see if
that would give more stability?  

In addition is the new ath5k driver (that is presumably also in the rawhide
kernel?) actually usable at the moment? I have a Dlink G-650 card with the
Ahteros 5212 chipset that I could test if this is the case.

Does anyone have any info to enlighten me on this?

Thanks
Mike



From atkac at redhat.com  Wed Oct 17 11:11:15 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 17 Oct 2007 13:11:15 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <20071015213117.GA6325@petra.dvoda.cz>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
Message-ID: <20071017111115.GA1758@evileye.englab.brq.redhat.com>

On Mon, Oct 15, 2007 at 11:31:17PM +0200, Karel Zak wrote:
>  Couldn't be better to maintain default selinux labels like others
>  file attributes?
> 
>      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
>

I think restorecon is fare more better than this approach. With this you have two databases of file contexts - first is in specfile and second in selinux-policy*. When you use restorecon you have one centralised database. We will discuss if rpm will automaticaly run restorecon on all installed files.

Adam 



From atkac at redhat.com  Wed Oct 17 11:24:09 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 17 Oct 2007 13:24:09 +0200
Subject: Request for Comments: Proposed changes to Fedora development
	cycle
In-Reply-To: <4714D34F.1080304@hhs.nl>
References: <20071016102448.6cc4af82@redhat.com> <4714D34F.1080304@hhs.nl>
Message-ID: <20071017112409.GB1758@evileye.englab.brq.redhat.com>

On Tue, Oct 16, 2007 at 05:05:51PM +0200, Hans de Goede wrote:
> As for the tagging request avoiding people braking things late in the game:
> 1) we don't need barriers, we need to educate people

Definitely. All Fedora people are intelligent

> 2) if someone really wants to get an update in he will most likely
>    succeed as he knows his package best and can probably convince rel-eng
>    of the necessity of the update.

I think not needed. Early branching should solve this problem. Only bugfixing will be done in CVS and maintainer knows what is needed.

>
> So all in all:
> -calling it alpha / beta / release candidate instead of test# +1
> -no freeze for alpha +1
> -early branching (I would say a week for the RC) +1

Better will be create separate branch immediately after alpha release so development will be done continually (in devel branch).

> -making builds in the release branch goto updates-testing after
>  branching -1 (esp combined with early branching)

Yes, it's really annoying

Adam



From wtogami at redhat.com  Wed Oct 17 11:47:14 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 17 Oct 2007 07:47:14 -0400
Subject: Conflict: fedorainfinity-gdm-theme and fedora-logos
Message-ID: <4715F642.1040208@redhat.com>

[root at newcaprica ~]# yum update
Loading "refresh-updatesd" plugin
Loading "basearchonly" plugin
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kde-i18n-Japanese.noarch 1:3.5.8-1.fc8 set to be updated
---> Package kde-i18n-Chinese.noarch 1:3.5.8-1.fc8 set to be updated
---> Package libgcj.i386 0:4.1.2-32 set to be updated
---> Package libstdc++-devel.x86_64 0:4.1.2-32 set to be updated
---> Package libstdc++.x86_64 0:4.1.2-32 set to be updated
---> Package libstdc++.i386 0:4.1.2-32 set to be updated
---> Package gnome-compiz-manager.x86_64 0:0.10.4-2.fc8 set to be updated
---> Package gnome-vfs2-devel.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package gtk2-devel.x86_64 0:2.12.1-1.fc8 set to be updated
---> Package readahead.x86_64 1:1.4.2-3.fc8 set to be updated
---> Package libgomp.x86_64 0:4.1.2-32 set to be updated
---> Package kernel.x86_64 0:2.6.23.1-18.fc8 set to be updated
---> Package kde-i18n-Chinese-Big5.noarch 1:3.5.8-1.fc8 set to be updated
---> Package kernel-headers.x86_64 0:2.6.23.1-18.fc8 set to be updated
---> Package gnome-vfs2-smb.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package gnome-vfs2.i386 0:2.20.0-3.fc8 set to be updated
---> Package libgcc.i386 0:4.1.2-32 set to be updated
---> Package fedorainfinity-gdm-theme.noarch 0:8.0.1-1.fc8 set to be updated
---> Package perl-URI.noarch 0:1.35-3.1 set to be updated
---> Package libgcj.x86_64 0:4.1.2-32 set to be updated
---> Package gcc-c++.x86_64 0:4.1.2-32 set to be updated
---> Package policycoreutils-gui.x86_64 0:2.0.31-5.fc8 set to be updated
---> Package elfutils.x86_64 0:0.130-3.fc8 set to be updated
---> Package gtk2.x86_64 0:2.12.1-1.fc8 set to be updated
---> Package elfutils-libs.x86_64 0:0.130-3.fc8 set to be updated
---> Package gcc.x86_64 0:4.1.2-32 set to be updated
---> Package elfutils-libelf.i386 0:0.130-3.fc8 set to be updated
---> Package libgcc.x86_64 0:4.1.2-32 set to be updated
---> Package policycoreutils.x86_64 0:2.0.31-5.fc8 set to be updated
---> Package gnome-vfs2.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package cpp.x86_64 0:4.1.2-32 set to be updated
---> Package elfutils-libelf.x86_64 0:0.130-3.fc8 set to be updated
---> Package gtk2.i386 0:2.12.1-1.fc8 set to be updated
---> Package kde-i18n-Korean.noarch 1:3.5.8-1.fc8 set to be updated
filelists.xml.gz          100% |=========================|  10 MB 
00:31
filelists.xml.gz          100% |=========================|  11 MB 
00:37
filelists.sqlite.bz2      100% |=========================|  63 kB 
00:00
--> Finished Dependency Resolution
--> Running transaction check
---> Package kde-i18n-Japanese.noarch 1:3.5.8-1.fc8 set to be updated
---> Package kde-i18n-Chinese.noarch 1:3.5.8-1.fc8 set to be updated
---> Package libgcj.i386 0:4.1.2-32 set to be updated
---> Package libstdc++-devel.x86_64 0:4.1.2-32 set to be updated
---> Package libstdc++.x86_64 0:4.1.2-32 set to be updated
---> Package libstdc++.i386 0:4.1.2-32 set to be updated
---> Package gnome-compiz-manager.x86_64 0:0.10.4-2.fc8 set to be updated
---> Package gnome-vfs2-devel.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package gtk2-devel.x86_64 0:2.12.1-1.fc8 set to be updated
---> Package readahead.x86_64 1:1.4.2-3.fc8 set to be updated
---> Package libgomp.x86_64 0:4.1.2-32 set to be updated
---> Package kernel.x86_64 0:2.6.23.1-18.fc8 set to be installed
---> Package kde-i18n-Chinese-Big5.noarch 1:3.5.8-1.fc8 set to be updated
---> Package kernel-headers.x86_64 0:2.6.23.1-18.fc8 set to be updated
---> Package gnome-vfs2-smb.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package gnome-vfs2.i386 0:2.20.0-3.fc8 set to be updated
---> Package libgcc.i386 0:4.1.2-32 set to be updated
---> Package fedorainfinity-gdm-theme.noarch 0:8.0.1-1.fc8 set to be updated
---> Package perl-URI.noarch 0:1.35-3.1 set to be updated
---> Package libgcj.x86_64 0:4.1.2-32 set to be updated
---> Package gcc-c++.x86_64 0:4.1.2-32 set to be updated
---> Package policycoreutils-gui.x86_64 0:2.0.31-5.fc8 set to be updated
---> Package elfutils.x86_64 0:0.130-3.fc8 set to be updated
---> Package gtk2.x86_64 0:2.12.1-1.fc8 set to be updated
---> Package elfutils-libs.x86_64 0:0.130-3.fc8 set to be updated
---> Package gcc.x86_64 0:4.1.2-32 set to be updated
---> Package elfutils-libelf.i386 0:0.130-3.fc8 set to be updated
---> Package libgcc.x86_64 0:4.1.2-32 set to be updated
---> Package policycoreutils.x86_64 0:2.0.31-5.fc8 set to be updated
---> Package gnome-vfs2.x86_64 0:2.20.0-3.fc8 set to be updated
---> Package cpp.x86_64 0:4.1.2-32 set to be updated
---> Package elfutils-libelf.x86_64 0:0.130-3.fc8 set to be updated
---> Package gtk2.i386 0:2.12.1-1.fc8 set to be updated
---> Package kde-i18n-Korean.noarch 1:3.5.8-1.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
  Package                 Arch       Version          Repository 
Size
=============================================================================
Installing:
  kernel                  x86_64     2.6.23.1-18.fc8  static-x86-64 
  16 M
Updating:
  cpp                     x86_64     4.1.2-32         static-x86-64 
2.9 M
  elfutils                x86_64     0.130-3.fc8      static-x86-64 
199 k
  elfutils-libelf         i386       0.130-3.fc8      static-i386 
  55 k
  elfutils-libelf         x86_64     0.130-3.fc8      static-x86-64 
  50 k
  elfutils-libs           x86_64     0.130-3.fc8      static-x86-64 
114 k
  fedorainfinity-gdm-theme  noarch     8.0.1-1.fc8      static-x86-64 
   1.1 M
  gcc                     x86_64     4.1.2-32         static-x86-64 
5.3 M
  gcc-c++                 x86_64     4.1.2-32         static-x86-64 
3.7 M
  gnome-compiz-manager    x86_64     0.10.4-2.fc8     static-x86-64 
185 k
  gnome-vfs2              i386       2.20.0-3.fc8     static-i386 
1.1 M
  gnome-vfs2              x86_64     2.20.0-3.fc8     static-x86-64 
1.1 M
  gnome-vfs2-devel        x86_64     2.20.0-3.fc8     static-x86-64 
264 k
  gnome-vfs2-smb          x86_64     2.20.0-3.fc8     static-x86-64 
  38 k
  gtk2                    x86_64     2.12.1-1.fc8     static-x86-64 
6.9 M
  gtk2                    i386       2.12.1-1.fc8     static-i386 
6.9 M
  gtk2-devel              x86_64     2.12.1-1.fc8     static-x86-64 
3.4 M
  kde-i18n-Chinese        noarch     1:3.5.8-1.fc8    static-x86-64 
2.2 M
  kde-i18n-Chinese-Big5   noarch     1:3.5.8-1.fc8    static-x86-64 
2.8 M
  kde-i18n-Japanese       noarch     1:3.5.8-1.fc8    static-x86-64 
3.3 M
  kde-i18n-Korean         noarch     1:3.5.8-1.fc8    static-x86-64 
2.1 M
  kernel-headers          x86_64     2.6.23.1-18.fc8  static-x86-64 
700 k
  libgcc                  i386       4.1.2-32         static-i386 
  94 k
  libgcc                  x86_64     4.1.2-32         static-x86-64 
  97 k
  libgcj                  i386       4.1.2-32         static-i386 
  19 M
  libgcj                  x86_64     4.1.2-32         static-x86-64 
  20 M
  libgomp                 x86_64     4.1.2-32         static-x86-64 
  84 k
  libstdc++               x86_64     4.1.2-32         static-x86-64 
351 k
  libstdc++               i386       4.1.2-32         static-i386 
360 k
  libstdc++-devel         x86_64     4.1.2-32         static-x86-64 
2.8 M
  perl-URI                noarch     1.35-3.1         static-x86-64 
116 k
  policycoreutils         x86_64     2.0.31-5.fc8     static-x86-64 
948 k
  policycoreutils-gui     x86_64     2.0.31-5.fc8     static-x86-64 
161 k
  readahead               x86_64     1:1.4.2-3.fc8    static-x86-64 
  44 k
Removing:
  kernel                  x86_64     2.6.23.1-16.fc8  installed 
  61 M

Transaction Summary
=============================================================================
Install      1 Package(s)
Update      33 Package(s)
Remove       1 Package(s)

Total download size: 105 M
Is this ok [y/N]: y
Downloading Packages:
(1/34): kde-i18n-Korean-3 100% |=========================| 2.1 MB 
00:07
(2/34): gtk2-2.12.1-1.fc8 100% |=========================| 6.9 MB 
00:35
(3/34): elfutils-libelf-0 100% |=========================|  50 kB 
00:00
(4/34): cpp-4.1.2-32.x86_ 100% |=========================| 2.9 MB 
00:11
(5/34): gnome-vfs2-2.20.0 100% |=========================| 1.1 MB 
00:05
(6/34): policycoreutils-2 100% |=========================| 948 kB 
00:04
(7/34): libgcc-4.1.2-32.x 100% |=========================|  97 kB 
00:00
(8/34): elfutils-libelf-0 100% |=========================|  55 kB 
00:00
(9/34): gcc-4.1.2-32.x86_ 100% |=========================| 5.3 MB 
00:17
(10/34): elfutils-libs-0. 100% |=========================| 114 kB 
00:00
(11/34): gtk2-2.12.1-1.fc 100% |=========================| 6.9 MB 
00:21
(12/34): elfutils-0.130-3 100% |=========================| 199 kB 
00:00
(13/34): policycoreutils- 100% |=========================| 161 kB 
00:00
(14/34): gcc-c++-4.1.2-32 100% |=========================| 3.7 MB 
00:11
(15/34): libgcj-4.1.2-32. 100% |=========================|  20 MB 
01:10
(16/34): perl-URI-1.35-3. 100% |=========================| 116 kB 
00:00
(17/34): fedorainfinity-g 100% |=========================| 1.1 MB 
00:04
(18/34): libgcc-4.1.2-32. 100% |=========================|  94 kB 
00:00
(19/34): gnome-vfs2-2.20. 100% |=========================| 1.1 MB 
00:05
(20/34): gnome-vfs2-smb-2 100% |=========================|  38 kB 
00:00
(21/34): kernel-headers-2 100% |=========================| 700 kB 
00:03
(22/34): kde-i18n-Chinese 100% |=========================| 2.8 MB 
00:12
(23/34): kernel-2.6.23.1- 100% |=========================|  16 MB 
00:50
(24/34): libgomp-4.1.2-32 100% |=========================|  84 kB 
00:00
(25/34): readahead-1.4.2- 100% |=========================|  44 kB 
00:00
(26/34): gtk2-devel-2.12. 100% |=========================| 3.4 MB 
00:10
(27/34): gnome-vfs2-devel 100% |=========================| 264 kB 
00:00
(28/34): gnome-compiz-man 100% |=========================| 185 kB 
00:01
(29/34): libstdc++-4.1.2- 100% |=========================| 360 kB 
00:02
(30/34): libstdc++-4.1.2- 100% |=========================| 351 kB 
00:00
(31/34): libstdc++-devel- 100% |=========================| 2.8 MB 
00:10
(32/34): libgcj-4.1.2-32. 100% |=========================|  19 MB 
01:02
(33/34): kde-i18n-Chinese 100% |=========================| 2.2 MB 
00:09
(34/34): kde-i18n-Japanes 100% |=========================| 3.3 MB 
00:16
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test


Transaction Check Error:
   file /usr/share/gdm/themes/FedoraInfinity/FedoraInfinityGDM.xml from 
install of fedorainfinity-gdm-theme-8.0.1-1.fc8 conflicts with file from 
package fedora-logos-7.96.0-1.fc8



From opensource at till.name  Wed Oct 17 11:55:14 2007
From: opensource at till.name (Till Maas)
Date: Wed, 17 Oct 2007 13:55:14 +0200
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <358207.61361.qm@web52411.mail.re2.yahoo.com>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
Message-ID: <200710171355.15775.opensource@till.name>

On Mi Oktober 17 2007, Otto Rey wrote:
> I'm looking on Andreas Bierfert wine wiki
> (http://fedoraproject.org/wiki/AndreasBierfert/Wine), but i can't find wine
> 0.9.47 in updates-testing or in updates-testing-source (Fedora 7). Is there
> any schedule to sync testing repos with new packages?

wine 0.9.47 did not build on F7/8:

https://koji.fedoraproject.org/koji/packageinfo?packageID=4106

So the wiki is wrong.

Regards,
Till



From lkundrak at redhat.com  Wed Oct 17 12:22:48 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 17 Oct 2007 14:22:48 +0200
Subject: RHGB not running
In-Reply-To: <1192552321.2194.7.camel@scrappy.miketc.com>
References: <1192552321.2194.7.camel@scrappy.miketc.com>
Message-ID: <1192623768.10107.4.camel@localhost.localdomain>


On Tue, 2007-10-16 at 11:32 -0500, Mike Chambers wrote:
> Anyway, try a reboot and see if anyone else has same problem?

/me has.

Also, today's rawhide introduced a couple of more breakages I am not
sure where to report to (the guility component).

The gnome desktop's background flashes after the login and then
disappears. And there are no icons in the gnome desktop menu.

I installed with fairly minimal kickstart with %packages --default.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From joost at cnoc.nl  Wed Oct 17 12:41:35 2007
From: joost at cnoc.nl (Joost van der Sluis)
Date: Wed, 17 Oct 2007 14:41:35 +0200
Subject: debugedit exits with a SIGSEGV
Message-ID: <1192624895.28698.12.camel@wsjoost.cnoc.local>

Hi all,

I have another problem with the new find-debuginfo.sh script (and
friends).

debugedit crashes on one of the files (h2pas) in the fpc-package. I have
no idea what makes this executable other then the other fpc-executables.
I can try to install rpm-debuginfo to get a usefull backtrace. Or does
anyone has another idea?

This is Koji's log: 
http://koji.fedoraproject.org/koji/getfile?taskID=199082&name=build.log

Regards,

Joost van der Sluis.



From bnocera at redhat.com  Wed Oct 17 12:42:11 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 17 Oct 2007 13:42:11 +0100
Subject: FLAC update in F-7
Message-ID: <1192624931.9971.10.camel@snoogens.fab.redhat.com>

Heya,

Just a heads-up that I'm currently compiling FLAC 1.2.1 in Fedora 7 to
fix CVE-2007-4619.

Hopefully, it won't break too much (same patches and same code as seen
in the devel/F-8 branch).

See https://bugzilla.redhat.com/show_bug.cgi?id=332571

The first person to complain that I should have backported the security
fixes gets to do the backport themselves :)



From SteveD at redhat.com  Wed Oct 17 12:45:49 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Wed, 17 Oct 2007 08:45:49 -0400
Subject: s/libgssapi/libgssglue/ now?
In-Reply-To: <20071016160337.44c8653f@redhat.com>
References: <471517E5.7040304@redhat.com> <20071016160337.44c8653f@redhat.com>
Message-ID: <471603FD.5050301@RedHat.com>



Jesse Keating wrote:
> On Tue, 16 Oct 2007 15:58:29 -0400
> Warren Togami <wtogami at redhat.com> wrote:
> 
>> First ever build of libgssglue which seems to replace libgssapi
>> happened today, one day before the freeze of F8.  In addition to
>> replacing libgssapi it seems to bump soname.
> 
> Hrm, when I was contacted about this I was told it was just a package
> rename, not a soname rename too.  This is a much bigger change than I
> expected.  With the freeze tomorrow and the sluggishness of koji lately
> I'm reluctant to let this go through.
> 
> Steve?
I was waiting for libgssglue to show up on the build root
so I could rebuild all of the packages that were dependent
on it. That didn't happen in a timely matter (as Jesse can
a test due to the private emails) and unfortunately
a life interrupt came a long which knocked me off
line until this morning..

There has been no code changes with this library, just
the name has changed (due to an upstream change). The
dependent packages are nfs-utils, nfs-utils-lib, libtirpc.
I saw these problems and I was trying to build all the packages
to avoid them but I couldn't because libgssglue was not found
on the build root... Basically a catch-22...

We don't make this change the upstream development will
not be able to use F8 since this packages is now
required by the upstream version of nfs-utils.
This changed happen at the end of last week.

Those are the facts and I'll let "the power to be"
make the final decision.


steved.



From ssorce at redhat.com  Wed Oct 17 12:47:30 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 17 Oct 2007 08:47:30 -0400
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <20071017111115.GA1758@evileye.englab.brq.redhat.com>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
Message-ID: <1192625250.7342.89.camel@localhost.localdomain>

On Wed, 2007-10-17 at 13:11 +0200, Adam Tkac wrote:
> On Mon, Oct 15, 2007 at 11:31:17PM +0200, Karel Zak wrote:
> >  Couldn't be better to maintain default selinux labels like others
> >  file attributes?
> > 
> >      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
> >
> 
> I think restorecon is fare more better than this approach. With this you have two databases of file contexts - first is in specfile and second in selinux-policy*. When you use restorecon you have one centralised database. We will discuss if rpm will automaticaly run restorecon on all installed files.

Not only that, but a new policy may well change some labels to fix
errors, and make the package content obsolete. And even dangerous if the
package maintainer forgets to update it and on a yum update you get back
the old broken label.

Simo.



From gilboad at gmail.com  Wed Oct 17 12:56:21 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 17 Oct 2007 14:56:21 +0200
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <200710171355.15775.opensource@till.name>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
	<200710171355.15775.opensource@till.name>
Message-ID: <1192625781.29602.5.camel@gilboa-work-dev.localdomain>

On Wed, 2007-10-17 at 13:55 +0200, Till Maas wrote:
> On Mi Oktober 17 2007, Otto Rey wrote:
> > I'm looking on Andreas Bierfert wine wiki
> > (http://fedoraproject.org/wiki/AndreasBierfert/Wine), but i can't find wine
> > 0.9.47 in updates-testing or in updates-testing-source (Fedora 7). Is there
> > any schedule to sync testing repos with new packages?
> 
> wine 0.9.47 did not build on F7/8:
> 
> https://koji.fedoraproject.org/koji/packageinfo?packageID=4106
> 
> So the wiki is wrong.
> 
> Regards,
> Till
> 

Looks like a minor packaging problem. (Most likely new stub DLLs)

error: Installed (but unpackaged) file(s) found:
   /usr/lib/wine/msvcirt.dll.so
   /usr/lib/wine/qmgr.dll.so


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/wine/msvcirt.dll.so
   /usr/lib/wine/qmgr.dll.so

- Gilboa



From bnocera at redhat.com  Wed Oct 17 13:20:10 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 17 Oct 2007 14:20:10 +0100
Subject: Question on wireless module
In-Reply-To: <loom.20071017T105100-379@post.gmane.org>
References: <loom.20071017T105100-379@post.gmane.org>
Message-ID: <1192627210.9971.16.camel@snoogens.fab.redhat.com>


On Wed, 2007-10-17 at 10:58 +0000, Mike C wrote:
> I have recently been testing the rt2x00 driver and specifically the rt73usb
> component with a usb wireless adapter, using the test kernels currently
> available for F7 in updates-testing.
> 
> However the wireless link is very unstable and throws streams of messages at the
> terminal as well as in the alternative consoles. I reported this in bugzilla.
> 
> The question I have is whether the version of rt2x00 (and rt73usb) in rawhide is
> nearer to being usable than the driver in the F7 kernels? Therefore another
> question is whether it would be likely to work if I simply installed the rawhide
> current kernel into F7 (and maybe the rawhide wpa_supplicant also?) and see if
> that would give more stability?  
> 
> In addition is the new ath5k driver (that is presumably also in the rawhide
> kernel?) actually usable at the moment? I have a Dlink G-650 card with the
> Ahteros 5212 chipset that I could test if this is the case.
> 
> Does anyone have any info to enlighten me on this?

My desktop machine is unusable with the current rt73usb drivers. Half of
the ping packets to it are not coming back. I was ready to blame my AP,
or my internet provider, but this laptop with an ipw3495 worked great.

I used to use the rt73 driver from the project page on FC6, and other
than falling over every couple of days (requiring me to stop all the
network connections, and rmmod/insmod the driver), it was pretty solid
and fast.

The rt73usb in the current rawhide isn't quite there (although it's nice
not having to recompile the module for every kernel update).



From ajackson at redhat.com  Wed Oct 17 12:59:03 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 17 Oct 2007 08:59:03 -0400
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <1192575852.6439.13.camel@tiger>
References: <1192575852.6439.13.camel@tiger>
Message-ID: <1192625943.9104.23.camel@localhost.localdomain>


On Tue, 2007-10-16 at 19:04 -0400, Louis E Garcia II wrote:
> I asked this question on the Xorg list:
> 
> The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
> laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
> Integrated Graphics Controller (rev 03) with vga out. Can my video chip
> power this monitor?

Yes, it can.

- ajax



From jdennis at redhat.com  Wed Oct 17 13:48:23 2007
From: jdennis at redhat.com (John Dennis)
Date: Wed, 17 Oct 2007 09:48:23 -0400
Subject: Small Fonts in Firefox and Thunderbird
In-Reply-To: <471583D6.6070904@redhat.com>
References: <471583D6.6070904@redhat.com>
Message-ID: <471612A7.7050500@redhat.com>

Warren Togami wrote:
> I upgraded to some package built during Tuesday (should be in 
> Wednesday's rawhide) that suddenly changed the menu and dialog fonts in 
> both Firefox and Thunderbird.  In Thunderbird the fonts of the title 
> bar, menus, mail listings, To, From all became smaller and difficult to 
> read.  The font size and appearance within reading e-mail and composer 
> hasn't changed.  In Firefox the menus and URL bar became similarly 
> small, while web pages haven't changed in appearance.
> 
> I'm guessing some font rendering thing changed?
> Was this intentional or a bug?

Yes, I've seen the same thing but wasn't sure how to address it, font 
handling is somewhat mysterious because I haven't invested the time to 
learn all the issues.

I've also noticed that font size even within a single application seems 
to vary inconsistently (e.g. some mail content in thunderbird is tiny, 
some is huge, same thing in firefox)

-- 
John Dennis <jdennis at redhat.com>



From laurent.rineau__fedora at normalesup.org  Wed Oct 17 13:47:54 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Wed, 17 Oct 2007 15:47:54 +0200
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <1192625943.9104.23.camel@localhost.localdomain>
References: <1192575852.6439.13.camel@tiger>
	<1192625943.9104.23.camel@localhost.localdomain>
Message-ID: <200710171547.54528@rineau.tsetse>

On Wednesday 17 October 2007 14:59:03 Adam Jackson wrote:
> On Tue, 2007-10-16 at 19:04 -0400, Louis E Garcia II wrote:
> > I asked this question on the Xorg list:
> >
> > The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
> > laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
> > Integrated Graphics Controller (rev 03) with vga out. Can my video chip
> > power this monitor?
>
> Yes, it can.

Even through a VGA port? I thought a DVI port was needed for such a 
resolution.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From aph at redhat.com  Wed Oct 17 13:59:14 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 14:59:14 +0100
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <200710171547.54528@rineau.tsetse>
References: <1192575852.6439.13.camel@tiger>
	<1192625943.9104.23.camel@localhost.localdomain>
	<200710171547.54528@rineau.tsetse>
Message-ID: <18198.5426.595770.320037@zebedee.pink>

Laurent Rineau writes:
 > On Wednesday 17 October 2007 14:59:03 Adam Jackson wrote:
 > > On Tue, 2007-10-16 at 19:04 -0400, Louis E Garcia II wrote:
 > > > I asked this question on the Xorg list:
 > > >
 > > > The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
 > > > laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
 > > > Integrated Graphics Controller (rev 03) with vga out. Can my video chip
 > > > power this monitor?
 > >
 > > Yes, it can.
 > 
 > Even through a VGA port? I thought a DVI port was needed for such a
 > resolution.

I don't see why.  I've driven a 24" monitor at 2304 x 1440 over a VGA
connection.  Granted, you need something like a 350 MHz pixel clock,
but it does work.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From dcbw at redhat.com  Wed Oct 17 14:00:22 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 17 Oct 2007 10:00:22 -0400
Subject: Question on wireless module
In-Reply-To: <loom.20071017T105100-379@post.gmane.org>
References: <loom.20071017T105100-379@post.gmane.org>
Message-ID: <1192629622.10567.22.camel@localhost.localdomain>

On Wed, 2007-10-17 at 10:58 +0000, Mike C wrote:
> I have recently been testing the rt2x00 driver and specifically the rt73usb
> component with a usb wireless adapter, using the test kernels currently
> available for F7 in updates-testing.
> 
> However the wireless link is very unstable and throws streams of messages at the
> terminal as well as in the alternative consoles. I reported this in bugzilla.
> 
> The question I have is whether the version of rt2x00 (and rt73usb) in rawhide is
> nearer to being usable than the driver in the F7 kernels? Therefore another
> question is whether it would be likely to work if I simply installed the rawhide
> current kernel into F7 (and maybe the rawhide wpa_supplicant also?) and see if
> that would give more stability?  

I have an rt73usb device that's been working pretty consistently with
rawhide kernels for the past 3 weeks (Belkin F5D7050 ver 1000).  I
haven't had kernel oopses with it, and it seems to do fine with light
traffic (and even yum upgrades).

> In addition is the new ath5k driver (that is presumably also in the rawhide
> kernel?) actually usable at the moment? I have a Dlink G-650 card with the
> Ahteros 5212 chipset that I could test if this is the case.

ath5k driver has only just stopped panicing the kernel on boot, and is
still unstable in some situations.  It will likely get better, but don't
bet on ath5k being reliable at this point.

Dan




From dwalsh at redhat.com  Wed Oct 17 14:06:10 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 17 Oct 2007 10:06:10 -0400
Subject: gdm dosen't show my pix on the face greeter (selinux)
In-Reply-To: <1192484433.2486.10.camel@tiger>
References: <1192204108.2492.7.camel@tiger>
	<1192420770.2612.2.camel@tiger>	<1192465539.2792.6.camel@tiger>
	<1192480778.9477.7.camel@tiger> <1192484433.2486.10.camel@tiger>
Message-ID: <471616D2.1050002@redhat.com>

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

Louis E Garcia II wrote:
> On Mon, 2007-10-15 at 17:10 -0400, Daniel J Walsh wrote:
>> On Mon, 2007-10-15 at 16:39 -0400, Louis E Garcia II wrote:
>>> On Mon, 2007-10-15 at 14:57 -0400, Daniel J Walsh wrote:
>>>> On Mon, 2007-10-15 at 12:25 -0400, Louis E Garcia II wrote: 
>>>>> On Mon, 2007-10-15 at 18:02 +0200, Lubomir Kundrak wrote:
>>>>>> On Sun, 2007-10-14 at 23:59 -0400, Louis E Garcia II wrote:
>>>>>>> On Fri, 2007-10-12 at 11:48 -0400, Louis E Garcia II wrote:
>>>>>>>> I put a pix of myself in the 'about me' capplet and have a .face in my
>>>>>>>> home dir. Why doesn't gdm pick it up?
>>>>>>>>
>>>>>>>> -Louis
>>>>>>> Would this be the cause?
>>>>>>>
>>>>>>> SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to
>>>>>>> (home_root_t).
>>>>>>>
>>>>>>>
>>>>>> Aren'y you using the root account, are you? Where is your login
>>>>>> picture located? Have you tried runing restorecon on the image?
>>>>> No, this is a normal user account in /home a seperate partition.
>>>>>
>>>>> $ls -Z .face
>>>>> -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
>>>>>
>>>> Thils looks like the wrong location for this file. 
>>>>
>>>> In my case it would be
>>>>
>>>> /home/dwalsh/.face
>>>>
>>>> And it would have a context of user_home_t?
>>> $ls -Z /home/louisg00/.face
>>> -rw-r--r--  louisg00 users system_u:object_r:home_root_t:s0 .face
>>>
>>> Seems my entire /home dir is labeled home_root_t should I relabel it
>>> to user_home_t? This is a seperate partition. I remember something like
>>> putting .relabel in the root partition to have it relabel on boot?
>> Yes,
>>
>> restorecon -R -v /home
>>
>> Should fix the problem.
> 
> Yes it did and a few other problems I had, thanks.
> 
> One more thing, everything under /home is user_home_t but /home itself is
> still home_root_t. Is this correct?
> 
> $ls -Z /home
> drwx------  root     root  system_u:object_r:lost_found_t:s0 lost+found
> drwx------  louisg00 users system_u:object_r:user_home_dir_t:s0 louisg00
> 
> $ls -Zd /home
> drwxr-xr-x  root root system_u:object_r:home_root_t:s0 /home
> 
> 
Yes that is correct.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHFhbSrlYvE4MpobMRAhCwAKDRIClT2geHD/9iidNRQlHHdCUtgwCgmrqg
d4FJQdODbJd0+seCyScnchQ=
=z+m0
-----END PGP SIGNATURE-----



From dbhole at redhat.com  Wed Oct 17 14:07:49 2007
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 17 Oct 2007 10:07:49 -0400
Subject: Deploying noarch builds to specific arch's
Message-ID: <20071017140748.GG13974@redhat.com>

Hi,

I am attempting to build a package (checkstyle) with IcedTea. Currently,
Fedora allows building of noarch packages with IcedTea and shipping them
on all archs (where they run via IcedTea, or via gcj in interpreted
mode).

The problem is that IcedTea is only available on x86/x86_64. Since my
package is noarch, koji randomly distributes it between ppc/x86/x86_64,
and when it goes to ppc, the build fails.

While IcedTea is not a strong requirement for checkstyle, this problem
will be encountered by any package that is to be built with IcedTea..

Deepak



From jkeating at redhat.com  Wed Oct 17 14:06:56 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 10:06:56 -0400
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <4715A3D0.4000109@leemhuis.info>
References: <20071016102448.6cc4af82@redhat.com> <4714F153.202@leemhuis.info>
	<20071016133828.1a1c4cb5@redhat.com>
	<4715A3D0.4000109@leemhuis.info>
Message-ID: <20071017100656.30f05b65@redhat.com>

On Wed, 17 Oct 2007 07:55:28 +0200
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> >  We have to stop changes in order to finalize
> > the release and get it out the door.  
> 
> A week IMHO should suffice. If it doesn't I'd say we need more point
> in the middle to bring rawhide at least in a better shape beforehand.

I think you severely understimate the amount of time it takes to
compose trees, including all the Live images, validate that the compose
itself went fine, final check that all the test cases still work, move
the bits around to stage for mirrors, get mirrors populated, send gold
bits off to pressers to produce media to use at events, finalize
release notes web content, etc, etc, etc...  A week is a severely short
amount of time to accomplish all of this.

> > [...]  
> >> Normal, non-critical
> >> updates for the release (once it happens) stay updates candidates
> >> and thus don't get much tested either.  
> > They can be pushed to updates-testing at the 0day mark and thus get
> > testing there.  
> 
> Depends on how much lands into updates-testing over those weeks (and
> how many weeks we are taking of; three to four afaics). IOW: it IMHO
> looks bad to do a release and have more than <n> updates in
> updates-proper and <n> in updates testing (<n> something like 10 or
> 20 each in both cases).

I'm sorry but I just can't fathom being able to accomplish all we need
to do to get the release out in just a week's time, especially if there
have been open commits and builds right up until that week's time.

> >> Some packagers will thus likely just push their updates into the
> >> current release without testing them in rawhide first.   
> > But rawhide isn't the place to test them,  
> 
> Sure it is -- at least for me. Here is what I do when I get a new
> upstream release in Fedora:
> 
> - test locally (but that's of course always limited, as apps get used
> differently by different people)
> - update cvs for devel and build for rawhide, as rawhide users are
> those that won't yell to much if upstream released something new with
> multiple bugs in it
> - leave it there -- depending how crucial the package is for a few
> days a week some weeks
> - if nothing bad turned up in rawhide (e.g. if the new upstream
> release didn't contain any new bugs) I ship it in F7 updates-testing
> for some days
> - if nothing bad turns up move it to F7 updates proper
> - if that package would be of interest for F6 I would put it in
> updates-testing for F6 at this point (if one would exist)
> - if nothing bad turned some days later up push to F6 updates proper
> 
> Shipping a update in multiple branches at the same time or in F7
> earlier then in rawhide (because it is blocked for release) seems
> like a bad idea to me (I know, that's the standard behavior for a lot
> of people) -- if upstream got a bad bug in it all our users are
> effected by it and that can easily be prevented by above scheme.

However rawhide is not the place to test F7 issues.  You have different
sets of users in rawhide, F8-testing, F7-testing, etc...  You need to
have testing by each of those user sets before you can go final updates
for those releases.  They are different releases with different
userlands and different kernels/runtimes/etc... and quite likely there
are different interactions you need to validate.  Using rawhide as a
test case for these may find you the really really glaring problems
(which IMHO should be found in local testing anyway) but won't get you
near those other issues.  Releasing it as a testing update for F7
before it shows up in rawhide is perfectly fine.  Again different sets
of users, different problems, different test cases.

> >> That's bad in
> >> general already; but it's even more bad here, as it also create
> >> EVR-update troubles once the release is done.  
> > How can it create EVR-update troubles?  Only if maintainers push
> > updates to previous releases before pushing them for the pending
> > release, and even so this is not a new problem, as updates to
> > previous releases happen all the time while the release is a static
> > package set that quickly has "lower" nvrs than the fully updated
> > previous release. Not a new problem, [...]  
> 
> No, but with the new scheme it becomes bigger afaics.

I don't see how it will become bigger.  We're /shortening/ the amount
of time where builds don't automatically go somewhere, not lengthening
it.

> 
> >>> In order to accommodate a
> >>> release candidate set plus the final release creation the freeze
> >>> point for this should happen between the current Test3 dates and
> >>> the final deep freeze dates.    
> >> This proposal would IMHO be a bit easier to understand if you could
> >> write a potential F9 schedule with release, freeze and branching
> >> dates.  
> > I can add some example dates, but they shouldn't be counted on until
> > the Board and FESCo et al set the schedule.  
> 
> thx for doing that!
> 
> > [...]  
> >> Yes, sure, I know out mirrors are important, but not that
> >> important to delay the release that 5 days when the test window is
> >> four weeks (the usual cycle we had between test releases up to
> >> now).  
> > That puts an extreme pressure on the mirrors that I'd not like to
> > do. We've frequently seen feedback from them that if we just do
> > torrent first and delay the mirrors that they'd just as likely stop
> > mirroring us which doesn't help anybody.  The only /real/ way to
> > get releases out there quicker is to not have unstable trees all
> > the time.  
> 
> I strongly disagree with the "only" in that sentence. OpenSuse and
> Ubuntu afaics seem to get their test-release out way more quickly. We
> should be as well for *test*releases. For the final, yeah, the old
> behavior might fine. I'd say most mirror admins will understand that
> we need to get test releases out more quickly.
> 
> >> Further: I know multiple people that don't run rawhide because we
> >> always tell everyone "once rawhide always rawhide"  
> > Where exactly do "we" tell everyone this?  
> 
> It's in peoples heads afaics and they mention it on the list if
> questions come up "can I run a test release and later the final
> without reinstalling?" -> "No".

Find me a place that states this in official Fedora documentation and
we'll change it.  It's just absolutely untrue.

> Of did we document somewhere in between how to switch from rawhide to
> release before rawhide moves on? If yes please point me to, then I'll
> blog about it to get the old scheme out of peoples head.

As I said before, we may not have the process documented, but to the
best of my knowledge we certainly don't have the opposite written down
either, that you /can't/ do it.

> >> and "rawhide easts
> >> babies". That' IMHO are our biggest problems. Thus i suggest:
> >> - work hard to make rawhide not eat babies and kill kittens in the
> >> 5 weeks approaching a release. Tell the developers so they are more
> >> careful during that timeframe (e.g. as careful as they would be
> >> for a update for a released version) and send ninjas if they are
> >> not.  
> > Why 5 weeks, why not just all the time?  
> 
> Well, that's what we tried. Seemed it didn't work to well -- see for
> example OpenEXR.

Right.  It's hard to get into /every single/ person's head to not
disrupt rawhide without warnings or without doing some legwork to see
if what you're doing is going to cause undue problems.  We can only try
to get better each and every release.  I don't think putting a timeline
on it helps at all, I think it should be an all the time thing.

> >> - we need a way for testers that want to test the release that they
> >> want to continue to run afterwards without reinstalling it. Two
> >> ideas follow, I think we should do both:
> >> (1.) support and document the "rawhide -> stable" way -- e.g. at
> >> the point where rawhide on the servers becomes targeting the next
> >> Fedora version give users the choice "Do you want to continue
> >> using rawhide or stick to the release that is happening now?".  
> > Not sure how to "give them the choice"  
> 
> Yum-Plugin? Or something that disables all repos and asks which ones
> to activate again: rawhide or release.

Potentially.  Let me know when this code falls out of the air (:

> 
> > but we certainly can document
> > how to switch to the final release.   
> 
> thx -- in the past it seemed that was discouraged.

Maybe it depended upon who you talked to, but yes we've had an overall
paradigm shift to be more friendly to rawhide users and be more helpful
to get them from a release to rawhide and from rawhide to a release.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/198f0424/attachment.sig>

From Matt_Domsch at dell.com  Wed Oct 17 14:09:20 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 17 Oct 2007 09:09:20 -0500
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <18198.5426.595770.320037@zebedee.pink>
References: <1192575852.6439.13.camel@tiger>
	<1192625943.9104.23.camel@localhost.localdomain>
	<200710171547.54528@rineau.tsetse>
	<18198.5426.595770.320037@zebedee.pink>
Message-ID: <20071017140920.GC1277@auslistsprd01.us.dell.com>

On Wed, Oct 17, 2007 at 02:59:14PM +0100, Andrew Haley wrote:
> Laurent Rineau writes:
>  > On Wednesday 17 October 2007 14:59:03 Adam Jackson wrote:
>  > > On Tue, 2007-10-16 at 19:04 -0400, Louis E Garcia II wrote:
>  > > > I asked this question on the Xorg list:
>  > > >
>  > > > The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
>  > > > laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
>  > > > Integrated Graphics Controller (rev 03) with vga out. Can my video chip
>  > > > power this monitor?
>  > >
>  > > Yes, it can.
>  > 
>  > Even through a VGA port? I thought a DVI port was needed for such a
>  > resolution.
> 
> I don't see why.  I've driven a 24" monitor at 2304 x 1440 over a VGA
> connection.  Granted, you need something like a 350 MHz pixel clock,
> but it does work.

and it'll look much sharper with a DVI cable anyhow.  When I got my
2407 that's the first "upgrade" I made - a 10 foot DVI cable so the
computer can be in the closet.  It was like $30 online somewhere.  Now
if only my KVM switch had DVI...

-Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From aph at redhat.com  Wed Oct 17 14:15:55 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 15:15:55 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017140748.GG13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
Message-ID: <18198.6427.747568.101570@zebedee.pink>

Deepak Bhole writes:

 > I am attempting to build a package (checkstyle) with
 > IcedTea. Currently, Fedora allows building of noarch packages with
 > IcedTea and shipping them on all archs (where they run via IcedTea,
 > or via gcj in interpreted mode).
 > 
 > The problem is that IcedTea is only available on x86/x86_64. Since
 > my package is noarch, koji randomly distributes it between
 > ppc/x86/x86_64, and when it goes to ppc, the build fails.

So let's fix it on ppc.  In what way does it fail?

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From green at redhat.com  Wed Oct 17 14:23:09 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 17 Oct 2007 07:23:09 -0700
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18198.6427.747568.101570@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>
	<18198.6427.747568.101570@zebedee.pink>
Message-ID: <47161ACD.9020600@redhat.com>

Andrew Haley wrote:
> So let's fix it on ppc.  In what way does it fail?

There's no IcedTea for ppc yet, so koji is unable to create the buildroot.

We should just continue building bytecode with ecj for now.

AG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/b8c4fc2a/attachment.vcf>

From jkeating at redhat.com  Wed Oct 17 14:24:27 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 10:24:27 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017140748.GG13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
Message-ID: <20071017102427.617a217c@redhat.com>

On Wed, 17 Oct 2007 10:07:49 -0400
Deepak Bhole <dbhole at redhat.com> wrote:

> The problem is that IcedTea is only available on x86/x86_64. Since my
> package is noarch, koji randomly distributes it between
> ppc/x86/x86_64, and when it goes to ppc, the build fails.
> 
> While IcedTea is not a strong requirement for checkstyle, this problem
> will be encountered by any package that is to be built with IcedTea..

ExclusiveArch: i386 x86_64  in the spec, with loud comments about the
ExclusiveArch being there to match the arches where IcedTea is
available, and needs to be updated when IcedTea hits more arches.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/a4853ec2/attachment.sig>

From rstrode at redhat.com  Wed Oct 17 14:44:01 2007
From: rstrode at redhat.com (Ray Strode)
Date: Wed, 17 Oct 2007 10:44:01 -0400
Subject: Conflict: fedorainfinity-gdm-theme and fedora-logos
In-Reply-To: <4715F642.1040208@redhat.com>
References: <4715F642.1040208@redhat.com>
Message-ID: <47161FB1.3040008@redhat.com>

Hi,
>
> Transaction Check Error:
>   file /usr/share/gdm/themes/FedoraInfinity/FedoraInfinityGDM.xml from 
> install of fedorainfinity-gdm-theme-8.0.1-1.fc8 conflicts with file 
> from package fedora-logos-7.96.0-1.fc8
Fix running through Koji now.

--Ray



From aph at redhat.com  Wed Oct 17 14:48:16 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 15:48:16 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <47161ACD.9020600@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<18198.6427.747568.101570@zebedee.pink>
	<47161ACD.9020600@redhat.com>
Message-ID: <18198.8368.234303.167284@zebedee.pink>

Anthony Green writes:
 > Andrew Haley wrote:
 > > So let's fix it on ppc.  In what way does it fail?
 > 
 > There's no IcedTea for ppc yet, so koji is unable to create the buildroot.
 > 
 > We should just continue building bytecode with ecj for now.

Of course.  I don't know why that's not happening.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From dbhole at redhat.com  Wed Oct 17 14:49:46 2007
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 17 Oct 2007 10:49:46 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017102427.617a217c@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
Message-ID: <20071017144946.GH13974@redhat.com>

* Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
> On Wed, 17 Oct 2007 10:07:49 -0400
> Deepak Bhole <dbhole at redhat.com> wrote:
> 
> > The problem is that IcedTea is only available on x86/x86_64. Since my
> > package is noarch, koji randomly distributes it between
> > ppc/x86/x86_64, and when it goes to ppc, the build fails.
> > 
> > While IcedTea is not a strong requirement for checkstyle, this problem
> > will be encountered by any package that is to be built with IcedTea..
> 
> ExclusiveArch: i386 x86_64  in the spec, with loud comments about the
> ExclusiveArch being there to match the arches where IcedTea is
> available, and needs to be updated when IcedTea hits more arches.
> 

But that would create arch specific packages, which would not get
shipped on ppc. Packages built with icedtea can run on ppc with gcj in
interpreted mode.

Deepak

> -- 
> Jesse Keating
> Fedora -- All my bits are free, are yours?




From caolanm at redhat.com  Wed Oct 17 15:32:26 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 17 Oct 2007 16:32:26 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017144946.GH13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
Message-ID: <1192635146.28285.29.camel@Jehannum>


On Wed, 2007-10-17 at 10:49 -0400, Deepak Bhole wrote:
> * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
> > On Wed, 17 Oct 2007 10:07:49 -0400
> > Deepak Bhole <dbhole at redhat.com> wrote:
> > 
> But that would create arch specific packages, which would not get
> shipped on ppc. Packages built with icedtea can run on ppc with gcj in
> interpreted mode.

But doesn't icedtea by default generate byte-code targeted to a later
version than gij can handle ? i.e...

[caolan at Jehannum ~]$ /usr/lib/jvm/java-1.7.0-icedtea/bin/javac \
  findhome.java 
[caolan at Jehannum ~]$ gij findhome
Exception in thread "main" java.lang.ClassFormatError: findhome
(unrecognized class file version)
   at java.lang.VMClassLoader.defineClass(libgcj.so.8rh)
   at java.lang.ClassLoader.defineClass(libgcj.so.8rh)
   at java.security.SecureClassLoader.defineClass(libgcj.so.8rh)
   at java.net.URLClassLoader.findClass(libgcj.so.8rh)
   at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.8rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.8rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.8rh)
   at gnu.java.lang.MainThread.run(libgcj.so.8rh)
[caolan at Jehannum ~]$ /usr/lib/jvm/java-1.7.0-icedtea/bin/javac \
  -target 1.5 findhome.java 
[caolan at Jehannum ~]$ gij findhome
all ok

C.



From caolanm at redhat.com  Wed Oct 17 15:32:26 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 17 Oct 2007 16:32:26 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017144946.GH13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
Message-ID: <1192635146.28285.29.camel@Jehannum>


On Wed, 2007-10-17 at 10:49 -0400, Deepak Bhole wrote:
> * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
> > On Wed, 17 Oct 2007 10:07:49 -0400
> > Deepak Bhole <dbhole at redhat.com> wrote:
> > 
> But that would create arch specific packages, which would not get
> shipped on ppc. Packages built with icedtea can run on ppc with gcj in
> interpreted mode.

But doesn't icedtea by default generate byte-code targeted to a later
version than gij can handle ? i.e...

[caolan at Jehannum ~]$ /usr/lib/jvm/java-1.7.0-icedtea/bin/javac \
  findhome.java 
[caolan at Jehannum ~]$ gij findhome
Exception in thread "main" java.lang.ClassFormatError: findhome
(unrecognized class file version)
   at java.lang.VMClassLoader.defineClass(libgcj.so.8rh)
   at java.lang.ClassLoader.defineClass(libgcj.so.8rh)
   at java.security.SecureClassLoader.defineClass(libgcj.so.8rh)
   at java.net.URLClassLoader.findClass(libgcj.so.8rh)
   at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.8rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.8rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.8rh)
   at gnu.java.lang.MainThread.run(libgcj.so.8rh)
[caolan at Jehannum ~]$ /usr/lib/jvm/java-1.7.0-icedtea/bin/javac \
  -target 1.5 findhome.java 
[caolan at Jehannum ~]$ gij findhome
all ok

C.



From aph at redhat.com  Wed Oct 17 14:59:42 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 15:59:42 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017144946.GH13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
Message-ID: <18198.9054.567547.992798@zebedee.pink>

Deepak Bhole writes:
 > * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
 > > On Wed, 17 Oct 2007 10:07:49 -0400
 > > Deepak Bhole <dbhole at redhat.com> wrote:
 > > 
 > > > The problem is that IcedTea is only available on x86/x86_64. Since my
 > > > package is noarch, koji randomly distributes it between
 > > > ppc/x86/x86_64, and when it goes to ppc, the build fails.
 > > > 
 > > > While IcedTea is not a strong requirement for checkstyle, this problem
 > > > will be encountered by any package that is to be built with IcedTea..
 > > 
 > > ExclusiveArch: i386 x86_64  in the spec, with loud comments about the
 > > ExclusiveArch being there to match the arches where IcedTea is
 > > available, and needs to be updated when IcedTea hits more arches.
 > > 
 > 
 > But that would create arch specific packages, which would not get
 > shipped on ppc. Packages built with icedtea can run on ppc with gcj in
 > interpreted mode.

Indeed.  As you said on IRC: it is acceptable Fedora policy to build
noarch with icedtea and ship on all archs.  However, although the
policy allows this, the buildsystem does not.

I suggest that we adjust Fedora policy to match what the build system
is capable of.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From aph at redhat.com  Wed Oct 17 15:01:40 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 16:01:40 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <1192635146.28285.29.camel@Jehannum>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<1192635146.28285.29.camel@Jehannum>
Message-ID: <18198.9172.818517.660400@zebedee.pink>

Caolan McNamara writes:
 > 
 > On Wed, 2007-10-17 at 10:49 -0400, Deepak Bhole wrote:
 > > * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
 > > > On Wed, 17 Oct 2007 10:07:49 -0400
 > > > Deepak Bhole <dbhole at redhat.com> wrote:
 > > > 
 > > But that would create arch specific packages, which would not get
 > > shipped on ppc. Packages built with icedtea can run on ppc with gcj in
 > > interpreted mode.
 > 
 > But doesn't icedtea by default generate byte-code targeted to a later
 > version than gij can handle ? i.e...

We've been around this before.  It is *vital* that all packages built
with IcedTea are built with -target 1.5.  Otherwise, as you say,
people won't be able to run with most current VMs.  If this isn't
current Fedora policy, it really needs to be.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From green at redhat.com  Wed Oct 17 15:03:04 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 17 Oct 2007 08:03:04 -0700
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18198.8368.234303.167284@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>	<18198.6427.747568.101570@zebedee.pink>	<47161ACD.9020600@redhat.com>
	<18198.8368.234303.167284@zebedee.pink>
Message-ID: <47162428.2080008@redhat.com>

Andrew Haley wrote:
> Anthony Green writes:
>  > Andrew Haley wrote:
>  > > So let's fix it on ppc.  In what way does it fail?
>  > 
>  > There's no IcedTea for ppc yet, so koji is unable to create the buildroot.
>  > 
>  > We should just continue building bytecode with ecj for now.
> 
> Of course.  I don't know why that's not happening.

Just don't BuildRequire icedtea and all is good.

AG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/0552ab57/attachment.vcf>

From aph at redhat.com  Wed Oct 17 15:03:27 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 16:03:27 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18198.9172.818517.660400@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<1192635146.28285.29.camel@Jehannum>
	<18198.9172.818517.660400@zebedee.pink>
Message-ID: <18198.9279.295202.318537@zebedee.pink>

Andrew Haley writes:

 > It is *vital* that all packages built with IcedTea are built with
 > -target 1.5.  Otherwise, as you say, people won't be able to run
 > with most current VMs.  If this isn't current Fedora policy, it
 > really needs to be.

A thought: perhaps we can have a sript in the buildsystem or in RPM
that checks this.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From jkeating at redhat.com  Wed Oct 17 15:06:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 11:06:43 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017140748.GG13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
Message-ID: <20071017110643.54101d13@redhat.com>

On Wed, 17 Oct 2007 10:07:49 -0400
Deepak Bhole <dbhole at redhat.com> wrote:

> I am attempting to build a package (checkstyle) with IcedTea.
> Currently, Fedora allows building of noarch packages with IcedTea and
> shipping them on all archs (where they run via IcedTea, or via gcj in
> interpreted mode).
> 
> The problem is that IcedTea is only available on x86/x86_64. Since my
> package is noarch, koji randomly distributes it between
> ppc/x86/x86_64, and when it goes to ppc, the build fails.
> 
> While IcedTea is not a strong requirement for checkstyle, this problem
> will be encountered by any package that is to be built with IcedTea..

Rereading the problem, I don't think we can /build/ with IcedTea yet.
We need to build them all with gcj and they could runtime use IcedTea
if it's available, or gcj if not.  But they're all built with gcj until
such time as we have IcedTea everywhere.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/b1a8cdb3/attachment.sig>

From caolanm at redhat.com  Wed Oct 17 15:45:30 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 17 Oct 2007 16:45:30 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18198.9279.295202.318537@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<1192635146.28285.29.camel@Jehannum>
	<18198.9172.818517.660400@zebedee.pink>
	<18198.9279.295202.318537@zebedee.pink>
Message-ID: <1192635930.28285.32.camel@Jehannum>


On Wed, 2007-10-17 at 16:03 +0100, Andrew Haley wrote:
> Andrew Haley writes:
> 
>  > It is *vital* that all packages built with IcedTea are built with
>  > -target 1.5.  Otherwise, as you say, people won't be able to run
>  > with most current VMs.  If this isn't current Fedora policy, it
>  > really needs to be.
> 
> A thought: perhaps we can have a sript in the buildsystem or in RPM
> that checks this.

Or perhaps tweak our icedtea to just default to targeting 1.5 without
the use of -target ? Seems more fool-proof.

I know I stumbled into the problem a few weeks ago, perhaps I missed
mails about this before when on vacation.

C.



From aph at redhat.com  Wed Oct 17 15:13:53 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Oct 2007 16:13:53 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <1192635930.28285.32.camel@Jehannum>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<1192635146.28285.29.camel@Jehannum>
	<18198.9172.818517.660400@zebedee.pink>
	<18198.9279.295202.318537@zebedee.pink>
	<1192635930.28285.32.camel@Jehannum>
Message-ID: <18198.9905.553522.650164@zebedee.pink>

Caolan McNamara writes:
 > 
 > On Wed, 2007-10-17 at 16:03 +0100, Andrew Haley wrote:
 > > Andrew Haley writes:
 > > 
 > >  > It is *vital* that all packages built with IcedTea are built with
 > >  > -target 1.5.  Otherwise, as you say, people won't be able to run
 > >  > with most current VMs.  If this isn't current Fedora policy, it
 > >  > really needs to be.
 > > 
 > > A thought: perhaps we can have a sript in the buildsystem or in RPM
 > > that checks this.
 > 
 > Or perhaps tweak our icedtea to just default to targeting 1.5 without
 > the use of -target ? Seems more fool-proof.

Perhaps, but it is a major deviation from the way OpenJDK behaves,
making us even more of a local fork.  I don't think we really want to
diverge on something as basic as this.

 > I know I stumbled into the problem a few weeks ago, perhaps I missed
 > mails about this before when on vacation.

As Jesse says, it should be that "they're all built with gcj until
such time as we have IcedTea everywhere."  It's the only sensible way
to proceed.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From ville.skytta at iki.fi  Wed Oct 17 15:36:25 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 17 Oct 2007 18:36:25 +0300
Subject: rpms/rpcbind/devel rpcbind.init,1.7,1.8 rpcbind.spec,1.21,1.22
In-Reply-To: <20071017114043.257c7adf.mschwendt.tmp0701.nospam@arcor.de>
References: <200710161612.l9GGCQ9H031104@cvs-int.fedora.redhat.com>
	<20071017114043.257c7adf.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200710171836.25628.ville.skytta@iki.fi>

On Wednesday 17 October 2007, Michael Schwendt wrote:
> On Tue, 16 Oct 2007 12:12:26 -0400, Steve Dickson (steved) wrote:
> > Author: steved
> >
> > Update of /cvs/pkgs/rpms/rpcbind/devel
> > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31038
> >
> > Modified Files:
> > 	rpcbind.init rpcbind.spec
> > Log Message:
> > Corrected a typo in the initscript from previous commit.
> >
> >  	# Check that networking is up.
> > -	[ "$NETWORKING" = "no" ] || exit 6
> > +	[ "$NETWORKING" = "no" ] && exit 6
> >  	[ -f /sbin/$prog ] || exit 5
>
> Isn't
>
> 	[ "$NETWORKING" = "yes" ] || exit 6
>
> preferred, so the service is off by default unless networking
> is turnt on explicitly?

There have also been opinons that sourcing /etc/sysconfig/network and then 
testing $NETWORKING to see if networking is available is primarily legacy 
cruft that should be just removed.



From mike.cohler at gmail.com  Wed Oct 17 15:36:07 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 17 Oct 2007 15:36:07 +0000 (UTC)
Subject: Question on wireless module
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
Message-ID: <loom.20071017T153203-848@post.gmane.org>

Dan Williams <dcbw <at> redhat.com> writes:

> I have an rt73usb device that's been working pretty consistently with
> rawhide kernels for the past 3 weeks (Belkin F5D7050 ver 1000).  I
> haven't had kernel oopses with it, and it seems to do fine with light
> traffic (and even yum upgrades).

OK it sounds like it would be worth testing the rawhide kernels for rt73usb even
within f7. The legacy rt73 does work nicely, and is stable for me in f7, but
does not support wpa_supplicant, though it will do WPA directly in the driver
with the right config I believe. Of course it needs compiling and installing for
each kernel. I guess rt2x00 will not be fully stable until F9 given that F8
release is only a few weeks away?

> ath5k driver has only just stopped panicing the kernel on boot, and is
> still unstable in some situations.  It will likely get better, but don't
> bet on ath5k being reliable at this point.

Thanks - sounds like further work needs to be done before trying this driver.





From dcbw at redhat.com  Wed Oct 17 15:42:48 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 17 Oct 2007 11:42:48 -0400
Subject: Question on wireless module
In-Reply-To: <loom.20071017T153203-848@post.gmane.org>
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
Message-ID: <1192635768.11584.8.camel@localhost.localdomain>

On Wed, 2007-10-17 at 15:36 +0000, Mike C wrote:
> Dan Williams <dcbw <at> redhat.com> writes:
> 
> > I have an rt73usb device that's been working pretty consistently with
> > rawhide kernels for the past 3 weeks (Belkin F5D7050 ver 1000).  I
> > haven't had kernel oopses with it, and it seems to do fine with light
> > traffic (and even yum upgrades).
> 
> OK it sounds like it would be worth testing the rawhide kernels for rt73usb even
> within f7. The legacy rt73 does work nicely, and is stable for me in f7, but
> does not support wpa_supplicant, though it will do WPA directly in the driver
> with the right config I believe. Of course it needs compiling and installing for
> each kernel. I guess rt2x00 will not be fully stable until F9 given that F8
> release is only a few weeks away?

Well, it's pretty good so far, and a lot of drivers that are based on
mac80211 are landing in F8 (iwl3945, iwl4965, rt2x00, ath5k, b43).
That's a _lot_ of cards.  So I'd expect update kernels to iron out any
issues people have pretty quickly.  That said, ath5k is the least mature
of all the drivers in the tree right now.

Dan

> > ath5k driver has only just stopped panicing the kernel on boot, and is
> > still unstable in some situations.  It will likely get better, but don't
> > bet on ath5k being reliable at this point.
> 
> Thanks - sounds like further work needs to be done before trying this driver.
> 
> 
> 



From ville.skytta at iki.fi  Wed Oct 17 15:42:49 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 17 Oct 2007 18:42:49 +0300
Subject: libgpod update for Fedora 7
In-Reply-To: <1192616258.4729.1.camel@cookie.hadess.net>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
Message-ID: <200710171842.50159.ville.skytta@iki.fi>

On Wednesday 17 October 2007, Bastien Nocera wrote:

> Is this a wise thing to do at this stage?

Also, please post the reasons why the update is so important that it warrants 
potential breakage not only within a released distro version in Fedora, but 
in 3rd party repositories as well.



From ville.skytta at iki.fi  Wed Oct 17 15:44:23 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 17 Oct 2007 18:44:23 +0300
Subject: FLAC update in F-7
In-Reply-To: <1192624931.9971.10.camel@snoogens.fab.redhat.com>
References: <1192624931.9971.10.camel@snoogens.fab.redhat.com>
Message-ID: <200710171844.23517.ville.skytta@iki.fi>

On Wednesday 17 October 2007, Bastien Nocera wrote:
> Heya,
>
> Just a heads-up that I'm currently compiling FLAC 1.2.1 in Fedora 7 to
> fix CVE-2007-4619.
>
> Hopefully, it won't break too much (same patches and same code as seen
> in the devel/F-8 branch).

xine-lib seems to work fine with the updated flac without a rebuild.



From zcerza at redhat.com  Wed Oct 17 15:46:59 2007
From: zcerza at redhat.com (Zack Cerza)
Date: Wed, 17 Oct 2007 11:46:59 -0400
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>
References: <1192559987.2807.3.camel@tiger> <47150A93.2090608@redhat.com>
	<e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>
Message-ID: <47162E73.5080705@redhat.com>

Jon Nettleton wrote:
> On 10/16/07, Zack Cerza <zcerza at redhat.com> wrote:
>> Louis E Garcia II wrote:
>>> when logging on I need to give gnome-keyring the password to unlock even
>>> though I check it so it unlocks automatically. What gives?
>>>
>>> -Louis
>>  From what I understand, the feature isn't complete and depends on [0].
>> Matthias said in [1] that he removed the checkboxes until that work is
>> finished.
>>
> 
> We decided yesterday it would definitely be better to turn that off
> rather than feel the wrath of thousands of people checking that box
> and it not doing anything.  If you don't use a smart card reader or a
> biometric authentication device, you can edit /etc/pam.d/gdm and move
> the
> auth line for pam_gnome_keyring above the system auth include.
> However I take no responsibility for what it could possibly break in
> the future ;-).
> 
> Jon

That was definitely the right decision. However, here's to hoping the 
feature does get fully implemented, because that would obviously be 
awesome. :)

Zack



From mike.cohler at gmail.com  Wed Oct 17 15:48:02 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 17 Oct 2007 15:48:02 +0000 (UTC)
Subject: Question on wireless module
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
	<1192635768.11584.8.camel@localhost.localdomain>
Message-ID: <loom.20071017T154639-422@post.gmane.org>

Dan Williams <dcbw <at> redhat.com> writes:

> Well, it's pretty good so far, and a lot of drivers that are based on
> mac80211 are landing in F8 (iwl3945, iwl4965, rt2x00, ath5k, b43).
> That's a _lot_ of cards.  So I'd expect update kernels to iron out any
> issues people have pretty quickly.  That said, ath5k is the least mature
> of all the drivers in the tree right now.

OK I will install the latest rawhide kernel in that F7 machine and see how
rt73usb behaves - it has to be better than the current F7 testing kernel! I'll
report back in a day or two when I have had a chance to tinker with it.



From fedora at leemhuis.info  Wed Oct 17 15:54:51 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 17 Oct 2007 17:54:51 +0200
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071017100656.30f05b65@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
	<4714F153.202@leemhuis.info>	<20071016133828.1a1c4cb5@redhat.com>	<4715A3D0.4000109@leemhuis.info>
	<20071017100656.30f05b65@redhat.com>
Message-ID: <4716304B.2080004@leemhuis.info>

On 17.10.2007 16:06, Jesse Keating wrote:
> On Wed, 17 Oct 2007 07:55:28 +0200
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>>>  We have to stop changes in order to finalize
>>> the release and get it out the door.  
>> A week IMHO should suffice. If it doesn't I'd say we need more point
>> in the middle to bring rawhide at least in a better shape beforehand.
> I think you severely understimate the amount of time it takes to
> compose trees, 

We drifted of and talk on cross purposes (as we two often do when
discussing...). So let's try differently:

- yes, sure, I know and accept that it takes more then a week to
finalize and publish the *final* release

- for a test-relase a week should suffice (that's actually what we used
in the schedule in the past; see the initial F7 schedule for example:
http://fedoraproject.org/wiki/Releases/7/Schedule?action=recall&rev=2 )

- I nevertheless think rawhide should not stand still (or nearly still)
for more then a week as two many changes are done in between, which
results in a massive pile of updates once rawhide opens again, which
results in tons of problems at once. Your proposal solves a part of this
problem, but it doesn't solve it for real IMHO

>>>> Some packagers will thus likely just push their updates into the
>>>> current release without testing them in rawhide first.   
>>> But rawhide isn't the place to test them,  
>> Sure it is -- at least for me. Here is what I do when I get a new
>> upstream release in Fedora:
>>
>> - test locally (but that's of course always limited, as apps get used
>> differently by different people)
>> - update cvs for devel and build for rawhide, as rawhide users are
>> those that won't yell to much if upstream released something new with
>> multiple bugs in it
>> - leave it there -- depending how crucial the package is for a few
>> days a week some weeks
>> - if nothing bad turned up in rawhide (e.g. if the new upstream
>> release didn't contain any new bugs) I ship it in F7 updates-testing
>> for some days
>> - if nothing bad turns up move it to F7 updates proper
>> - if that package would be of interest for F6 I would put it in
>> updates-testing for F6 at this point (if one would exist)
>> - if nothing bad turned some days later up push to F6 updates proper
>> Shipping a update in multiple branches at the same time or in F7
>> earlier then in rawhide (because it is blocked for release) seems
>> like a bad idea to me (I know, that's the standard behavior for a lot
>> of people) -- if upstream got a bad bug in it all our users are
>> effected by it and that can easily be prevented by above scheme. 
> However rawhide is not the place to test F7 issues. 

No, of course not. But it's IMHO the best and first place to push a new
upstream release out, to get that tested. If that works fine for rawhide
users then it will likely work well for F7 as well.

> You have different
> sets of users in rawhide, F8-testing, F7-testing, etc...  You need to
> have testing by each of those user sets before you can go final updates
> for those releases.

And that's why we have F<n>-testing, and that's a good thing. But just
because we have it it doesn't mean that I have to push a new version to
rawhide, F8-testing and F7-testing at the same time, as a new upstream
version with lots of bugs will then git more users then needed.

>  They are different releases with different
> userlands and different kernels/runtimes/etc...

And the code from upstream is what has the widest impact. If that is
full of bugs I'll notice that after pushing it to rawhide; thus I won't
release it for F7- and F8-testing and safe users of those branches a lot
of trouble; instead I wait for the next upstream release.

> [...]
>>>> That's bad in
>>>> general already; but it's even more bad here, as it also create
>>>> EVR-update troubles once the release is done.  
>>> How can it create EVR-update troubles?  Only if maintainers push
>>> updates to previous releases before pushing them for the pending
>>> release, and even so this is not a new problem, as updates to
>>> previous releases happen all the time while the release is a static
>>> package set that quickly has "lower" nvrs than the fully updated
>>> previous release. Not a new problem, [...]  
>> No, but with the new scheme it becomes bigger afaics.
> I don't see how it will become bigger.  We're /shortening/ the amount
> of time where builds don't automatically go somewhere, not lengthening
> it.

I fail to see that.

/me takes a closer look at the example schedule

F9 hypothetical schedule: Final Development freeze is 20080408 -- thus
all updates after that point that are *not* release-critical gets tagged
as "updates candidate" afaics (at least that's how I understand it from
the description; please tell me if I got something wrong). Thus
non-critical stuff doesn't make it into the tree for 23 days (release is
scheduled for 20080501).

F8: Final freeze is today 20071017; everything from now afaics gets
tagged as "updates candidate" until release, which is scheduled for
20071108 -- 22 days

So there is not a real difference I can see.

And three weeks is a long time -- much updates will get shipped in the
still-current releases (e.g. F7) in those weeks; some of them with a
higher EVR then what will be on the F8 media later.

BTW, now that I see your hypothetical schedule for F9 -- five weeks
between beta and RC sounds like a lot; how about a beta 2 half way?

> [...]  

Doesn't look like it's worth to answer the other parts -- you wanted
opinions, you got some and I lost interest to discuss them further.

Cu
knurd



From mike.cohler at gmail.com  Wed Oct 17 15:58:28 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 17 Oct 2007 15:58:28 +0000 (UTC)
Subject: Question on wireless module
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
	<1192635768.11584.8.camel@localhost.localdomain>
Message-ID: <loom.20071017T155456-80@post.gmane.org>

Dan Williams <dcbw <at> redhat.com> writes:
 
> Well, it's pretty good so far, and a lot of drivers that are based on
> mac80211 are landing in F8 (iwl3945, iwl4965, rt2x00, ath5k, b43).

I have been running iwl3945 in F7 recently and it is nice and works well for WPA
encryption with wpa_supplicant. Running WPA rather than WEP encryption makes for
a much safer wireless network, but also in many institutions WPA/PEAP + MSCHAP
V2 and similar means that unless a laptop can cope with that encryption method
then it cannot be linked via wifi at all!  Hence getting these drivers fully
operational is a big step forward.





From jakub at redhat.com  Wed Oct 17 16:04:24 2007
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 17 Oct 2007 12:04:24 -0400
Subject: glibc breaks googleearth?
In-Reply-To: <1192499340.18611.5.camel@optimus>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
	<1192496794.617.0.camel@neuromancer>
	<1192497837.18611.1.camel@optimus>
	<1192499340.18611.5.camel@optimus>
Message-ID: <20071017160423.GS5451@devserv.devel.redhat.com>

On Tue, Oct 16, 2007 at 11:49:00AM +1000, Dave Airlie wrote:
> Okay I've installed the latest glibc from F7 updates (in a separate
> directory on my F8 box, and ran
> 
> LD_LIBRARY_PATH=.:/home/airlied/test/lib /home/airlied/test/lib//ld-2.6.so ./googleearth-bin
> 
> and it appears to start and work.. so what changed in glibc that annoys
> it?

Bug in both googleearth (some libraries incorrectly linked, even when they
use libpthread symbols not linked against -lpthread, which means many
unversioned symbols) and glibc i?86 sem_post glibc 2.0 compatibility code.
The latter is fixed in CVS and will be in tonight's glibc build.

	Jakub



From orion at cora.nwra.com  Wed Oct 17 16:34:26 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 17 Oct 2007 10:34:26 -0600
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071016102448.6cc4af82@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
Message-ID: <47163992.6070804@cora.nwra.com>

Jesse Keating wrote:
> The rel-eng team in conjunction with FESCo has developed a proposal for
> changing the development cycle of Fedora.  The goals are to disrupt
> development less frequently, make it easier for maintainers to get
> fixes in, and make it easier for future work to happen without risking
> disruption of a release in progress.
> 
> Please read through
> http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal and follow up on this thread with any questions comments.  I'd like to potentially hold a "town meeting" type of IRC meeting to discuss this proposal with interested parties and address questions/concerns.  However I will delay scheduling such a meeting until discussion has happened here.
> 
> Thanks!
> 
> 

Looking good.  A big thumbs up for early branching, perhaps even earlier 
than the final devel freeze.  Publicize the koji repos for those people 
wanting to test development branch while rawhide is composing the next 
release.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From tmz at pobox.com  Wed Oct 17 16:49:27 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 17 Oct 2007 12:49:27 -0400
Subject: libgpod update for Fedora 7
In-Reply-To: <1192616258.4729.1.camel@cookie.hadess.net>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
Message-ID: <20071017164927.GA5777@psilocybe.teonanacatl.org>

Bastien Nocera wrote:
> You can't get updates-testing packages in the buildroots, so you'd
> be breaking everything in there, unless there's no soname changes.

Perhaps my understanding is wrong then. I thought that with help from
rel-eng, I could build libgpod and get it into the buildroots in order
to rebuild the other packages against?  Then they can all be pushed
together to updates-testing.  Is that not possible?

> Is this a wise thing to do at this stage?

Unless the build system can't do this, I think it is a wise thing to
do.  I'll elaborate in a reply to Ville's mail in a moment.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If I was the King Adrock I'd get stupid dumb,
and if rhymes were valiums I'd be comfortably numb.

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

From tmz at pobox.com  Wed Oct 17 16:50:28 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 17 Oct 2007 12:50:28 -0400
Subject: libgpod update for Fedora 7
In-Reply-To: <200710171842.50159.ville.skytta@iki.fi>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
	<200710171842.50159.ville.skytta@iki.fi>
Message-ID: <20071017165028.GB5777@psilocybe.teonanacatl.org>

Ville Skytt? wrote:
> Also, please post the reasons why the update is so important that it
> warrants potential breakage not only within a released distro
> version in Fedora, but in 3rd party repositories as well.

Sure thing.  libgpod tends to not release as often as a lot of other
projects.  There were quite a large number of features added and bugs
fixed between the release of 0.4.2 (2007/01/15) and 0.5.2
(2005/06/23).  The short list of these changes are included in the
release notes:

http://sourceforge.net/project/shownotes.php?group_id=67873&release_id=518093

For the full ChangeLog differences, see:

http://gtkpod.svn.sourceforge.net/viewvc/gtkpod/libgpod/tags/V0_5_2/ChangeLog?r1=1386&r2=1582

These changes improve the usefulness of the iPods they manage.  The
change to make the ArtworkDB sizes smaller, for example, helps speed
up the iPod's interface a bit (which can be a real problem on larger
iPods with a lot of cover art).  Ditto for the ability to set the sort
order, which allows "The Beatles" to show up under B instead of under
T.

There are also numerous improvements in the python bindings, which
should allow more people to write cool apps for their iPods.  I've
been (slowly) working on a pygtk app to manage the photos on mine, for
instance.

Many of the changes in libgpod are needed by gtkpod, so I am unable to
update gtkpod without a libgpod update.  There have been a similar
number of improvements in gtkpod since the 0.99.8 release that's
included in F-7 currently.  See the short list of improvements and bug
fixes in gtkpod here:

http://sourceforge.net/project/shownotes.php?group_id=67873&release_id=519243

I have tested all of the apps in the F-7 repo with the updated libgpod
and I haven't found any problems from the update.  Quodlibet needs a
small patch to deal with the change in libgpod time functions, which
is already in the rawhide/F-8 quodlibet package.

I'm not sure which 3rd party repos have packages that depend on
libgpod.  There are none in Livna.  If anyone knows of packages in
other 3rd party repositories, let me know.  I'll check them out and
see if they might need more than just a rebuild.  Then I can send a
patch to the maintainer if needed, or just a heads up that an update
is coming.

Generally, I would expect 3rd party repos to be happy to see an
update.  They're more likely to be frustrated with an older version
that doesn't support some brand new app they want to package, I think.

So, I think an update is a good thing for Fedora users.  Hopefully you
don't think I'm too biased (or foolish). :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The only difference between a rut and a grave is the depth.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/19c9c482/attachment.sig>

From ajackson at redhat.com  Wed Oct 17 16:36:32 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 17 Oct 2007 12:36:32 -0400
Subject: 1680 x 1050 with intel driver?
In-Reply-To: <200710171547.54528@rineau.tsetse>
References: <1192575852.6439.13.camel@tiger>
	<1192625943.9104.23.camel@localhost.localdomain>
	<200710171547.54528@rineau.tsetse>
Message-ID: <1192638992.24016.3.camel@localhost.localdomain>

On Wed, 2007-10-17 at 15:47 +0200, Laurent Rineau wrote:
> On Wednesday 17 October 2007 14:59:03 Adam Jackson wrote:
> > On Tue, 2007-10-16 at 19:04 -0400, Louis E Garcia II wrote:
> > > I asked this question on the Xorg list:
> > >
> > > The Dell UltraSharp 2407WFP-HC 24-inch is capable of 1920 x 1200. My
> > > laptop has an Intel Corporation Mobile 945GM/GMS, 943/940GML Express
> > > Integrated Graphics Controller (rev 03) with vga out. Can my video chip
> > > power this monitor?
> >
> > Yes, it can.
> 
> Even through a VGA port? I thought a DVI port was needed for such a 
> resolution.

It depends on the hardware, but in this case yes.  The maximum analog
pixel clock for 915-series hardware is something like 300MHz and
1920x1200 at 60Hz is only ~190MHz.

- ajax



From rdieter at math.unl.edu  Wed Oct 17 16:55:54 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 17 Oct 2007 11:55:54 -0500
Subject: libgpod update for Fedora 7
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
	<20071017164927.GA5777@psilocybe.teonanacatl.org>
Message-ID: <ff5eqq$ns3$1@ger.gmane.org>

Todd Zullinger wrote:

> Bastien Nocera wrote:
>> You can't get updates-testing packages in the buildroots, so you'd
>> be breaking everything in there, unless there's no soname changes.
> 
> Perhaps my understanding is wrong then. I thought that with help from
> rel-eng, I could build libgpod and get it into the buildroots in order
> to rebuild the other packages against?

Your understanding is correct.

-- Rex



From cra at WPI.EDU  Wed Oct 17 17:19:36 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 17 Oct 2007 13:19:36 -0400
Subject: Question on wireless module
In-Reply-To: <loom.20071017T153203-848@post.gmane.org>
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
Message-ID: <20071017171936.GJ4751@angus.ind.WPI.EDU>

On Wed, Oct 17, 2007 at 03:36:07PM +0000, Mike C wrote:
> > ath5k driver has only just stopped panicing the kernel on boot, and is
> > still unstable in some situations.  It will likely get better, but don't
> > bet on ath5k being reliable at this point.
> 
> Thanks - sounds like further work needs to be done before trying this driver.

I've been testing ath5k, and it seems to work fine on open networks 
(no encryption).  However, even a simple WEP key didn't work when I 
tried it earlier this week.  This was configuring wireless the old, 
manual way with NM and wpa_supplicant stopped:

iwconfig wifi0 enc <KEY>
iwconfig wifi0 enc restricted
dhclient wifi0

I tried "open" as well as "restricted", and nothing worked.  When I 
switched back to madwifi, it all works, even with NM.



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 17 17:34:36 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 17 Oct 2007 19:34:36 +0200
Subject: rpms/rpcbind/devel rpcbind.init,1.7,1.8 rpcbind.spec,1.21,1.22
In-Reply-To: <200710171836.25628.ville.skytta@iki.fi>
References: <200710161612.l9GGCQ9H031104@cvs-int.fedora.redhat.com>
	<20071017114043.257c7adf.mschwendt.tmp0701.nospam@arcor.de>
	<200710171836.25628.ville.skytta@iki.fi>
Message-ID: <20071017193436.4b13bd92.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 17 Oct 2007 18:36:25 +0300, Ville Skytt? wrote:

> On Wednesday 17 October 2007, Michael Schwendt wrote:
> > On Tue, 16 Oct 2007 12:12:26 -0400, Steve Dickson (steved) wrote:
> > > Author: steved
> > >
> > > Update of /cvs/pkgs/rpms/rpcbind/devel
> > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31038
> > >
> > > Modified Files:
> > > 	rpcbind.init rpcbind.spec
> > > Log Message:
> > > Corrected a typo in the initscript from previous commit.
> > >
> > >  	# Check that networking is up.
> > > -	[ "$NETWORKING" = "no" ] || exit 6
> > > +	[ "$NETWORKING" = "no" ] && exit 6
> > >  	[ -f /sbin/$prog ] || exit 5
> >
> > Isn't
> >
> > 	[ "$NETWORKING" = "yes" ] || exit 6
> >
> > preferred, so the service is off by default unless networking
> > is turnt on explicitly?
> 
> There have also been opinons that sourcing /etc/sysconfig/network and then 
> testing $NETWORKING to see if networking is available is primarily legacy 
> cruft that should be just removed.
 
Fine.

I don't disagree.

But the initscripts doc files still cover this variable (albeit
without any details), and many initscripts do the ||'n'&& dance based
on its value (albeit without a policy). /etc/init.d/network even
exists with 0 (zero!) when NETWORKING=no, so not evaluating it in
network service scripts would be inconsistent.

Low hanging fruit for Fedora 9?



From jkeating at redhat.com  Wed Oct 17 17:53:02 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 13:53:02 -0400
Subject: rpms/rpcbind/devel rpcbind.init,1.7,1.8 rpcbind.spec,1.21,1.22
In-Reply-To: <20071017193436.4b13bd92.mschwendt.tmp0701.nospam@arcor.de>
References: <200710161612.l9GGCQ9H031104@cvs-int.fedora.redhat.com>
	<20071017114043.257c7adf.mschwendt.tmp0701.nospam@arcor.de>
	<200710171836.25628.ville.skytta@iki.fi>
	<20071017193436.4b13bd92.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071017135302.6903deda@redhat.com>

On Wed, 17 Oct 2007 19:34:36 +0200
Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:

> But the initscripts doc files still cover this variable (albeit
> without any details), and many initscripts do the ||'n'&& dance based
> on its value (albeit without a policy). /etc/init.d/network even
> exists with 0 (zero!) when NETWORKING=no, so not evaluating it in
> network service scripts would be inconsistent.
> 
> Low hanging fruit for Fedora 9?


Yes, I'd like to see an effort to clean up init scripts and set some
policy on them in F9.  We have some bugs currently to make them more
LSB compat, but that was rather terse and without guidelines.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/0199407f/attachment.sig>

From shenson at redhat.com  Wed Oct 17 18:02:22 2007
From: shenson at redhat.com (Scott Henson)
Date: Wed, 17 Oct 2007 14:02:22 -0400
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>
References: <1192559987.2807.3.camel@tiger> <47150A93.2090608@redhat.com>
	<e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>
Message-ID: <ff5irm$7ei$1@ger.gmane.org>

Jon Nettleton wrote:
> On 10/16/07, Zack Cerza <zcerza at redhat.com> wrote:
>> Louis E Garcia II wrote:
>>> when logging on I need to give gnome-keyring the password to unlock even
>>> though I check it so it unlocks automatically. What gives?
>>>
>>> -Louis
>>  From what I understand, the feature isn't complete and depends on [0].
>> Matthias said in [1] that he removed the checkboxes until that work is
>> finished.
>>
> 
> We decided yesterday it would definitely be better to turn that off
> rather than feel the wrath of thousands of people checking that box
> and it not doing anything.  If you don't use a smart card reader or a
> biometric authentication device, you can edit /etc/pam.d/gdm and move
> the
> auth line for pam_gnome_keyring above the system auth include.
> However I take no responsibility for what it could possibly break in
> the future ;-).
> 

Is it possible to use those devices to unlock your gnome-keyring?



From tibbs at math.uh.edu  Wed Oct 17 18:44:44 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 17 Oct 2007 13:44:44 -0500
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18198.9172.818517.660400@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<1192635146.28285.29.camel@Jehannum>
	<18198.9172.818517.660400@zebedee.pink>
Message-ID: <ufabqaxmvhf.fsf@epithumia.math.uh.edu>

>>>>> "AH" == Andrew Haley <aph at redhat.com> writes:

AH> We've been around this before.  It is *vital* that all packages
AH> built with IcedTea are built with -target 1.5.  Otherwise, as you
AH> say, people won't be able to run with most current VMs.  If this
AH> isn't current Fedora policy, it really needs to be.

Someone who understands the issues surrounding Java packaging needs to
sit down and write out some packaging guidelines.  Currently we have
nothing at all, which is really suboptimal.

Just look at the Application Specific Guidelines section at the end
http://fedoraproject.org/wiki/Packaging/Guidelines, create
PackagingDrafts/Java in the same style and bug the packaging
committe.  One of us will volunteer to help drive your submission.

 - J<



From andreas.bierfert at lowlatency.de  Wed Oct 17 18:49:34 2007
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Wed, 17 Oct 2007 20:49:34 +0200
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <1192625781.29602.5.camel@gilboa-work-dev.localdomain>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
	<200710171355.15775.opensource@till.name>
	<1192625781.29602.5.camel@gilboa-work-dev.localdomain>
Message-ID: <20071017204934.145f4093@spica.a.lan>

On Wed, 17 Oct 2007 14:56:21 +0200
Gilboa Davara <gilboad at gmail.com> wrote:
> Looks like a minor packaging problem. (Most likely new stub DLLs)
> 
> error: Installed (but unpackaged) file(s) found:
>    /usr/lib/wine/msvcirt.dll.so
>    /usr/lib/wine/qmgr.dll.so
> 
> 
> RPM build errors:
>     Installed (but unpackaged) file(s) found:
>    /usr/lib/wine/msvcirt.dll.so
>    /usr/lib/wine/qmgr.dll.so

Hi,

I know about the issue but due to being sick an a bit overworked I could not
fix it. Strange thing is: This did not happen on my mock builds so after
test-building and testing the new version a bit I just blindly pushed the
builds. Sorry for the issue I will push new builds tonight.

Regards,
Andreas


-- 
Andreas Bierfert, B.Sc.        | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/37a8c2d9/attachment.sig>

From andreas.bierfert at lowlatency.de  Wed Oct 17 18:56:51 2007
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Wed, 17 Oct 2007 20:56:51 +0200
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <20071017080554.GA13285@wolff.to>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
	<20071017080554.GA13285@wolff.to>
Message-ID: <20071017205651.17acb115@spica.a.lan>

On Wed, 17 Oct 2007 03:05:54 -0500
Bruno Wolff III <bruno at wolff.to> wrote:

> There is typically a bit of delay before new wine packages show up.
> Someitmes particular releases get skipped. (I don't why; that's just what
> I have observed.)

Hi,

releases don't get skipped mostly (if you look at the changelog you will notice
at least for devel). Sometimes they get skipped because of known upstream
issues or because packages sit forever in updates-testing and nobody cares.
Since I sometimes don't have time to do extensive testing I refrain from
upgrading to a broken release. Fell free to take a look at bodhi every now and
then and carma up the packages ;)

Regards,
Andreas

-- 
Andreas Bierfert, B.Sc.        | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/ca455dc3/attachment.sig>

From dcbw at redhat.com  Wed Oct 17 19:23:11 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 17 Oct 2007 15:23:11 -0400
Subject: Question on wireless module
In-Reply-To: <20071017171936.GJ4751@angus.ind.WPI.EDU>
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
	<20071017171936.GJ4751@angus.ind.WPI.EDU>
Message-ID: <1192648991.14276.21.camel@localhost.localdomain>

On Wed, 2007-10-17 at 13:19 -0400, Chuck Anderson wrote:
> On Wed, Oct 17, 2007 at 03:36:07PM +0000, Mike C wrote:
> > > ath5k driver has only just stopped panicing the kernel on boot, and is
> > > still unstable in some situations.  It will likely get better, but don't
> > > bet on ath5k being reliable at this point.
> > 
> > Thanks - sounds like further work needs to be done before trying this driver.
> 
> I've been testing ath5k, and it seems to work fine on open networks 
> (no encryption).  However, even a simple WEP key didn't work when I 
> tried it earlier this week.  This was configuring wireless the old, 
> manual way with NM and wpa_supplicant stopped:
> 
> iwconfig wifi0 enc <KEY>
> iwconfig wifi0 enc restricted
> dhclient wifi0
> 
> I tried "open" as well as "restricted", and nothing worked.  When I 
> switched back to madwifi, it all works, even with NM.

Latest rawhide kernels (-6.f8) hang my AR5006X machine on startup when
NM starts scanning.  Insmoding the driver after bootup works, but
another rmmod/insmod loop hangs.  It doesn't actually _freeze_, but the
keyboard is unresponsive and there are no messages about oops or panic
on the console.

Dan




From mike.cohler at gmail.com  Wed Oct 17 19:29:05 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 17 Oct 2007 19:29:05 +0000 (UTC)
Subject: Question on wireless module
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
	<loom.20071017T153203-848@post.gmane.org>
	<20071017171936.GJ4751@angus.ind.WPI.EDU>
Message-ID: <loom.20071017T192657-547@post.gmane.org>

Chuck Anderson <cra <at> WPI.EDU> writes:

> I've been testing ath5k, and it seems to work fine on open networks 
> (no encryption).  However, even a simple WEP key didn't work when I 
> tried it earlier this week.  This was configuring wireless the old, 
> manual way with NM and wpa_supplicant stopped:

I have not tried ath5k but I guess it would behave much the same for me.

I have now installed the rawhide kernel 2.6.23-6.fc8 with much the same results
on instability as with the F7 kernel.
Bugzilla report at https://bugzilla.redhat.com/show_bug.cgi?id=334951





From jspaleta at gmail.com  Wed Oct 17 19:59:27 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Oct 2007 11:59:27 -0800
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
In-Reply-To: <4715D632.80403@poolshark.org>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
Message-ID: <604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>

On 10/17/07, Denis Leroy <denis at poolshark.org> wrote:
> A good idea, but not a simple one to implement. How would you
> communicate the information to the package management tool ? The tool
> couldn't distinguish between an Obsolete caused by an orphan versus one
> caused by, say, a package rename. Maybe a RSS feed of some sort ?

how does the package tool know that some updates are security fixes?

-jef



From tcallawa at redhat.com  Wed Oct 17 20:09:12 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 17 Oct 2007 16:09:12 -0400
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-14
In-Reply-To: <20071014230613.A28552@humbolt.us.dell.com>
References: <20071014230613.A28552@humbolt.us.dell.com>
Message-ID: <1192651752.3699.80.camel@localhost.localdomain>


On Sun, 2007-10-14 at 23:06 -0500, Matt Domsch wrote:
> Fedora Rawhide-in-Mock Build Results for i386 Sun Oct 14 22:44:53 CDT 2007

Matt, how much memory/swap do your builders have? You might need to up
it.

> Pixie-2.2.2-2.fc8 (build/make) kwizart

Reason: virtual memory exhausted: Cannot allocate memory

~spot



From jkeating at redhat.com  Wed Oct 17 20:18:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 16:18:35 -0400
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
 2007-10-16
In-Reply-To: <604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
	<604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
Message-ID: <20071017161835.787270f9@redhat.com>

On Wed, 17 Oct 2007 11:59:27 -0800
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> how does the package tool know that some updates are security fixes?

Via the update-info that is added into yum repodata.  We aren't quite
producing that yet I don't think, luke has been working on reviving
that within bodhi.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/99063762/attachment.sig>

From jspaleta at gmail.com  Wed Oct 17 20:30:35 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Oct 2007 12:30:35 -0800
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
In-Reply-To: <20071017161835.787270f9@redhat.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
	<604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
	<20071017161835.787270f9@redhat.com>
Message-ID: <604aa7910710171330v4912880coa8a369ec36b47023@mail.gmail.com>

On 10/17/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 17 Oct 2007 11:59:27 -0800
> "Jeff Spaleta" <jspaleta at gmail.com> wrote:
>
> > how does the package tool know that some updates are security fixes?
>
> Via the update-info that is added into yum repodata.  We aren't quite
> producing that yet I don't think, luke has been working on reviving
> that within bodhi.

So the question becomes, as currently designed, does the repodata
extend to include package-info that is not tied to the name of a
package and not the specific n-v-r? If we had repodata info that was
tied to a package name only we could most definitely send out notices
to users when packages orphan and/or expire.

-jef



From jspaleta at gmail.com  Wed Oct 17 20:33:53 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Oct 2007 12:33:53 -0800
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
In-Reply-To: <604aa7910710171330v4912880coa8a369ec36b47023@mail.gmail.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
	<604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
	<20071017161835.787270f9@redhat.com>
	<604aa7910710171330v4912880coa8a369ec36b47023@mail.gmail.com>
Message-ID: <604aa7910710171333x4f1e32efs88aec3bc2b2bfe29@mail.gmail.com>

On 10/17/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
> So the question becomes, as currently designed, does the repodata
> extend to include package-info that is not tied to the name of a
> package and not the specific n-v-r? If we had repodata info that was
> tied to a package name only we could most definitely send out notices
> to users when packages orphan and/or expire.

Sorry I hit send a little too soon, I added an extra 'not' in one of
those sentences.
I'll re-summarize for people i just confused.
repodata update-info  such as 'security update' ties to a packages n-v-r  right?
can we tie repodata info to package name regardless of version and release?

-jef



From peter at thecodergeek.com  Wed Oct 17 20:43:10 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 17 Oct 2007 13:43:10 -0700
Subject: rpms/gnome-compiz-manager/devel .cvsignore, 1.2, 1.3
	gnome-compiz-manager.spec, 1.1, 1.2 sources, 1.2, 1.3
In-Reply-To: <200710170626.l9H6QAln032296@cvs-int.fedora.redhat.com>
References: <200710170626.l9H6QAln032296@cvs-int.fedora.redhat.com>
Message-ID: <1192653790.3405.5.camel@localhost.localdomain>

On Wed, 2007-10-17 at 02:26 -0400, John Patrick Mahowald wrote:
> --- .cvsignore	18 Aug 2007 23:07:30 -0000	1.2
> +++ .cvsignore	17 Oct 2007 06:25:38 -0000	1.3
> @@ -1 +1,2 @@
>  gnome-compiz-manager-0.10.4.tar.gz
> +desktop.png

While it's not strictly required (AFAIK), please prefix extra sources
with the name of the package (such as %{name}-desktop.png or similar),
to minimize conflicts when installing multiple source RPMs to the same
build tree.

Also, please use "cp -p" when copying it to the buildroot to ensure that
the timestamps and whatnot are preserved.

Thanks.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071017/156c5198/attachment.sig>

From Matt_Domsch at dell.com  Wed Oct 17 20:44:25 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 17 Oct 2007 15:44:25 -0500
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-14
In-Reply-To: <1192651752.3699.80.camel@localhost.localdomain>
References: <20071014230613.A28552@humbolt.us.dell.com>
	<1192651752.3699.80.camel@localhost.localdomain>
Message-ID: <20071017204425.GA1897@auslistsprd01.us.dell.com>

On Wed, Oct 17, 2007 at 04:09:12PM -0400, Tom spot Callaway wrote:
> 
> On Sun, 2007-10-14 at 23:06 -0500, Matt Domsch wrote:
> > Fedora Rawhide-in-Mock Build Results for i386 Sun Oct 14 22:44:53 CDT 2007
> 
> Matt, how much memory/swap do your builders have? You might need to up
> it.
> 
> > Pixie-2.2.2-2.fc8 (build/make) kwizart
> 
> Reason: virtual memory exhausted: Cannot allocate memory

This particular box has 2GB RAM + 2GB swap, but it had 4 mock builds
running in parallel.

It still failed on x86_64:
 g++: Internal error: Killed (program cc1plus)

so it wasn't an OOM killer that killed it on i386, it ran out of
virtual memory space.  On x86_64 it couldn't, so failed differently.
I suspect they're related.  and yes it may be a g++ bug this package
tickles.

-Matt


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From roland at redhat.com  Wed Oct 17 20:57:31 2007
From: roland at redhat.com (Roland McGrath)
Date: Wed, 17 Oct 2007 13:57:31 -0700 (PDT)
Subject: debugedit exits with a SIGSEGV
In-Reply-To: Joost van der Sluis's message of  Wednesday,
	17 October 2007 14:41:35 +0200
	<1192624895.28698.12.camel@wsjoost.cnoc.local>
References: <1192624895.28698.12.camel@wsjoost.cnoc.local>
Message-ID: <20071017205731.5404B4D04E2@magilla.localdomain>

Ouch!  I'll look into this.



From loganjerry at gmail.com  Wed Oct 17 21:04:56 2007
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 17 Oct 2007 15:04:56 -0600
Subject: pm-utils list in s-c-p on F-7 i386
Message-ID: <870180fe0710171404m6f6e226bm2491d7f83a3049b9@mail.gmail.com>

system-config-packages on an F-7 i386 box is showing this:

pm-utils - 0.99.3-6.fc7.i586
pm-utils - 0.99.3-6.fc7.athlon
pm-utils - 0.99.3-6.fc7.i686
pm-utils - 0.99.4-3.fc7.i386

I assume that the first 3 should not be listed.  Is this a known issue?
-- 
Jerry James
http://loganjerry.googlepages.com/



From bnocera at redhat.com  Wed Oct 17 22:54:56 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 17 Oct 2007 23:54:56 +0100
Subject: Question on wireless module
In-Reply-To: <1192629622.10567.22.camel@localhost.localdomain>
References: <loom.20071017T105100-379@post.gmane.org>
	<1192629622.10567.22.camel@localhost.localdomain>
Message-ID: <1192661696.2843.7.camel@cookie.hadess.net>


On Wed, 2007-10-17 at 10:00 -0400, Dan Williams wrote:
> On Wed, 2007-10-17 at 10:58 +0000, Mike C wrote:
> > I have recently been testing the rt2x00 driver and specifically the rt73usb
> > component with a usb wireless adapter, using the test kernels currently
> > available for F7 in updates-testing.
> > 
> > However the wireless link is very unstable and throws streams of messages at the
> > terminal as well as in the alternative consoles. I reported this in bugzilla.
> > 
> > The question I have is whether the version of rt2x00 (and rt73usb) in rawhide is
> > nearer to being usable than the driver in the F7 kernels? Therefore another
> > question is whether it would be likely to work if I simply installed the rawhide
> > current kernel into F7 (and maybe the rawhide wpa_supplicant also?) and see if
> > that would give more stability?  
> 
> I have an rt73usb device that's been working pretty consistently with
> rawhide kernels for the past 3 weeks (Belkin F5D7050 ver 1000).  I
> haven't had kernel oopses with it, and it seems to do fine with light
> traffic (and even yum upgrades).

I really can't say I've had that much luck. It worked fine doing yum
upgrades, but slowed down to a crawl accessing some sites like
bugzilla.redhat.com. Switching back to rt73, or accessing the same site
with my laptop worked just fine.

I'm not sure what information one can draw from that, but, as usual,
trying out version+1 of the kernel is more useful than reporting kernel
bugs.



From rapponcape at gmail.com  Wed Oct 17 23:33:13 2007
From: rapponcape at gmail.com (rapponcape)
Date: Wed, 17 Oct 2007 19:33:13 -0400
Subject: removable storage devices still do not auto-mount
Message-ID: <55df67120710171633n54a6e3ads6454573cbec1d517@mail.gmail.com>

I continue to have trouble with removable usb memory sticks not
auto-mounting with Fedora.  Had problem on FC6( auto-mounted
the stick once, then never again) and now, after a fresh install of
FC7, the same problem.  Hal output always ends with "scsi.type is
unknown" "Not adding device object", but, other indicators show that
the device is recognized and present.  I can mount it manually.

I've removed the following file, as some suggested, but still no luck
/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi

This seems to be an ongoing problem. Can anyone shed any light on this?
The hal dev group had nothing for me.

What's up??

Thanks.
=============== info follows ==================

FC7 ships with the following udev rules.

05-udev-early.rules:
# sysfs is populated after the event is sent
ACTION=="add", KERNEL=="[0-9]*:[0-9]*", SUBSYSTEM=="scsi",
WAIT_FOR_SYSFS="ioerr_cnt"

---------

===================
kernel message output is:

Oct 14 11:19:45 localhost kernel: usb 1-1: new full speed USB device
using uhci_hcd and address 9
Oct 14 11:19:48 localhost kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct 14 11:19:48 localhost kernel: scsi8 : SCSI emulation for USB Mass
Storage devices
Oct 14 11:19:54 localhost kernel: scsi 8:0:0:0: Direct-Access
SanDisk  Cruzer Micro     0.1  PQ: 0 ANSI: 2
Oct 14 11:19:56 localhost kernel: sd 8:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 14 11:19:56 localhost kernel: sd 8:0:0:0: [sdb] Write Protect is off
Oct 14 11:19:56 localhost kernel: sd 8:0:0:0: [sdb] Assuming drive
cache: write through
Oct 14 11:19:59 localhost kernel: sd 8:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 14 11:20:00 localhost kernel: sd 8:0:0:0: [sdb] Write Protect is off
Oct 14 11:20:00 localhost kernel: sd 8:0:0:0: [sdb] Assuming drive
cache: write through
Oct 14 11:20:01 localhost kernel:  sdb: sdb1
Oct 14 11:20:01 localhost kernel: sd 8:0:0:0: [sdb] Attached SCSI removable disk
Oct 14 11:20:01 localhost kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0

===================


Running hal in debug produces the following output:

===========
:04:11.731 [I] osspec.c:232: SEQNUM=877, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1,
DEVNAME=/dev/bus/usb/001/007, IFINDEX=0
11:04:11.732 [E] hotplug.c:94: devpath
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1 already present in the
store, ignore event


11:04:11.843 [I] osspec.c:232: SEQNUM=878, ACTION=add,
SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.7_ep00,
DEVNAME=/dev/bus/usb/1/7_ep/00, IFINDEX=0
11:04:11.843 [I] hotplug.c:134: /sys/class/usb_endpoint/usbdev1.7_ep00
is a device (subsystem)
11:04:11.843 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.7_ep00'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
11:04:11.844 [I] device.c:3319: add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.7_ep00
dev=/dev/bus/usb/1/7_ep/00 parent_dev=0x09f06da0



11:04:12.185 [I] osspec.c:232: SEQNUM=879, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0,
DEVNAME=, IFINDEX=0
11:04:12.185 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 is a device
(subsystem)
11:04:12.186 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
11:04:12.186 [I] device.c:3319: add_dev: subsys=usb
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 dev=
parent_dev=0x09f06da0
11:04:12.186 [E] util.c:382: Cannot open
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/interface'
11:04:12.208 [E] device_info.c:272: Could not resolve keypath
'@block.storage_device:storage.hotpluggable' on udi 'false'
11:04:12.208 [I] device.c:3181: Add callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
11:04:12.208 [I] hald.c:103: Added device to GDL;
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
11:04:12.304 [I] osspec.c:232: SEQNUM=880, ACTION=add,
SUBSYSTEM=scsi_host, DEVPATH=/sys/class/scsi_host/host6, DEVNAME=,
IFINDEX=0
11:04:12.304 [I] hotplug.c:134: /sys/class/scsi_host/host6 is a device
(subsystem)
11:04:12.304 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/scsi_host/host6'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
11:04:12.304 [I] device.c:3319: add_dev: subsys=scsi_host
sysfs_path=/sys/class/scsi_host/host6 dev= parent_dev=0x09f151a0
11:04:12.316 [I] osspec.c:232: SEQNUM=882, ACTION=add,
SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.7_ep01,
DEVNAME=/dev/bus/usb/1/7_ep/01, IFINDEX=0
11:04:12.316 [I] hotplug.c:134: /sys/class/usb_endpoint/usbdev1.7_ep01
is a device (subsystem)
11:04:12.316 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.7_ep01'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
11:04:12.316 [I] device.c:3319: add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.7_ep01
dev=/dev/bus/usb/1/7_ep/01 parent_dev=0x09f151a0
11:04:12.325 [I] osspec.c:232: SEQNUM=881, ACTION=add,
SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.7_ep81,
DEVNAME=/dev/bus/usb/1/7_ep/81, IFINDEX=0
11:04:12.325 [I] hotplug.c:134: /sys/class/usb_endpoint/usbdev1.7_ep81
is a device (subsystem)
11:04:12.326 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.7_ep81'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
11:04:12.326 [I] device.c:3319: add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.7_ep81
dev=/dev/bus/usb/1/7_ep/81 parent_dev=0x09f151a0
11:04:12.448 [I] osspec.c:232: SEQNUM=883, ACTION=add,
SUBSYSTEM=usb_device, DEVPATH=/sys/class/usb_device/usbdev1.7,
DEVNAME=/dev/bus/usb/001/007, IFINDEX=0
11:04:12.448 [I] hotplug.c:134: /sys/class/usb_device/usbdev1.7 is a
device (subsystem)
11:04:12.449 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/usb_device/usbdev1.7'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
11:04:12.449 [I] device.c:3319: add_dev: subsys=usb_device
sysfs_path=/sys/class/usb_device/usbdev1.7 dev=/dev/bus/usb/001/007
parent_dev=0x09f06da0
11:04:12.451 [I] device_info.c:501: Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'camera'
11:04:12.451 [I] device_info.c:501: Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'scanner'
11:04:12.452 [E] device_info.c:272: Could not resolve keypath
'@block.storage_device:storage.hotpluggable' on udi 'false'
11:04:12.452 [I] device.c:3181: Add callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
11:04:12.452 [I] hald.c:103: Added device to GDL;
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
[3211]: 11:04:13.895 [I] addon-storage.c:346: Checking whether device
/dev/scd0 is locked on HAL
[3211]: 11:04:13.896 [I] addon-storage.c:354: ... device /dev/scd0 is
not locked on HAL
[3227]: 11:04:14.059 [I] addon-storage.c:346: Checking whether device
/dev/scd1 is locked on HAL
[3227]: 11:04:14.060 [I] addon-storage.c:354: ... device /dev/scd1 is
not locked on HAL
11:04:21.203 [I] osspec.c:232: SEQNUM=884, ACTION=add, SUBSYSTEM=scsi,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0,
DEVNAME=, IFINDEX=0
11:04:21.203 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0
is a device (subsystem)
11:04:21.204 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
11:04:21.204 [I] device.c:3319: add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0
dev= parent_dev=0x09f151a0
11:04:21.204 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
11:04:21.204 [I] device.c:3319: add_dev: subsys=scsi_host
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6
dev= parent_dev=0x09f151a0
11:04:21.209 [E] device_info.c:272: Could not resolve keypath
'@block.storage_device:storage.hotpluggable' on udi 'false'
11:04:21.210 [I] device.c:3181: Add callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
11:04:21.210 [I] hald.c:103: Added device to GDL;
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
11:04:21.225 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6'
11:04:21.225 [I] device.c:3319: add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0
dev= parent_dev=0x09f08e20
11:04:21.226 [E] util.c:382: Cannot open
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/model'
11:04:21.236 [E] util.c:382: Cannot open
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/vendor'
11:04:21.236 [E] util.c:190: Cannot open
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/type'
11:04:21.236 [I] device.c:1969:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/type
-> -1081868168 (-> scsi.type)
11:04:21.239 [E] device_info.c:272: Could not resolve keypath
'@block.storage_device:storage.hotpluggable' on udi 'false'
11:04:21.239 [I] device.c:3181: Add callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
11:04:21.239 [I] hald.c:103: Added device to GDL;
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
11:04:21.359 [I] osspec.c:232: SEQNUM=885, ACTION=add,
SUBSYSTEM=scsi_disk, DEVPATH=/sys/class/scsi_disk/6:0:0:0, DEVNAME=,
IFINDEX=0
11:04:21.360 [I] hotplug.c:134: /sys/class/scsi_disk/6:0:0:0 is a
device (subsystem)
11:04:21.360 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/scsi_disk/6:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'
11:04:21.361 [I] device.c:3319: add_dev: subsys=scsi_disk
sysfs_path=/sys/class/scsi_disk/6:0:0:0 dev= parent_dev=0x09f08f70
[3211]: 11:04:21.895 [I] addon-storage.c:346: Checking whether device
/dev/scd0 is locked on HAL
[3211]: 11:04:21.897 [I] addon-storage.c:354: ... device /dev/scd0 is
not locked on HAL
[3227]: 11:04:22.059 [I] addon-storage.c:346: Checking whether device
/dev/scd1 is locked on HAL
[3227]: 11:04:22.061 [I] addon-storage.c:354: ... device /dev/scd1 is
not locked on HAL
11:04:24.498 [I] osspec.c:232: SEQNUM=889, ACTION=add,
SUBSYSTEM=scsi_generic, DEVPATH=/sys/class/scsi_generic/sg3,
DEVNAME=/dev/sg3, IFINDEX=0
11:04:24.499 [I] hotplug.c:134: /sys/class/scsi_generic/sg3 is a
device (subsystem)
11:04:24.499 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/scsi_generic/sg3'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'
11:04:24.499 [I] device.c:3319: add_dev: subsys=scsi_generic
sysfs_path=/sys/class/scsi_generic/sg3 dev=/dev/sg3
parent_dev=0x09f08f70
11:04:24.502 [E] device_info.c:272: Could not resolve keypath
'@block.storage_device:storage.hotpluggable' on udi 'false'
11:04:24.502 [I] device.c:3181: Add callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
11:04:24.502 [I] hald.c:103: Added device to GDL;
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
11:04:24.706 [I] osspec.c:232: SEQNUM=888, ACTION=add,
SUBSYSTEM=scsi_device, DEVPATH=/sys/class/scsi_device/6:0:0:0,
DEVNAME=, IFINDEX=0
11:04:24.707 [I] hotplug.c:134: /sys/class/scsi_device/6:0:0:0 is a
device (subsystem)
11:04:24.708 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/class/scsi_device/6:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'
11:04:24.708 [I] device.c:3319: add_dev: subsys=scsi_device
sysfs_path=/sys/class/scsi_device/6:0:0:0 dev= parent_dev=0x09f08f70
11:04:25.157 [I] osspec.c:232: SEQNUM=886, ACTION=add,
SUBSYSTEM=block, DEVPATH=/sys/block/sdb, DEVNAME=/dev/sdb, IFINDEX=0
11:04:25.158 [I] osspec.c:892: hal_util_find_known_parent:
'/sys/block/sdb'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0'
11:04:25.158 [I] blockdev.c:645: block_add: sysfs_path=/sys/block/sdb
dev=/dev/sdb is_part=0, parent=0x09f08f70
11:04:25.159 [I] blockdev.c:951: parent_bus is scsi
11:04:25.159 [W] blockdev.c:990: scsi.type is unknown
11:04:25.159 [W] blockdev.c:1151: Not adding device object
[3211]: 11:04:25.895 [I] addon-storage.c:346: Checking whether device
/dev/scd0 is locked on HAL
[3211]: 11:04:25.897 [I] addon-storage.c:354: ... device /dev/scd0 is
not locked on HAL
[3227]: 11:04:26.059 [I] addon-storage.c:346: Checking whether device
/dev/scd1 is locked on HAL
[3227]: 11:04:26.061 [I] addon-storage.c:354: ... device /dev/scd1 is
not locked on HAL

===========

udevmonitor produces:


UEVENT[1192374736.724415] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
UEVENT[1192374736.724862] add      /class/usb_endpoint/usbdev1.8_ep00
(usb_endpoint)
UDEV  [1192374736.732817] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
UDEV  [1192374736.854122] add      /class/usb_endpoint/usbdev1.8_ep00
(usb_endpoint)
UEVENT[1192374736.974401] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UEVENT[1192374736.981475] add      /class/scsi_host/host7 (scsi_host)
UEVENT[1192374736.983058] add      /class/usb_endpoint/usbdev1.8_ep81
(usb_endpoint)
UEVENT[1192374736.984133] add      /class/usb_endpoint/usbdev1.8_ep01
(usb_endpoint)
UEVENT[1192374736.985998] add      /class/usb_device/usbdev1.8 (usb_device)
UDEV  [1192374737.188546] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UDEV  [1192374737.297828] add      /class/scsi_host/host7 (scsi_host)
UDEV  [1192374737.305961] add      /class/usb_endpoint/usbdev1.8_ep81
(usb_endpoint)
UDEV  [1192374737.313694] add      /class/usb_endpoint/usbdev1.8_ep01
(usb_endpoint)
UDEV  [1192374737.448602] add      /class/usb_device/usbdev1.8 (usb_device)
UEVENT[1192374742.977513] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host7/target7:0:0/7:0:0:0
(scsi)
UEVENT[1192374742.981429] add      /class/scsi_disk/7:0:0:0 (scsi_disk)
UDEV  [1192374746.102740] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host7/target7:0:0/7:0:0:0
(scsi)
UDEV  [1192374746.212032] add      /class/scsi_disk/7:0:0:0 (scsi_disk)
UEVENT[1192374749.475701] add      /block/sdb (block)
UEVENT[1192374749.475863] add      /block/sdb/sdb1 (block)
UEVENT[1192374749.480640] add      /class/scsi_device/7:0:0:0 (scsi_device)
UEVENT[1192374749.481632] add      /class/scsi_generic/sg3 (scsi_generic)
UDEV  [1192374749.526717] add      /class/scsi_generic/sg3 (scsi_generic)
UDEV  [1192374749.738637] add      /class/scsi_device/7:0:0:0 (scsi_device)
UDEV  [1192374750.142546] add      /block/sdb (block)
UDEV  [1192374762.080633] add      /block/sdb/sdb1 (block)

=================


UEVENT[1192374736.724415] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
UEVENT[1192374736.724862] add      /class/usb_endpoint/usbdev1.8_ep00
(usb_endpoint)
UDEV  [1192374736.732817] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
UDEV  [1192374736.854122] add      /class/usb_endpoint/usbdev1.8_ep00
(usb_endpoint)
UEVENT[1192374736.974401] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UEVENT[1192374736.981475] add      /class/scsi_host/host7 (scsi_host)
UEVENT[1192374736.983058] add      /class/usb_endpoint/usbdev1.8_ep81
(usb_endpoint)
UEVENT[1192374736.984133] add      /class/usb_endpoint/usbdev1.8_ep01
(usb_endpoint)
UEVENT[1192374736.985998] add      /class/usb_device/usbdev1.8 (usb_device)
UDEV  [1192374737.188546] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UDEV  [1192374737.297828] add      /class/scsi_host/host7 (scsi_host)
UDEV  [1192374737.305961] add      /class/usb_endpoint/usbdev1.8_ep81
(usb_endpoint)
UDEV  [1192374737.313694] add      /class/usb_endpoint/usbdev1.8_ep01
(usb_endpoint)
UDEV  [1192374737.448602] add      /class/usb_device/usbdev1.8 (usb_device)
UEVENT[1192374742.977513] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host7/target7:0:0/7:0:0:0
(scsi)
UEVENT[1192374742.981429] add      /class/scsi_disk/7:0:0:0 (scsi_disk)
UDEV  [1192374746.102740] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host7/target7:0:0/7:0:0:0
(scsi)
UDEV  [1192374746.212032] add      /class/scsi_disk/7:0:0:0 (scsi_disk)
UEVENT[1192374749.475701] add      /block/sdb (block)
UEVENT[1192374749.475863] add      /block/sdb/sdb1 (block)
UEVENT[1192374749.480640] add      /class/scsi_device/7:0:0:0 (scsi_device)
UEVENT[1192374749.481632] add      /class/scsi_generic/sg3 (scsi_generic)
UDEV  [1192374749.526717] add      /class/scsi_generic/sg3 (scsi_generic)
UDEV  [1192374749.738637] add      /class/scsi_device/7:0:0:0 (scsi_device)
UDEV  [1192374750.142546] add      /block/sdb (block)
UDEV  [1192374762.080633] add      /block/sdb/sdb1 (block)

-------------------------------------------------------------------------


=================
 /sbin/lsusb
Bus 001 Device 009: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB
Flash Drive


=================



From david at fubar.dk  Wed Oct 17 23:57:58 2007
From: david at fubar.dk (David Zeuthen)
Date: Wed, 17 Oct 2007 19:57:58 -0400
Subject: removable storage devices still do not auto-mount
In-Reply-To: <55df67120710171633n54a6e3ads6454573cbec1d517@mail.gmail.com>
References: <55df67120710171633n54a6e3ads6454573cbec1d517@mail.gmail.com>
Message-ID: <1192665478.7047.1.camel@oneill.fubar.dk>


On Wed, 2007-10-17 at 19:33 -0400, rapponcape wrote:
> What's up??

If you can reproduce this from, say, a F8t3 live cd then please file a
bug against the 'hal' component. I remember most of these bugs happened
when Harald changed the udev rules; maybe there's some old cruft laying
around on your system.

      David




From darrellpf at gmail.com  Thu Oct 18 02:15:20 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 17 Oct 2007 19:15:20 -0700
Subject: java release notes for FC8
Message-ID: <f6e5806f0710171915w34342564g6787fe6db000f45e@mail.gmail.com>

Current rawhide has a severe bug that affects all Sun Java
implementations including the jdk1.7.0 betas.

https://bugzilla.redhat.com/show_bug.cgi?id=254144

The bug causes any Java application to die when it attempts to do graphics.

The current workaround for the bug is to run icedtea.

I'm not sure that there will be a resolution any time soon. If the bug
isn't fixed for FC8, the release notes should clearly indicate that
icedtea is the only Java implementation that will work.



From buildsys at redhat.com  Thu Oct 18 02:34:19 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 17 Oct 2007 22:34:19 -0400
Subject: rawhide report: 20071017 changes
Message-ID: <200710180234.l9I2YJOb000797@porkchop.devel.redhat.com>

New package culmus-fonts
	Fonts for Hebrew from Culmus project

New package kacst-fonts
	Fonts for arabic from arabeyes project

New package lklug-fonts
	Fonts for Sinhala language

New package madan-fonts
	Font for Nepali language

New package paktype-fonts
	Fonts for Arabic from PakType

New package perl-Class-Date
	Class for easy date and time manipulation

New package xorg-x11-drv-radeonhd
	Xorg X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets


 
Updated Packages:

NetworkManager-1:0.7.0-0.3.svn2983.fc8
--------------------------------------
* Tue Oct 16 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2983
- Add rfkill functionality
- Fix applet crash when choosing wired networks from the menu

ORBit2-2.14.10-2.fc8
--------------------
* Tue Oct 16 2007 Dennis Gilmore <dennis at ausil.us> - 2.14.10-2
- add sparc64 to the list  of 64 bit archs

Pixie-2.2.2-4.fc8
-----------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 2.2.2-4
- Fix namespace with show (renamed to Pixie_show).

bind-32:9.5.0-15.a6.fc8
-----------------------
* Tue Oct 16 2007 Adam Tkac <atkac redhat com> 32:9.5.0-15.a6
- corrected named.5 SDB statement (#326051)

blender-2.45-4.fc8
------------------
* Tue Oct 16 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.45-4
- Rebuild again for OpenEXR

bzflag-2.0.8-8.fc8
------------------
* Wed Oct 17 2007 Nils Philippsen <nphilipp at redhat.com> 2.0.8-8
- really use opengl-games-wrapper.sh from Fedora 7 on (#304781)

* Tue Oct 16 2007 Nils Philippsen <nphilipp at redhat.com> 2.0.8-7
- use opengl-games-wrapper.sh from Fedora 7 on (#304781)

codeina-0.10.1-5.fc8
--------------------
* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 0.10.1-5
- Fix #325231:
  + Remove excessive branding
  + Change the wording of the dialog
  + Add a link

compat-gcc-34-3.4.6-8
---------------------
* Tue Oct 16 2007 Jakub Jelinek  <jakub at redhat.com> 3.4.6-8
- update License tag
- build with ld --build-id
- grok makeinfo >= 4.10 during configury
- avoid aliasing warnings in libstdc++-v3 headers when compiled
  with g++ 4.x (Paolo Carlini, PR libstdc++/24975, #240020)
- fix RTL expansion of COMPLEX_EXPR (#233941)
- fix deque<>::erase(iterator, iterator) (Steve LoBasso,
  Paolo Carlini, #234515)
- fix french and kinyarwanda translations (#235008)
- handle PARALLELs in GCSE store motion (Alexandre Oliva, #235255)
- ensure zero termination for invalid, overly long, std::__enc_traits
  internal or external character set names (Jatin Nansi, #242685)
elfutils-0.130-3.fc8
--------------------
* Wed Oct 17 2007 Roland McGrath <roland at redhat.com> - 0.130-3
- Fix ET_REL support.
- Fix odd indentation in eu-readelf -x output.

* Tue Oct 16 2007 Roland McGrath <roland at redhat.com> - 0.130-1
- Update to 0.130
  - eu-readelf -p option can take an argument like -x for one section
  - eu-readelf --archive-index (or -c)
  - eu-readelf -n improved output for core dumps
  - eu-readelf: handle SHT_NOTE sections without requiring phdrs (#249467)
  - eu-elflint: ditto
  - eu-elflint: stricter checks on debug sections
  - eu-unstrip: new options, --list (or -n), --relocate (or -R)
  - libelf: new function elf_getdata_rawchunk, replaces gelf_rawchunk;
	    new functions gelf_getnote, gelf_getauxv, gelf_update_auxv
  - libebl: backend improvements (#324031)
  - libdwfl: build_id support, new functions for it
  - libdwfl: dwfl_module_addrsym fixes (#268761, #268981)
  - libdwfl offline archive support, new script eu-make-debug-archive

empathy-0.14-3.fc8
------------------
* Tue Oct 16 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-3
- Depend on Salut and Gabble to enable XMPP by default. Otherwise, Empathy
  is essentially useless due to the need to install an external connection
  manager. Also, add a README.ConnectionManagers to the installed
  documentation which lists other possibilities.
- Resolves: bug 308871 (Make empathy dependent at least on telepathy-gabble)
  and bug 334221 (Default empathy install is useless).

epiphany-2.20.1-2.fc8
---------------------
* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Add patch to allow epiphany to use the plugins wrapped by
  nspluginwrapper (#334751)

* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Fix network status monitoring with new NM (#332771)

epiphany-extensions-2.20.1-1.fc8
--------------------------------
* Mon Oct 15 2007 Peter Gordon <peter at thecodergeek.com> - 2.20.1-1
- Update to new upstream release (2.20.1), which fixes the "About" dialog of
  the AdBlocker extension and contains updated translations for Thai (th) and
  Catalan (ca). 
- Use the system libtool for building, to avoid unnecessary RPATH inclusions.

evolution-data-server-1.12.1-2.fc8
----------------------------------
* Tue Oct 16 2007 Matthew Barnes <mbarnes at redhat.com> - 1.12.1-2.fc8
- Disable patch for GNOME bug #376991 for now.  It may be contributing
  to password prompting problems as described in RH bug #296671.

fedora-logos-7.96.0-1.fc8
-------------------------
* Tue Oct 16 2007 Ray Strode <rstrode at redhat.com> - 7.96.0-1
- Fix up some %install goo
- drop bluecurve kdm fedora logo images too

* Tue Oct 16 2007 Ray Strode <rstrode at redhat.com> - 7.95.0-1
- actually drop bluecurve gdm fedora logo images that aren't trademarked

fedorainfinity-gdm-theme-8.0.1-1.fc8
------------------------------------

fonts-arabic-2.1-1.fc8
----------------------
* Wed Oct 17 2007 Rahul Bhalerao <rbhalera at redhat.com> - 2.1-1.fc8
- This package is now metapackage since kacst and paktype fonts have been moved to their separate packages

fonts-hebrew-0.101-1.fc8
------------------------
* Wed Oct 17 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.101-1.fc8
- This is now a metapackage since Culmus fonts were moved to a separate package

* Fri Jul 27 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.100-5.fc8
- SPEC cleanup as part of merge review #225762

* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 0.100-4.1.1
- rebuild

fonts-sinhala-0.2.2-2.fc8
-------------------------
* Wed Oct 17 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.2.2-2
- This package is now metapackage since lklug-fonts have been moved to its separate package

funtools-1.4.0-3.fc8
--------------------
* Tue Oct 16 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 1.4.0-3
- Fixing wcs headers

gcc-4.1.2-32
------------
* Tue Oct 16 2007 Jakub Jelinek <jakub at redhat.com> 4.1.2-32
- only allow __label__ at the start of a block (PR c++/32121)
- disable -fipa-type-escape by default (PR tree-optimization/33136)
- VLA handling fix (PR c/33238, PR c/27301)
- disable TER of pure and const function calls except for __builtin_expect
  (PR tree-optimization/33619)
- handle classes with characters other than [a-zA-Z0-9_$] in
  their names (Andrew Haley, #297961, PR java/33639)
- fix parsing of C++ function-like cast in template argument where cast's
  argument uses greater-than operator (PR c++/33744)
- ignore always_inline attribute on redefined extern inline
  functions (Jan Hubicka, #329671, PR tree-optimization/33763)
- add support for Fortran int conversion intrinsics (Francois-Xavier
  Coudert, #317051)
- link libgcj-tools.so* against libgcj.so* (#330771)

glib2-2.14.2-1.fc8
------------------
* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 2.14.2-1
- Update to 2.14.2 (bug fixes)

gnome-compiz-manager-0.10.4-2.fc8
---------------------------------
* Fri Oct 12 2007 Matthias Clasen <mclasen at redhat.com> - 0.10.4-2
- Don't ship Ubuntu branding

gnome-power-manager-2.20.0-6.fc8
--------------------------------
* Tue Oct 16 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-6
- When hibernate is triggered by system idle, avoid suspending
  right after resuming from hibernate (#329541)

gnome-vfs2-2.20.0-3.fc8
-----------------------
* Tue Oct 16 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-3
- Also avoid showing /var/tmp as an icon on the desktop (#335241)

* Mon Oct 15 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-2
- Don't show /var/log/audit on the desktop (#333041)

* Mon Sep 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-1
- Update to 2.20.0

gonvert-0.2.19-1.fc8
--------------------
* Tue Oct 16 2007 Todd Zullinger <tmz at pobox.com> - 0.2.19-1
- update to 2.19
- update License and URL tags
- drop version from python Requires
- replace libglade2 and pygtk2 Requires with pygtk2-libglade
- remove execute bits from doc files
- remove unneeded make in %build
- re-work %install, avoid placing glade file under python site dir (#237286)
- fix encoding on THANKS and TODO files

gtk2-2.12.1-1.fc8
-----------------
* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-1
- Update to 2.12.1 (bug fixes and translation updates)
- Drop obsolete patches

* Thu Oct 11 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-6
- Fix a double-free problem in gtk-update-icon-cache (#327711)

* Thu Oct 04 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-5
- Fix a grab problem with multiple volume buttons

hsqldb-1:1.8.0.8-1jpp.4.fc8
---------------------------
* Tue Oct 16 2007 Deepak Bhole <dbhole at redhat.com> 1.8.0.8-1jpp.4
- Rebuild

* Tue Oct 16 2007 Deepak Bhole <dbhole at redhat.com> 1.8.0.8-1jpp.3
- Fix bz# 218135: Init script now specifies shell when starting service

hwbrowser-0.40-1.fc8
--------------------
* Wed Oct 17 2007 Nils Philippsen <nphilipp at redhat.com> - 0.40-1
- remove obsolete no.po translation file (#335201)

imlib-1:1.9.15-4.fc8
--------------------
* Thu Aug 09 2007 Paul Howarth <paul at city-fan.org> 1:1.9.15-4
- re-clarify license as GNU Lesser General Public License v2 or later (LGPLv2+)

iptables-1.3.8-5.fc8
--------------------
* Tue Oct 16 2007 Thomas Woerner <twoerner at redhat.com> 1.3.8-5
- fixed error code for stopping a already stopped firewall (rhbz#321751)
- moved blacklist test into start

kbd-1.12-27.fc8
---------------
* Wed Oct 17 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.12-27
- Add resizecons (with man page) for x86_64
  Resolves: #333651

kde-i18n-1:3.5.8-1.fc8
----------------------
* Tue Oct 16 2007 Than Ngo <than at redhat.com> 3.5.8-1
- 3.5.8

* Tue Feb 06 2007 Than Ngo <than at redhat.com> 1:3.5.6-1.fc7
- 3.5.6

* Tue Aug 08 2006 Than Ngo <than at redhat.com> 1:3.5.4-1
- 3.5.4

kdemultimedia-6:3.5.8-4.fc8
---------------------------
* Tue Oct 16 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4
- omit libs from main pkg (-> -libs)

kdenetwork-7:3.5.8-2.fc8
------------------------
* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 7:3.5.8-2
- -libs: %post/%postun -p /sbin/ldconfig

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 7:3.5.8-1
- kde-3.5.8
- libs subpkg (more multilib friendly)

kdewebdev-6:3.5.8-2.fc8
-----------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-2
- -libs subpkg (more multilib friendly)
- kommander_ver 1.2.2

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-1
- kde-3.5.8

kernel-2.6.23.1-18.fc8
----------------------
* Tue Oct 16 2007 Eric Paris <eparis at redhat.com>
- SELinux: performance: do not revalite perms on read/write
- SELinux: performance: use ebitmaps to speed up AVC misses
- SELinux: performance: fix warnings in ebitmaps to speed up AVC misses

* Tue Oct 16 2007 Dave Jones <davej at redhat.com>
- Disable sparse builds.

* Tue Oct 16 2007 John W. Linville <linville at redhat.com>
- ath5k updates

koffice-1.6.3-12.fc8
--------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org>
1.6.3-12
- rebuild (for openexr-1.6.0)
- -libs: %post/%postun -p /sbin/ldconfig

* Wed Sep 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org>
1.6.3-11
- rebuild (for poppler) 
- re-enable (kross)ruby support (f8+)

* Wed Aug 22 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
1.6.3-10
- rebuild for buildid

libX11-1.1.3-3.fc8
------------------
* Tue Oct 16 2007 Adam Jackson <ajax at redhat.com> 1.1.3-3
- libX11-devel Requires: libxcb-devel.

libannodex-0.7.3-9.fc8
----------------------
* Tue Oct 16 2007 Joe Orton <jorton at redhat.com> 0.7.3-9
- rebuild for expat 2.x

libcmml-0.9.1-4.fc8
-------------------
* Tue Oct 16 2007 Joe Orton <jorton at redhat.com> 0.9.1-4
- rebuild for expat 2.x (#296301)

libgcrypt-1.2.4-6
-----------------
* Tue Oct 16 2007 Nalin Dahyabhai <nalin at redhat.com> - 1.2.4-6
- use ldconfig to build the soname symlink for packaging along with the
  shared library (#334731)

libpng10-1.0.30-1.fc8
---------------------
* Tue Oct 16 2007 Paul Howarth <paul at city-fan.org> 1.0.30-1
- update to 1.0.30

man-pages-it-0.3.0-17.4
-----------------------
* Wed Oct 10 2007 Ding-Yi Chen <dchen at redhat.com> - 0.3.0-17.3
- Bugzilla Bug 236116: Unsupported programs in man-pages-it
- remove celibacy.1 and sex.6

* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 0.3.0-17.1
- rebuild

* Thu Mar 23 2006 Karsten Hopp <karsten at redhat.de> 0.3.0-17
- remove vim.1, provided by the vim-common package

mod_annodex-0.2.2-7.fc8
-----------------------
* Tue Oct 16 2007 Joe Orton <jorton at redhat.com> 0.2.2-7
- rebuild against expat 2.x

nautilus-2.20.0-5.fc8
---------------------
* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-5
- Add patch from upstream to get audio preview working again
  (#332251)

* Wed Oct 03 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Move /usr/lib/nautilus/extensions-1.0 to the extensions package

* Tue Oct 02 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-3
- Fix a crash with small fonts (#242350)

ncurses-5.6-12.20070812.fc8
---------------------------
* Tue Oct 16 2007 Miroslav Lichvar <mlichvar at redhat.com> 5.6-12.20070812
- allocate additional working buffers in new_field (#310071)

net-snmp-1:5.4.1-4.fc8
----------------------
* Tue Oct 16 2007 Jan Safranek <jsafranek at redhat.com> 5.4.1-4
- License: field fixed to "BSD and CMU"

nip2-7.12.5-2.fc8
-----------------
* Tue Oct 16 2007 Adam Goode <adam at spicenitz.org> - 7.12.5-2
- Rebuild for OpenEXR soname change

octave-6:2.9.15-2.fc8
---------------------
* Tue Oct 16 2007 Orion Poplawski <orion at ora.nwra.com> 2.9.15-2
- Updated pkg.m patch

octave-forge-20071014-2.fc8
---------------------------
* Tue Oct 16 2007 Orion Poplawski <orion at cora.nwra.com>  20071014-2
- Add patch to fix parallel build of odepkg and optiminterp

* Tue Oct 16 2007 Orion Poplawski <orion at cora.nwra.com>  20071014-1
- Rewrite to handle new "bundle" method to releasing packages and
  new octave package manager
- Prepare for eventual splitting of the package with provides

* Mon Sep 24 2007 Jesse Keating <jkeating at redhat.com> - 2006.07.09-10
- Rebuild for new octave

opengl-games-utils-0.1-4.fc8
----------------------------
* Tue Oct 16 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.1-4
- Fix a minor spelling error in the dialog shown when DRI is not available
perl-4:5.8.8-29.fc8
-------------------
* Tue Oct 16 2007 Robin Norwood <rnorwood at redhat.com> - 4:5.8.8-29
- Add Artistic, AUTHORS, and Changes* to %docs.
- Compress Changes* to save space.

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.4
- Require db4, not db4-devel. -EIDIOT

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.3
- add versioned Requires for db4-devel that we built against (resolves 144672)

perl-Compress-Bzip2-2.09-4.fc8.2
--------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.09-4.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.09-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-ExtUtils-PkgConfig-1.07-5.fc8.2
------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-5.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-File-BaseDir-0.02-1.fc8.2
------------------------------

perl-File-DesktopEntry-0.02-1.fc8.2
-----------------------------------

perl-GDGraph-1:1.44-2.fc8.2
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1:1.44-2.2
- add BR: perl(Test::More)

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1:1.44-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-GPS-0.15-1.fc8.1
---------------------

perl-GPS-PRN-0.05-1.fc8.1
-------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.05-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Geo-Constants-0.06-1.fc8.1
-------------------------------

perl-Geo-Ellipsoids-0.14-1.fc8.1
--------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.14-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Geo-Forward-0.11-1.fc8.1
-----------------------------

perl-Geo-Functions-0.06-1.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.06-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-Geo-Inverse-0.05-1.fc8.1
-----------------------------

perl-Glib-1.144-1.fc8.2
-----------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.144-1.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.144-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-HTML-Scrubber-0.08-4.fc8.2
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.08-4.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.08-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-HTML-Table-2.05-1.fc8.1
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.05-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

* Thu May 17 2007 Orion Poplawski <orion at cora.nwra.com> 2.05-1
- Update to 2.05

* Tue Nov 07 2006 Orion Poplawski <orion at cora.nwra.com> 2.04a-1
- Update to 2.04a

perl-HTML-Template-2.9-1.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.9-1.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.9-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-HTTP-Request-Params-1.01-1.fc8.2
-------------------------------------

perl-Hook-LexWrap-0.20-4.fc8.1
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.20-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-Capture-0.05-2.fc8.2
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.05-2.2
- add BR: perl(Test::More)
perl-IO-Interface-1.03-1.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.03-1.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.03-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-Multiplex-1.08-5.fc8.1
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.08-5.1
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-Socket-INET6-2.51-2.fc8.1
---------------------------------

perl-IO-Socket-SSL-1.02-1.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.02-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-String-1.08-2
---------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0:1.08-2
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-Tty-1.07-2.fc8.1
------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IO-Zlib-1.07-1
-------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-1
- bump to 1.07
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-IPC-SharedCache-1.3-7.fc8.1
--------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.3-7.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Image-Base-1.07-7.fc8.1
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.07-7.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Image-Xbm-1.08-6.fc8.1
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.08-6.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Image-Xpm-1.09-6.fc8.1
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.09-6.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Inline-0.44-16
-------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.44-16
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-LWP-Authen-Wsse-0.05-2.fc8.1
---------------------------------

perl-List-Compare-0.33-2.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.33-2.2
- add BR: perl(Test::Simple)
perl-Locale-Maketext-Fuzzy-0.02-4.fc8.2
---------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.02-4.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.02-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Log-Dispatch-Config-1.01-2.fc8.2
-------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.01-2.2
- add BR: perl(Test::More)
perl-Log-Dispatch-FileRotate-1.16-1.fc8.1
-----------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.16-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-MD5-2.03-1.fc8.1
---------------------

perl-MIME-Lite-3.01-5.fc8.1
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 3.01-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-MLDBM-2.01-5.fc8.1
-----------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.01-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Mail-Sender-0.8.13-2.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.8.13-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Mail-Sendmail-0.79-9.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.79-9.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Math-Round-0.06-1.fc8.1
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.06-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Module-Locate-1.7-1.fc8.2
------------------------------

perl-Module-Versions-Report-1.03-1.fc8.1
----------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.03-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Mozilla-LDAP-1.5.2-2.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.5.2-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Net-GPSD-0.35-1.fc8.1
--------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.35-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Net-Jabber-2.0-7.fc8.1
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.0-7.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Net-Patricia-1.014-4.fc8.1
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.014-4.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Net-SNMP-5.2.0-1.fc8.1
---------------------------

perl-Net-SSLeay-1.30-5.fc8.1
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.30-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Net-Telnet-3.03-5.1
------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 3.03-5.1 
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-PadWalker-1.5-1.fc8.1
--------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.5-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Parse-RecDescent-1.95.1-2.fc8
----------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.95-2
- add BR: perl(version), perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.95.1-1
- bump to 1.95.1
- correct license tag (now under perl license)
- add BR: perl(ExtUtils::MakeMaker)

perl-Parse-Yapp-1.05-36.fc8.1
-----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.05-36.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-PatchReader-0.9.5-4.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.9.5-4.2
- add BR: perl(Test::Simple)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.9.5-4.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Pod-Escapes-1.04-5.fc8.1
-----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.04-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Pod-Simple-3.05-1.fc8.1
----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 3.05-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Pod-Spell-1.01-2.fc8.1
---------------------------

perl-Proc-Daemon-0.03-1.fc8.2
-----------------------------

perl-Readonly-1.03-6.fc8.2
--------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.03-6.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.03-6.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Readonly-XS-1.04-8.fc8.2
-----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.04-8.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.04-8.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

* Tue Aug 21 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.04-8
- bump

perl-SNMP_Session-1.08-3.fc8.1
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.08-3.1
- add BR: perl(ExtUtils::MakeMaker)

perl-SOAP-Lite-0.68-4.fc8.1
---------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.68-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

* Sat Mar 03 2007 Mike McGrath <mmcgrath at redhat.com> - 0.68-4
- bogus reqs diff

* Tue Jan 02 2007 Mike McGrath <imlinux at gmail.com> - 0.68-3
- Changed the way this package removes bogus reqs for EL4

perl-SQL-Library-0.0.3-2.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.0.3-2.2
- add BR: perl(Test::More)
perl-SQL-Statement-1.15-2.fc8.2
-------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.15-2.2
- add BR: perl(Test::More)

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.15-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Scalar-Properties-0.12-1.fc8.1
-----------------------------------

perl-Set-Scalar-1.20-1.fc8.1
----------------------------

perl-Socket6-0.19-4.fc8.1
-------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.19-4.1
- add BR: perl(ExtUtils::MakeMaker)

perl-Statistics-Descriptive-2.6-2.fc8.1
---------------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.6-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-String-Format-1.14-1.fc8.2
-------------------------------

perl-Sub-Identify-0.02-2.fc8.2
------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.02-2.2
- add BR: perl(Test::More)
perl-Sub-Name-0.02-3.fc8.1
--------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.02-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-TeX-Hyphen-0.140-5.fc8.1
-----------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.140-5.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Term-UI-0.16-1.fc8
-----------------------
* Mon Oct 15 2007 Steven Pritchard <steve at kspei.com> 0.16-1
- Update to 0.16.
- Update License tag.
- BR Test::More.

perl-TermReadKey-2.30-2
-----------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.30-2
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Test-Cmd-1.05-1.fc8.1
--------------------------

perl-Test-Differences-0.47-2.fc8.2
----------------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.47-2.2
- add BR: perl(Test::More)
perl-Text-CHM-0.01-2.fc8.1
--------------------------

perl-Text-CharWidth-0.04-2.fc8.2
--------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.04-2.2
- add BR: perl(Test::Simple)
perl-Text-Template-1.44-4.fc8.1
-------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.44-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Text-Tree-1.0-2.fc8.2
--------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.0-2.2
- add BR: perl(Test::More)
perl-Text-Unidecode-0.04-4.fc8.1
--------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.04-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Text-WrapI18N-0.06-2.fc8.2
-------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.06-2.2
- add BR: perl(Test::Simple)
perl-Tie-IxHash-1.21-6.fc8.1
----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.21-6.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Time-Period-1.20-1.fc8.1
-----------------------------

perl-Time-Piece-1.09-2.fc8.2
----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.09-2.2
- add BR: perl(Test::More)

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.09-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

* Thu Sep 14 2006 Chris Grau <chris at chrisgrau.com> 1.09-2
- Rebuild for FC-6.

perl-Time-modules-2003.1126-4.fc8.1
-----------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2003.1126-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-Tree-DAG_Node-1.05-4.fc8.1
-------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.05-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-URI-1.35-3.1
-----------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.35-3.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-WWW-Babelfish-0.16-1.fc8.1
-------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.16-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-WWW-Bugzilla-0.9-1.fc8.1
-----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.9-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-DOM-1.44-2.fc8.1
-------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.44-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-XML-Dumper-0.81-2.fc8.2
----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.81-2.2
- add BR: perl(Test::More)

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.81-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-Grove-0.46alpha-30
---------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.46alpha-30
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-LibXML-1.62001-2.fc8.3
-------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.62001-2.3
- fix stupid test

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.62001-2.2
- add BR: perl(Test::More)

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.62001-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-LibXML-Common-0.13-9
-----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.13-9
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-NamespaceSupport-1.09-2.fc8.1
--------------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.09-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-RegExp-0.03-2.fc8.1
----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.03-2.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-XML-Stream-1.22-6.fc8.1
----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.22-6.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-XML-XPath-1.13-4.fc8.1
---------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.13-4.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)
perl-YAML-0.66-1.fc8
--------------------
* Tue Oct 16 2007 Steven Pritchard <steve at kspei.com> 0.66-1
- Update to 0.66.
- Update License tag.

* Wed Jun 27 2007 Steven Pritchard <steve at kspei.com> 0.65-1
- Update to 0.65.

* Tue Mar 13 2007 Steven Pritchard <steve at kspei.com> 0.62-3
- Use fixperms macro instead of our own chmod incantation.
- Drop Test::Base build dependency to avoid a BR loop.
- BR ExtUtils::MakeMaker.

perl-YAML-Syck-0.98-1.fc8
-------------------------
* Tue Oct 16 2007 Steven Pritchard <steve at kspei.com> 0.98-1
- Update to 0.98.

perl-libxml-perl-0.08-2
-----------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.08-2
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

perl-pmtools-1.01-2.fc8.1
-------------------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.01-2.1
- add BR: perl(ExtUtils::MakeMaker)

php-5.2.4-3
-----------
* Mon Oct 15 2007 Joe Orton <jorton at redhat.com> 5.2.4-3
- correct pcre BR version (#333021)
- restore metaphone fix (#205714)
- add READMEs to php-cli
plplot-5.7.4-4.fc8
------------------
* Tue Oct 16 2007 - Orion Poplawski <orion at cora.nwra.com> - 5.7.4-4
- Add patch from svn to fix octave bindings for octave 2.9.15, drop
  old version

policycoreutils-2.0.31-5.fc8
----------------------------
* Tue Oct 16 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-5
- Fix enable/disable audit messages

* Mon Oct 15 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-4
- Add booleans page

* Mon Oct 15 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-3
- Lots of updates to gui

postgis-1.3.1-1.fc8
-------------------
* Tue Oct 16 2007 Devrim GUNDUZ <devrim at commandprompt.com> - 1.3.1-1
- Update to 1.3.1
- Updated patch2

postgresql-pgpool-3.4.1-1.fc8
-----------------------------
* Tue Oct 16 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4.1-1
- Update to 3.4.1

* Sun Aug 05 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4-2
- Added an init script for pgpool
- Added /etc/sysconfig/pgpool

* Wed Aug 01 2007 - Devrim GUNDUZ <devrim at commandprompt.com> 3.4-1
- Update to 3.4
- Removed patches, they are now in upstream

ppracer-0.3.1-13.fc8
--------------------
* Wed Oct 17 2007 Nils Philippsen <nphilipp at redhat.com> 0.3.1-13
- really use opengl-games-wrapper.sh from Fedora 7 on (#335691)

* Wed Oct 17 2007 Nils Philippsen <nphilipp at redhat.com> 0.3.1-12
- use opengl-games-wrapper.sh from Fedora 7 on (#335691)

python-2.5.1-12.fc8
-------------------
* Tue Oct 16 2007 Mike Bonnet <mikeb at redhat.com> - 2.5.1-12
- fix marshalling of objects in xmlrpclib (python bug #1739842)

* Fri Sep 14 2007 Jeremy Katz <katzj at redhat.com> - 2.5.1-11
- fix encoding of sqlite .py files to work around weird encoding problem 
  in Turkish (#283331)

* Mon Sep 10 2007 Jeremy Katz <katzj at redhat.com> - 2.5.1-10
- work around problems with multi-line plural specification (#252136)

qpxtool-0.6.1-6.fc8
-------------------
* Wed Oct 17 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.1-6
- Drop libata patch - no longer needed with fixed udev

readahead-1:1.4.2-3.fc8
-----------------------
* Wed Oct 17 2007 Karel Zak <kzak at redhat.com> 1:1.4.2-3
- update default lists
- fix #327041 - readahead --sort generates file with "(null)"
- fix #326891 - readahead-collector doesn't collect binaries

redland-1.0.6-2.fc8
-------------------
* Tue Oct 16 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.0.6-2
- fix unpackaged files and unowned directory

* Tue Oct 16 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.0.6-1
- update to 1.0.6 (for Soprano 2, also some bugfixes)
- update minimum raptor and rasqal versions
- drop sed hacks for dependency bloat (#248106), fixed upstream

rhgb-8.0.1-1.fc8
----------------
* Tue Oct 16 2007 Ray Strode <rstrode at redhat.com> 8.0.1-1
- update to 8.0.1
- fixes crasher because of misplaced unref call

rpcbind-0.1.4-10.fc8
--------------------
* Tue Oct 16 2007 Steve Dickson <steved at redhat.com> 0.1.4-10
- Corrected a typo in the initscript from previous 
  commit.

rsh-0.17-44.fc8
---------------
* Tue Oct 16 2007 Adam Tkac <atkac redhat com> 0.17-44
- added -D option for compatibility with F8 test releases
- fixed rsh-server description

* Thu Sep 27 2007 Adam Tkac <atkac redhat com> 0.17-43
- removed -D option from rshd and rlogind (we have -a option when
  we need force reverse DNS lookup)
- patches netkit-rsh-0.17-nodns.patch and netkit-rsh-0.17-nohostcheck.patch
  are substituted by netkit-rsh-0.17-dns.patch

scim-python-0.1.4-3.fc8
-----------------------
* Wed Oct 17 2007 Huang Peng <shawn.p.huang at gmail.com> - 0.1.4-3
- Fix require error in spec file.

sepostgresql-8.2.5-1.33.fc8
---------------------------
* Wed Oct 17 2007 <kaigai at kaigai.gr.jp> - 8.2.5-1.33
- Fix bug: security context was not canonicalized
  when irregular context (but interpretable) was inputed.

slrn-0.9.8.1pl1-4.20070716cvs.fc8
---------------------------------
* Tue Oct 16 2007 Miroslav Lichvar <mlichvar at redhat.com> 0.9.8.1pl1-4.20070716cvs
- don't use gethostbyname

smolt-0.9.9-1.fc8
-----------------
* Tue Oct 16 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9-1
- Upstream released new version

spambayes-1.0.4-5.fc8
---------------------
* Wed Oct 17 2007 Christopher Stone <chris.stone at gmail.com> 1.0.4-5
- Providing Eggs for non-setuptools packages (bz#325041)

ssmtp-2.61-11.4.fc8
-------------------
* Tue Oct 16 2007 lonely wolf <wolfy at nobugconsulting.ro> 2.61-11.4
- includes patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340803
  replacing md5 from RSA with a version released under GPLv2+
- fix URL for upstream

stunnel-4.20-4
--------------
* Tue Oct 16 2007 Miloslav Trma?? <mitr at redhat.com> - 4.20-4
- Revert the port to NSS, wait for NSS-based stunnel 5.x instead
  Resolves: #301971
- Mark localized man pages with %lang (patch by Ville Skytt??)
  Resolves: #322281

swatch-3.2.1-1.fc8.1
--------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 3.2.1-1.1
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

system-config-netboot-0.1.42-1.fc8
----------------------------------
* Wed Oct 17 2007 Radek Brich <rbrich at redhat.com> - 0.1.42-1
- transition to initramfs, patch by Bernardo Innocenti (bugs #204877, #248979)
- additional checks for pxeos/pxeboot (bug #203788)
- fix -S parameter in pxeboot
  o added to getopt
  o use IP as snapshot name when the name wasn't specified and there is no DNS
- updated license tag
- source tree and spec clean up
- drop unused rhpl dependency
- fix i18n of pxeos and pxeboot

system-config-users-1.2.72-1.fc8
--------------------------------
* Tue Oct 16 2007 Nils Philippsen <nphilipp at redhat.com> - 1.2.72-1
- make /usr/share/system-config-users/system-config-users.py executable again

tinyerp-4.0.3-3.fc8
-------------------
* Tue Oct 16 2007 Dan Horak <dan[at]danny.cz> 4.0.3-3
- fix problem with xmlrpc from Python 2.5 (#334121)

tmpwatch-2.9.11-2
-----------------
* Tue Oct 16 2007 Miloslav Trma?? <mitr at redhat.com> - 2.9.11-2
- Update License:

tsclient-0.150-5.fc8
--------------------
* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 0.150.5
- Don't crash when saving a connection  (#333461)

udev-116-2.fc8
--------------
* Tue Oct 16 2007 Dennis Gilmore <dennis at ausil.us> 116-2
- sparc64 requires -fPIE not -fpie

udunits-1.12.4-11.fc8.3
-----------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-11.3
- add BR: perl(ExtUtils::MakeMaker)

usermode-1.93.1-1.fc8
---------------------
* Tue Oct 16 2007 Miloslav Trma?? <mitr at redhat.com> - 1.93.1-1
- New release with updated translations
  Resolves: #332441
- Build with startup notification
  Resolves: #294591

util-linux-ng-2.13-3.fc8
------------------------
* Tue Oct 16 2007 Karel Zak <kzak at redhat.com> 2.13-3
- fix mount -L | -U segfault
- fix script die on SIGWINCH

vdr-1.4.7-6.fc8
---------------
* Wed Oct 17 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.4.7-6
- Add patch to start playback from recordings menu with the play button.

* Fri Oct 12 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.4.7-5
- Fix init script not to start a new vdr if it's already running (#247089).
- Update subtitles+ttxtsubs patch to Rolf's latest revision.

* Mon Aug 06 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.4.7-4
- License: GPL+ for skincurses and sky plugins.

xclip-0.10-1.fc8
----------------
* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.10-1
- bump to 0.10
- new URL

xorg-x11-drv-i810-2.1.1-7.fc8
-----------------------------
* Wed Oct 17 2007 Dave Airlie <airlied at redhat.com> 2.1.1-7
- intel-2.1.1-fix-xv-compiz.patch - update to not crash is we can't get RAM

* Wed Oct 17 2007 Dave Airlie <airlied at redhat.com> 2.1.1-6
- intel-2.1.1-fix-xv-compiz.patch - Real dirty hack to allocate 4MB of RAM
  for textured Xv to use as an offscreen pixmap so xv actually works under
  compiz - granted it may be unusably slow but at least stuff shows up.

yum-cron-0.6-1.fc8
------------------
* Mon Oct 15 2007 Alec Habig <ahabig at umn.edu> - 0.6-1
- Fixes for bug 327401: checkonly formatting fix and make lockfile
  grabbing an atomic action using mkdir instead of touch
- Added downloadonly option (bug 333131)
- Don't update yum if set to checkonly (bug 333111)

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.i386 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.i386 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.i386 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.x86_64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.x86_64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.x86_64 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew
	wammu - 0.19-3.fc8.noarch requires python-gammu



Broken deps for ppc64
----------------------------------------------------------
	beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1
	emerald-themes - 0.5.2-1.fc8.noarch requires emerald >= 0:0.5.2
	emerald-themes - 0.5.2-1.fc8.noarch requires compiz >= 0:0.5.2
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew
	wammu - 0.19-3.fc8.noarch requires python-gammu





From jwilson at redhat.com  Thu Oct 18 03:06:29 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Wed, 17 Oct 2007 23:06:29 -0400
Subject: Experimental ppc livecd-iso-to-stick support
Message-ID: <4716CDB5.8000001@redhat.com>

Spent a while beating on a usb stick to make it boot my powerbook. Once 
that was working, I attempted to add support to livecd-iso-to-stick to 
set up a stick automagically. The work-in-progress, works-for-me fruits 
of my labor:

http://people.redhat.com/jwilson/misc/livecd-iso-to-stick.ppc
http://people.redhat.com/jwilson/misc/livecd-iso-to-stick-ppc.diff

A few caveats:

1) only works on ppc macs

2) requires repartitioning sticks to use a mac partition table (script 
includes some support for auto-formatting)

3) at the moment, some usb open firmware devices are hard-coded, so it 
only boots in a specific usb port (the one on the right side of my 
powerbook g4)

4) requires entering open firmware and manually specifying the boot 
device (not sure why holding down option at boot doesn't find it).

5) not tested on any other machines yet

Thanks be to Ralf Ertzinger for pointing me to his ydl4 usb boot docs, 
which helped out a ton convincing things to work. Definitely still needs 
testing and plenty of room for improvement, but I think its a decent 
start...

-- 
Jarod Wilson
jwilson at redhat.com



From jwilson at redhat.com  Thu Oct 18 03:17:41 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Wed, 17 Oct 2007 23:17:41 -0400
Subject: Experimental ppc livecd-iso-to-stick support
In-Reply-To: <4716CDB5.8000001@redhat.com>
References: <4716CDB5.8000001@redhat.com>
Message-ID: <4716D055.2030606@redhat.com>

Jarod Wilson wrote:
> Spent a while beating on a usb stick to make it boot my powerbook. Once 
> that was working, I attempted to add support to livecd-iso-to-stick to 
> set up a stick automagically. The work-in-progress, works-for-me fruits 
> of my labor:
> 
> http://people.redhat.com/jwilson/misc/livecd-iso-to-stick.ppc
> http://people.redhat.com/jwilson/misc/livecd-iso-to-stick-ppc.diff

That would be livecd-iso-to-disk, not -stick, so:

http://people.redhat.com/jwilson/misc/livecd-iso-to-disk.ppc
http://people.redhat.com/jwilson/misc/livecd-iso-to-disk-ppc.diff

Oops.

-- 
Jarod Wilson
jwilson at redhat.com



From jkeating at redhat.com  Thu Oct 18 03:36:54 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 17 Oct 2007 23:36:54 -0400
Subject: We are Frozen for Fedora 8
Message-ID: <20071017233654.5ed0d1a3@redhat.com>

We've reached the final freeze phase.  During this phase new builds are
not automatically tagged for the release.  Instead they are held as
potential updates to Fedora 8.  Exceptions do this should follow the
policy as outlined at
http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

For schedule information, see
http://fedoraproject.org/wiki/Releases/8/Schedule

To see if your build made the freeze cut off, see
http://koji.fedoraproject.org/koji/builds?tagID=30

or simply call 'koji latest-pkg f8-final <pkgname>'

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071017/45551940/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From lmacken at redhat.com  Thu Oct 18 04:20:38 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 18 Oct 2007 00:20:38 -0400
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
	2007-10-16
In-Reply-To: <20071017161835.787270f9@redhat.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
	<604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
	<20071017161835.787270f9@redhat.com>
Message-ID: <20071018042038.GA28790@crow.myhome.westell.com>

On Wed, Oct 17, 2007 at 04:18:35PM -0400, Jesse Keating wrote:
> On Wed, 17 Oct 2007 11:59:27 -0800
> "Jeff Spaleta" <jspaleta at gmail.com> wrote:
> 
> > how does the package tool know that some updates are security fixes?
> 
> Via the update-info that is added into yum repodata.  We aren't quite
> producing that yet I don't think, luke has been working on reviving
> that within bodhi.

Bodhi has been generating the updateinfo in the repodata for a while now,
which should contain this data.  If it doesn't exist, please open a ticket[0].

luke

[0]: https://hosted.fedoraproject.org/projects/bodhi/newticket



From roland at redhat.com  Thu Oct 18 04:24:30 2007
From: roland at redhat.com (Roland McGrath)
Date: Wed, 17 Oct 2007 21:24:30 -0700 (PDT)
Subject: debugedit exits with a SIGSEGV
In-Reply-To: Joost van der Sluis's message of  Wednesday,
	17 October 2007 14:41:35 +0200
	<1192624895.28698.12.camel@wsjoost.cnoc.local>
References: <1192624895.28698.12.camel@wsjoost.cnoc.local>
Message-ID: <20071018042430.624694D04E2@magilla.localdomain>

https://bugzilla.redhat.com/show_bug.cgi?id=336951
https://bugzilla.redhat.com/show_bug.cgi?id=337011
https://bugzilla.redhat.com/show_bug.cgi?id=337051

The first one was really debugedit's fault.  The second one is really just
it being less than perfectly robust in the face of the bad data from fpc,
which the third one describes.


Thanks,
Roland



From jkeating at redhat.com  Thu Oct 18 04:25:27 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Oct 2007 00:25:27 -0400
Subject: Summary - Broken dependencies in Fedora 7 + Test Updates -
 2007-10-16
In-Reply-To: <20071018042038.GA28790@crow.myhome.westell.com>
References: <20071016231519.3262.27912@extras64.linux.duke.edu>
	<471549BF.6010109@poolshark.org>
	<1192577929.3409.20.camel@localhost.localdomain>
	<471550C4.5090704@poolshark.org>
	<604aa7910710161722q4e7f084ey19c798141d217466@mail.gmail.com>
	<4715D632.80403@poolshark.org>
	<604aa7910710171259v7be6de75sef9881402e6066d7@mail.gmail.com>
	<20071017161835.787270f9@redhat.com>
	<20071018042038.GA28790@crow.myhome.westell.com>
Message-ID: <20071018002527.5bc86e37@redhat.com>

On Thu, 18 Oct 2007 00:20:38 -0400
Luke Macken <lmacken at redhat.com> wrote:

> Bodhi has been generating the updateinfo in the repodata for a while
> now, which should contain this data.  If it doesn't exist, please
> open a ticket[0].

I stand corrected.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/e4101333/attachment.sig>

From jspaleta at gmail.com  Thu Oct 18 05:12:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 17 Oct 2007 21:12:58 -0800
Subject: libgpod update for Fedora 7
In-Reply-To: <20071017164927.GA5777@psilocybe.teonanacatl.org>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
	<20071017164927.GA5777@psilocybe.teonanacatl.org>
Message-ID: <604aa7910710172212w14b8d248q4bdb220355886a41@mail.gmail.com>

On 10/17/07, Todd Zullinger <tmz at pobox.com> wrote:
> Perhaps my understanding is wrong then. I thought that with help from
> rel-eng, I could build libgpod and get it into the buildroots in order
> to rebuild the other packages against?  Then they can all be pushed
> together to updates-testing.  Is that not possible?
>
> > Is this a wise thing to do at this stage?
>
> Unless the build system can't do this, I think it is a wise thing to
> do.  I'll elaborate in a reply to Ville's mail in a moment.


I think you can use the magic of chain building with koji and build
multiple packages together and then push them all to updates-testing.
But i've honestly never used chain building so i've no idea how well
it works.

-jef



From tmz at pobox.com  Thu Oct 18 05:34:18 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Thu, 18 Oct 2007 01:34:18 -0400
Subject: libgpod update for Fedora 7
In-Reply-To: <604aa7910710172212w14b8d248q4bdb220355886a41@mail.gmail.com>
References: <20071017035627.GC596@psilocybe.teonanacatl.org>
	<1192616258.4729.1.camel@cookie.hadess.net>
	<20071017164927.GA5777@psilocybe.teonanacatl.org>
	<604aa7910710172212w14b8d248q4bdb220355886a41@mail.gmail.com>
Message-ID: <20071018053418.GC25026@psilocybe.teonanacatl.org>

Jeff Spaleta wrote:
> I think you can use the magic of chain building with koji and build
> multiple packages together and then push them all to
> updates-testing.  But i've honestly never used chain building so
> i've no idea how well it works.

As I understand it, you can only use make chain-build for the devel
branch.  For released branches, you need the magic of rel-eng(tm) to
get the earlier build(s) into the buildroots so that it/they will be
available to the later builds.

I used chain-build when I pushed libgpod to devel a month or so ago.
It worked as advertised.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The things most people want to know are usually none of their
business.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/92abc823/attachment.sig>

From caolanm at redhat.com  Thu Oct 18 07:25:38 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Thu, 18 Oct 2007 08:25:38 +0100
Subject: rawhide report: 20071017 changes
In-Reply-To: <200710180234.l9I2YJOb000797@porkchop.devel.redhat.com>
References: <200710180234.l9I2YJOb000797@porkchop.devel.redhat.com>
Message-ID: <1192692338.28285.37.camel@Jehannum>

On Wed, 2007-10-17 at 22:34 -0400, Build System wrote:
> New package culmus-fonts
> 	Fonts for Hebrew from Culmus project
> 
> New package kacst-fonts
> 	Fonts for arabic from arabeyes project

> 
> fonts-arabic-2.1-1.fc8
> ----------------------
> * Wed Oct 17 2007 Rahul Bhalerao <rbhalera at redhat.com> - 2.1-1.fc8
> - This package is now metapackage since kacst and paktype fonts have been moved to their separate packages
> 
> fonts-hebrew-0.101-1.fc8
> ------------------------
> * Wed Oct 17 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.101-1.fc8
> - This is now a metapackage since Culmus fonts were moved to a separate package

> 	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
> 	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc64 requires fonts-hebrew
> 	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
> 	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew


So is this just some sort of bug in the fonts-arabic/fonts-hebrew
meta-packages or do all the above requiring packages need to be fixed to
require the differently named packages.

C.




From harald at redhat.com  Thu Oct 18 07:04:45 2007
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 18 Oct 2007 09:04:45 +0200
Subject: removable storage devices still do not auto-mount
In-Reply-To: <55df67120710171633n54a6e3ads6454573cbec1d517@mail.gmail.com>
References: <55df67120710171633n54a6e3ads6454573cbec1d517@mail.gmail.com>
Message-ID: <4717058D.50007@redhat.com>

rapponcape wrote:
> I continue to have trouble with removable usb memory sticks not
> auto-mounting with Fedora.  Had problem on FC6( auto-mounted
> the stick once, then never again) and now, after a fresh install of
> FC7, the same problem.  Hal output always ends with "scsi.type is
> unknown" "Not adding device object", but, other indicators show that
> the device is recognized and present.  I can mount it manually.
> 
> I've removed the following file, as some suggested, but still no luck
> /usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi
> 
> This seems to be an ongoing problem. Can anyone shed any light on this?
> The hal dev group had nothing for me.
> 
> What's up??
> 
> Thanks.


Fresh install or updated to the latest versions?



From pmatilai at redhat.com  Thu Oct 18 07:16:01 2007
From: pmatilai at redhat.com (Panu Matilainen)
Date: Thu, 18 Oct 2007 10:16:01 +0300 (EEST)
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192625250.7342.89.camel@localhost.localdomain>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
Message-ID: <alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>



On Wed, 17 Oct 2007, Simo Sorce wrote:

> On Wed, 2007-10-17 at 13:11 +0200, Adam Tkac wrote:
>> On Mon, Oct 15, 2007 at 11:31:17PM +0200, Karel Zak wrote:
>>>  Couldn't be better to maintain default selinux labels like others
>>>  file attributes?
>>>
>>>      %attr(4755,root,root) %selinux(foo_t)  /bin/foo
>>>
>>
>> I think restorecon is fare more better than this approach. With this 
>> you have two databases of file contexts - first is in specfile and 
>> second in selinux-policy*. When you use restorecon you have one 
>> centralised database. We will discuss if rpm will automaticaly run 
>> restorecon on all installed files.
>
> Not only that, but a new policy may well change some labels to fix
> errors, and make the package content obsolete. And even dangerous if the
> package maintainer forgets to update it and on a yum update you get back
> the old broken label.

Amen. If the labels were universally set in stone, it might make sense to
store into rpm but as they can and do vary between policy versions,
different policies and local custom policies... RPM is not the place to
strore the labels, period.

RPM simply queries the active SELinux policy via libselinux to set labels 
on files and directories on install and that works just fine except for 
per-package policies (https://bugzilla.redhat.com/show_bug.cgi?id=185434). 
Helping that case somehow is one thing, but stuffing the labels into 
packages is not the fix.

 	- Panu -



From alexl at redhat.com  Thu Oct 18 07:14:13 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Thu, 18 Oct 2007 09:14:13 +0200
Subject: should readahead allow generic paths?
In-Reply-To: <20071012191457.GA6022@redhat.com>
References: <1192089592.6478.36.camel@jcmlaptop>
	<p04330102c333d3e26fe9@[192.168.123.162]> <470E311A.8020406@redhat.com>
	<1192112561.2571.9.camel@localhost.localdomain>
	<470E33A6.7070903@redhat.com>
	<1192174445.13539.96.camel@localhost.localdomain>
	<20071012191457.GA6022@redhat.com>
Message-ID: <1192691653.19725.33.camel@localhost.localdomain>

On Fri, 2007-10-12 at 15:14 -0400, Dave Jones wrote:
> On Fri, Oct 12, 2007 at 09:34:05AM +0200, Alexander Larsson wrote:
> 
>  > Is there any chance we can use Jens Axboes "fcache"?
>  > Info e.g. at:
>  > http://en.opensuse.org/Fcache-howto
> 
> That really needs to get into the upstream kernel before I'm comfortable
> enabling it in Fedora.

But nobody seems to be interested at all in it, not upstream, nor
everyone working on hacks like preload. I just think that is strange.

> ext3's block allocation policy seems a little.. suboptimal in some cases.
> It doesn't seem particularly difficult to end up with fragmented files,
> especially with large ones.

Maybe one could do the allocation manually for the fcache a file and
then mark the blocks so they won't be moved? This can be done at install
time and doesn't need generic extents support.



From alexl at redhat.com  Thu Oct 18 07:18:59 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Thu, 18 Oct 2007 09:18:59 +0200
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <ff5irm$7ei$1@ger.gmane.org>
References: <1192559987.2807.3.camel@tiger> <47150A93.2090608@redhat.com>
	<e71b3daf0710161458v7deda4ceqf8e16b75e6d4592c@mail.gmail.com>
	<ff5irm$7ei$1@ger.gmane.org>
Message-ID: <1192691939.19725.35.camel@localhost.localdomain>

On Wed, 2007-10-17 at 14:02 -0400, Scott Henson wrote:
> Jon Nettleton wrote:
> > On 10/16/07, Zack Cerza <zcerza at redhat.com> wrote:
> >> Louis E Garcia II wrote:
> >>> when logging on I need to give gnome-keyring the password to unlock even
> >>> though I check it so it unlocks automatically. What gives?
> >>>
> >>> -Louis
> >>  From what I understand, the feature isn't complete and depends on [0].
> >> Matthias said in [1] that he removed the checkboxes until that work is
> >> finished.
> >>
> > 
> > We decided yesterday it would definitely be better to turn that off
> > rather than feel the wrath of thousands of people checking that box
> > and it not doing anything.  If you don't use a smart card reader or a
> > biometric authentication device, you can edit /etc/pam.d/gdm and move
> > the
> > auth line for pam_gnome_keyring above the system auth include.
> > However I take no responsibility for what it could possibly break in
> > the future ;-).
> > 
> 
> Is it possible to use those devices to unlock your gnome-keyring?

No, but if you move gnome_keyring before system_auth they break, as it
will ask for your password.





From nicolas.mailhot at laposte.net  Thu Oct 18 07:35:42 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Oct 2007 09:35:42 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
Message-ID: <1192692942.19550.3.camel@rousalka.dyndns.org>


Le jeudi 18 octobre 2007 ? 10:16 +0300, Panu Matilainen a ?crit :

> Amen. If the labels were universally set in stone, it might make sense to
> store into rpm but as they can and do vary between policy versions,
> different policies and local custom policies... 

You could make the same arguments for user names, unix permissions or
file location ? a lot them have different values in the wild than in
Fedora and yet we store our policy in rpm.

It all goes down to whether we want to make selinux a first-class
citizen, provide good selinux support by default, and make Fedora policy
choices, or keep it in the current netherworld where most Fedora
packagers do not feel concerned and users learn to add selinux=false to
their grub config.

There is no middle ground. Middle ground is just a way to avoid fixing
problems, confuses people and makes them avoid the thing like the
plague.

-- 
Nicolas Mailhot



From kevin.kofler at chello.at  Thu Oct 18 07:50:12 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Oct 2007 07:50:12 +0000 (UTC)
Subject: gnome keyring always needs to be unlocked
References: <1192559987.2807.3.camel@tiger>
Message-ID: <loom.20071018T074804-134@post.gmane.org>

IMHO gnome-keyring should simply allow passwordless keyrings like KWallet does, 
that would solve this problem in a much simpler way for most use cases, and 
standard *nix permissions will keep the data just as secure as with pam_keyring 
automatically unlocking the keyring for the user owning it anyway.

        Kevin Kofler



From tmraz at redhat.com  Thu Oct 18 07:52:40 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 18 Oct 2007 09:52:40 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192692942.19550.3.camel@rousalka.dyndns.org>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
Message-ID: <1192693960.19241.2.camel@vespa.kabelta.loc>


On Thu, 2007-10-18 at 09:35 +0200, Nicolas Mailhot wrote:
> Le jeudi 18 octobre 2007 ? 10:16 +0300, Panu Matilainen a ?crit :
> 
> > Amen. If the labels were universally set in stone, it might make sense to
> > store into rpm but as they can and do vary between policy versions,
> > different policies and local custom policies... 
> 
> You could make the same arguments for user names, unix permissions or
> file location ? a lot them have different values in the wild than in
> Fedora and yet we store our policy in rpm.
> 
> It all goes down to whether we want to make selinux a first-class
> citizen, provide good selinux support by default, and make Fedora policy
> choices, or keep it in the current netherworld where most Fedora
> packagers do not feel concerned and users learn to add selinux=false to
> their grub config.
> 
> There is no middle ground. Middle ground is just a way to avoid fixing
> problems, confuses people and makes them avoid the thing like the
> plague.
Yes, but sticking only file labels into the spec and not the rest of the
policy associated to the package is the same middle ground only slightly
shifted.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From pmatilai at redhat.com  Thu Oct 18 07:57:53 2007
From: pmatilai at redhat.com (Panu Matilainen)
Date: Thu, 18 Oct 2007 10:57:53 +0300 (EEST)
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192692942.19550.3.camel@rousalka.dyndns.org>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
Message-ID: <alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>

On Thu, 18 Oct 2007, Nicolas Mailhot wrote:

>
> Le jeudi 18 octobre 2007 ? 10:16 +0300, Panu Matilainen a ?crit :
>
>> Amen. If the labels were universally set in stone, it might make sense to
>> store into rpm but as they can and do vary between policy versions,
>> different policies and local custom policies...
>
> You could make the same arguments for user names, unix permissions or
> file location ? a lot them have different values in the wild than in
> Fedora and yet we store our policy in rpm.

The difference here is that we don't even try to support several 
different policies (including custom local policies on top of the distro 
policies) for user names, permissions etc. If we did, we'd be in the very 
same swamp as with SELinux currently.

The total lack of support for custom file permissions etc could well be 
considered a bug too...

> It all goes down to whether we want to make selinux a first-class
> citizen, provide good selinux support by default, and make Fedora policy
> choices, or keep it in the current netherworld where most Fedora
> packagers do not feel concerned and users learn to add selinux=false to
> their grub config.
>
> There is no middle ground. Middle ground is just a way to avoid fixing
> problems, confuses people and makes them avoid the thing like the
> plague.

I'm not claiming there is no problem. What I'm saying is that storing the 
labels within RPM doesn't fix a thing.

 	- Panu -




From petersen at redhat.com  Thu Oct 18 08:32:21 2007
From: petersen at redhat.com (Jens Petersen)
Date: Thu, 18 Oct 2007 18:32:21 +1000
Subject: rawhide report: 20071017 changes
In-Reply-To: <1192692338.28285.37.camel@Jehannum>
References: <200710180234.l9I2YJOb000797@porkchop.devel.redhat.com>
	<1192692338.28285.37.camel@Jehannum>
Message-ID: <47171A15.2080907@redhat.com>

Hi Caolan,

Caolan McNamara wrote:
>> 	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
>> 	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc64 requires fonts-hebrew
>> 	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
>> 	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew
> 
> So is this just some sort of bug in the fonts-arabic/fonts-hebrew
> meta-packages or do all the above requiring packages need to be fixed to
> require the differently named packages.

It seems fonts-arabic and fonts-hebrew were not in rawhide-20071017
for some reason - dunno why.  They have been updated for the new fonts 
packages (along with fonts-sinhala) so assuming they come back 
everything ought to be ok.

Jens



From pertusus at free.fr  Thu Oct 18 09:04:33 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Oct 2007 11:04:33 +0200
Subject: virtual provides for local servers
Message-ID: <20071018090433.GA5293@free.fr>

Hello,

ltsp5 requires an xdmcp server, but more than one package provides the
functionnality. What about adding a virtual provides for local servers
like

Provides: server(xdmcp) 

This could also be used for smtpdaemon and webserver, which would become
server(smtp) and server(web) (or server(http))?

What do you think about that idea?

--
Pat



From gilboad at gmail.com  Thu Oct 18 09:17:36 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 18 Oct 2007 11:17:36 +0200
Subject: Anybody see my wine 0.9.47???
In-Reply-To: <20071017204934.145f4093@spica.a.lan>
References: <358207.61361.qm@web52411.mail.re2.yahoo.com>
	<200710171355.15775.opensource@till.name>
	<1192625781.29602.5.camel@gilboa-work-dev.localdomain>
	<20071017204934.145f4093@spica.a.lan>
Message-ID: <1192699056.27717.6.camel@gilboa-work-dev.localdomain>

On Wed, 2007-10-17 at 20:49 +0200, Andreas Bierfert wrote:
> On Wed, 17 Oct 2007 14:56:21 +0200
> Gilboa Davara <gilboad at gmail.com> wrote:
> > Looks like a minor packaging problem. (Most likely new stub DLLs)
> > 
> > error: Installed (but unpackaged) file(s) found:
> >    /usr/lib/wine/msvcirt.dll.so
> >    /usr/lib/wine/qmgr.dll.so
> > 
> > 
> > RPM build errors:
> >     Installed (but unpackaged) file(s) found:
> >    /usr/lib/wine/msvcirt.dll.so
> >    /usr/lib/wine/qmgr.dll.so
> 
> Hi,
> 
> I know about the issue but due to being sick an a bit overworked I could not
> fix it. Strange thing is: This did not happen on my mock builds so after
> test-building and testing the new version a bit I just blindly pushed the
> builds. Sorry for the issue I will push new builds tonight.
> 
> Regards,
> Andreas

Nothing to be sorry about. You're doing a fine job... even if a certain
build is borked.
Heck, because of you I can play TF2 on my Fedora7 machine ;)
Do you require co-maintainers?

- Gilboa



From gemi at bluewin.ch  Thu Oct 18 09:44:43 2007
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Thu, 18 Oct 2007 11:44:43 +0200
Subject: New clisp packages
Message-ID: <1192700683.4666.2.camel@localhost.localdomain>

I created packages for the new clisp release 2.42. They are available
at:
http://math.ifi.unizh.ch/fedora/tmp/
It would be helpful if they get tested before I submit them, especially
wrt to packages like maxima.
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From buildsys at fedoraproject.org  Thu Oct 18 09:54:45 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 18 Oct 2007 05:54:45 -0400 (EDT)
Subject: Package EVR problems in Fedora 2007-10-18
Message-ID: <20071018095445.7062015212E@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8

aportal AT univ-montp2 fr:
    pikloops
      FE6 > F7-updates (0:0.2.4-4.fc6 > 0:0.2.4-1.fc7)
      FE6 > F8 (0:0.2.4-4.fc6 > 0:0.2.4-1.fc8)
    
cweyl AT alumni drew edu:
    Zim
      FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
      F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
esandeen AT redhat com:
    xfsprogs
      FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)
    
foolish AT guezz net:
    gtranslator
      F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
lxtnow AT gmail com:
    gammu
      FE6 > F7-updates-testing (0:1.13.0-1.fc6 > 0:1.12.92-1.fc7)
    
    python-gammu
      FE6 > F7-updates (0:0.22-2.fc6 > 0:0.20-1.fc7)
    
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
michel sylvan AT gmail com:
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)
    
    smolt
      FE6 > F7-updates (0:0.9.9-1.fc6 > 0:0.9.8.4-4.fc7)
    
mtasaka AT ioa s u-tokyo ac jp:
    catfish
      F7-updates > F8 (0:0.3-1.fc7 > 0:0.3-0.3.c.fc8)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
rc040203 AT freenet de:
    perl-File-Remove
      F7-updates > F8 (0:0.38-1.fc7 > 0:0.37-2.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
roland AT redhat com:
    monotone
      FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
tjanouse AT redhat com:
    cyrus-imapd
      FE6 > F7 (0:2.3.9-7.fc6 > 0:2.3.8-3.fc7)
    
----------------------------------------------------------------------

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)

catfish: mtasaka AT ioa s u-tokyo ac jp
  F7-updates > F8 (0:0.3-1.fc7 > 0:0.3-0.3.c.fc8)

cyrus-imapd: tjanouse AT redhat com
  FE6 > F7 (0:2.3.9-7.fc6 > 0:2.3.8-3.fc7)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

gammu: lxtnow AT gmail com
  FE6 > F7-updates-testing (0:1.13.0-1.fc6 > 0:1.12.92-1.fc7)

gtranslator: foolish AT guezz net
  F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

monotone: roland AT redhat com
  FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

perl-File-Remove: rc040203 AT freenet de
  F7-updates > F8 (0:0.38-1.fc7 > 0:0.37-2.fc8)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.4-4.fc6 > 0:0.2.4-1.fc7)
  FE6 > F8 (0:0.2.4-4.fc6 > 0:0.2.4-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-gammu: lxtnow AT gmail com
  FE6 > F7-updates (0:0.22-2.fc6 > 0:0.20-1.fc7)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9-1.fc6 > 0:0.9.8.4-4.fc7)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

xfsprogs: esandeen AT redhat com
  FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

Zim: cweyl AT alumni drew edu
  FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
  F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From aph at redhat.com  Thu Oct 18 10:16:50 2007
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Oct 2007 11:16:50 +0100
Subject: java release notes for FC8
In-Reply-To: <f6e5806f0710171915w34342564g6787fe6db000f45e@mail.gmail.com>
References: <f6e5806f0710171915w34342564g6787fe6db000f45e@mail.gmail.com>
Message-ID: <18199.12946.826782.811027@zebedee.pink>

darrell pfeifer writes:
 > Current rawhide has a severe bug that affects all Sun Java
 > implementations including the jdk1.7.0 betas.
 > 
 > https://bugzilla.redhat.com/show_bug.cgi?id=254144
 > 
 > The bug causes any Java application to die when it attempts to do graphics.
 > 
 > The current workaround for the bug is to run icedtea.
 > 
 > I'm not sure that there will be a resolution any time soon. If the bug
 > isn't fixed for FC8, the release notes should clearly indicate that
 > icedtea is the only Java implementation that will work.

I don't see why: presumably IBM, BEA, gcj, etc, still work.  Does the
problem exist anywhere outside Sun's Java?

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From buildsys at fedoraproject.org  Thu Oct 18 10:46:04 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 18 Oct 2007 06:46:04 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-18
Message-ID: <20071018104604.1B90E15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 12

    catfish-0.3-1.fc6
    hatari-0.95-4.fc6
    kbackup-0.5.3-1.fc6
NEW perl-Digest-CRC-0.10-2.fc6 : Generic CRC functions
    perl-File-Remove-0.38-1.fc6
    pikloops-0.2.5-1.fc6
    pipepanic-0.1.3-4.fc6
    python-gammu-0.22-3.fc6
NEW python-minihallib-0.1.8-2.fc6 : Library to handle HAL devices and events
NEW R-multcomp-0.992-3.fc6 : Simultaneous inference for general linear hypotheses R Package
    spambayes-1.0.4-5.fc6
    tecnoballz-0.91-6.fc6


Changes in Fedora Extras 6: 


catfish-0.3-1.fc6
-----------------
* Thu Oct 18 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-1
- 0.3

* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-0.3.c
- Remove beagle dependency for now because beagle is not
  available on ppc64 (although catfish itself is noarch :( )

hatari-0.95-4.fc6
-----------------
* Sat Oct 06 2007 Andrea Musuruane <musuruan at gmail.com> 0.95-4
- Fixed doc/authors.txt file encoding
- Updated icon cache scriptlets to be compliant to new guidelines

* Wed Aug 29 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 0.95-3
- Rebuild for selinux ppc32 issue.

* Mon Aug 20 2007 Andrea Musuruane <musuruan at gmail.com> 0.95-2
- changed license due to new guidelines 
- removed %{?dist} tag from changelog

* Sat Jun 23 2007 Andrea Musuruane <musuruan at gmail.com> 0.95-1
- updated to upstream 0.95
- updated description
- README.tos and hatari.desktop are no longer built in the spec file
- added new upstream hmsa tool
- added new upstream french man page
- updated icon cache scriptlets to be compliant to new guidelines
- cosmetic changes

kbackup-0.5.3-1.fc6
-------------------
* Thu Oct 18 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.5.3-1
- New upstream version
  - Update patch 0
  - Remove patch 1 that is no more needed

perl-Digest-CRC-0.10-2.fc6
--------------------------
* Tue Oct 16 2007 Christopher Stone <chris.stone at gmail.com> 0.10-2
- Remove zero length files.

* Tue Oct 16 2007 Christopher Stone <chris.stone at gmail.com> 0.10-1
- Initial Release.

perl-File-Remove-0.38-1.fc6
---------------------------
* Wed Oct 17 2007 Ralf Cors?pius <rc040203 at freenet.de> - 0.38-1
- Upstream update.

* Fri Aug 17 2007 Ralf Cors?pius <rc040203 at freenet.de> - 0.37-2
- Update license tag.

pikloops-0.2.5-1.fc6
--------------------
* Wed Oct 17 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.5-1
- New upstream version
  - Removing Education category no more needed
  - BR automake no more needed

pipepanic-0.1.3-4.fc6
---------------------
* Sat Oct 06 2007 Andrea Musuruane <musuruan at gmail.com> 0.1.3-4
- Fixed COPYING-ARTWORK file encoding
- Updated icon cache scriptlets to be compliant to new guidelines

* Mon Aug 20 2007 Andrea Musuruane <musuruan at gmail.com> 0.1.3-3
- Changed license due to new guidelines
- Removed %{?dist} tag from changelog
- Updated icon cache scriptlets to be compliant to new guidelines

* Wed May 02 2007 Andrea Musuruane <musuruan at gmail.com> 0.1.3-2
- Fixed package ownership of its datadir
- Changed description
- Added a patch by Hans de Goede to set a window title and icon

python-gammu-0.22-3.fc6
-----------------------
* Wed Oct 17 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.22-3
- Added pcc arch build.

python-minihallib-0.1.8-2.fc6
-----------------------------
* Wed Oct 17 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.8-2
- remove duplicates at the files section

* Tue Oct 16 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.8-1
- update to the last release

* Tue Oct 16 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.7-2
- don't use CFLAGS
- fix this file according to the Python Eggs Guidelines
  (http://fedoraproject.org/wiki/Packaging/Python/Eggs)

* Tue Oct 16 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.7-1
- update to the last release
- add examples to the documentation

* Wed Oct 03 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.6-1
- update to the last release
- fix Source tag

* Tue Oct 02 2007 Andy Shevchenko <andy at smile.org.ua>
- fix License tag according to last Fedora guidelines

R-multcomp-0.992-3.fc6
----------------------
* Mon Jul 23 2007 Orion Poplawski <orion at cora.nwra.com> - 0.992-3
- Update to 0.992-5
- Update license tag

spambayes-1.0.4-5.fc6
---------------------
* Wed Oct 17 2007 Christopher Stone <chris.stone at gmail.com> 1.0.4-5
- Providing Eggs for non-setuptools packages (bz#325041)

tecnoballz-0.91-6.fc6
---------------------
* Sat Aug 25 2007 Andrea Musuruane <musuruan at gmail.com> 0.91-6
- changed license due to new guidelines
- removed %{?dist} tag from changelog
- updated icon cache scriptlets to be compliant to new guidelines
- changed desktop categories from Game;ArcadeGame; to
  Game;ArcadeGame;BlocksGame; (resolves bugzilla #250940)

* Tue Apr 03 2007 Andrea Musuruane <musuruan at gmail.com> 0.91-5
- changed summary to avoid naming trademarks.



From fedora at camperquake.de  Thu Oct 18 10:48:56 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 18 Oct 2007 12:48:56 +0200
Subject: Experimental ppc livecd-iso-to-stick support
In-Reply-To: <4716D055.2030606@redhat.com>
References: <4716CDB5.8000001@redhat.com>
	<4716D055.2030606@redhat.com>
Message-ID: <20071018124856.61b2b16d@banea.int.addix.net>

Hi.

On Wed, 17 Oct 2007 23:17:41 -0400, Jarod Wilson wrote:

> http://people.redhat.com/jwilson/misc/livecd-iso-to-disk.ppc
> http://people.redhat.com/jwilson/misc/livecd-iso-to-disk-ppc.diff

You're hardcoding /dev/sda2 into the mkofboot call, which is probably
not a good idea.



From buildsys at redhat.com  Thu Oct 18 10:58:28 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 18 Oct 2007 06:58:28 -0400
Subject: rawhide report: 20071018 changes
Message-ID: <200710181058.l9IAwSQM020892@porkchop.devel.redhat.com>

New package R-multcomp
	Simultaneous inference for general linear hypotheses R Package

New package blitz
	C++ class library for matrix scientific computing

New package kcbench
	Kernel compile benchmark

New package kcbench-data
	Kernel sources to be used by kcbench

New package libcompizconfig
	Configuration backend for compiz

New package libgssglue
	Generic Security Services Application Programming Interface Library

New package perl-Digest-CRC
	Generic CRC functions

New package vecmath1.2
	Free version of vecmath from the Java3D 1.2 specification


Removed package beryl-manager

Removed package beryl-core

Removed package aquamarine

Removed package heliodor

Removed package beryl-settings

Removed package bdock

Removed package beryl-plugins

Updated Packages:

NetworkManager-vpnc-1:0.7.0-0.3.svn2970.fc8
-------------------------------------------
* Wed Oct 17 2007 Bill Nottingham <notting at redhat.com> - 1:0.7.0-0.3.svn2970
- rebuild (#336261)

adaptx-0.9.13-4jpp.3.fc8
------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.9.13-4jpp.3
- enum is a reserved keyword now, fix javadoc by not naming variables "enum"

* Wed Apr 18 2007 Permaine Cheung <pcheung at redhat.com> 0.9.13-4jpp.2
- Fixed the building of javadoc

alsa-lib-1.0.15-0.4.rc3.fc8
---------------------------
* Wed Oct 17 2007 Lennart Poettering <lpoetter at redhat.com> 1.0.15-0.3.rc3
- Add hook to /etc/alsa/alsa.conf so that /etc/alsa/default-pulse.conf
  is loaded when it exists. This allows us to enable the pulse plugin by
  default depending on whether it is installed or not.

alsa-plugins-1.0.14-5.fc8
-------------------------
* Wed Oct 17 2007 Lennart Poettering <lpoetter at redhat.com> - 1.0.14-5
- Split pulse.conf into two, so that we can load one part from
  form /etc/alsa/alsa.conf. (#251943)

anaconda-11.3.0.42-1
--------------------
* Wed Oct 17 2007 Peter Jones <pjones at redhat.com> 11.3.0.42-1
- Don't include 'sound-and-video' in 'Office and Productivity' since the
  former is enabled by default, and including it here causes disabling OaP
  to result in disabling s-a-v unintentionally.

* Wed Oct 17 2007 Peter Jones <pjones at redhat.com> 11.3.0.41-1
- Fix liveinst build on ppc

* Wed Oct 17 2007 Peter Jones <pjones at redhat.com> 11.3.0.40-1
- Don't build gptsync on ppc (katzj)
- Remove obsolete no.po translation (clumens, #332141)
- Update gptsync to 0.10

arts-8:1.5.8-4.fc8
------------------
* Wed Oct 17 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 8:1.5.8-4
- remove arts/open workaround (#329671)

audit-1.6.2-4.fc8
-----------------
* Wed Oct 17 2007 Steve Grubb <sgrubb at redhat.com> 1.6.2-4
- Fix race between threads accessing common data in auditd
- Fix double free in event dispatcher.

bigboard-0.5.23-1.fc8
---------------------
* Wed Oct 17 2007 Colin Walters <walters at redhat.com> - 0.5.23-1
- new upstream

catfish-0.3-1.fc8
-----------------
* Thu Oct 18 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3-1
- 0.3

dom4j-0:1.6.1-2jpp.3.fc8
------------------------
* Wed Oct 17 2007 Deepak Bhole <dbhole at redhat.com> 1.6.1-2jpp.3
- Resaolve bz#302321: Add copyright header that was accidentally removed.

emerald-themes-0.5.2-2.fc8
--------------------------
* Wed Oct 17 2007 Jarod Wilson <jwilson at redhat.com> 0.5.2-2
- Add ExcludeArch: ppc64, since emerald isn't available

fedora-logos-8.0.0-1.fc8
------------------------
* Wed Oct 17 2007 Ray Strode <rstrode at redhat.com> - 8.0.0-1
- Drop Fedora Infinity gdm theme

fpc-2.2.0-10.fc8
----------------
* Tue Oct 16 2007 Joost van der Sluis <joost at cnoc.nl> 2.2.0-10
- Strip the debuginfo from grab_vcsa and ppudump, since debugedit chokes on it
- Only strip debugdata on x86_64

* Tue Oct 16 2007 Joost van der Sluis <joost at cnoc.nl> 2.2.0-9
- Strip the debuginfo from mkxmlrpc, since debugedit chokes on it

* Tue Oct 16 2007 Joost van der Sluis <joost at cnoc.nl> 2.2.0-8
- Strip the debuginfo from h2pas, since debugedit chokes on it

frysk-0.0.1.2007.10.17-1.fc8
----------------------------
* Wed Oct 17 2007 Andrew Cagney <cagney at redhat.com> - 0.0.1.2007.10.17-1
- Import frysk-0.0.1.2007.10.17.
- Remove hack disabling glade check.

* Mon Sep 24 2007 Andrew Cagney <cagney at redhat.com> - 0.0.1.2007.09.24-2
- Install frysk.desktop; but with Hidden=true.
- Sort files list.
- Remove trailing period from summaries.
- Replace ExclusiveArch with ExcludeArch of ppc and ppc64; bug 305611.

gdm-1:2.20.1-4.fc8
------------------
* Wed Oct 17 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.1-4
- Improve Warren's fix (#246399)

* Wed Oct 17 2007 Warren Togami <wtogami at redhat.com> - 1:2.20.1-3
- Fix GDM segfault when XInput extension not available
  Also fixes XDMCP (#246399)

* Wed Oct 17 2007 Dan Walsh <dwalsh at redhat.com> - 1:2.20.1-1
- Change pam config so keyinit happens after pam_selinux open

glibc-2.7-1
-----------
* Wed Oct 17 2007 Jakub Jelinek <jakub at redhat.com> 2.7-1
- glibc 2.7 release
- fix tzfile.c for times after last transition (#333561)
- fix sem_post at GLIBC_2.0 on i?86
- appease valgrind in libpthread.so initialization
- misc fixes (BZ#3425, BZ#5184, BZ#5186)

gnome-media-2.20.1-3.fc8
------------------------
* Wed Oct 17 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-3
- Show the "Front" track by default (#335121)

gnome-phone-manager-0.20-1.fc8
------------------------------
* Wed Oct 17 2007 - Bastien Nocera <bnocera at redhat.com> - 0.20-1
- Update to 0.20

gnu-regexp-1.1.4-10jpp.3.fc8
----------------------------
* Wed Oct 17 2007 Deepak Bhole <dbhole at redhat.com> 1.1.4-10jpp.3
- Resolve bz# 245270: Fixed URL

gnuplot-4.2.0-7.fc8
-------------------
* Wed Oct 17 2007 Ivana Varekova <varekova at redhat.com> - 4.2.0-7
- add URL tag

gtk2-2.12.1-2.fc8
-----------------
* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-2
- Fix a crash in the firefox print preview (#336771)

* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-1
- Update to 2.12.1 (bug fixes and translation updates)
- Drop obsolete patches

* Thu Oct 11 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.0-6
- Fix a double-free problem in gtk-update-icon-cache (#327711)

hdf-4.2r2-2.fc8
---------------
* Wed Oct 17 2007 Patrice Dumas <pertusus at free.fr> 4.2r2-2
- update to 4.2r2

hdf5-1.6.6-1.fc8
----------------
* Wed Oct 17 2007 Orion Poplawski <orion at cora.nwra.com> 1.6.6-1
- Update to 1.6.6, drop upstreamed patches
- Explicitly set compilers

java-1.5.0-gcj-1.5.0.0-17.fc8
-----------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.5.0.0-17
- fix aot-compile-rpm to not run inside the buildroot

* Tue Oct 16 2007 Dennis Gilmore <dennis at ausil.us> - 1.5.0.0-16
- add sparc64 to the list of 64 bit archs

* Tue May 15 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 1.5.0.0-15
- Require findutils for post and postun.
- Resolves: rhbz#240159

kdelibs-6:3.5.8-4.fc8
---------------------
* Wed Oct 17 2007 Than Ngo <than at redhat.com> 3.5.8-4
- apply upstream patch to fix http-regression

* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-3
- respin (for openexr-1.6.0)

* Fri Oct 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-2
- kde-3.5.8

kernel-2.6.23.1-23.fc8
----------------------
* Wed Oct 17 2007 John W. Linville <linville at redhat.com>
- iee80211: fix an endian bug
- mac80211: change BSSID list key to (BSSID, SSID, frequency) tuple
- mac80211: make honor IW_SCAN_THIS_ESSID
- mac80211: don't fail IE parse if junk at end of frame

* Wed Oct 17 2007 Chuck Ebbert <cebbert at redhat.com>
- Revert to less-accurate but stable 2.6.22 cputime accounting.

* Wed Oct 17 2007 John W. Linville <linville at redhat.com>
- ath5k fix to avoid oops on driver load w/ unknown/unsupported cards

keyjnote-0.10.1-2.fc8
---------------------
* Wed Oct 17 2007 Allisson Azevedo <allisson at gmail.com> 0.10.1-2
- Fix spec issues
libgnome-2.20.1-2.fc8
---------------------
* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Install all necessary GConf schemas

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation update)

* Thu Oct 11 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-4
- Add Requires: fedora-gnome-theme >= 8.0.0

libgnomeui-2.20.1.1-1.fc8
-------------------------
* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1.1-1
- Update to 2.20.1.1 (fixes a crash in thumbnailing code)

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates, file chooser improvements)

* Wed Sep 19 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-1
- Update to 2.20.0

libtirpc-0.1.7-12.fc8
---------------------
* Wed Oct 17 2007 Steve Dickson  <steved at redhat.com> 0.1.7-12
- Switch the libgssapi dependency to libgssglue

memtest86+-1.70-2.fc8
---------------------
* Wed Oct 17 2007 Warren Togami <wtogami at redhat.com> - 1.70-2
- mschmidt's boot time configuration of serial console (#319631)

mesa-7.0.1-7.fc8
----------------
* Thu Oct 18 2007 Dave Airlie <airlied at redhat.com> 7.0.1-7
- mesa-7.0.1-stable-branch.patch - Updated with more fixes from stable
- mesa-7.0.1-r300-fix-writemask.patch - fix r300 fragprog writemask
- mesa-7.0.1-r200-settexoffset.patch - add zero-copy TFP support for r200

nfs-utils-1:1.1.0-6.fc8
-----------------------
* Wed Oct 17 2007 Steve Dickson <steved at redhat.com>  1.1.0-6
- Switch the libgssapi dependency to libgssglue

* Fri Sep 14 2007 Steve Dickson <steved at redhat.com>  1.1.0-5
- Changed the default paths in sm-notify to 
  /var/lib/nfs/statd (bz 258461)
- Updated exportfs manpage (bz 262861)

* Wed Aug 15 2007 Steve Dickson <steved at redhat.com>  1.1.0-4
- Make sure the open() system calling in exportfs uses
  mode bits when creating the etab file (bz 252440).

nfs-utils-lib-1.1.0-3.fc8
-------------------------
* Tue Oct 16 2007 Steve Dickson <steved at redhat.com> 1.1.0-3
- Switch the libgssapi dependency to libgssglue
- Updated  librpcsecgss to the 0.16 release

online-desktop-0.2.20-1.fc8
---------------------------
* Wed Oct 17 2007 Colin Walters <walters at redhat.com> - 0.2.20-1
- new upstream
- require gconf devel

openmpi-1.2.4-1.fc8
-------------------
* Wed Oct 17 2007 Doug Ledford <dledford at redhat.com> - 1.2.4-1
- Update to 1.2.4 upstream version
- Build against libtorque
- Pass a valid mode to open
- Resolves: bz189441, bz265141

* Tue Aug 28 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 1.2.3-5
- Rebuild for selinux ppc32 issue.

perl-File-Remove-0.38-1.fc8
---------------------------
* Wed Oct 17 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.38-1
- Upstream update.

perl-Log-Log4perl-1.13-1.fc8.1
------------------------------
* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.13-1.1
- disable tests

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.13-1
- bump to 1.13

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.12-1.2
- add BR: perl(Test::More)

pikloops-0.2.5-1.fc8
--------------------
* Wed Oct 17 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.2.5-1
- New upstream version
  - Removing Education category no more needed

pulseaudio-0.9.7-0.16.svn20071017.fc8
-------------------------------------
* Wed Oct 17 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.7-0.16.svn20071017
- Another SVN snapshot, fixing another round of bugs (#330541)
- Split libpulscore into a seperate package to work around multilib limitation (#335011)

python-alsa-1.0.15-1.fc8
------------------------
* Wed Oct 17 2007 Andy Shevchenko <andy at smile.org.ua> 1.0.15-1
- update to relase 1.0.15
python-gammu-0.22-3.fc8
-----------------------
* Wed Oct 17 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.22-3
- Added pcc arch build.

rpcbind-0.1.4-11.fc8
--------------------
* Wed Oct 17 2007 Steve Dickson <steved at redhat.com> 0.1.4-11
- Reworked logic in initscript so the correct exit is 
  used when networking does not exist or is set up
  incorrectly.

rt3-3.6.5-1.fc8
---------------
* Wed Oct 17 2007 Ralf Cors??pius <rc040203 at freenet.de> - 3.6.5-1
- Upstream update.
- Split-out rt-mailgate in to rt3-mailgate (BZ 332731).

selinux-policy-3.0.8-24.fc8
---------------------------
* Tue Oct 16 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-24
- Allow rpm to chat with networkmanager

* Mon Oct 15 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-23
- Fixes for ipsec and exim mail
- Change default to unconfined user

setools-3.3.1-6.fc8
-------------------
* Wed Oct 17 2007 Chris PeBenito <cpebenito at tresys.com> 3.3.1-6.fc8
- Update for 3.3.1.

syslinux-3.36-7.fc8
-------------------
* Wed Oct 17 2007 Peter Jones <pjones at redhat.com> - 3.36-7
- Add necessary files for makebootfat to make usb images (patch from
  Joel Granados <jgranado at redhat.com>)

totem-2.20.1-1.fc8
------------------
* Wed Oct 17 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-1
- Update to 2.20.1
- Require GTK+ 2.12.1

valgrind-1:3.2.3-7
------------------
* Thu Oct 18 2007 Jakub Jelinek <jakub at redhat.com> 3.2.3-7
- add suppressions for glibc >= 2.7

warzone2100-2.0.7-5.fc8
-----------------------
* Wed Oct 17 2007 Karol Trzcionka <karlikt at gmail.com> - 2.0.7-5
- Fix build on koji ppc (remove smp_flags)
- set ExcludeArch x86_64 ppc64 sparc64 alpha

* Wed Oct 17 2007 Karol Trzcionka <karlikt at gmail.com> - 2.0.7-4
- Merge data subpackage with core package
- Replace ExcludeArch with ExclusiveArch

wine-0.9.47-1.fc8
-----------------
* Sat Oct 13 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.47-1
- version upgrade

* Sun Oct 07 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

* Sun Sep 16 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.45-1
- version upgrade

xorg-x11-drv-mouse-1.2.3-1.fc8
------------------------------
* Wed Oct 17 2007 Adam Jackson <ajax at redhat.com> 1.2.3-1
- xf86-input-mouse 1.2.3

xorg-x11-drv-radeonhd-0.0.2-0.7.20071017git.fc8
-----------------------------------------------
* Wed Oct 17 2007 Hans Ulrich Niedermann <hun at n-dimensional.de> - 0.0.2-0.7.20071017git
- New snapshot (upstream commit d03841b4950b3b827b3c42507e01767d0569391f).
- Use upstream's version 0.0.2.
- Trade in ThinkPad backlight key fix for non-broken mode on lid event.

xorg-x11-server-1.3.0.0-33.fc8
------------------------------
* Thu Oct 18 2007 Dave Airlie <airlied at redhat.com> 1.3.0.0-33
- xserver-1.3.0-xorg-conf-man-randr-update.patch - update man page for randr setup
- xserver-1.3.0-update-quirks.patch - update quirks for more monitor issues
- BuildReq: mesa-source >= 7.0.1-6.

* Mon Oct 15 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-31.jx
- xserver-1.3.0-late-sigusr1.patch: Test, move kill(getppid(), SIGUSR1)
  as late as possible.

* Fri Oct 12 2007 Adam Jackson <ajax at redhat.com> 1.3.0.0-31
- xorg-x11-server-Red-Hat-extramodes.patch: Remove 2560x1600 GTF timing.

yum-utils-1.1.8-1.fc8
---------------------
* Wed Oct 17 2007 Tim Lauridsen <tla at rasmil.dk>
- mark as 1.1.8

* Sun Sep 30 2007 James Bowes <jbowes at redhat.com>
- Update the yum-refresh-updatesd description

* Fri Sep 14 2007 Tim Lauridsen <tla at rasmil.dk>
- do not use wildcards for manpages in yum-utils files section to avoid duplicates

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.i386 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.i386 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.i386 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.x86_64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.x86_64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.x86_64 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQClient::MQSeries)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::QueueManager)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Message)
	perl-SOAP-Lite - 0.68-4.fc8.1.noarch requires perl(MQSeries::Queue)
	setools-libs - 3.3.1-6.fc8.ppc64 requires libstdc++.so.6
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew





From aph at redhat.com  Thu Oct 18 11:23:59 2007
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Oct 2007 12:23:59 +0100
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017144946.GH13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
Message-ID: <18199.16975.56489.987680@zebedee.pink>

Deepak Bhole writes:
 > * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
 > > On Wed, 17 Oct 2007 10:07:49 -0400
 > > Deepak Bhole <dbhole at redhat.com> wrote:
 > > 
 > > > The problem is that IcedTea is only available on x86/x86_64. Since my
 > > > package is noarch, koji randomly distributes it between
 > > > ppc/x86/x86_64, and when it goes to ppc, the build fails.
 > > > 
 > > > While IcedTea is not a strong requirement for checkstyle, this problem
 > > > will be encountered by any package that is to be built with IcedTea..
 > > 
 > > ExclusiveArch: i386 x86_64  in the spec, with loud comments about the
 > > ExclusiveArch being there to match the arches where IcedTea is
 > > available, and needs to be updated when IcedTea hits more arches.
 > > 
 > 
 > But that would create arch specific packages, which would not get
 > shipped on ppc. Packages built with icedtea can run on ppc with gcj in
 > interpreted mode.

FYI, here are the mandriva spec and patches for checkstyle.
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/checkstyle/current/

Thanks to akurtakov for that.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From nicolas.mailhot at laposte.net  Thu Oct 18 11:33:27 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 18 Oct 2007 13:33:27 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
Message-ID: <1192707207.19550.18.camel@rousalka.dyndns.org>


Le jeudi 18 octobre 2007 ? 10:57 +0300, Panu Matilainen a ?crit :
> On Thu, 18 Oct 2007, Nicolas Mailhot wrote:

> > You could make the same arguments for user names, unix permissions or
> > file location ? a lot them have different values in the wild than in
> > Fedora and yet we store our policy in rpm.
> 
> The difference here is that we don't even try to support several 
> different policies (including custom local policies on top of the distro 
> policies) for user names, permissions etc. If we did, we'd be in the very 
> same swamp as with SELinux currently.

And the swamp root is not in-spec definition of our security policy the
swamp root is trying to manage several set of security policies without
getting one right distro-wide first.

The more I think about it the more I'm convinced we should have started
by adopting a lax Fedora selinux policy (and get it supported by all
packages and distro tools including getting selinux labels in-spec like
all our other policies) and then spent the following releases tightening
it instead of doing all at once, compromising on tool support to be a
jack-of-all-trades, and get nowhere.

We don't do file relocation. We don't do debian suggests. We forced a
single encoding on everyone. We don't do a lot of things that would mean
letting users choose instead of getting our Fedora policy right.

For selinux we went the other way and everyone can see the resulting
disaster.

> I'm not claiming there is no problem. What I'm saying is that storing the 
> labels within RPM doesn't fix a thing.

It stops the pretense selinux is special and can not be integrated
properly.

-- 
Nicolas Mailhot



From jon.nettleton at gmail.com  Thu Oct 18 11:36:15 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 18 Oct 2007 07:36:15 -0400
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <loom.20071018T074804-134@post.gmane.org>
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
Message-ID: <e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>

On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
> IMHO gnome-keyring should simply allow passwordless keyrings like KWallet does,
> that would solve this problem in a much simpler way for most use cases, and
> standard *nix permissions will keep the data just as secure as with pam_keyring
> automatically unlocking the keyring for the user owning it anyway.
>

That is absolutely 100% not true.  If someone steals your laptop and
you have a passwordless keyring like in KWallet, your passwords are
pretty much stolen.  Boot off a bootable cd mount the filesystem,
done.

With pam_gnome_keyring those passwords are still encrypted on disk and
without the key, the thief gets nothing.

Jon



From pertusus at free.fr  Thu Oct 18 12:03:08 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Oct 2007 14:03:08 +0200
Subject: rpms/xgrav/devel xgrav.spec,1.1,1.2
In-Reply-To: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
References: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
Message-ID: <20071018120308.GD5293@free.fr>

On Thu, Oct 18, 2007 at 07:44:04AM -0400, Jon Ciesla wrote:
> Author: limb
> 
> -BuildRequires: desktop-file-utils, SDL-devel, flex
> +BuildRequires: desktop-file-utils, SDL-devel, flex, zlib-devel

Why is it needed?

--
Pat



From limb at jcomserv.net  Thu Oct 18 12:07:23 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Oct 2007 07:07:23 -0500 (CDT)
Subject: rpms/xgrav/devel xgrav.spec,1.1,1.2
In-Reply-To: <20071018120308.GD5293@free.fr>
References: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
	<20071018120308.GD5293@free.fr>
Message-ID: <9101.63.85.68.164.1192709243.squirrel@mail.jcomserv.net>


> On Thu, Oct 18, 2007 at 07:44:04AM -0400, Jon Ciesla wrote:
>> Author: limb
>>
>> -BuildRequires: desktop-file-utils, SDL-devel, flex
>> +BuildRequires: desktop-file-utils, SDL-devel, flex, zlib-devel
>
> Why is it needed?

Build failed without it.

http://koji.fedoraproject.org/koji/getfile?taskID=201754&name=build.log

Succeeded with it.

> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From panemade at gmail.com  Thu Oct 18 13:10:50 2007
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Thu, 18 Oct 2007 18:40:50 +0530
Subject: rawhide report: 20071017 changes
In-Reply-To: <47171A15.2080907@redhat.com>
References: <200710180234.l9I2YJOb000797@porkchop.devel.redhat.com>
	<1192692338.28285.37.camel@Jehannum> <47171A15.2080907@redhat.com>
Message-ID: <f4586a2e0710180610k2761dd2avcb61a9ddc6091b5f@mail.gmail.com>

Hi,
On 10/18/07, Jens Petersen <petersen at redhat.com> wrote:
> Hi Caolan,
>
> Caolan McNamara wrote:
> >>      openoffice.org-langpack-ar - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
> >>      openoffice.org-langpack-he_IL - 1:2.3.0-6.3.fc8.ppc64 requires fonts-hebrew
> >>      openoffice.org-langpack-ur - 1:2.3.0-6.3.fc8.ppc64 requires fonts-arabic
> >>      tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew
> >
> > So is this just some sort of bug in the fonts-arabic/fonts-hebrew
> > meta-packages or do all the above requiring packages need to be fixed to
> > require the differently named packages.
>
> It seems fonts-arabic and fonts-hebrew were not in rawhide-20071017
> for some reason - dunno why.  They have been updated for the new fonts
> packages (along with fonts-sinhala) so assuming they come back
> everything ought to be ok.
     I found %files section missing in all 3 packages. Rahul has built
them now (guess it happened while making them as meta-package). So
this dependency problem will get resolved in tomorrow's rawhide->
20071019.
Thanks,
parag.



From jwilson at redhat.com  Thu Oct 18 13:12:54 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Thu, 18 Oct 2007 09:12:54 -0400
Subject: Experimental ppc livecd-iso-to-stick support
In-Reply-To: <20071018124856.61b2b16d@banea.int.addix.net>
References: <4716CDB5.8000001@redhat.com>	<4716D055.2030606@redhat.com>
	<20071018124856.61b2b16d@banea.int.addix.net>
Message-ID: <47175BD6.2090004@redhat.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 17 Oct 2007 23:17:41 -0400, Jarod Wilson wrote:
> 
>> http://people.redhat.com/jwilson/misc/livecd-iso-to-disk.ppc
>> http://people.redhat.com/jwilson/misc/livecd-iso-to-disk-ppc.diff
> 
> You're hardcoding /dev/sda2 into the mkofboot call, which is probably
> not a good idea.

Oops. That should probably be ${device}2, at least for the moment...
Fixing... Okay, fixed.

-- 
Jarod Wilson
jwilson at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/d0264cfc/attachment.sig>

From valent.turkovic at gmail.com  Thu Oct 18 13:35:26 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 18 Oct 2007 15:35:26 +0200
Subject: what to do when gnome power manager shows wrong battery capacity?
Message-ID: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>

Sorry for long subject, but what to do when gnome power manager shows
wrong battery capacity?

I have two laptops for who I see that battery capacity is stated as
88.8Wh but it is not! So when gnome starts I get an error message
saying I have a faulty battery. What do I need to do? Submit a bug? To
what component? Send an email? To whom?

Thank you,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jwilson at redhat.com  Thu Oct 18 13:38:34 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Thu, 18 Oct 2007 09:38:34 -0400
Subject: Experimental ppc livecd-iso-to-stick support
In-Reply-To: <4716CDB5.8000001@redhat.com>
References: <4716CDB5.8000001@redhat.com>
Message-ID: <471761DA.6040507@redhat.com>

Jarod Wilson wrote:
> Spent a while beating on a usb stick to make it boot my powerbook. Once
> that was working, I attempted to add support to livecd-iso-to-stick to
> set up a stick automagically.
[...]
> 5) not tested on any other machines yet

Yay, same stick that boots my powerbook boots a ppc mac mini too.

-- 
Jarod Wilson
jwilson at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/aced2298/attachment.sig>

From skvidal at fedoraproject.org  Thu Oct 18 13:37:02 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 18 Oct 2007 09:37:02 -0400
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
Message-ID: <1192714622.8542.104.camel@cutter>


On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> Sorry for long subject, but what to do when gnome power manager shows
> wrong battery capacity?
> 
> I have two laptops for who I see that battery capacity is stated as
> 88.8Wh but it is not! So when gnome starts I get an error message
> saying I have a faulty battery. What do I need to do? Submit a bug? To
> what component? Send an email? To whom?
> 
> Thank you,
> Valent.
> 

how old are the batteries?

If they're more than say, a year old, it's probably true. battery charge
life declines. Get the info on your battery by clicking on the
gnome-power-manager icon and you can find out the info on your battery.

-sv




From rapponcape at gmail.com  Thu Oct 18 13:44:57 2007
From: rapponcape at gmail.com (rapponcape)
Date: Thu, 18 Oct 2007 09:44:57 -0400
Subject: removable storage devices still do not auto-mount
Message-ID: <55df67120710180644m56851f32j26813b125e2a348d@mail.gmail.com>

This is a fresh, DVD, install of FC7.



From valent.turkovic at gmail.com  Thu Oct 18 13:46:21 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 18 Oct 2007 15:46:21 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <1192714622.8542.104.camel@cutter>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
Message-ID: <64b14b300710180646h3a3b029bm469d517f3394c21c@mail.gmail.com>

One laptop is brand new and other is 2 years old.

On both laptops there are 6-cell batteries - my googling showed me
that capacity should be around 60Wh for a 6-cell battery.

On both laptops gnome-power-manager (GPM) shows that capacity should
be 88.8Wh (which I think is wrong).

On new laptop actual capacity that GPM shows is 60Wh and on the old
laptop is 44Wh (it droped from 60 to 44 in 2 years).

Valent.

On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
>
> On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > Sorry for long subject, but what to do when gnome power manager shows
> > wrong battery capacity?
> >
> > I have two laptops for who I see that battery capacity is stated as
> > 88.8Wh but it is not! So when gnome starts I get an error message
> > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > what component? Send an email? To whom?
> >
> > Thank you,
> > Valent.
> >
>
> how old are the batteries?
>
> If they're more than say, a year old, it's probably true. battery charge
> life declines. Get the info on your battery by clicking on the
> gnome-power-manager icon and you can find out the info on your battery.
>
> -sv
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From pertusus at free.fr  Thu Oct 18 13:46:29 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Oct 2007 15:46:29 +0200
Subject: rpms/xgrav/devel xgrav.spec,1.1,1.2
In-Reply-To: <9101.63.85.68.164.1192709243.squirrel@mail.jcomserv.net>
References: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
	<20071018120308.GD5293@free.fr>
	<9101.63.85.68.164.1192709243.squirrel@mail.jcomserv.net>
Message-ID: <20071018123008.GE5293@free.fr>

On Thu, Oct 18, 2007 at 07:07:23AM -0500, Jon Ciesla wrote:
> 
> > On Thu, Oct 18, 2007 at 07:44:04AM -0400, Jon Ciesla wrote:
> >> Author: limb
> >>
> >> -BuildRequires: desktop-file-utils, SDL-devel, flex
> >> +BuildRequires: desktop-file-utils, SDL-devel, flex, zlib-devel
> >
> > Why is it needed?
> 
> Build failed without it.
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=201754&name=build.log

Ok, there is an include for zlib.h. Maybe the include should be removed?
I have checked that it still builds without. Also maybe worth sending
upstream.

--
Pat



From dbhole at redhat.com  Thu Oct 18 13:52:37 2007
From: dbhole at redhat.com (Deepak Bhole)
Date: Thu, 18 Oct 2007 09:52:37 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <18199.16975.56489.987680@zebedee.pink>
References: <20071017140748.GG13974@redhat.com>
	<20071017102427.617a217c@redhat.com>
	<20071017144946.GH13974@redhat.com>
	<18199.16975.56489.987680@zebedee.pink>
Message-ID: <20071018135237.GD32224@redhat.com>

* Andrew Haley <aph at redhat.com> [2007-10-18 07:24]:
> Deepak Bhole writes:
>  > * Jesse Keating <jkeating at redhat.com> [2007-10-17 10:25]:
>  > > On Wed, 17 Oct 2007 10:07:49 -0400
>  > > Deepak Bhole <dbhole at redhat.com> wrote:
>  > > 
>  > > > The problem is that IcedTea is only available on x86/x86_64. Since my
>  > > > package is noarch, koji randomly distributes it between
>  > > > ppc/x86/x86_64, and when it goes to ppc, the build fails.
>  > > > 
>  > > > While IcedTea is not a strong requirement for checkstyle, this problem
>  > > > will be encountered by any package that is to be built with IcedTea..
>  > > 
>  > > ExclusiveArch: i386 x86_64  in the spec, with loud comments about the
>  > > ExclusiveArch being there to match the arches where IcedTea is
>  > > available, and needs to be updated when IcedTea hits more arches.
>  > > 
>  > 
>  > But that would create arch specific packages, which would not get
>  > shipped on ppc. Packages built with icedtea can run on ppc with gcj in
>  > interpreted mode.
> 
> FYI, here are the mandriva spec and patches for checkstyle.
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/checkstyle/current/
> 
> Thanks to akurtakov for that.
> 

Thanks. I'm encountering a class not found problem when the Native2Ascii
task runs. Looking at the above files, I see that that task is disabled there.
Doing so will disable/break Japanese messages via checkstyle.

I will see if I can workaround the class issue; if I cannot get
something going soon, I will disable the task for the time being in Fedora 
as well.

Cheers,
Deepak

> Andrew.
> 
> -- 
> Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
> Registered in England and Wales No. 3798903



From limb at jcomserv.net  Thu Oct 18 13:51:56 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Oct 2007 08:51:56 -0500 (CDT)
Subject: rpms/xgrav/devel xgrav.spec,1.1,1.2
In-Reply-To: <20071018123008.GE5293@free.fr>
References: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
	<20071018120308.GD5293@free.fr>
	<9101.63.85.68.164.1192709243.squirrel@mail.jcomserv.net>
	<20071018123008.GE5293@free.fr>
Message-ID: <23841.63.85.68.164.1192715516.squirrel@mail.jcomserv.net>


> On Thu, Oct 18, 2007 at 07:07:23AM -0500, Jon Ciesla wrote:
>>
>> > On Thu, Oct 18, 2007 at 07:44:04AM -0400, Jon Ciesla wrote:
>> >> Author: limb
>> >>
>> >> -BuildRequires: desktop-file-utils, SDL-devel, flex
>> >> +BuildRequires: desktop-file-utils, SDL-devel, flex, zlib-devel
>> >
>> > Why is it needed?
>>
>> Build failed without it.
>>
>> http://koji.fedoraproject.org/koji/getfile?taskID=201754&name=build.log
>
> Ok, there is an include for zlib.h. Maybe the include should be removed?
> I have checked that it still builds without. Also maybe worth sending
> upstream.

I'll check it out with upstream, but I'll leave it in place for now.

> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From pertusus at free.fr  Thu Oct 18 13:56:17 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 18 Oct 2007 15:56:17 +0200
Subject: rpms/xgrav/devel xgrav.spec,1.1,1.2
In-Reply-To: <23841.63.85.68.164.1192715516.squirrel@mail.jcomserv.net>
References: <200710181144.l9IBi4tq001873@cvs-int.fedora.redhat.com>
	<20071018120308.GD5293@free.fr>
	<9101.63.85.68.164.1192709243.squirrel@mail.jcomserv.net>
	<20071018123008.GE5293@free.fr>
	<23841.63.85.68.164.1192715516.squirrel@mail.jcomserv.net>
Message-ID: <20071018135617.GF5293@free.fr>

On Thu, Oct 18, 2007 at 08:51:56AM -0500, Jon Ciesla wrote:
> 
> 
> I'll check it out with upstream, but I'll leave it in place for now.

Indeed, that's better. Worth a comment, since zlib won't be a direct 
dependency of xgrav.

--
Pat



From bernie at codewiz.org  Thu Oct 18 14:02:07 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Thu, 18 Oct 2007 10:02:07 -0400
Subject: koji server installation
Message-ID: <4717675F.6000608@codewiz.org>

Hello Mike,

I'm installing a local Koji server at OLPC so we could create as
topical integration streams such as "rainbow", "xtest", "sugar"...

I installed all the koji packages following the tutorial on the
fedoraproject wiki.  The web interface is up and running:

  http://bender.codewiz.org/koji/

I configured it similar to the koji.fedoraproject.org setup, but
I can't seem to get builds to work.

First of all, I get these errors:

2007-10-18 09:12:56,389 [WARNING] koji.build.TaskManager: FAULT:
Traceback (most recent call last):
  File "/usr/sbin/kojid", line 1109, in runTask
    response = (handler.run(),)
  File "/usr/sbin/kojid", line 1185, in run
    return self.handler(*self.params,**self.opts)
  File "/usr/sbin/kojid", line 2174, in handler
    repo_id, event_id = self.wait(preptask)[preptask]
  File "/usr/sbin/kojid", line 1272, in wait
    return dict(session.host.taskWaitResults(self.id,subtasks))
  File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1077, in __call__
    return self.__func(self.__name,args,opts)
  File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1304, in _callMethod
    raise convertFault(fault)
Fault: <Fault 1: "<type 'exceptions.OSError'>: [Errno 13] Permission denied: '/mnt/koji'">

...even though I had set topdir=/usr/local/koji in /etc/kojid/kojid.conf.

The problem seems to be that PathInfo gets instantiated with no topdir and
so it gets the default from BASEDIR, but even after fixing that I still got
sporadic errors elsewhere until I replaced all instances of "/mnt/koji"
everywhere.

I'd suggest taking off these defaults and hard-failing when the client code
did not provide a default.  It's still better than using the configured path
only half of the times.

After fixing this problem, I got a different one:

bender:/home/bernie/src# koji --debug build dist-olpc2 xorg-x11-proto-devel-7.2-13.olpc2.src.rpm
successfully connected to hub
Uploading srpm: xorg-x11-proto-devel-7.2-13.olpc2.src.rpm
[====================================] 100% 00:00:07   1.30 MiB 171.37 KiB/sec
Created task: 3748
Task info: http://bender.codewiz.org/koji/taskinfo?taskID=3748
Watching tasks (this may be safely interrupted)...
3748 build (dist-olpc2, xorg-x11-proto-devel-7.2-13.olpc2.src.rpm): free
3748 build (dist-olpc2, xorg-x11-proto-devel-7.2-13.olpc2.src.rpm): free -> open (bender.codewiz.org)
3748 build (dist-olpc2, xorg-x11-proto-devel-7.2-13.olpc2.src.rpm): open (bender.codewiz.org) -> FAILED: BuildError: package xorg-x11-proto-devel not in list for tag dist-olpc2
  0 free  0 open  0 done  1 failed

3748 build (dist-olpc2, xorg-x11-proto-devel-7.2-13.olpc2.src.rpm) failed


Not knowing what to do, I tried a scratch build instead, but the server
got stuck, and kojira started spitting these:


2007-10-18 09:50:46,417 [ERROR] koji: Traceback (most recent call last):
  File "/usr/sbin/kojira", line 341, in main
    repomgr.updateRepos()
  File "/usr/sbin/kojira", line 250, in updateRepos
    tstate = koji.TASK_STATES[tinfo['state']]
TypeError: 'NoneType' object is unsubscriptable


I noticed there are mock-config entries in the database.  I was unsure
whether they're supposed to be created automatically, so I tried
creating one manually like so:

$ koji mock-config --arch=i386  --tag=dist-olpc2-build --mockdir=/var/lib/mock/olpc-2-i386 --distribution=dist-olpc2 olpc-2-i386
Could not get a repo for tag: dist-olpc2-build

I couldn't figure out what a correct combination of parameters would be.

Is koji 1.2.2 the version you're really
running on koji.fedoraproject.org?  After some

What else am I overlooking?  I'd be *very* glad if you could dedicate some
of your time to help me on this.  I usually hang out on freenode as _bernie
or _bernie|home.

Thanks.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From bernie at codewiz.org  Thu Oct 18 14:07:35 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Thu, 18 Oct 2007 10:07:35 -0400
Subject: koji server installation
In-Reply-To: <4717675F.6000608@codewiz.org>
References: <4717675F.6000608@codewiz.org>
Message-ID: <471768A7.3000800@codewiz.org>

Bernardo Innocenti wrote:

> Is koji 1.2.2 the version you're really
> running on koji.fedoraproject.org?  After some

[oops, it seems I've hit Send too quickly]

...After some attempts with the old RPMs from F7, I cloned
the git repository and rebuilt RPMs off the master branch.
No better luck.

With both the stable version and the snapshot, when the server
gets "stuck" building a package, it permanently stores broken
records in the database, and the main page of the web interface
barfs a big stack trace ending up with:

  File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1304, in _callMethod
    raise convertFault(fault)

  Fault: <Fault 1: "<type 'exceptions.TypeError'>: cannot marshal <class 'xmlrpclib.Fault'> objects">


The records I need to delete are:

COPY task (id, state, create_time, completion_time, channel_id, host_id, parent, label, waiting, awaited, "owner", method, request, result, eta, arch, priority, weight) FROM stdin;
3748    5       2007-10-18 09:47:47.978694      2007-10-18 09:47:54.569714      1       1       \N      \N      \N      \N      1       build   <?xml version='1.0'?>\n<methodCall>\n<methodName>build</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715259.2614679.APWGZpwg/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><string>dist-olpc2</string></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>skip_tag</name>\n<value><nil/></value></member>\n<member>\n<name>scratch</name>\n<value><nil/></value></member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n    <?xml version='1.0'?>\n<methodResponse>\n<fault>\n<value><struct>\n<member>\n<name>faultCode</name>\n<value><int>1005</int></value>\n</member>\n<member>\n<name>faultString</name>\n<value><string>package xorg-x11-proto-devel not in list for tag dist-olpc2</string></value>\n</member>\n</struct></value>\n</fault>\n</methodResponse>\n    \N      noarch  20    
  0.20000000000000001
3749    1       2007-10-18 09:50:05.047597      \N      1       1       \N      \N      t       \N      1       build   <?xml version='1.0'?>\n<methodCall>\n<methodName>build</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715395.710408.UfURJSZh/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><string>dist-olpc2</string></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>skip_tag</name>\n<value><nil/></value></member>\n<member>\n<name>scratch</name>\n<value><boolean>1</boolean></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n     \N      \N      noarch  20      0.20000000000000001
3750    1       2007-10-18 09:50:17.777683      \N      1       1       3749    i386    \N      t       1       buildArch       <?xml version='1.0'?>\n<methodCall>\n<methodName>buildArch</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715395.710408.UfURJSZh/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><int>2</int></value>\n</param>\n<param>\n<value><string>i386</string></value>\n</param>\n<param>\n<value><boolean>1</boolean></value>\n</param>\n</params>\n</methodCall>\n       \N      \N      i386    19      1.5
\.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From valent.turkovic at gmail.com  Thu Oct 18 14:17:28 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 18 Oct 2007 16:17:28 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <1192714622.8542.104.camel@cutter>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
Message-ID: <64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>

Here is the info from 2 year oly HP Compaq nx9030:

# cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         6000 mAh
last full capacity:      2784 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 250 mAh
design capacity low:     150 mAh
capacity granularity 1:  10 mAh
capacity granularity 2:  25 mAh
model number:            JM-6
serial number:           4063
battery type:            LION
OEM info:                Hewlett-Packard


and GPM says this:

Vendor: Hewlett-Packard
Serial Number: 4063
Model: JM-6
Current charge: 34.6 Wh
Design charge: 88 Wh

Who is showing wrong info?

On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
>
> On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > Sorry for long subject, but what to do when gnome power manager shows
> > wrong battery capacity?
> >
> > I have two laptops for who I see that battery capacity is stated as
> > 88.8Wh but it is not! So when gnome starts I get an error message
> > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > what component? Send an email? To whom?
> >
> > Thank you,
> > Valent.
> >
>
> how old are the batteries?
>
> If they're more than say, a year old, it's probably true. battery charge
> life declines. Get the info on your battery by clicking on the
> gnome-power-manager icon and you can find out the info on your battery.
>
> -sv
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From choeger at cs.tu-berlin.de  Thu Oct 18 14:28:30 2007
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 18 Oct 2007 16:28:30 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
Message-ID: <1192717710.25694.3.camel@s6.math.tu-berlin.de>

Well, if my physics teacher was right then no application shows wrong
values. 6000mAh and 148000mV compute to 88.8Wh.
So either the battery gives wrong values via acpi or the kernel reads
them wrong (which is very unlikely because 6000mAh seem to be a too
normal value for a read error) 

Am Donnerstag, den 18.10.2007, 16:17 +0200 schrieb Valent Turkovic:
> Here is the info from 2 year oly HP Compaq nx9030:
> 
> # cat /proc/acpi/battery/BAT0/info
> present:                 yes
> design capacity:         6000 mAh
> last full capacity:      2784 mAh
> battery technology:      rechargeable
> design voltage:          14800 mV
> design capacity warning: 250 mAh
> design capacity low:     150 mAh
> capacity granularity 1:  10 mAh
> capacity granularity 2:  25 mAh
> model number:            JM-6
> serial number:           4063
> battery type:            LION
> OEM info:                Hewlett-Packard
> 
> 
> and GPM says this:
> 
> Vendor: Hewlett-Packard
> Serial Number: 4063
> Model: JM-6
> Current charge: 34.6 Wh
> Design charge: 88 Wh
> 
> Who is showing wrong info?
> 
> On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> > On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > > Sorry for long subject, but what to do when gnome power manager shows
> > > wrong battery capacity?
> > >
> > > I have two laptops for who I see that battery capacity is stated as
> > > 88.8Wh but it is not! So when gnome starts I get an error message
> > > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > > what component? Send an email? To whom?
> > >
> > > Thank you,
> > > Valent.
> > >
> >
> > how old are the batteries?
> >
> > If they're more than say, a year old, it's probably true. battery charge
> > life declines. Get the info on your battery by clicking on the
> > gnome-power-manager icon and you can find out the info on your battery.
> >
> > -sv
> >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> 
> -- 
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
> 



From valent.turkovic at gmail.com  Thu Oct 18 14:38:56 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 18 Oct 2007 16:38:56 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <1192717710.25694.3.camel@s6.math.tu-berlin.de>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
	<1192717710.25694.3.camel@s6.math.tu-berlin.de>
Message-ID: <64b14b300710180738y14913485o9d7334b465087afa@mail.gmail.com>

Upps :) my bad... I mixed my units. I saw mAh but I read it mWh :(

On 10/18/07, Christoph H?ger <choeger at cs.tu-berlin.de> wrote:
> Well, if my physics teacher was right then no application shows wrong
> values. 6000mAh and 148000mV compute to 88.8Wh.
> So either the battery gives wrong values via acpi or the kernel reads
> them wrong (which is very unlikely because 6000mAh seem to be a too
> normal value for a read error)
>
> Am Donnerstag, den 18.10.2007, 16:17 +0200 schrieb Valent Turkovic:
> > Here is the info from 2 year oly HP Compaq nx9030:
> >
> > # cat /proc/acpi/battery/BAT0/info
> > present:                 yes
> > design capacity:         6000 mAh
> > last full capacity:      2784 mAh
> > battery technology:      rechargeable
> > design voltage:          14800 mV
> > design capacity warning: 250 mAh
> > design capacity low:     150 mAh
> > capacity granularity 1:  10 mAh
> > capacity granularity 2:  25 mAh
> > model number:            JM-6
> > serial number:           4063
> > battery type:            LION
> > OEM info:                Hewlett-Packard
> >
> >
> > and GPM says this:
> >
> > Vendor: Hewlett-Packard
> > Serial Number: 4063
> > Model: JM-6
> > Current charge: 34.6 Wh
> > Design charge: 88 Wh
> >
> > Who is showing wrong info?
> >
> > On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
> > >
> > > On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > > > Sorry for long subject, but what to do when gnome power manager shows
> > > > wrong battery capacity?
> > > >
> > > > I have two laptops for who I see that battery capacity is stated as
> > > > 88.8Wh but it is not! So when gnome starts I get an error message
> > > > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > > > what component? Send an email? To whom?
> > > >
> > > > Thank you,
> > > > Valent.
> > > >
> > >
> > > how old are the batteries?
> > >
> > > If they're more than say, a year old, it's probably true. battery charge
> > > life declines. Get the info on your battery by clicking on the
> > > gnome-power-manager icon and you can find out the info on your battery.
> > >
> > > -sv
> > >
> > >
> > > --
> > > fedora-devel-list mailing list
> > > fedora-devel-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> > >
> >
> >
> > --
> > http://kernelreloaded.blog385.com/
> > linux, blog, anime, spirituality, windsurf, wireless
> > registered as user #367004 with the Linux Counter, http://counter.li.org.
> > ICQ: 2125241, Skype: valent.turkovic
> >
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From overholt at redhat.com  Thu Oct 18 14:39:42 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Thu, 18 Oct 2007 10:39:42 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071017140748.GG13974@redhat.com>
References: <20071017140748.GG13974@redhat.com>
Message-ID: <20071018143942.GA30267@redhat.com>

* Deepak Bhole <dbhole at redhat.com> [2007-10-17 10:08]:
> 
> Currently, Fedora allows building of noarch packages with IcedTea and
> shipping them on all archs (where they run via IcedTea, or via gcj in
> interpreted mode).

Except that it's preferred to ship the aot-compiled bits until we have
IcedTea on all arches.

Andrew
-------------- 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/20071018/bd9558d9/attachment.sig>

From dbhole at redhat.com  Thu Oct 18 14:56:37 2007
From: dbhole at redhat.com (Deepak Bhole)
Date: Thu, 18 Oct 2007 10:56:37 -0400
Subject: Deploying noarch builds to specific arch's
In-Reply-To: <20071018143942.GA30267@redhat.com>
References: <20071017140748.GG13974@redhat.com>
	<20071018143942.GA30267@redhat.com>
Message-ID: <20071018145637.GE32224@redhat.com>

* Andrew Overholt <overholt at redhat.com> [2007-10-18 10:40]:
> * Deepak Bhole <dbhole at redhat.com> [2007-10-17 10:08]:
> > 
> > Currently, Fedora allows building of noarch packages with IcedTea and
> > shipping them on all archs (where they run via IcedTea, or via gcj in
> > interpreted mode).
> 
> Except that it's preferred to ship the aot-compiled bits until we have
> IcedTea on all arches.
>

Right. All I am pointing out is that the allowance of building noarch with
icedtea is a moot point, as it is not possible at this time with Koji.

Deepak



From mikeb at redhat.com  Thu Oct 18 15:06:07 2007
From: mikeb at redhat.com (Mike Bonnet)
Date: Thu, 18 Oct 2007 11:06:07 -0400
Subject: koji server installation
In-Reply-To: <471768A7.3000800@codewiz.org>
References: <4717675F.6000608@codewiz.org>  <471768A7.3000800@codewiz.org>
Message-ID: <1192719967.3358.6.camel@burren.boston.redhat.com>

On Thu, 2007-10-18 at 10:07 -0400, Bernardo Innocenti wrote:
> Bernardo Innocenti wrote:
> 
> > Is koji 1.2.2 the version you're really
> > running on koji.fedoraproject.org?  After some
> 
> [oops, it seems I've hit Send too quickly]
> 
> ...After some attempts with the old RPMs from F7, I cloned
> the git repository and rebuilt RPMs off the master branch.
> No better luck.
> 
> With both the stable version and the snapshot, when the server
> gets "stuck" building a package, it permanently stores broken
> records in the database, and the main page of the web interface
> barfs a big stack trace ending up with:
> 
>   File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1304, in _callMethod
>     raise convertFault(fault)
> 
>   Fault: <Fault 1: "<type 'exceptions.TypeError'>: cannot marshal <class 'xmlrpclib.Fault'> objects">
> 
> 
> The records I need to delete are:
> 
> COPY task (id, state, create_time, completion_time, channel_id, host_id, parent, label, waiting, awaited, "owner", method, request, result, eta, arch, priority, weight) FROM stdin;
> 3748    5       2007-10-18 09:47:47.978694      2007-10-18 09:47:54.569714      1       1       \N      \N      \N      \N      1       build   <?xml version='1.0'?>\n<methodCall>\n<methodName>build</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715259.2614679.APWGZpwg/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><string>dist-olpc2</string></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>skip_tag</name>\n<value><nil/></value></member>\n<member>\n<name>scratch</name>\n<value><nil/></value></member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n    <?xml version='1.0'?>\n<methodResponse>\n<fault>\n<value><struct>\n<member>\n<name>faultCode</name>\n<value><int>1005</int></value>\n</member>\n<member>\n<name>faultString</name>\n<value><string>package xorg-x11-proto-devel not in list for tag dist-olpc2</string></value>\n</member>\n</struct></value>\n</fault>\n</methodResponse>\n    \N      noarch  20 !
    
>   0.20000000000000001
> 3749    1       2007-10-18 09:50:05.047597      \N      1       1       \N      \N      t       \N      1       build   <?xml version='1.0'?>\n<methodCall>\n<methodName>build</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715395.710408.UfURJSZh/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><string>dist-olpc2</string></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>skip_tag</name>\n<value><nil/></value></member>\n<member>\n<name>scratch</name>\n<value><boolean>1</boolean></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n     \N      \N      noarch  20      0.20000000000000001
> 3750    1       2007-10-18 09:50:17.777683      \N      1       1       3749    i386    \N      t       1       buildArch       <?xml version='1.0'?>\n<methodCall>\n<methodName>buildArch</methodName>\n<params>\n<param>\n<value><string>cli-build/1192715395.710408.UfURJSZh/xorg-x11-proto-devel-7.2-13.olpc2.src.rpm</string></value>\n</param>\n<param>\n<value><int>2</int></value>\n</param>\n<param>\n<value><string>i386</string></value>\n</param>\n<param>\n<value><boolean>1</boolean></value>\n</param>\n</params>\n</methodCall>\n       \N      \N      i386    19      1.5
> \.

This is caused by a regression in python xmlrpclib in 2.5.  A patched
python package is available here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=21576

Take a look at http://bugs.python.org/issue1739842 for the gory details.

In terms of your other problems, you need to to bootstrap Koji by
importing a bunch of pre-built packages so Koji is able to populate a
buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
guide, I'll point you at it when it's posted.




From opensource at till.name  Thu Oct 18 16:11:21 2007
From: opensource at till.name (Till Maas)
Date: Thu, 18 Oct 2007 18:11:21 +0200
Subject: make qmake honour $RPM_OPT_FLAGS
Message-ID: <200710181811.27097.opensource@till.name>

Hiyas,

when one wants to make sure that a package, that uses qmake(-qt4) to build its 
Makefile, honours $RPM_OPT_FLAGS, waht is the best method?

Is e.g. the following good? (It's in example for vym):
qmake-qt4 INSTALLDIR=%{buildroot}%{_prefix} \
QMAKE_CFLAGS="%{optflags}" \
QMAKE_CXXFLAGS="%{optflags}" \
QMAKE_LFLAGS="%{optflags}"

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/7f0d0627/attachment.sig>

From jspaleta at gmail.com  Thu Oct 18 17:37:13 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Oct 2007 09:37:13 -0800
Subject: removable storage devices still do not auto-mount
In-Reply-To: <55df67120710180644m56851f32j26813b125e2a348d@mail.gmail.com>
References: <55df67120710180644m56851f32j26813b125e2a348d@mail.gmail.com>
Message-ID: <604aa7910710181037i1997e021xbed233cecab09b56@mail.gmail.com>

On 10/18/07, rapponcape <rapponcape at gmail.com> wrote:
> This is a fresh, DVD, install of FC7.

Is this kde or gnome?

I run gnome and I've got 5 usb sticks... 4 of them have never had a
problem automount on F7. One of them, my LG branded drive has
inconsistently worked since I got it way way back when I had F5
installed.   As of this moment, all of my usb sticks currently work
with my F7 under the Gnome desktop using updates and updates-testing.

for reference see: https://bugzilla.redhat.com/show_bug.cgi?id=203488

-jef"i really need to check the test3 live image i guess to see if the
lg drive works there too"spaleta



From ajackson at redhat.com  Thu Oct 18 17:12:18 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 18 Oct 2007 13:12:18 -0400
Subject: java release notes for FC8
In-Reply-To: <f6e5806f0710171915w34342564g6787fe6db000f45e@mail.gmail.com>
References: <f6e5806f0710171915w34342564g6787fe6db000f45e@mail.gmail.com>
Message-ID: <1192727538.26127.5.camel@localhost.localdomain>

On Wed, 2007-10-17 at 19:15 -0700, darrell pfeifer wrote:
> Current rawhide has a severe bug that affects all Sun Java
> implementations including the jdk1.7.0 betas.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=254144

This is a bug in the Sun JDK code, not in the X libraries.  I already
provided a patch here:

https://bugzilla.redhat.com/show_bug.cgi?id=301691

and it has been applied upstream.  It is _not_ a bug in rawhide.

That bug also describes a workaround, if you're stuck using a buggy JDK.

- ajax



From mmcgrath at redhat.com  Thu Oct 18 17:36:39 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 18 Oct 2007 12:36:39 -0500
Subject: Short outage notification
Message-ID: <471799A7.7090008@redhat.com>

I apologize for the short notice of this notification, releng1 (and thus 
bodhi) is being taken down for an upgrade, the techs are at the data 
center now to do it.

    -Mike



From rapponcape at gmail.com  Thu Oct 18 18:05:49 2007
From: rapponcape at gmail.com (rapponcape)
Date: Thu, 18 Oct 2007 14:05:49 -0400
Subject: removable storage devices still do not auto-mount
Message-ID: <55df67120710181105m20bd3cf3x6a82d42b7622495c@mail.gmail.com>

I'm running gnome, and, non of my usb sticks auto-mount.  They all
create similar output as the logs in my original post.



From hughsient at gmail.com  Thu Oct 18 18:22:47 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 18 Oct 2007 19:22:47 +0100
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <1192717710.25694.3.camel@s6.math.tu-berlin.de>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
	<1192717710.25694.3.camel@s6.math.tu-berlin.de>
Message-ID: <1192731767.2846.10.camel@hughsie-laptop>

On Thu, 2007-10-18 at 16:28 +0200, Christoph H?ger wrote:
> So either the battery gives wrong values via acpi or the kernel reads
> them wrong (which is very unlikely because 6000mAh seem to be a too
> normal value for a read error) 

It will be case where the "smart battery" (deliberate quotes) is
actually very dumb. For most of the DSDT's I've seen most of these
numbers are hardcoded, and not queried from the battery.

I've even sent the Lenovo BIOS guys a DSDT patch to query the battery
instead of a best guess, but it was ignored. This is why the new g-p-m
code self-profiles, and corrects the values from ACPI.

Richard.




From rapponcape at gmail.com  Thu Oct 18 18:47:34 2007
From: rapponcape at gmail.com (rapponcape)
Date: Thu, 18 Oct 2007 14:47:34 -0400
Subject: removable storage devices still do not auto-mount
	(updates-testing helped)
Message-ID: <55df67120710181147j6d4cd951t6a146f511fab5c55@mail.gmail.com>

Okay, I just updated udev and libvolume_id using:

 yum --enablerepo=*-testing update udev libvolume_id

And, the stick is now recognized and probed further, but,
it still does not auto-mount.

See log below.

Any suggestions?






==============
Oct 18 14:40:01 palm1 kernel: usb 1-1: new full speed USB device using
uhci_hcd and address 5
Oct 18 14:40:05 palm1 kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.490 [I] osspec.c:232:
SEQNUM=816, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1,
DEVNAME=/dev/bus/usb/001/005, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.490 [E] hotplug.c:94:
devpath /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1 already present
in the store, ignore event
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] osspec.c:232:
SEQNUM=817, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep00,
DEVNAME=/dev/usbdev1.5_ep00, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep00 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep00'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.517 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep00
dev=/dev/usbdev1.5_ep00 parent_dev=0x09255480
Oct 18 14:40:05 palm1 kernel: scsi4 : SCSI emulation for USB Mass
Storage devices
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] osspec.c:232:
SEQNUM=818, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0,
DEVNAME=, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 is a device
(subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.837 [I] device.c:3319:
add_dev: subsys=usb
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 dev=
parent_dev=0x09255480
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.837 [E] util.c:382: Cannot
open '/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/interface'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.863 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.872 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.915 [I] osspec.c:232:
SEQNUM=821, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep01,
DEVNAME=/dev/usbdev1.5_ep01, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep01 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep01'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep01
dev=/dev/usbdev1.5_ep01 parent_dev=0x092512c0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.955 [I] osspec.c:232:
SEQNUM=820, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep81,
DEVNAME=/dev/usbdev1.5_ep81, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.956 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep81 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.956 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep81'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.957 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep81
dev=/dev/usbdev1.5_ep81 parent_dev=0x092512c0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.975 [I] osspec.c:232:
SEQNUM=819, ACTION=add, SUBSYSTEM=scsi_host,
DEVPATH=/sys/class/scsi_host/host4, DEVNAME=, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.976 [I] hotplug.c:134:
/sys/class/scsi_host/host4 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.976 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_host/host4'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.977 [I] device.c:3319:
add_dev: subsys=scsi_host sysfs_path=/sys/class/scsi_host/host4 dev=
parent_dev=0x092512c0
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.036 [I] osspec.c:232:
SEQNUM=822, ACTION=add, SUBSYSTEM=usb_device,
DEVPATH=/sys/class/usb_device/usbdev1.5, DEVNAME=/dev/bus/usb/001/005,
IFINDEX=0
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] hotplug.c:134:
/sys/class/usb_device/usbdev1.5 is a device (subsystem)
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_device/usbdev1.5'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] device.c:3319:
add_dev: subsys=usb_device sysfs_path=/sys/class/usb_device/usbdev1.5
dev=/dev/bus/usb/001/005 parent_dev=0x09255480
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.039 [I] device_info.c:501:
Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'camera'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] device_info.c:501:
Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'scanner'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
Oct 18 14:40:07 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:07.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:07.642 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:07.724 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:07.726 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:11 palm1 kernel: scsi 4:0:0:0: Direct-Access     SanDisk
Cruzer Micro     0.1  PQ: 0 ANSI: 2
Oct 18 14:40:12 palm1 kernel: sd 4:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 18 14:40:13 palm1 kernel: sd 4:0:0:0: [sdb] Write Protect is off
Oct 18 14:40:13 palm1 kernel: sd 4:0:0:0: [sdb] Assuming drive cache:
write through
Oct 18 14:40:16 palm1 kernel: sd 4:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 18 14:40:17 palm1 kernel: sd 4:0:0:0: [sdb] Write Protect is off
Oct 18 14:40:17 palm1 kernel: sd 4:0:0:0: [sdb] Assuming drive cache:
write through
Oct 18 14:40:18 palm1 kernel:  sdb: sdb1
Oct 18 14:40:18 palm1 kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk
Oct 18 14:40:18 palm1 kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.339 [I] osspec.c:232:
SEQNUM=823, ACTION=add, SUBSYSTEM=scsi,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0,
DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] device.c:3319:
add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
dev= parent_dev=0x092512c0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.341 [I] device.c:3319:
add_dev: subsys=scsi_host
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4
dev= parent_dev=0x092512c0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.344 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.344 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.349 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.349 [I] device.c:3319:
add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
dev= parent_dev=0x0924e490
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.350 [I] device.c:1969:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0/type
-> 0 (-> scsi.type)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.353 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.353 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.422 [I] osspec.c:232:
SEQNUM=828, ACTION=add, SUBSYSTEM=scsi_generic,
DEVPATH=/sys/class/scsi_generic/sg3, DEVNAME=/dev/sg3, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.422 [I] hotplug.c:134:
/sys/class/scsi_generic/sg3 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.423 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_generic/sg3'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.423 [I] device.c:3319:
add_dev: subsys=scsi_generic sysfs_path=/sys/class/scsi_generic/sg3
dev=/dev/sg3 parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.426 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.426 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] osspec.c:232:
SEQNUM=824, ACTION=add, SUBSYSTEM=scsi_disk,
DEVPATH=/sys/class/scsi_disk/4:0:0:0, DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] hotplug.c:134:
/sys/class/scsi_disk/4:0:0:0 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_disk/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] device.c:3319:
add_dev: subsys=scsi_disk sysfs_path=/sys/class/scsi_disk/4:0:0:0 dev=
parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.540 [I] osspec.c:232:
SEQNUM=827, ACTION=add, SUBSYSTEM=scsi_device,
DEVPATH=/sys/class/scsi_device/4:0:0:0, DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] hotplug.c:134:
/sys/class/scsi_device/4:0:0:0 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_device/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] device.c:3319:
add_dev: subsys=scsi_device sysfs_path=/sys/class/scsi_device/4:0:0:0
dev= parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.624 [I] osspec.c:232:
SEQNUM=825, ACTION=add, SUBSYSTEM=block, DEVPATH=/sys/block/sdb,
DEVNAME=/dev/sdb, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.624 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/block/sdb'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.625 [I] blockdev.c:645:
block_add: sysfs_path=/sys/block/sdb dev=/dev/sdb is_part=0,
parent=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.625 [I] blockdev.c:951:
parent_bus is scsi
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.626 [I] blockdev.c:479:
Probing storage device /dev/sdb
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4767:
********* got a connection 9242140
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.648 [D]
probe-storage.c:153: Doing probe-storage for /dev/sdb (bus usb)
(drive_type disk) (udi=/org/freedesktop/Hal/devices/temp/117)
(--only-check-for-fs==0)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.649 [D]
probe-storage.c:392: Checking for file system on /dev/sdb
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.654 [D]
probe-storage.c:398: Doing open ("/dev/sdb", O_RDONLY)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.981 [D]
probe-storage.c:406: Returned from open(2)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.981 [D]
probe-storage.c:422: look for existing partitions for sdb
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.982 [D]
probe-storage.c:432: partition sdb1 found, skip probing for filesystem
Oct 18 14:40:19 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:19.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:19.642 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:19.723 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:19.725 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:20 palm1 hald-probe-storage: [2825]: 14:40:20.231 [I]
partutil.c:860: MSDOS partition table detected
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.735 [I] hald_dbus.c:1264:
storage.removable.media_available -> True
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.736 [I] hald_dbus.c:1248:
storage.removable.media_size -> 256900608
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.737 [I] hald_dbus.c:1232:
storage.partitioning_scheme -> mbr
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.739 [I] blockdev.c:364:
entering; exit_type=0, return_code=0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.744 [I] blockdev.c:127: Add
callouts completed
udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.744 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.753 [I] hald_runner.c:597:
running_processes 0x9240998, num = 8
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald.c:115: Started
addon hald-addon-storage for udi
/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4711:
************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4712:
Client to local_server was disconnected for 9242140
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4713:
************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4752:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4753:
********* unregistered 9242140
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4754:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4767:
********* got a connection 92420f8
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.782 [D] hald_dbus.c:3090:
udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.791 [I] hald_dbus.c:3116:
AddonIsReady on udi
'/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0'
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.836 [D]
addon-storage.c:670:
**************************************************
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.840 [D]
addon-storage.c:671: Doing addon-storage for /dev/sdb (bus usb)
(drive_type disk) (udi
/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0)
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.840 [D]
addon-storage.c:672:
**************************************************
Oct 18 14:40:21 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:21.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:21.643 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:21.723 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:21.726 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:22 palm1 orage: polling /dev/sdb (every 2 sec): [2831]:
14:40:22.860 [I] addon-storage.c:346: Checking whether device /dev/sdb
is locked on HAL
Oct 18 14:40:22 palm1 orage: polling /dev/sdb (every 2 sec): [2831]:
14:40:22.863 [I] addon-storage.c:354: ... device /dev/sdb is not
locked on HAL
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] osspec.c:232:
SEQNUM=826, ACTION=add, SUBSYSTEM=block, DEVPATH=/sys/block/sdb/sdb1,
DEVNAME=/dev/sdb1, IFINDEX=0
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [E] util.c:190: Cannot
open '/sys/block/sdb/sdb1/range'
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] osspec.c:892:
hal_util_find_known_parent: '/sys/block/sdb/sdb1'->'/sys/block/sdb'
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] blockdev.c:645:
block_add: sysfs_path=/sys/block/sdb/sdb1 dev=/dev/sdb1 is_part=1,
parent=0x0925bd60
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.518 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.519 [I] hald_dbus.c:4767:
********* got a connection 925c268
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.519 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.529 [D]
probe-volume.c:381: Doing probe-volume for /dev/sdb1
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.981 [D]
probe-volume.c:392: volume.block_size = 512
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.981 [D]
probe-volume.c:396: volume.size = 256588288
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.984 [I]
probe-volume.c:625: invoking volume_id_probe_all, offset=0, size=0
Oct 18 14:40:35 palm1 hald-probe-volume: 2833: 14:40:35.985:
volume_id.c:351 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:35 palm1 hald-probe-volume: 2833: 14:40:35.985:
linux_raid.c:70 probing at offset 0xf4a0000, size 0xf4b3a00
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:35.985:
util.c:342 get buffer off 0xf4a0000(256507904), len 0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:35.985:
util.c:391 read seekbuf off:0xf4a0000 len:0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:401 got 0x800 (2048) bytes
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
linux_raid.c:124 probing at offset 0xf4b1000, size 0xf4b3a00
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:342 get buffer off 0xf4b1000(256577536), len 0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:391 read seekbuf off:0xf4b1000 len:0x800
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:401 got 0x800 (2048) bytes
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
linux_raid.c:124 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:342 get buffer off 0x0(0), len 0x800
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:355 read sbbuf len:0x800
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.503:
util.c:365 got 0x800 (2048) bytes
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
linux_raid.c:124 probing at offset 0x1000, size 0xf4b3a00
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
util.c:342 get buffer off 0x1000(4096), len 0x800
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
util.c:355 read sbbuf len:0x1800
Oct 18 14:40:40 palm1 hald[2093]: 14:40:40.841 [I] device.c:1811:
Removing locks from ':1.23'
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:365 got 0x1800 (6144) bytes
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
ddf_raid.c:49 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:391 read seekbuf off:0xf4b3800 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
isw_raid.c:47 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:342 get buffer off 0xf4b3600(256587264), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:391 read seekbuf off:0xf4b3600 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
lsi_raid.c:42 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:391 read seekbuf off:0xf4b3800 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
via_raid.c:67 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
silicon_raid.c:57 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.733:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.736:
nvidia_raid.c:45 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.739:
util.c:342 get buffer off 0xf4b3600(256587264), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.742:
util.c:391 read seekbuf off:0xf4b3600 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.744:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.746:
promise_raid.c:46 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.748:
util.c:342 get buffer off 0xf4abc00(256556032), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.750:
util.c:391 read seekbuf off:0xf4abc00 len:0x200
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:342 get buffer off 0xf493c00(256457728), len 0x200
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:391 read seekbuf off:0xf493c00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:342 get buffer off 0xf493a00(256457216), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:391 read seekbuf off:0xf493a00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:342 get buffer off 0xf4b1a00(256580096), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:391 read seekbuf off:0xf4b1a00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.482:
util.c:342 get buffer off 0xf481c00(256384000), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.482:
util.c:391 read seekbuf off:0xf481c00 len:0x200
Oct 18 14:40:45 palm1 hald[2093]: 14:40:45.503 [I] blockdev.c:364:
entering; exit_type=1, return_code=0
Oct 18 14:40:47 palm1 hald-probe-volume: [2833]: 14:40:47.481 [E]
probe-volume.c:304: Timed out probing /dev/sdb1 - broken device
driver?
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.483 [I] hald_dbus.c:4711:
************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4712:
Client to local_server was disconnected for 925c268
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4713:
************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4752:
***************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4753:
********* unregistered 925c268
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4754:
***************************

==============



From a.badger at gmail.com  Thu Oct 18 19:08:24 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 18 Oct 2007 12:08:24 -0700
Subject: PackageDB Update
Message-ID: <4717AF28.1000702@gmail.com>

I performed a minor update on the package database yesterday.  This 
should fix a variety of issues with how ownership of packages were 
displayed.
* Looking at a package page will no longer show a person who has removed 
all their acls from the package.
* Looking at the list of packages you own will no longer show packages 
from which you've removed all your acls.
* Packages which are only owned (or orphaned) in EOL releases no longer 
show up in a person's packagelisting page.

There are also a few features related to filtering of results that have 
been enabled.  There isn't a UI element for them yet but power users who 
  are willing to edit their URLs can limit what is displayed on the 
package page according to the release by doing something like this:

https://admin.fedoraproject.org/pkgdb/packages/name/yum/Fedora%20EPEL/
https://admin.fedoraproject.org/pkgdb/packages/name/yum/Fedora
https://admin.fedoraproject.org/pkgdb/packages/name/yum/Fedora/devel

You can also limit what is displayed on the user overview of packages 
like so:

https://admin.fedoraproject.org/pkgdb/users/packages/toshio?acls=owner
https://admin.fedoraproject.org/pkgdb/users/packages/toshio?acls=owner,commit

The acls that you can list in the acls field are:
owner,commit,approveacls,watchbugzilla,watchcommits

-Toshio



From ville.skytta at iki.fi  Thu Oct 18 19:13:00 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 18 Oct 2007 22:13:00 +0300
Subject: PackageDB Update
In-Reply-To: <4717AF28.1000702@gmail.com>
References: <4717AF28.1000702@gmail.com>
Message-ID: <200710182213.00928.ville.skytta@iki.fi>

On Thursday 18 October 2007, Toshio Kuratomi wrote:
> I performed a minor update on the package database yesterday.  This
> should fix a variety of issues with how ownership of packages were
> displayed.

Yay, my "My Packages" view is usable again.  Thanks!



From rdieter at math.unl.edu  Thu Oct 18 19:36:26 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Oct 2007 14:36:26 -0500
Subject: make qmake honour $RPM_OPT_FLAGS
References: <200710181811.27097.opensource@till.name>
Message-ID: <ff8cjq$57c$1@ger.gmane.org>

Till Maas wrote:

> when one wants to make sure that a package, that uses qmake(-qt4) to build
> its Makefile, honours $RPM_OPT_FLAGS, waht is the best method?

See
http://fedoraproject.org/wiki/Packaging/cmake

-- Rex



From rdieter at math.unl.edu  Thu Oct 18 19:39:06 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Oct 2007 14:39:06 -0500
Subject: F8+KDE+PulseAudio
Message-ID: <ff8coq$57c$2@ger.gmane.org>

Here's some notes on making PulseAudio work with KDE,
http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
which turned out to be painfully easy.

Have only tested this lightly myself, so feedback please.

-- Rex



From limb at jcomserv.net  Thu Oct 18 19:37:15 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Oct 2007 14:37:15 -0500 (CDT)
Subject: make qmake honour $RPM_OPT_FLAGS
In-Reply-To: <ff8cjq$57c$1@ger.gmane.org>
References: <200710181811.27097.opensource@till.name>
	<ff8cjq$57c$1@ger.gmane.org>
Message-ID: <50336.63.85.68.164.1192736235.squirrel@mail.jcomserv.net>


> Till Maas wrote:
>
>> when one wants to make sure that a package, that uses qmake(-qt4) to
>> build
>> its Makefile, honours $RPM_OPT_FLAGS, waht is the best method?
>
> See
> http://fedoraproject.org/wiki/Packaging/cmake

This is also applicable to qmake?

> -- Rex
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From pemboa at gmail.com  Thu Oct 18 19:42:47 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 18 Oct 2007 14:42:47 -0500
Subject: F8+KDE+PulseAudio
In-Reply-To: <ff8coq$57c$2@ger.gmane.org>
References: <ff8coq$57c$2@ger.gmane.org>
Message-ID: <16de708d0710181242k6dbff234n3f27afff7630724b@mail.gmail.com>

On 10/18/07, Rex Dieter <rdieter at math.unl.edu> wrote:
> Here's some notes on making PulseAudio work with KDE,
> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
> which turned out to be painfully easy.
>
> Have only tested this lightly myself, so feedback please.


Thank you.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From rdieter at math.unl.edu  Thu Oct 18 19:50:22 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Oct 2007 14:50:22 -0500
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org>
Message-ID: <ff8ddv$7rn$1@ger.gmane.org>

Rex Dieter wrote:

> Here's some notes on making PulseAudio work with KDE,
> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
> which turned out to be painfully easy.

Really, to make this work, all we needed was pulseaudio getting autostarted
with the session.  After chatting on fedora-desktop, we tried the
/etc/X11/xinit.d/pulseaudio.sh containing
pulseaudio -D
solution (I initially had tried an over-complicated xdg/autostart setup).

Could this (or something like it) be considered for inclusion in F8's
pulseaudio pkg?

-- Rex






From jkeating at redhat.com  Thu Oct 18 19:53:03 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Oct 2007 15:53:03 -0400
Subject: F8+KDE+PulseAudio
In-Reply-To: <ff8ddv$7rn$1@ger.gmane.org>
References: <ff8coq$57c$2@ger.gmane.org>
	<ff8ddv$7rn$1@ger.gmane.org>
Message-ID: <20071018155303.591a9918@redhat.com>

On Thu, 18 Oct 2007 14:50:22 -0500
Rex Dieter <rdieter at math.unl.edu> wrote:

> Really, to make this work, all we needed was pulseaudio getting
> autostarted with the session.  After chatting on fedora-desktop, we
> tried the /etc/X11/xinit.d/pulseaudio.sh containing
> pulseaudio -D
> solution (I initially had tried an over-complicated xdg/autostart
> setup).
> 
> Could this (or something like it) be considered for inclusion in F8's
> pulseaudio pkg?

Hrm, in the Gnome desktop case we get this:

/usr/bin/pulseaudio --log-target=syslog

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/5cffb393/attachment.sig>

From rdieter at math.unl.edu  Thu Oct 18 19:51:20 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Oct 2007 14:51:20 -0500
Subject: make qmake honour $RPM_OPT_FLAGS
References: <200710181811.27097.opensource@till.name>
	<ff8cjq$57c$1@ger.gmane.org>
	<50336.63.85.68.164.1192736235.squirrel@mail.jcomserv.net>
Message-ID: <ff8dfo$7rn$2@ger.gmane.org>

Jon Ciesla wrote:

> 
>> Till Maas wrote:
>>
>>> when one wants to make sure that a package, that uses qmake(-qt4) to
>>> build
>>> its Makefile, honours $RPM_OPT_FLAGS, waht is the best method?
>>
>> See
>> http://fedoraproject.org/wiki/Packaging/cmake
> 
> This is also applicable to qmake?

doh! sorry.

qmake *should* inherit %optflags already by default, no intervention
required.

-- Rex




From limb at jcomserv.net  Thu Oct 18 19:53:57 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 18 Oct 2007 14:53:57 -0500 (CDT)
Subject: make qmake honour $RPM_OPT_FLAGS
In-Reply-To: <ff8dfo$7rn$2@ger.gmane.org>
References: <200710181811.27097.opensource@till.name>
	<ff8cjq$57c$1@ger.gmane.org>
	<50336.63.85.68.164.1192736235.squirrel@mail.jcomserv.net>
	<ff8dfo$7rn$2@ger.gmane.org>
Message-ID: <1150.63.85.68.164.1192737237.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>
>>
>>> Till Maas wrote:
>>>
>>>> when one wants to make sure that a package, that uses qmake(-qt4) to
>>>> build
>>>> its Makefile, honours $RPM_OPT_FLAGS, waht is the best method?
>>>
>>> See
>>> http://fedoraproject.org/wiki/Packaging/cmake
>>
>> This is also applicable to qmake?
>
> doh! sorry.
>
> qmake *should* inherit %optflags already by default, no intervention
> required.

Oh, good.  Less for me to do then. :)

> -- Rex
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From bnocera at redhat.com  Thu Oct 18 20:06:43 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 18 Oct 2007 21:06:43 +0100
Subject: F8+KDE+PulseAudio
In-Reply-To: <20071018155303.591a9918@redhat.com>
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<20071018155303.591a9918@redhat.com>
Message-ID: <1192738003.2843.34.camel@cookie.hadess.net>


On Thu, 2007-10-18 at 15:53 -0400, Jesse Keating wrote:
> On Thu, 18 Oct 2007 14:50:22 -0500
> Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > Really, to make this work, all we needed was pulseaudio getting
> > autostarted with the session.  After chatting on fedora-desktop, we
> > tried the /etc/X11/xinit.d/pulseaudio.sh containing
> > pulseaudio -D
> > solution (I initially had tried an over-complicated xdg/autostart
> > setup).
> > 
> > Could this (or something like it) be considered for inclusion in F8's
> > pulseaudio pkg?
> 
> Hrm, in the Gnome desktop case we get this:
> 
> /usr/bin/pulseaudio --log-target=syslog

GNOME just launches the "esd" binary. Bear in mind that currently,
pulseaudio is only started when "ESD" would have been started before. We
even still have the prefs.

Frankly, we should kill the pref, and always start Pulseaudio. In the
meanwhile, it would be better if KDE came up with something that just
starts it for KDE.



From opensource at till.name  Thu Oct 18 20:11:41 2007
From: opensource at till.name (Till Maas)
Date: Thu, 18 Oct 2007 22:11:41 +0200
Subject: make qmake honour $RPM_OPT_FLAGS
In-Reply-To: <1150.63.85.68.164.1192737237.squirrel@mail.jcomserv.net>
References: <200710181811.27097.opensource@till.name>
	<ff8dfo$7rn$2@ger.gmane.org>
	<1150.63.85.68.164.1192737237.squirrel@mail.jcomserv.net>
Message-ID: <200710182211.46840.opensource@till.name>

On Do Oktober 18 2007, Jon Ciesla wrote:

> > qmake *should* inherit %optflags already by default, no intervention
> > required.
>
> Oh, good.  Less for me to do then. :)

But it does not do this on my local F7 i386 machine, I will investigate this a 
little now.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/d73fbd67/attachment.sig>

From rdieter at math.unl.edu  Thu Oct 18 20:14:01 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 18 Oct 2007 15:14:01 -0500
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<20071018155303.591a9918@redhat.com>
	<1192738003.2843.34.camel@cookie.hadess.net>
Message-ID: <ff8eq9$d6m$1@ger.gmane.org>

Bastien Nocera wrote:

> In the
> meanwhile, it would be better if KDE came up with something that just
> starts it for KDE.

We (KDE) can do that too.

-- Rex



From rapponcape at gmail.com  Thu Oct 18 20:19:12 2007
From: rapponcape at gmail.com (rapponcape)
Date: Thu, 18 Oct 2007 16:19:12 -0400
Subject: removable storage devices still do not auto-mount
Message-ID: <55df67120710181319w72b0283dsc93215840c9aeb3c@mail.gmail.com>

Okay, I just updated udev and libvolume_id using:

 yum --enablerepo=*-testing update udev libvolume_id

And, the stick is now recognized and probed further, but,
it still does not auto-mount.

See log below.

Any suggestions?






==============
Oct 18 14:40:01 palm1 kernel: usb 1-1: new full speed USB device using
uhci_hcd and address 5
Oct 18 14:40:05 palm1 kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.490 [I] osspec.c:232:
SEQNUM=816, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1,
DEVNAME=/dev/bus/usb/001/005, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.490 [E] hotplug.c:94:
devpath /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1 already present
in the store, ignore event
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] osspec.c:232:
SEQNUM=817, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep00,
DEVNAME=/dev/usbdev1.5_ep00, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep00 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.516 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep00'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.517 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep00
dev=/dev/usbdev1.5_ep00 parent_dev=0x09255480
Oct 18 14:40:05 palm1 kernel: scsi4 : SCSI emulation for USB Mass
Storage devices
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] osspec.c:232:
SEQNUM=818, ACTION=add, SUBSYSTEM=usb,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0,
DEVNAME=, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 is a device
(subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.836 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.837 [I] device.c:3319:
add_dev: subsys=usb
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 dev=
parent_dev=0x09255480
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.837 [E] util.c:382: Cannot
open '/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/interface'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.863 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.872 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.915 [I] osspec.c:232:
SEQNUM=821, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep01,
DEVNAME=/dev/usbdev1.5_ep01, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep01 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep01'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.916 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep01
dev=/dev/usbdev1.5_ep01 parent_dev=0x092512c0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.955 [I] osspec.c:232:
SEQNUM=820, ACTION=add, SUBSYSTEM=usb_endpoint,
DEVPATH=/sys/class/usb_endpoint/usbdev1.5_ep81,
DEVNAME=/dev/usbdev1.5_ep81, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.956 [I] hotplug.c:134:
/sys/class/usb_endpoint/usbdev1.5_ep81 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.956 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_endpoint/usbdev1.5_ep81'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.957 [I] device.c:3319:
add_dev: subsys=usb_endpoint
sysfs_path=/sys/class/usb_endpoint/usbdev1.5_ep81
dev=/dev/usbdev1.5_ep81 parent_dev=0x092512c0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.975 [I] osspec.c:232:
SEQNUM=819, ACTION=add, SUBSYSTEM=scsi_host,
DEVPATH=/sys/class/scsi_host/host4, DEVNAME=, IFINDEX=0
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.976 [I] hotplug.c:134:
/sys/class/scsi_host/host4 is a device (subsystem)
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.976 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_host/host4'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:05 palm1 hald[2093]: 14:40:05.977 [I] device.c:3319:
add_dev: subsys=scsi_host sysfs_path=/sys/class/scsi_host/host4 dev=
parent_dev=0x092512c0
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.036 [I] osspec.c:232:
SEQNUM=822, ACTION=add, SUBSYSTEM=usb_device,
DEVPATH=/sys/class/usb_device/usbdev1.5, DEVNAME=/dev/bus/usb/001/005,
IFINDEX=0
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] hotplug.c:134:
/sys/class/usb_device/usbdev1.5 is a device (subsystem)
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/usb_device/usbdev1.5'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.037 [I] device.c:3319:
add_dev: subsys=usb_device sysfs_path=/sys/class/usb_device/usbdev1.5
dev=/dev/bus/usb/001/005 parent_dev=0x09255480
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.039 [I] device_info.c:501:
Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'camera'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] device_info.c:501:
Checking sibling
'/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0'
of '/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw'
whether 'info.capabilities' contains 'scanner'
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
Oct 18 14:40:06 palm1 hald[2093]: 14:40:06.040 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_usbraw
Oct 18 14:40:07 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:07.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:07.642 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:07.724 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:07 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:07.726 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:11 palm1 kernel: scsi 4:0:0:0: Direct-Access     SanDisk
Cruzer Micro     0.1  PQ: 0 ANSI: 2
Oct 18 14:40:12 palm1 kernel: sd 4:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 18 14:40:13 palm1 kernel: sd 4:0:0:0: [sdb] Write Protect is off
Oct 18 14:40:13 palm1 kernel: sd 4:0:0:0: [sdb] Assuming drive cache:
write through
Oct 18 14:40:16 palm1 kernel: sd 4:0:0:0: [sdb] 501759 512-byte
hardware sectors (257 MB)
Oct 18 14:40:17 palm1 kernel: sd 4:0:0:0: [sdb] Write Protect is off
Oct 18 14:40:17 palm1 kernel: sd 4:0:0:0: [sdb] Assuming drive cache:
write through
Oct 18 14:40:18 palm1 kernel:  sdb: sdb1
Oct 18 14:40:18 palm1 kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk
Oct 18 14:40:18 palm1 kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.339 [I] osspec.c:232:
SEQNUM=823, ACTION=add, SUBSYSTEM=scsi,
DEVPATH=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0,
DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] hotplug.c:134:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] device.c:3319:
add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
dev= parent_dev=0x092512c0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.340 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.341 [I] device.c:3319:
add_dev: subsys=scsi_host
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4
dev= parent_dev=0x092512c0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.344 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.344 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.349 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.349 [I] device.c:3319:
add_dev: subsys=scsi
sysfs_path=/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0
dev= parent_dev=0x0924e490
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.350 [I] device.c:1969:
/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0/type
-> 0 (-> scsi.type)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.353 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.353 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.422 [I] osspec.c:232:
SEQNUM=828, ACTION=add, SUBSYSTEM=scsi_generic,
DEVPATH=/sys/class/scsi_generic/sg3, DEVNAME=/dev/sg3, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.422 [I] hotplug.c:134:
/sys/class/scsi_generic/sg3 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.423 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_generic/sg3'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.423 [I] device.c:3319:
add_dev: subsys=scsi_generic sysfs_path=/sys/class/scsi_generic/sg3
dev=/dev/sg3 parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.426 [I] device.c:3181: Add
callouts completed
udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.426 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_781_5151_200443172002dba2262e_if0_scsi_host_scsi_device_lun0_scsi_generic
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] osspec.c:232:
SEQNUM=824, ACTION=add, SUBSYSTEM=scsi_disk,
DEVPATH=/sys/class/scsi_disk/4:0:0:0, DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] hotplug.c:134:
/sys/class/scsi_disk/4:0:0:0 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_disk/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.472 [I] device.c:3319:
add_dev: subsys=scsi_disk sysfs_path=/sys/class/scsi_disk/4:0:0:0 dev=
parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.540 [I] osspec.c:232:
SEQNUM=827, ACTION=add, SUBSYSTEM=scsi_device,
DEVPATH=/sys/class/scsi_device/4:0:0:0, DEVNAME=, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] hotplug.c:134:
/sys/class/scsi_device/4:0:0:0 is a device (subsystem)
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/class/scsi_device/4:0:0:0'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.541 [I] device.c:3319:
add_dev: subsys=scsi_device sysfs_path=/sys/class/scsi_device/4:0:0:0
dev= parent_dev=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.624 [I] osspec.c:232:
SEQNUM=825, ACTION=add, SUBSYSTEM=block, DEVPATH=/sys/block/sdb,
DEVNAME=/dev/sdb, IFINDEX=0
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.624 [I] osspec.c:892:
hal_util_find_known_parent:
'/sys/block/sdb'->'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host4/target4:0:0/4:0:0:0'
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.625 [I] blockdev.c:645:
block_add: sysfs_path=/sys/block/sdb dev=/dev/sdb is_part=0,
parent=0x09251560
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.625 [I] blockdev.c:951:
parent_bus is scsi
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.626 [I] blockdev.c:479:
Probing storage device /dev/sdb
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4767:
********* got a connection 9242140
Oct 18 14:40:18 palm1 hald[2093]: 14:40:18.646 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.648 [D]
probe-storage.c:153: Doing probe-storage for /dev/sdb (bus usb)
(drive_type disk) (udi=/org/freedesktop/Hal/devices/temp/117)
(--only-check-for-fs==0)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.649 [D]
probe-storage.c:392: Checking for file system on /dev/sdb
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.654 [D]
probe-storage.c:398: Doing open ("/dev/sdb", O_RDONLY)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.981 [D]
probe-storage.c:406: Returned from open(2)
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.981 [D]
probe-storage.c:422: look for existing partitions for sdb
Oct 18 14:40:18 palm1 hald-probe-storage: [2825]: 14:40:18.982 [D]
probe-storage.c:432: partition sdb1 found, skip probing for filesystem
Oct 18 14:40:19 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:19.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:19.642 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:19.723 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:19 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:19.725 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:20 palm1 hald-probe-storage: [2825]: 14:40:20.231 [I]
partutil.c:860: MSDOS partition table detected
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.735 [I] hald_dbus.c:1264:
storage.removable.media_available -> True
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.736 [I] hald_dbus.c:1248:
storage.removable.media_size -> 256900608
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.737 [I] hald_dbus.c:1232:
storage.partitioning_scheme -> mbr
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.739 [I] blockdev.c:364:
entering; exit_type=0, return_code=0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.744 [I] blockdev.c:127: Add
callouts completed
udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.744 [I] hald.c:103: Added
device to GDL; udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.753 [I] hald_runner.c:597:
running_processes 0x9240998, num = 8
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald.c:115: Started
addon hald-addon-storage for udi
/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4711:
************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4712:
Client to local_server was disconnected for 9242140
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4713:
************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4752:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4753:
********* unregistered 9242140
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.754 [I] hald_dbus.c:4754:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4767:
********* got a connection 92420f8
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.776 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.782 [D] hald_dbus.c:3090:
udi=/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0
Oct 18 14:40:20 palm1 hald[2093]: 14:40:20.791 [I] hald_dbus.c:3116:
AddonIsReady on udi
'/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0'
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.836 [D]
addon-storage.c:670:
**************************************************
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.840 [D]
addon-storage.c:671: Doing addon-storage for /dev/sdb (bus usb)
(drive_type disk) (udi
/org/freedesktop/Hal/devices/storage_serial_SanDisk_Cruzer_Micro_200443172002dba2262e_0_0)
Oct 18 14:40:20 palm1 hald-addon-storage: [2831]: 14:40:20.840 [D]
addon-storage.c:672:
**************************************************
Oct 18 14:40:21 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:21.640 [I] addon-storage.c:346: Checking whether device /dev/sr0
is locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr0 (every 2 sec): [2154]:
14:40:21.643 [I] addon-storage.c:354: ... device /dev/sr0 is not
locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:21.723 [I] addon-storage.c:346: Checking whether device /dev/sr1
is locked on HAL
Oct 18 14:40:21 palm1 orage: polling /dev/sr1 (every 2 sec): [2157]:
14:40:21.726 [I] addon-storage.c:354: ... device /dev/sr1 is not
locked on HAL
Oct 18 14:40:22 palm1 orage: polling /dev/sdb (every 2 sec): [2831]:
14:40:22.860 [I] addon-storage.c:346: Checking whether device /dev/sdb
is locked on HAL
Oct 18 14:40:22 palm1 orage: polling /dev/sdb (every 2 sec): [2831]:
14:40:22.863 [I] addon-storage.c:354: ... device /dev/sdb is not
locked on HAL
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] osspec.c:232:
SEQNUM=826, ACTION=add, SUBSYSTEM=block, DEVPATH=/sys/block/sdb/sdb1,
DEVNAME=/dev/sdb1, IFINDEX=0
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [E] util.c:190: Cannot
open '/sys/block/sdb/sdb1/range'
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] osspec.c:892:
hal_util_find_known_parent: '/sys/block/sdb/sdb1'->'/sys/block/sdb'
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.493 [I] blockdev.c:645:
block_add: sysfs_path=/sys/block/sdb/sdb1 dev=/dev/sdb1 is_part=1,
parent=0x0925bd60
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.518 [I] hald_dbus.c:4766:
***************************
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.519 [I] hald_dbus.c:4767:
********* got a connection 925c268
Oct 18 14:40:35 palm1 hald[2093]: 14:40:35.519 [I] hald_dbus.c:4768:
***************************
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.529 [D]
probe-volume.c:381: Doing probe-volume for /dev/sdb1
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.981 [D]
probe-volume.c:392: volume.block_size = 512
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.981 [D]
probe-volume.c:396: volume.size = 256588288
Oct 18 14:40:35 palm1 hald-probe-volume: [2833]: 14:40:35.984 [I]
probe-volume.c:625: invoking volume_id_probe_all, offset=0, size=0
Oct 18 14:40:35 palm1 hald-probe-volume: 2833: 14:40:35.985:
volume_id.c:351 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:35 palm1 hald-probe-volume: 2833: 14:40:35.985:
linux_raid.c:70 probing at offset 0xf4a0000, size 0xf4b3a00
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:35.985:
util.c:342 get buffer off 0xf4a0000(256507904), len 0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:35.985:
util.c:391 read seekbuf off:0xf4a0000 len:0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:401 got 0x800 (2048) bytes
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
linux_raid.c:124 probing at offset 0xf4b1000, size 0xf4b3a00
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:342 get buffer off 0xf4b1000(256577536), len 0x800
Oct 18 14:40:36 palm1 hald-probe-volume: 2833: 14:40:36.731:
util.c:391 read seekbuf off:0xf4b1000 len:0x800
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:401 got 0x800 (2048) bytes
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
linux_raid.c:124 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:342 get buffer off 0x0(0), len 0x800
Oct 18 14:40:38 palm1 hald-probe-volume: 2833: 14:40:38.731:
util.c:355 read sbbuf len:0x800
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.503:
util.c:365 got 0x800 (2048) bytes
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
linux_raid.c:124 probing at offset 0x1000, size 0xf4b3a00
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
util.c:342 get buffer off 0x1000(4096), len 0x800
Oct 18 14:40:39 palm1 hald-probe-volume: 2833: 14:40:39.504:
util.c:355 read sbbuf len:0x1800
Oct 18 14:40:40 palm1 hald[2093]: 14:40:40.841 [I] device.c:1811:
Removing locks from ':1.23'
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:365 got 0x1800 (6144) bytes
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
ddf_raid.c:49 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:41 palm1 hald-probe-volume: 2833: 14:40:41.481:
util.c:391 read seekbuf off:0xf4b3800 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
isw_raid.c:47 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:342 get buffer off 0xf4b3600(256587264), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:391 read seekbuf off:0xf4b3600 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
lsi_raid.c:42 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:391 read seekbuf off:0xf4b3800 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
via_raid.c:67 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.732:
silicon_raid.c:57 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.733:
util.c:342 get buffer off 0xf4b3800(256587776), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.736:
nvidia_raid.c:45 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.739:
util.c:342 get buffer off 0xf4b3600(256587264), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.742:
util.c:391 read seekbuf off:0xf4b3600 len:0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.744:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.746:
promise_raid.c:46 probing at offset 0x0, size 0xf4b3a00
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.748:
util.c:342 get buffer off 0xf4abc00(256556032), len 0x200
Oct 18 14:40:42 palm1 hald-probe-volume: 2833: 14:40:42.750:
util.c:391 read seekbuf off:0xf4abc00 len:0x200
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:342 get buffer off 0xf493c00(256457728), len 0x200
Oct 18 14:40:44 palm1 hald-probe-volume: 2833: 14:40:44.731:
util.c:391 read seekbuf off:0xf493c00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:342 get buffer off 0xf493a00(256457216), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:391 read seekbuf off:0xf493a00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:342 get buffer off 0xf4b1a00(256580096), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:391 read seekbuf off:0xf4b1a00 len:0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.481:
util.c:401 got 0x200 (512) bytes
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.482:
util.c:342 get buffer off 0xf481c00(256384000), len 0x200
Oct 18 14:40:45 palm1 hald-probe-volume: 2833: 14:40:45.482:
util.c:391 read seekbuf off:0xf481c00 len:0x200
Oct 18 14:40:45 palm1 hald[2093]: 14:40:45.503 [I] blockdev.c:364:
entering; exit_type=1, return_code=0
Oct 18 14:40:47 palm1 hald-probe-volume: [2833]: 14:40:47.481 [E]
probe-volume.c:304: Timed out probing /dev/sdb1 - broken device
driver?
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.483 [I] hald_dbus.c:4711:
************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4712:
Client to local_server was disconnected for 925c268
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4713:
************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4752:
***************************
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4753:
********* unregistered 925c268
Oct 18 14:40:47 palm1 hald[2093]: 14:40:47.484 [I] hald_dbus.c:4754:
***************************

==============



From opensource at till.name  Thu Oct 18 20:55:24 2007
From: opensource at till.name (Till Maas)
Date: Thu, 18 Oct 2007 22:55:24 +0200
Subject: make qmake honour $RPM_OPT_FLAGS
In-Reply-To: <ff8dfo$7rn$2@ger.gmane.org>
References: <200710181811.27097.opensource@till.name>
	<50336.63.85.68.164.1192736235.squirrel@mail.jcomserv.net>
	<ff8dfo$7rn$2@ger.gmane.org>
Message-ID: <200710182255.30156.opensource@till.name>

On Do Oktober 18 2007, Rex Dieter wrote:

> qmake *should* inherit %optflags already by default, no intervention
> required.

In a scratch build there was no sign of %optflags being honoured:
http://koji.fedoraproject.org/koji/getfile?taskID=202276&name=build.log

I opened a bug report about this here:
https://bugzilla.redhat.com/338791

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/babdf0ef/attachment.sig>

From kevin.kofler at chello.at  Thu Oct 18 21:05:56 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Oct 2007 21:05:56 +0000 (UTC)
Subject: gnome keyring always needs to be unlocked
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
Message-ID: <loom.20071018T210255-233@post.gmane.org>

Jon Nettleton <jon.nettleton <at> gmail.com> writes:
> That is absolutely 100% not true.  If someone steals your laptop and
> you have a passwordless keyring like in KWallet, your passwords are
> pretty much stolen.  Boot off a bootable cd mount the filesystem,
> done.

You have a point there, but isn't that use case better served by encrypting the 
entire home directory, not just the keyring/wallet? Many users have plenty of 
sensitive data outside the keyring/wallet too.

(By the way, KWallet isn't always passwordless, it just allows it. I consider 
gnome-keyrings refusal to allow an empty password a typical example of 
GNOME's "we know better than you" attitude.)

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 18 21:18:19 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Oct 2007 21:18:19 +0000 (UTC)
Subject: make qmake honour $RPM_OPT_FLAGS
References: <200710181811.27097.opensource@till.name>
Message-ID: <loom.20071018T211545-333@post.gmane.org>

Till Maas <opensource <at> till.name> writes:
> when one wants to make sure that a package, that uses qmake(-qt4) to build 
its 
> Makefile, honours $RPM_OPT_FLAGS, waht is the best method?
> 
> Is e.g. the following good? (It's in example for vym):
> qmake-qt4 INSTALLDIR=%{buildroot}%{_prefix} \
> QMAKE_CFLAGS="%{optflags}" \
> QMAKE_CXXFLAGS="%{optflags}" \
> QMAKE_LFLAGS="%{optflags}"

IMHO the .pro file should be fixed to take CXXFLAGS from the environment (and 
use sane defaults if the environment defines nothing), e.g. like this:

isEmpty(CXXFLAGS) {
  CXXFLAGS = $$(CXXFLAGS)
}
isEmpty(CXXFLAGS) {
  debug {
    CXXFLAGS = -Os -g
  } else {
    CXXFLAGS = -Os -s -fomit-frame-pointer
  }
}
QMAKE_CXXFLAGS_DEBUG = $$CXXFLAGS -Wno-non-virtual-dtor $$PKGCONFIG_CFLAGS
QMAKE_CXXFLAGS_RELEASE = $$CXXFLAGS -Wno-non-virtual-dtor $$PKGCONFIG_CFLAGS

(This example, taken from a real program, also shows how to add mandatory flags 
after the ones from the environment.) Then all you have to do is set CXXFLAGS 
like with autotools-based programs.

        Kevin Kofler



From jspaleta at gmail.com  Thu Oct 18 21:18:49 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Oct 2007 13:18:49 -0800
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <loom.20071018T210255-233@post.gmane.org>
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
	<loom.20071018T210255-233@post.gmane.org>
Message-ID: <604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>

On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
> You have a point there, but isn't that use case better served by encrypting the
> entire home directory, not just the keyring/wallet? Many users have plenty of
> sensitive data outside the keyring/wallet too.

Personally, I'd prefer a dedicated encrypted directory under home
directories. Like say encrypting Documents by default or having a
secured area that xdg enabled apps can be instructed to use or not.

On systems that I act as admin encrypted home directories are going to
cause problems when i need to help a user with something...even
primarily single user systems where I am not the primary user. Having
to unencrypt a user's home directory to troubleshoot things like gconf
or other settings stored in user's home directory would be a huge
frelling pain in the ass.  I really don't think encrypting the whole
home directory by default for general use is a good idea..even on a
laptop.

In any event, i would prefer to continue to use a passphrase on my
keyring and also relevation's key file, and be able to unlock both at
login.

-jef



From kevin.kofler at chello.at  Thu Oct 18 21:25:05 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 18 Oct 2007 21:25:05 +0000 (UTC)
Subject: gnome keyring always needs to be unlocked
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
	<loom.20071018T210255-233@post.gmane.org>
	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>
Message-ID: <loom.20071018T212349-186@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:
> On systems that I act as admin encrypted home directories are going to
> cause problems when i need to help a user with something...even
> primarily single user systems where I am not the primary user. Having
> to unencrypt a user's home directory to troubleshoot things like gconf
> or other settings stored in user's home directory would be a huge
> frelling pain in the ass.  I really don't think encrypting the whole
> home directory by default for general use is a good idea..even on a
> laptop.

Encrypted home directories are a solution for a computer which can be stolen. 
If you're worried about your central server getting stolen, you have bigger 
security problems than keyring security. ;-) Permissions should be enough to 
secure a computer if physical security is present.

        Kevin Kofler



From sundaram at fedoraproject.org  Thu Oct 18 20:33:49 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 19 Oct 2007 03:03:49 +0630
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <loom.20071018T210255-233@post.gmane.org>
References: <1192559987.2807.3.camel@tiger>	<loom.20071018T074804-134@post.gmane.org>	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
	<loom.20071018T210255-233@post.gmane.org>
Message-ID: <4717C32D.8010200@fedoraproject.org>

Kevin Kofler wrote:
> Jon Nettleton <jon.nettleton <at> gmail.com> writes:
>> That is absolutely 100% not true.  If someone steals your laptop and
>> you have a passwordless keyring like in KWallet, your passwords are
>> pretty much stolen.  Boot off a bootable cd mount the filesystem,
>> done.
> 
> You have a point there, but isn't that use case better served by encrypting the 
> entire home directory, not just the keyring/wallet? Many users have plenty of 
> sensitive data outside the keyring/wallet too.

Perhaps but we don't offer an really easy way to do this yet in Fedora. 
Until then the pam module is better than no password at all.

Rahul



From jspaleta at gmail.com  Thu Oct 18 21:36:02 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Oct 2007 13:36:02 -0800
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <loom.20071018T212349-186@post.gmane.org>
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
	<loom.20071018T210255-233@post.gmane.org>
	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>
	<loom.20071018T212349-186@post.gmane.org>
Message-ID: <604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>

On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Encrypted home directories are a solution for a computer which can be stolen.
> If you're worried about your central server getting stolen, you have bigger
> security problems than keyring security. ;-) Permissions should be enough to
> secure a computer if physical security is present.

Are suggestion that linux laptop users are somehow immune to falling
prey to problem which require  troubleshooting application
configurations stored in a user's home directory?

-jef



From dmc.fedora at filteredperception.org  Thu Oct 18 22:37:35 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Thu, 18 Oct 2007 17:37:35 -0500
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>
References: <1192559987.2807.3.camel@tiger>	<loom.20071018T074804-134@post.gmane.org>	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>	<loom.20071018T210255-233@post.gmane.org>	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>	<loom.20071018T212349-186@post.gmane.org>
	<604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>
Message-ID: <4717E02F.2030307@filteredperception.org>

Jeff Spaleta wrote:
> On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Encrypted home directories are a solution for a computer which can be stolen.
>> If you're worried about your central server getting stolen, you have bigger
>> security problems than keyring security. ;-) Permissions should be enough to
>> secure a computer if physical security is present.
> 
> Are suggestion that linux laptop users are somehow immune to falling
> prey to problem which require  troubleshooting application
> configurations stored in a user's home directory?

It's an interesting question as to what 'doesn't matter'.  I.e. mail 
server passwords and other data and configuration stored in 
~/.thunderbird.  Or everything stored in ~/.firefox.  Those seem to me 
to be things I'd like encrypted by default as a laptop user, in addition 
to what you described as some special xdg style directory.

IMHO, in your scenario, if someone else is troubleshooting my 
application configuration, I'd like as a user to be present both

a) to learn how to fix/prevent the problem myself
b) make sure that the troubleshooter isn't violating my privacy.

Now, if it's a corporate laptop, in a scenario where as a user I don't 
have a right to that much privacy/paranoia, the corporate sysadmin 
should already have the encryption keys (or backdoors).

$0.02...

-dmc



From jspaleta at gmail.com  Thu Oct 18 22:56:19 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 18 Oct 2007 14:56:19 -0800
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <4717E02F.2030307@filteredperception.org>
References: <1192559987.2807.3.camel@tiger>
	<loom.20071018T074804-134@post.gmane.org>
	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>
	<loom.20071018T210255-233@post.gmane.org>
	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>
	<loom.20071018T212349-186@post.gmane.org>
	<604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>
	<4717E02F.2030307@filteredperception.org>
Message-ID: <604aa7910710181556p45f8a2ccxc3a2b3402a00b851@mail.gmail.com>

On 10/18/07, Douglas McClendon <dmc.fedora at filteredperception.org> wrote:
> It's an interesting question as to what 'doesn't matter'.  I.e. mail
> server passwords and other data and configuration stored in
> ~/.thunderbird.  Or everything stored in ~/.firefox.  Those seem to me
> to be things I'd like encrypted by default as a laptop user, in addition
> to what you described as some special xdg style directory.

And if we had a subset of the home directory that was encrypted by
default... don't we then have applications the option to grow brains
about using such a space wisely as needed?

-jef



From rrelyea at redhat.com  Thu Oct 18 23:32:49 2007
From: rrelyea at redhat.com (Robert Relyea)
Date: Thu, 18 Oct 2007 16:32:49 -0700
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <4717E02F.2030307@filteredperception.org>
References: <1192559987.2807.3.camel@tiger>	<loom.20071018T074804-134@post.gmane.org>	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>	<loom.20071018T210255-233@post.gmane.org>	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>	<loom.20071018T212349-186@post.gmane.org>	<604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>
	<4717E02F.2030307@filteredperception.org>
Message-ID: <4717ED21.2090807@REDHAT.COM>

Douglas McClendon wrote:
> Jeff Spaleta wrote:
>> On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
>>> Encrypted home directories are a solution for a computer which can 
>>> be stolen.
>>> If you're worried about your central server getting stolen, you have 
>>> bigger
>>> security problems than keyring security. ;-) Permissions should be 
>>> enough to
>>> secure a computer if physical security is present.
>>
>> Are suggestion that linux laptop users are somehow immune to falling
>> prey to problem which require  troubleshooting application
>> configurations stored in a user's home directory?
>
> It's an interesting question as to what 'doesn't matter'.  I.e. mail 
> server passwords and other data and configuration stored in 
> ~/.thunderbird.  Or everything stored in ~/.firefox.  Those seem to me 
> to be things I'd like encrypted by default as a laptop user, in 
> addition to what you described as some special xdg style directory.
Your general data is stored in ~/.thunderbird and ~/.firefox, but your 
passwords are already stored encrypted in those directories (or should 
be if you have "use master password to encrypt" set in your 
privacy/password settings).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/33d2a96d/attachment.bin>

From dmc.fedora at filteredperception.org  Fri Oct 19 00:01:25 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Thu, 18 Oct 2007 19:01:25 -0500
Subject: gnome keyring always needs to be unlocked
In-Reply-To: <4717ED21.2090807@REDHAT.COM>
References: <1192559987.2807.3.camel@tiger>	<loom.20071018T074804-134@post.gmane.org>	<e71b3daf0710180436qd33df35y5684e580463080b9@mail.gmail.com>	<loom.20071018T210255-233@post.gmane.org>	<604aa7910710181418j599c47c1xcc3b3ecd09ed52aa@mail.gmail.com>	<loom.20071018T212349-186@post.gmane.org>	<604aa7910710181436y2a293f40r20349930f383a072@mail.gmail.com>	<4717E02F.2030307@filteredperception.org>
	<4717ED21.2090807@REDHAT.COM>
Message-ID: <4717F3D5.9030101@filteredperception.org>

Robert Relyea wrote:
> Douglas McClendon wrote:
>> Jeff Spaleta wrote:
>>> On 10/18/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
>>>> Encrypted home directories are a solution for a computer which can 
>>>> be stolen.
>>>> If you're worried about your central server getting stolen, you have 
>>>> bigger
>>>> security problems than keyring security. ;-) Permissions should be 
>>>> enough to
>>>> secure a computer if physical security is present.
>>>
>>> Are suggestion that linux laptop users are somehow immune to falling
>>> prey to problem which require  troubleshooting application
>>> configurations stored in a user's home directory?
>>
>> It's an interesting question as to what 'doesn't matter'.  I.e. mail 
>> server passwords and other data and configuration stored in 
>> ~/.thunderbird.  Or everything stored in ~/.firefox.  Those seem to me 
>> to be things I'd like encrypted by default as a laptop user, in 
>> addition to what you described as some special xdg style directory.
> Your general data is stored in ~/.thunderbird and ~/.firefox, but your 
> passwords are already stored encrypted in those directories (or should 
> be if you have "use master password to encrypt" set in your 
> privacy/password settings).
> 

Those are true things, but don't really have anything to do with point I 
was making.  I'm a fan of a few good layers of security for a typical 
laptop/desktop scenario.  A nice firewall with everything closed to the 
outside world, except that which is exlicitly allowed.  A nice 
encryption of the entire home directory, and screensaver locking.  Then, 
once I'm inside those layers, I prefer to not use things like master 
passwords in thunderbird and firefox.  If you can convince me that using 
master passwords, in combination with some alternate overall scheme 
provides a better balance of security and convenience...  let the debate 
begin.  But be warned, I place a pretty high relative value on convenience.

-dmc



From bpepple at fedoraproject.org  Fri Oct 19 00:21:42 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 18 Oct 2007 20:21:42 -0400
Subject: FESCo Meeting Summary for 2007-10-18
Message-ID: <1192753302.2725.2.camel@kennedy>

= Members Present =
      * Brian Pepple (bpepple) 
      * Jason Tibbitts (tibbs) 
      * Kevin Fenzi (nirik) 
      * Jesse Keating (f13) 
      * Dennis Gilmore (dgilmore) 
      * Christian Iseli (c4chris) 
      * Josh Boyer (jwb) 
      * Bill Nottingham (notting) 
      * Tom Callaway (spot) 
      * Warren Togami (warren) 

= Absent =
      * David Woodhouse (dwmw2) 
      * Jeremy Katz (jeremy) 
      * Christopher Aillon (caillon) 

= Summary =
== Orphaned Packages ==
      * Discussed some issues with orphaned packages: 
              * Packages that are orphaned in a stable maintained
                release (ie. F6 or F7), and aren't picked up by another
                maintainer, will only have security updates (handled by
                the security team) until EOL. 
              * Reminder: In CVS, the devel branches are marked with a
                dead.package file.
                http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife 
              * Beginning with F9, orphaned packages will be removed up
                to Feature Freeze, after feature freeze orphans will not
                be removed and must be picked up by somebody (with
                reasonable exceptions). 
                
IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2007-10-18.html

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071018/ab22b27f/attachment.sig>

From jkeating at redhat.com  Fri Oct 19 01:48:33 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 18 Oct 2007 21:48:33 -0400
Subject: Mass Branching for Fedora 8
Message-ID: <20071018214833.336a1659@redhat.com>

In a few minutes we will begin mass branching for Fedora 8.  CVS
commits will be disabled during this time.

I will announce when CVS is open again for commits.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071018/2b78c14a/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From valent.turkovic at gmail.com  Fri Oct 19 06:47:05 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 19 Oct 2007 08:47:05 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710180738y14913485o9d7334b465087afa@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
	<1192717710.25694.3.camel@s6.math.tu-berlin.de>
	<64b14b300710180738y14913485o9d7334b465087afa@mail.gmail.com>
Message-ID: <64b14b300710182347n6ed366f0scc0445fe5d5304b5@mail.gmail.com>

I found out why I got mixed up... I'm not an idiot after all :)

I have fedora core 6 system that I use for work - and on FC6 GPM shows
only W (not Wh or Ah) and it should be Wh as the number are the same
as from /proc/acpi/battery/BAT0/info

Here it is:

Laptop IBM Lenovo Thinkpad R52

cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         47520 mWh
last full capacity:      47690 mWh
battery technology:      rechargeable
design voltage:          10800 mV
design capacity warning: 2384 mWh
design capacity low:     200 mWh
capacity granularity 1:  1 mWh
capacity granularity 2:  1 mWh
model number:            IBM-92P1071
serial number:            7721
battery type:            LION
OEM info:                SONY



Gnome Power Manager:
Serial Number:     7721
Model:             IBM-92P1071
Capacity:          100%
Current charge:    47.7 W
Last full charge:  47.7 W
Design charge:     47.5 W

So in 1.5 years this old battery even got better :)

Why in Gnome Power Manager 2.16.3 the capacity is in W and not in Wh?

Thank you,
Valent.


On 10/18/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> Upps :) my bad... I mixed my units. I saw mAh but I read it mWh :(
>
> On 10/18/07, Christoph H?ger <choeger at cs.tu-berlin.de> wrote:
> > Well, if my physics teacher was right then no application shows wrong
> > values. 6000mAh and 148000mV compute to 88.8Wh.
> > So either the battery gives wrong values via acpi or the kernel reads
> > them wrong (which is very unlikely because 6000mAh seem to be a too
> > normal value for a read error)
> >
> > Am Donnerstag, den 18.10.2007, 16:17 +0200 schrieb Valent Turkovic:
> > > Here is the info from 2 year oly HP Compaq nx9030:
> > >
> > > # cat /proc/acpi/battery/BAT0/info
> > > present:                 yes
> > > design capacity:         6000 mAh
> > > last full capacity:      2784 mAh
> > > battery technology:      rechargeable
> > > design voltage:          14800 mV
> > > design capacity warning: 250 mAh
> > > design capacity low:     150 mAh
> > > capacity granularity 1:  10 mAh
> > > capacity granularity 2:  25 mAh
> > > model number:            JM-6
> > > serial number:           4063
> > > battery type:            LION
> > > OEM info:                Hewlett-Packard
> > >
> > >
> > > and GPM says this:
> > >
> > > Vendor: Hewlett-Packard
> > > Serial Number: 4063
> > > Model: JM-6
> > > Current charge: 34.6 Wh
> > > Design charge: 88 Wh
> > >
> > > Who is showing wrong info?
> > >
> > > On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
> > > >
> > > > On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > > > > Sorry for long subject, but what to do when gnome power manager shows
> > > > > wrong battery capacity?
> > > > >
> > > > > I have two laptops for who I see that battery capacity is stated as
> > > > > 88.8Wh but it is not! So when gnome starts I get an error message
> > > > > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > > > > what component? Send an email? To whom?
> > > > >
> > > > > Thank you,
> > > > > Valent.
> > > > >
> > > >
> > > > how old are the batteries?
> > > >
> > > > If they're more than say, a year old, it's probably true. battery charge
> > > > life declines. Get the info on your battery by clicking on the
> > > > gnome-power-manager icon and you can find out the info on your battery.
> > > >
> > > > -sv
> > > >
> > > >
> > > > --
> > > > fedora-devel-list mailing list
> > > > fedora-devel-list at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> > > >
> > >
> > >
> > > --
> > > http://kernelreloaded.blog385.com/
> > > linux, blog, anime, spirituality, windsurf, wireless
> > > registered as user #367004 with the Linux Counter, http://counter.li.org.
> > > ICQ: 2125241, Skype: valent.turkovic
> > >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
>
> --
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From hughsient at gmail.com  Fri Oct 19 07:34:21 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 19 Oct 2007 08:34:21 +0100
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710182347n6ed366f0scc0445fe5d5304b5@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
	<1192717710.25694.3.camel@s6.math.tu-berlin.de>
	<64b14b300710180738y14913485o9d7334b465087afa@mail.gmail.com>
	<64b14b300710182347n6ed366f0scc0445fe5d5304b5@mail.gmail.com>
Message-ID: <1192779261.2840.2.camel@hughsie-laptop>

On Fri, 2007-10-19 at 08:47 +0200, Valent Turkovic wrote:
> Why in Gnome Power Manager 2.16.3 the capacity is in W and not in Wh?

A typo  :-)

Richard.




From pertusus at free.fr  Fri Oct 19 08:37:03 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 19 Oct 2007 10:37:03 +0200
Subject: location of ltsp root
Message-ID: <20071019083703.GD2709@free.fr>

Hello,

I am a bit annoyed by the location of the ltsp root directory, where the
terminal nfs mounted root should be. Upstream contacted the lsb/fhs, and
they responded that /tftpboot and a new top directory were wrong. He
proposed /opt/ltsp and nobody complained.

It is not obvious, however that we should stick to that location in
fedora. It should be mentioned that the directories in there are not
part of a package, but they are installed by scripts that are in
ltsp-server (under review).

Should we use /opt/ltsp or something else, like /var/lib/ltsp for the
thin clients root directories?

--
Pat



From pertusus at free.fr  Fri Oct 19 08:43:52 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 19 Oct 2007 10:43:52 +0200
Subject: rpm and post script install/run order question (texlive) [2]
In-Reply-To: <470BA560.4040702@redhat.com>
References: <20071009080528.GC2616@free.fr> <470BA560.4040702@redhat.com>
Message-ID: <20071019084352.GE2709@free.fr>

On Tue, Oct 09, 2007 at 05:59:28PM +0200, Phil Knirsch wrote:
>
> Well, from looking at the dependencies you listed here the dependency tree 
> would look like this:
>
>
>
>
> updmap-sys    texconfig-sys    C
>   /|\             /|\
>    |               |
>            E       B
>           /|\
>            |
>            D
>           /|\
>            |
>            A

I don't really understand the diagram...

But I'd like to precise that updmap-sys and texconfig-sys are part of
the package A.

> So effectively this means that on the 1st level of the tree updmap-sys, 
> texconfig-sys and C can be ordered in any way as well as on the 2nd level E 
> and B as they have no cross and/or chained dependencies.

That's annoying...

> So to answer your questions:
>
> 1) Can C be installed prior to sA being called: No, as the dependency chain 
> clearly require B, C and D and therefore those will be installed prior to 
> A.

Maybe I wasn't clear, but sA is in A...

> 2) Will the various yum install [A|E|B] give the same script run orders? 
> Thats not 100% guaranteed as the installation order of E and B as well as 
> the installation of updmap-sys, texconfig-sys and C are not fixed by any 
> requires, so using a subset of packages to install first (e.g. only 
> updmap-sys, texconfig-sys and C) might result in a different order for 
> those packages than using a "full" install with A.

Once again, updmap-sys and texconfig-sys are in A...

> There might be some code inside rpm that could possibly have updmap-sys, 
> texconfig-sys and C be installed in the same order despite having not 
> dependencies between each other, but from an algorithmical point of view 
> you can't and shouldn't rely on it.

It is clearly something that shouldn't be done.

> Or to put it differently: If you need those packages to be installed in a 
> specific order then just use Requires.

The issue is that the postscript should only be run after all are
installed.

> On the other hand, if those are "soft" requires then things get tricky , 
> e.g. IF updmap-sys, texconfig-sys and C get installed then C needs to be 
> installed after updmap-sys and/or texconfig-sys. I remember vaguely that 
> such "soft" requires (which don't pull in packages automatically but which 
> will be honored in case it is already in the transaction) were either 
> planed or even already put into rpm, but Panu/JBJ can probably tell you a 
> lot more in detail about that.

Maybe this could be useful.

--
Pat



From jos at xos.nl  Fri Oct 19 08:47:55 2007
From: jos at xos.nl (Jos Vos)
Date: Fri, 19 Oct 2007 10:47:55 +0200
Subject: location of ltsp root
In-Reply-To: <20071019083703.GD2709@free.fr>
References: <20071019083703.GD2709@free.fr>
Message-ID: <20071019084755.GB9999@jasmine.xos.nl>

On Fri, Oct 19, 2007 at 10:37:03AM +0200, Patrice Dumas wrote:

> Should we use /opt/ltsp or something else, like /var/lib/ltsp for the
> thin clients root directories?

My vote goes to /var/lib/ltsp.  I don't see how /opt can be defended
as a good choice.

-- 
--    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 jkeating at redhat.com  Fri Oct 19 11:34:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 07:34:14 -0400
Subject: Mass Branching for Fedora 8
In-Reply-To: <20071018214833.336a1659@redhat.com>
References: <20071018214833.336a1659@redhat.com>
Message-ID: <20071019073414.10a02df4@redhat.com>

On Thu, 18 Oct 2007 21:48:33 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> In a few minutes we will begin mass branching for Fedora 8.  CVS
> commits will be disabled during this time.
> 
> I will announce when CVS is open again for commits.

CVS has been opened again, however the branching attempt failed.  The
failure was during the interaction with packagedb to request all the
branches, not actually during the CVS operations to create the branch.
We will be trying again this evening to create all the branches once
we've successfully requested them all through packagedb.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/bd3ee13c/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From buildsys at redhat.com  Fri Oct 19 11:40:42 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 19 Oct 2007 07:40:42 -0400
Subject: rawhide report: 20071019 changes
Message-ID: <200710191140.l9JBegID005844@porkchop.devel.redhat.com>

 

Removed package php-pear-PHPUnit2

Removed package gaim-otr

Removed package pdftk

Updated Packages:

control-center-1:2.20.1-3.fc8
-----------------------------
* Thu Oct 18 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-3
- Bind more default keys in the keybindings capplet (#330501)

* Thu Oct 18 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Remove OnlyShowIn GNOME from the default apps, so that KDE users
  can change their mailto: handlers easily (#161489)

drupal-5.3-1.fc8
----------------
* Thu Oct 18 2007 Jon Ciesla <limb at jcomserv.net> - 5.3-1
- Upgrade to 5.3, fixes:
- HTTP response splitting.
- Arbitrary code execution.
- Cross-site scripting.
- Cross-site request forgery.
- Access bypass.

* Mon Sep 24 2007 Jon Ciesla <limb at jcomserv.net> - 5.2-3
- Minor doc correction, BZ 301541.

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> - 5.2-2
- License tag correction.

evolution-2.12.1-3.fc8
----------------------
* Thu Oct 18 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.1-3.fc8
- Disable patch for GNOME bug #376991 for now.  It may be contributing
  to password prompting problems as described in RH bug #296671.

* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.1-2.fc8
- Fix a broken zoom icon.

* Mon Oct 15 2007 Milan Crha <mcrha at redhat.com> - 2.12.1-1.fc8
- Update to 2.12.1
- Add files for the new backup-restore plugin.

fedora-bookmarks-8-1
--------------------
* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> 8-1
- Update the link to the Fedora project homepage  (#291851)
firefox-2.0.0.6-12.fc8
----------------------
* Thu Oct 18 2007 Jesse Keating <jkeating at redhat.com> - 2.0.0.6-12
- Disable the Firefox startup notification support for now.

glibc-2.7-2
-----------
* Thu Oct 18 2007 Jakub Jelinek <jakub at redhat.com> 2.7-2
- glibc 2.7 release
- fix tzfile.c for times after last transition (#333561)
- fix sem_post at GLIBC_2.0 on i?86
- appease valgrind in libpthread.so initialization
- misc fixes (BZ#3425, BZ#5184, BZ#5186)

* Mon Oct 15 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-21
- fix getgr{name,gid}{,_r} with nscd

* Sun Oct 14 2007 Jakub Jelinek <jakub at redhat.com> 2.6.90-20
- install <bits/error.h> (#330031)
- disable -D_FORTIFY_SOURCE{,=2} support (with a warning) for
  GCC 3.4.x and earlier(#327641)
- pl_PL locale changes (BZ#4098, #242296)
- misc fixes (BZ#1140, BZ#3195, BZ#3242, BZ#4359)

gstreamer-plugins-base-0.10.14-6.fc8
------------------------------------
* Thu Oct 18 2007 - Bastien Nocera <bnocera at redhat.com> - 0.10.14-6
- Add patch to fix playback of short Ogg Vorbis files (#328851)

libtheora-0:1.0beta2-1.fc8
--------------------------
* Thu Oct 18 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0beta2-1
- New upstream bugfix release 1.0beta2

memtest86+-1.70-3.fc8
---------------------
* Thu Oct 18 2007 Warren Togami <wtogami at redhat.com> - 1.70-3
- one more patch from mschmidt to allow configuration of parity and bits

openoffice.org-1:2.3.0-6.4.fc8
------------------------------
* Tue Oct 16 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.4
- Resolves: rhbz#333201 dangling symlinks
- Resolves: rhbz#334841 fix "all files" glob in in mail merge picker
- Resolves: ooo#82671 print crash

* Fri Oct 12 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.3
- reenable prelink-optimized launchers
- rhbz#326161 make code compiled with icedtea compatible with 1.5.0 so libgcj
  can still be selected as a jvm
- add openoffice.org-2.3.0.ooo53885.raiseannotationpriority.sw.patch

* Sun Oct 07 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.2
- reenable visibility again now that guard visibility is sane again

perl-4:5.8.8-30.fc8
-------------------
* Thu Oct 18 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-30
- patch from perl bug 24254, fix for RH bz 114271

* Tue Oct 16 2007 Robin Norwood <rnorwood at redhat.com> - 4:5.8.8-29
- Add Artistic, AUTHORS, and Changes* to %docs.
- Compress Changes* to save space.

* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.4
- Require db4, not db4-devel. -EIDIOT

perl-SOAP-Lite-0.68-5.fc8
-------------------------
* Thu Oct 18 2007 Mike McGrath <mmcgrath at redhat.com> - 0.68-5
- Fixed build requires

samba-0:3.0.26a-6.fc8
---------------------
* Tue Oct 16 2007 Simo Sorce <ssorce at redhat.com> 3.0.26a-6.fc8
- Fix bug 253036

setools-3.3.1-7.fc8
-------------------
* Thu Oct 18 2007 Chris PeBenito <cpebenito at tresys.com> 3.3.1-7.fc8
- Rebuild to fix ppc64 issue.

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	openoffice.org-langpack-ar - 1:2.3.0-6.4.fc8.i386 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.4.fc8.i386 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.4.fc8.i386 requires fonts-arabic
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	openoffice.org-langpack-ar - 1:2.3.0-6.4.fc8.x86_64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.4.fc8.x86_64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.4.fc8.x86_64 requires fonts-arabic
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	openoffice.org-langpack-ar - 1:2.3.0-6.4.fc8.ppc requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.4.fc8.ppc requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.4.fc8.ppc requires fonts-arabic
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	openoffice.org-langpack-ar - 1:2.3.0-6.4.fc8.ppc64 requires fonts-arabic
	openoffice.org-langpack-he_IL - 1:2.3.0-6.4.fc8.ppc64 requires fonts-hebrew
	openoffice.org-langpack-ur - 1:2.3.0-6.4.fc8.ppc64 requires fonts-arabic
	tetex-fonts-hebrew - 0.1-7.fc6.noarch requires fonts-hebrew





From nicolas.mailhot at laposte.net  Fri Oct 19 11:54:17 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 19 Oct 2007 13:54:17 +0200 (CEST)
Subject: location of ltsp root
Message-ID: <15406.192.54.193.51.1192794857.squirrel@rousalka.dyndns.org>


Le Ven 19 octobre 2007 10:37, Patrice Dumas a ?crit :
> Hello,
>
> I am a bit annoyed by the location of the ltsp root directory, where
> the
> terminal nfs mounted root should be. Upstream contacted the lsb/fhs,
> and
> they responded that /tftpboot and a new top directory were wrong. He
> proposed /opt/ltsp and nobody complained.

/opt basically means "do your own non-standard stuff outside the FHS",
so no one will complain if you use opt, but at the same time using
/opt screams non-standard location with future breakage.

> Should we use /opt/ltsp or something else, like /var/lib/ltsp for the
> thin clients root directories?

IMHO this is a clear candidate for /srv/ltsp, but then the "don't use
/srv even if it's clearly defined for this kind of stuff" crowd will
object.

Please spend the time to get lsb/fhs to assign you a standard root
(which anything under /opt isn't)

-- 
Nicolas Mailhot



From i at stingr.net  Fri Oct 19 13:08:33 2007
From: i at stingr.net (Paul P Komkoff Jr)
Date: Fri, 19 Oct 2007 17:08:33 +0400
Subject: [LICENSE CHANGE] weechat
Message-ID: <20071019130833.GA2359@stingr.net>

Hi!

I'm going to update weechat to 0.2.6, which is GPLv3.
-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head



From pertusus at free.fr  Fri Oct 19 13:12:51 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 19 Oct 2007 15:12:51 +0200
Subject: location of ltsp root
In-Reply-To: <15406.192.54.193.51.1192794857.squirrel@rousalka.dyndns.org>
References: <15406.192.54.193.51.1192794857.squirrel@rousalka.dyndns.org>
Message-ID: <20071019131251.GK2709@free.fr>

On Fri, Oct 19, 2007 at 01:54:17PM +0200, Nicolas Mailhot wrote:
> 
> Please spend the time to get lsb/fhs to assign you a standard root
> (which anything under /opt isn't)

This has already be done by the ltsp maintainer without much success, I
certainly won't do that again.

--
Pat



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Oct 19 13:16:15 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 19 Oct 2007 22:16:15 +0900
Subject: License change of mirage [was: Re: rpms/mirage/devel .cvsignore,
 1.4, 1.5 mirage.spec, 1.9,	1.10 sources, 1.4, 1.5]
In-Reply-To: <200710181558.l9IFw8OU003412@cvs-int.fedora.redhat.com>
References: <200710181558.l9IFw8OU003412@cvs-int.fedora.redhat.com>
Message-ID: <4718AE1F.9020305@ioa.s.u-tokyo.ac.jp>

Mamoru Tasaka (mtasaka) wrote, at 10/19/2007 12:58 AM +9:00:
> Author: mtasaka
> 
> Log Message:
> * Fri Oct 19 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.9-1
> - 0.9
> 
> Index: mirage.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/mirage/devel/mirage.spec,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- mirage.spec	21 Aug 2007 18:35:28 -0000	1.9
> +++ mirage.spec	18 Oct 2007 15:57:35 -0000	1.10
> @@ -1,16 +1,17 @@
>  %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
>  
>  Name:		mirage
> -Version:	0.8.3
> -Release:	2%{?dist}.2
> +Version:	0.9
> +Release:	1%{?dist}
>  Summary:	A fast and simple image viewer
>  
>  Group:		Amusements/Graphics
> -License:	GPLv2+
> +License:	GPLv3+
>  URL:		http://mirageiv.berlios.de/

Mirage is now changed to GPLv3+



From robert at marcanoonline.com  Fri Oct 19 13:23:11 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 19 Oct 2007 06:23:11 -0700 (PDT)
Subject: Help packaging eclipse plugin on ppc64
Message-ID: <57011.190.72.189.143.1192800191.squirrel@webmail.marcanoonline.com>

If someone has access to a ppc64 that can help with the bug
https://bugzilla.redhat.com/show_bug.cgi?id=298071 or can allow me remote
access to it, it will be greatly appreciated, I am disabling ppc4 build of
that package but that still will break the upgrade path for ppc64 users



From jkeating at redhat.com  Fri Oct 19 13:59:19 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 09:59:19 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
Message-ID: <20071019095919.54791e62@redhat.com>

From http://jkeating.livejournal.com/46640.html :

So recently Firefox got some "better" notification support. One of the
effects of this support is that if you're using compiz and you have
your open browser on a different cube face, compiz will rotate you
automatically to the cube face that has firefox on it as soon as you
click a link. This is new as of roughly Sept 25th. In the past firefox
would go on opening the link but you wouldn't get any notification that
it was doing anything, nor would your cube rotate.

I'm of the opinion that I don't want my cube to rotate immediately.
This is a pretty severe context switch that is really annoying to me.
Often I'm handed links in IRC or email or wherever that I may not want
to read immediately, but I'll happily queue it up in a new firefox tab.
What I would /love/ to see is that when I click on a link and firefox
opens it, every cube face's window list grows a firefox entry that
pulses. At my choosing I can click on this pulsing item and /then/
compiz would spin the cube to wherever firefox happened to be.
Sometimes I'll want to do this immediately (or after a sufficient time
has passed to fully load the page), sometimes I'll wait until I've
opened 5 or 10 links.

However I recognize that I am strange at times, and what I'd like to
see may be different from what others would like to see. Given that,
I'm very interested in other people's opinions as one way or another
this feature is going to be in Fedora 8. We'd like to get it right for
the majority case or as best of a majority case as we can find. If you
have a Fedora (Red Hat) bugzilla account, please comment in a bug I
filed about this. If you don't have an account feel free to comment in
my blog about it. We'll be looking at comments in both places as we try
to make a decision about this issue.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/4c0a640e/attachment.sig>

From cra at WPI.EDU  Fri Oct 19 14:04:12 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 19 Oct 2007 10:04:12 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
	interaction for Fedora 8.
In-Reply-To: <20071019095919.54791e62@redhat.com>
References: <20071019095919.54791e62@redhat.com>
Message-ID: <20071019140412.GK4043@angus.ind.WPI.EDU>

On Fri, Oct 19, 2007 at 09:59:19AM -0400, Jesse Keating wrote:
> the majority case or as best of a majority case as we can find. If you
> have a Fedora (Red Hat) bugzilla account, please comment in a bug I
> filed about this. If you don't have an account feel free to comment in
> my blog about it. We'll be looking at comments in both places as we try
> to make a decision about this issue.

Bug #?



From fedora at camperquake.de  Fri Oct 19 14:11:34 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 19 Oct 2007 16:11:34 +0200
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
In-Reply-To: <20071019095919.54791e62@redhat.com>
References: <20071019095919.54791e62@redhat.com>
Message-ID: <20071019161134.2eb84fbc@banea.int.addix.net>

Hi.

On Fri, 19 Oct 2007 09:59:19 -0400, Jesse Keating wrote:

> From http://jkeating.livejournal.com/46640.html :
> 
> So recently Firefox got some "better" notification support. One of the
> effects of this support is that if you're using compiz and you have
> your open browser on a different cube face, compiz will rotate you
> automatically to the cube face that has firefox on it as soon as you
> click a link. This is new as of roughly Sept 25th. In the past firefox
> would go on opening the link but you wouldn't get any notification
> that it was doing anything, nor would your cube rotate.

Hah! So that was it. I do not use compiz, but recently firefox started
to come into the foreground as soon as I clicked on a link in, say,
claws mail or liferea.

I _hate_ that feature. Where do I turn that off?



From gilboad at gmail.com  Fri Oct 19 14:10:59 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Fri, 19 Oct 2007 16:10:59 +0200
Subject: PackageDB Update
In-Reply-To: <200710182213.00928.ville.skytta@iki.fi>
References: <4717AF28.1000702@gmail.com>
	<200710182213.00928.ville.skytta@iki.fi>
Message-ID: <1192803059.20439.16.camel@gilboa-home-dev.localdomain>

On Thu, 2007-10-18 at 22:13 +0300, Ville Skytt? wrote:
> On Thursday 18 October 2007, Toshio Kuratomi wrote:
> > I performed a minor update on the package database yesterday.  This
> > should fix a variety of issues with how ownership of packages were
> > displayed.
> 
> Yay, my "My Packages" view is usable again.  Thanks!
> 

Indeed.
(Not that I have too many packages to follow... but never the
less... ;))

- Gilboa



From emmanuel.seyman at club-internet.fr  Fri Oct 19 14:08:27 2007
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 19 Oct 2007 16:08:27 +0200
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
	interaction for Fedora 8.
In-Reply-To: <20071019140412.GK4043@angus.ind.WPI.EDU>
References: <20071019095919.54791e62@redhat.com>
	<20071019140412.GK4043@angus.ind.WPI.EDU>
Message-ID: <20071019140827.GA25970@orient.maison.lan>

* Chuck Anderson [19/10/2007 16:06] :
>
> Bug #?

I'm guessing :
https://bugzilla.redhat.com/show_bug.cgi?id=339711

Emmanuel



From david at fubar.dk  Fri Oct 19 14:12:45 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 19 Oct 2007 10:12:45 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
	interaction for Fedora 8.
In-Reply-To: <20071019095919.54791e62@redhat.com>
References: <20071019095919.54791e62@redhat.com>
Message-ID: <1192803165.7047.29.camel@oneill.fubar.dk>


On Fri, 2007-10-19 at 09:59 -0400, Jesse Keating wrote:
> From http://jkeating.livejournal.com/46640.html :
> 
> So recently Firefox got some "better" notification support. One of the
> effects of this support is that if you're using compiz and you have
> your open browser on a different cube face, compiz will rotate you
> automatically to the cube face that has firefox on it as soon as you
> click a link. 

It's worse than that. When using Metacity, firefox jumps to the
workspace thus ruining your carefully set up workspaces. That's bug
307581 which is almost certainly the same problem. Keep in mind that our
*default* install includes this very combo (multiple workspaces,
metacity, firefox). Yet, some people told me this wasn't a blocker... Go
figure. The good news is that there is patch.

     David




From jkeating at redhat.com  Fri Oct 19 14:12:44 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 10:12:44 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
In-Reply-To: <1192803165.7047.29.camel@oneill.fubar.dk>
References: <20071019095919.54791e62@redhat.com>
	<1192803165.7047.29.camel@oneill.fubar.dk>
Message-ID: <20071019101244.7a7d62c7@redhat.com>

On Fri, 19 Oct 2007 10:12:45 -0400
David Zeuthen <david at fubar.dk> wrote:

> It's worse than that. When using Metacity, firefox jumps to the
> workspace thus ruining your carefully set up workspaces. That's bug
> 307581 which is almost certainly the same problem. Keep in mind that
> our *default* install includes this very combo (multiple workspaces,
> metacity, firefox). Yet, some people told me this wasn't a blocker...
> Go figure. The good news is that there is patch.

and a build of metacity is done to fix this, and will be in Fedora 8.
I'm not as concerned about the metacity case, mostly because I don't
use it (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/d7dc99ee/attachment.sig>

From jdennis at redhat.com  Fri Oct 19 14:21:02 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 19 Oct 2007 10:21:02 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
In-Reply-To: <20071019161134.2eb84fbc@banea.int.addix.net>
References: <20071019095919.54791e62@redhat.com>
	<20071019161134.2eb84fbc@banea.int.addix.net>
Message-ID: <4718BD4E.6000205@redhat.com>

Ralf Ertzinger wrote:
> Hah! So that was it. I do not use compiz, but recently firefox started
> to come into the foreground as soon as I clicked on a link in, say,
> claws mail or liferea.
> 
> I _hate_ that feature. Where do I turn that off?

+1

I don't use ccompiz either but I too have been really annoyed by this 
behavior. Make it configurable, set it OFF by default.

-- 
John Dennis <jdennis at redhat.com>



From kevin.kofler at chello.at  Fri Oct 19 14:26:22 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 19 Oct 2007 14:26:22 +0000 (UTC)
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
	interaction for Fedora 8.
References: <20071019095919.54791e62@redhat.com>
	<1192803165.7047.29.camel@oneill.fubar.dk>
	<20071019101244.7a7d62c7@redhat.com>
Message-ID: <loom.20071019T142444-679@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> and a build of metacity is done to fix this, and will be in Fedora 8.
> I'm not as concerned about the metacity case, mostly because I don't
> use it (:

Please don't forget there's also KWin to consider. What happens in KWin?

        Kevin Kofler



From jkeating at redhat.com  Fri Oct 19 14:50:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 10:50:11 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
In-Reply-To: <loom.20071019T142444-679@post.gmane.org>
References: <20071019095919.54791e62@redhat.com>
	<1192803165.7047.29.camel@oneill.fubar.dk>
	<20071019101244.7a7d62c7@redhat.com>
	<loom.20071019T142444-679@post.gmane.org>
Message-ID: <20071019105011.7d35a0cb@redhat.com>

On Fri, 19 Oct 2007 14:26:22 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Please don't forget there's also KWin to consider. What happens in
> KWin?

Good question.
http://koji.fedoraproject.org/koji/buildinfo?buildID=19633 is a build of Firefox before I disabled this feature.  Please let us know what happens (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/bf066c06/attachment.sig>

From griso.roberto at gmail.com  Fri Oct 19 15:40:09 2007
From: griso.roberto at gmail.com (Roberto Griso)
Date: Fri, 19 Oct 2007 17:40:09 +0200
Subject: =?utf-8?q?Gi=C3=B9_le_mani_dai_Blog!?=
Message-ID: <b0a413aa0710190840h6f780921g619e3c9bb9956034@mail.gmail.com>

Gi? le mani dai Blog! *Inserito da admin il Ven, 19/10/2007 - 11:37*

Come Vice Presidente del Partito Pirata, sono costretto a chiedere ancora
una volta la vostra collaborazione per impedire che ci venga tolto ancora
un'altro pezzo di democrazia e di libert?. Questa volta ? a rischio niente
meno che il diritto di esprimere la propria opinione attraverso il web ed i
blog, cos? come sarebbe previsto dall'articolo 21 della Costituzione della
Repubblica Italiana.

*Col favore delle tenebre. No, anzi... delle ferie*

In pieno Agosto 2007, mentre l'intero paese era in vacanza, il solerte
Ricardo Franco Levi, Sottosegretario alla Presidenza del Consiglio, ha
presentato un progetto di legge chiaramente concepito con il solo scopo di
mettere la museruola a tutti coloro che intendono far sentire la voce della
Societ? Civile attraverso il World Wide Web. La settimana scorsa, nel pi?
assoluto silenzio, questo progetto di legge liberticida ha ottenuto
l'approvazione del Consiglio dei Ministri, guidato da Romano Prodi. Ecco
come ne ha dato la notizia Repubblica:

ROMA - Consiglio dei ministri del 12 ottobre: il governo approva e manda
all'esame del Parlamento il testo che vuole cambiare le regole del gioco del
mondo editoriale, per i giornali e anche per Internet. E' un disegno di
legge complesso, 20 pagine, 35 articoli, che adesso comincia a seminare il
panico in Rete. Chi ha un piccolo sito, perfino chi ha un blog personale
vede all'orizzonte obblighi di registrazione, burocrazia, spese impreviste.
Soprattutto teme sanzioni penali pi? forti in caso di diffamazione.

[Da Repubblica<http://www.repubblica.it/2007/10/sezioni/scienza_e_tecnologia/testo-editoria/testo-editoria/testo-editoria.html>del
19 Ottobre 2007]

*Scherzetto o balzello?*

La prima, e la pi? grave, conseguenz, di questo scherzo di Halloween del
nostro amato Governo ? un aumento iperbolico dei costi e delle complessit?
burocratiche necessari per mantenere in vita un qualunque sito web, compreso
un blog personale. In pratica, chiunque volesse pubblicare qualunque cosa
(anche le ricette della nonna) su un blog gratuito (come Wordpress o
Blogger) sarebbe comunque costretto a registrare la propria "testata
giornalistica" presso il famigerato ROC ("Registro degli Operatori di
Comunicazione"). Per chi non lo sapesse, il ROC ? un database delle persone
autorizzate dalla legge a parlare in pubblico, cio? qualcosa che esiste in
due soli paesi al mondo: in Italia ed in Cina! Ecco come spiega quello che
sta succedendo il quotidiano Repubblica:

"Articolo 6 del disegno di legge. C'? scritto che deve iscriversi al ROC, in
uno speciale registro custodito dall'Autorit? per le Comunicazioni, chiunque
faccia "attivit? editoriale". L'Autorit? non pretende soldi per
l'iscrizione, ma l'operazione ? faticosa e qualcuno tra i certificati
necessari richiede il pagamento del bollo. Attivit? editoriale - continua il
disegno di legge - significa inventare e distribuire un "prodotto
editoriale" anche senza guadagnarci. E prodotto editoriale ? tutto: ?
l'informazione, ma ? anche qualcosa che "forma" o "intrattiene" il
destinatario (articolo 2). I mezzi di diffusione di questo prodotto sono
sullo stesso piano, Web incluso."

[Da Repubblica<http://www.repubblica.it/2007/10/sezioni/scienza_e_tecnologia/testo-editoria/testo-editoria/testo-editoria.html>del
19 Ottobre 2007]

Per legge, una "testata giornalistica" (come "Repubblica Online" o "Punto
Informatico") deve avere un suo Direttore Responsabile e deve essere
pubblicata da una Societ? Editrice. Ovviamente, sia l'uno che l'altro
vogliono essere pagati per il lavoro che svolgono e per le responsabilit?
(anche penali) che si accollano. Altrettanto ovviamente, *nessun blogger
sar? mai in grado di coprire questi costi*. *Di conseguenza, la stragrande
maggioranza dei blog gestiti da italiani sono destinati a chiudere*. Si noti
che questo vale anche per i blog pubblicati in altre lingue e su altri
mercati. Ci? che conta ? infatti la residenza dell'autore.

Questo disegno di legge potrebbe quindi riuscire in qualcosa che nemmeno il
giverno Cinese ? mai riuscito a mettere in atto: la cancellazione dei blog
dalla faccia del pianeta. Incredibilmente, potrebbe riuscire in questa opera
senza nemmeno varare una legge che affermi esplicitamente che gestire un
blog ? illegale. Una azione come questa, infatti, susciterebbe un coro di
proteste. Il nostro amato Governo potrebbe riuscire in questa impresa
semplicemente innalzando i costi di gestione di un blog ad un livello
inaccettabile per gli autori. Un modo molto pi? sottile e meno appariscente
di mettere in atto una delle pi? odiose forme di censura che si possano
concepire.

*Il porto d'armi per il Blog*

Ma questo ? solo uno degli effetti di questo progetto di legge. L'altro ?
che trasformando i blog in testate giornalistiche si trasformano i blogger
in giornalisti *de facto* ed i loro reati da semplici maracechelle in reati
penali di notevole peso. In particolare, il reato di diffamazione commesso
da un blogger non sarebbe pi? "diffamazione semplice" ma "diffamazione a
mezzo stampa". La differenza in termini di anni di galera e di euro di danni
da pagare al diffamato ? notevole.

In buona sostanza, chiunque volesse ancora dire la sua attraverso un blog
dovrebbe agire con la stessa cautela di chi decide di portare un'arma sulla
persona.

*Le rassicurazioni di Mangiafuoco*

Naturalmente, a fronte di un testo di questa gravit?, steso *nero su bianco*,
il Sottosegretario Levi sta spendendo una grande quantit? di parole
(vibrazioni dell'aria tra due persone) per rassicurare i blogger che "No,
assolutamente! Non ? nostra intenzione chiudere la bocca alla Societ? Civile
ed ai dissidenti". Ecco come riporta le rassicurazioni del sottosegretario
il solito quotidiano "La Repubblica":

Ricardo Franco Levi, sottosegretario alla Presidenza del Consiglio e padre
della riforma, sdrammatizza: "Lo spirito del nostro progetto non ? certo
questo. Non abbiamo interesse a toccare i siti amatoriali o i blog
personali, non sarebbe praticabile".

[Da Repubblica<http://www.repubblica.it/2007/10/sezioni/scienza_e_tecnologia/testo-editoria/testo-editoria/testo-editoria.html>del
19 Ottobre 2007]

Verba volant, scripta
manent<http://it.wikipedia.org/wiki/Verba_volant,_scripta_manent>
....

*Ma ? possibile una cosa del genere? O ci state prendendo in giro?*

Giudicate voi stessi:

"Testo della Proposta di Legge del 3 Agosto
2007<http://www.governo.it/Presidenza/DIE/doc/DDL_editoria_030807.pdf>"
sul sito del Governo.

"Il Governo riforma l'editoria. Allarme in
Rete.<http://www.repubblica.it/2007/10/sezioni/scienza_e_tecnologia/testo-editoria/testo-editoria/testo-editoria.html>"
a epubblica Online.

"Il Governo vara la Internet
Tax.<http://punto-informatico.it/p.aspx?i=2092327>"
a Punto Informatico.

"La nuova legge sull'editoria del Governo obbligher? tutti i blog e i siti a
diventare testate
giornalistiche<http://www.civile.it/news/visual.php?num=45712>"a
Civile.it.

*Che fare?*

Si pu? fare qualcosa per contrastare questo ignobile progetto di censura,
degno solo della pi? squallida delle dittature? Si, si pu? fare qualcosa. Ad
esempio, si pu? spargere la voce. Si pu? far sapere all'intero paese (e, se
possibile, al mondo intero) che un Governo che si autodefinisce di Sinistra,
vicino al popolo e difensore della Libert?, sta cercando di cancellare
l'intero "fenomeno blog" dal suo ramo di Internet.

*Lo si pu? fare ripubblicando questo testo, cos? come lo trovate, sui vostri
siti web, ovunque possibile.* Questo testo, infatti, contiene al suo interno
un link a s? stesso. Ripubblicandolo su molti altri siti web si fa in modo
che Google (ed altri motori di ricerca) lo innalzino nel loro punteggio
("rank") e lo presentino tra i loro risultati migliori ogni volta che un
internauta cerca il termine "blog". In questo modo, chiunque sia
interessato, anche marginalmente ai blog pu? essere raggiunto da questo
grido di allarme. Per ripubblicare il testo, basta fare un copia&incolla.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/07ee875c/attachment.htm>

From dyoung at mesd.k12.or.us  Fri Oct 19 15:39:57 2007
From: dyoung at mesd.k12.or.us (Dan Young)
Date: Fri, 19 Oct 2007 08:39:57 -0700
Subject: location of ltsp root
In-Reply-To: <20071019083703.GD2709@free.fr>
References: <20071019083703.GD2709@free.fr>
Message-ID: <994441ae0710190839h4f3f44fbre588c44e70e67c1f@mail.gmail.com>

On 10/19/07, Patrice Dumas <pertusus at free.fr> wrote:
> Should we use /opt/ltsp or something else, like /var/lib/ltsp for the
> thin clients root directories?

/var/lib/ltsp seems like the obvious choice given the "no program should
rely on a specific subdirectory structure" nature of /srv.

-- 
Dan Young <dyoung at mesd.k12.or.us>
Multnomah ESD - Technology Services
503-257-1562



From bnocera at redhat.com  Fri Oct 19 15:51:12 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 19 Oct 2007 16:51:12 +0100
Subject: FLAC update in F-7
In-Reply-To: <200710171844.23517.ville.skytta@iki.fi>
References: <1192624931.9971.10.camel@snoogens.fab.redhat.com>
	<200710171844.23517.ville.skytta@iki.fi>
Message-ID: <1192809072.2843.49.camel@cookie.hadess.net>


On Wed, 2007-10-17 at 18:44 +0300, Ville Skytt? wrote:
> On Wednesday 17 October 2007, Bastien Nocera wrote:
> > Heya,
> >
> > Just a heads-up that I'm currently compiling FLAC 1.2.1 in Fedora 7 to
> > fix CVE-2007-4619.
> >
> > Hopefully, it won't break too much (same patches and same code as seen
> > in the devel/F-8 branch).
> 
> xine-lib seems to work fine with the updated flac without a rebuild.

Great. Could you +1 the update?



From jspaleta at gmail.com  Fri Oct 19 15:57:14 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Oct 2007 07:57:14 -0800
Subject: [LICENSE CHANGE] weechat
In-Reply-To: <20071019130833.GA2359@stingr.net>
References: <20071019130833.GA2359@stingr.net>
Message-ID: <604aa7910710190857q687b0bcejb60ae9dcbe520e6f@mail.gmail.com>

On 10/19/07, Paul P Komkoff Jr <i at stingr.net> wrote:
> Hi!
>
> I'm going to update weechat to 0.2.6, which is GPLv3.
GPLv3 or is it GPLv3+?

-jef



From rms at 1407.org  Fri Oct 19 15:55:22 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 19 Oct 2007 16:55:22 +0100
Subject: [LICENSE CHANGE] weechat
In-Reply-To: <604aa7910710190857q687b0bcejb60ae9dcbe520e6f@mail.gmail.com>
References: <20071019130833.GA2359@stingr.net>
	<604aa7910710190857q687b0bcejb60ae9dcbe520e6f@mail.gmail.com>
Message-ID: <20071019155522.GE2938@roque.1407.org>

On Fri, Oct 19, 2007 at 07:57:14AM -0800, Jeff Spaleta wrote:
> On 10/19/07, Paul P Komkoff Jr <i at stingr.net> wrote:
> > Hi!
> >
> > I'm going to update weechat to 0.2.6, which is GPLv3.
> GPLv3 or is it GPLv3+?

Looking at the source code seems to be GPLv3+

rms at roque:~/Downloads/weechat-0.2.6/src/gui$ grep "either version " *.c
gui-action.c: * the Free Software Foundation; either version 3 of the License, or
gui-buffer.c: * the Free Software Foundation; either version 3 of the License, or
gui-common.c: * the Free Software Foundation; either version 3 of the License, or
gui-keyboard.c: * the Free Software Foundation; either version 3 of the License, or
gui-log.c: * the Free Software Foundation; either version 3 of the License, or
gui-panel.c: * the Free Software Foundation; either version 3 of the License, or
gui-window.c: * the Free Software Foundation; either version 3 of the License, or
rms at roque:~/Downloads/weechat-0.2.6/src/gui$ grep "either version " *.h
gui-buffer.h: * the Free Software Foundation; either version 3 of the License, or
gui-color.h: * the Free Software Foundation; either version 3 of the License, or
gui.h: * the Free Software Foundation; either version 3 of the License, or
gui-keyboard.h: * the Free Software Foundation; either version 3 of the License, or
gui-panel.h: * the Free Software Foundation; either version 3 of the License, or
gui-window.h: * the Free Software Foundation; either version 3 of the License, or

But I can't do a full audit to say it's done properly.

Rui

-- 

Today is Boomtime, the 73rd day of Bureaucracy in the YOLD 3173
+ 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...?



From rnorwood at redhat.com  Fri Oct 19 16:21:36 2007
From: rnorwood at redhat.com (Robin Norwood)
Date: Fri, 19 Oct 2007 12:21:36 -0400
Subject: rpms/perl/devel perl.spec,1.136,1.137
In-Reply-To: <47139122.1080303@linux-kernel.at> (Oliver Falk's message of
	"Mon, 15 Oct 2007 18:11:14 +0200")
References: <200710151600.l9FG03bf006271@cvs-int.fedora.redhat.com>
	<47139122.1080303@linux-kernel.at>
Message-ID: <xf4r6jrm5wv.fsf@solitude.devel.redhat.com>

Oliver Falk <oliver at linux-kernel.at> writes:

> Spot, do you see and chance to Require db = x.x.x in perl spec? I
> updated db4 today on one devel machine and what happens? Apache doesn't
> start any more, because of DB_File, that wants older db4 :-(
>
> Well, cpan is your friend and this is easily fixed...
>
> However, the problem occurs every time you update db4 from one version
> to another...

Spot addressed this nicely in 28.3 and 28.4 - here's the bug that tracks
the issue, if you're curious:

https://bugzilla.redhat.com/show_bug.cgi?id=144672

-RN

> On 10/15/2007 06:00 PM, Tom Callaway (spot) wrote:
>> Author: spot
>> 
>> Update of /cvs/pkgs/rpms/perl/devel
>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6182
>> 
>> Modified Files:
>> 	perl.spec 
>> Log Message:
>> 
>> Bump for db4 version change
>> 
>> 
>> 
>> Index: perl.spec
>> ===================================================================
>> RCS file: /cvs/pkgs/rpms/perl/devel/perl.spec,v
>> retrieving revision 1.136
>> retrieving revision 1.137
>> diff -u -r1.136 -r1.137
>> --- perl.spec	3 Oct 2007 20:24:26 -0000	1.136
>> +++ perl.spec	15 Oct 2007 15:59:25 -0000	1.137
>> @@ -20,7 +20,7 @@
>>  
>>  Name:           perl
>>  Version:        %{perl_version}
>> -Release:        28%{?dist}.1
>> +Release:        28%{?dist}.2
>>  Epoch:          %{perl_epoch}
>>  Summary:        The Perl programming language
>>  Group:          Development/Languages
>> @@ -778,6 +778,9 @@
>>  # Nothing. Nada. Zilch. Zarro. Uh uh. Nope. Sorry.
>>  
>>  %changelog
>> +* Mon Oct 15 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28.2
>> +- bump again for db4 version increase
>> +
>>  * Mon Oct  1 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-28
>>  - update DB_File to 1.815
>>  
>> 
>
>
> -- 
> Oliver Falk
> UNIX/Linux Systems Engineer
> Mail: oliver at linux-kernel.at
> Phone: +43 (664) 838 59 25

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching



From buildsys at fedoraproject.org  Fri Oct 19 17:20:37 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri, 19 Oct 2007 13:20:37 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-19
Message-ID: <20071019172037.6C8FD15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 11

    adminutil-1.1.5-1.fc6
    drupal-5.3-1.fc6
    fuse-python-0.2-6.fc6
    fwfstab-0.02-1.fc6.1
    mod_nss-1.0.7-2.fc6
    mozldap-6.0.5-1.fc6
    perl-SVG-2.36-2.fc6
    perl-Text-Shellwords-1.08-3.fc6
    python-meld3-0.6.3-1.fc6
    seamonkey-1.0.9-3.fc6
    wammu-0.23-1.fc6


Changes in Fedora Extras 6: 


adminutil-1.1.5-1.fc6
---------------------
* Thu Oct 18 2007 Rich Megginson <rmeggins at redhat.com> - 1.1.5-1
- bump version to 1.1.5
- fix icu linking issue
- disable libtool rpath by default - added --enable-rpath option to configure

drupal-5.3-1.fc6
----------------
* Thu Oct 18 2007 Jon Ciesla <limb at jcomserv.net> - 5.3-1
- Upgrade to 5.3, fixes:
- HTTP response splitting.
- Arbitrary code execution.
- Cross-site scripting.
- Cross-site request forgery.
- Access bypass.

* Mon Sep 24 2007 Jon Ciesla <limb at jcomserv.net> - 5.2-3
- Minor doc correction, BZ 301541.

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> - 5.2-2
- License tag correction.

fuse-python-0.2-6.fc6
---------------------
* Thu Oct 18 2007 Michel Salim <michel.sylvan at gmail.com> 0.2-6
- Fix source URL
- Include examples

fwfstab-0.02-1.fc6.1
--------------------
* Fri Oct 19 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.02-1.1
- Oops, forgot we need python-devel BR so %{python_sitelib} is defined
- Add Requires: Python >= 2.4 because fwfstab uses subprocess

* Thu Oct 18 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.02-1
- Update to version 0.02
- Drop X-Fedora from .desktop file
- Why do I define the fedora version and never use it?
- No longer requires redhat-artwork

* Mon Aug 13 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.01.1-4
- Update license tag

* Sat Dec 09 2006 Stewart Adam <s.adam AT diffingo DOT com> 0.01.1-3
- 'make tag' problems, bumping...

* Sat Dec 09 2006 Stewart Adam <s.adam AT diffingo DOT com> 0.01.1-2
- Rebuild for new python

* Thu Nov 02 2006 Stewart Adam <s.adam AT diffingo DOT com> 0.01.1-1
- Update to 0.01.1

mod_nss-1.0.7-2.fc6
-------------------
* Thu Oct 18 2007 Rob Crittenden <rcritten at redhat.com> 1.0.7-2
- Register functions needed by mod_proxy if mod_ssl is not loaded.

mozldap-6.0.5-1.fc6
-------------------
* Wed Sep 26 2007 Rich Megginson <rmeggins at redhat.com> - 6.0.5-1
- bump to version 6.0.5 - this version allows the use of SASL
- with IPv6 numeric addresses, as well as some memory leak fixes

perl-SVG-2.36-2.fc6
-------------------
* Sat Oct 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 2.36-2
- Add missing BR: perl(ExtUtils::MakeMaker)

* Sat Oct 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 2.36-1
- Update to 2.36

perl-Text-Shellwords-1.08-3.fc6
-------------------------------
* Mon Oct 15 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.08-3
- Add missing BR: perl(ExtUtils::MakeMaker)

* Tue Sep 04 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.08-2
- Clarified license terms: GPL+ or Artistic

python-meld3-0.6.3-1.fc6
------------------------
* Wed Oct 17 2007 Toshio Kuratomi <a.badger at gmail.com> 0.6.3-1
- Update to 0.6.3 (Fix memory leaks).
- Update license tag.

* Wed Aug 22 2007 Mike McGrath <mmcgrath at redhat.com> 0.6-3
- Release bump for rebuild

* Thu Apr 26 2007 Mike McGrath <mmcgrath at redhat.com> 0.6-2.1
- Fix requires on python-elementtree for python-2.5.  (elementtree is included
  in python-2.5)

seamonkey-1.0.9-3.fc6
---------------------
* Thu Oct 18 2007 Martin Stransky <stransky at redhat.com> - 1.0.9-3
- Update to latest snapshot of Mozilla 1.8.0 branch
- added pathes for Mozilla bugs 267833,309322,345305,361745,
  362901,372309,378787,381300,384105,386914,387033,387881,388121,388784
  390078,393537,395942,325761,392149

wammu-0.23-1.fc6
----------------
* Sun Oct 14 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.23-1
- Updated Release.



From jreiser at BitWagon.com  Fri Oct 19 19:54:49 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Fri, 19 Oct 2007 12:54:49 -0700
Subject: CD audio: preference to limit drive speed?
Message-ID: <47190B89.1030506@BitWagon.com>

Is there a preference to limit the drive speed when playing
compact disc digital audio?  I find that "eject -x 8 /dev/cdrom"
is much quieter than the full speed (such as 48x) that appears to be
the default.  Would it be a preference of hal, nautilus, each player
application, gnome-desktop, or what?

-- 



From kevin at scrye.com  Fri Oct 19 20:01:26 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Fri, 19 Oct 2007 14:01:26 -0600
Subject: source file audit - 2007-10-17
Message-ID: <20071019140126.74e84103@ghistelwchlohm.scrye.com>


Here's attached another run of my sources/patches url checker. 

- There are 561 lines in this run, 620 lines in the last run, and 
700 in the one before that, so progress seems to be happening. 

- Should I keep running this? Do folks find it useful? 

- Should I try and spam maintainers? Or just keep posting in the list?

You can find the results file at: 

http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20071017.txt

And also attached to this mail. 

Lines in the output are of three forms: 

- BADURL:base-file-name:$PACKAGENAME

This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc. 
Also there are a number of packages with incorrect sourceforge links. 
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). 

- BADSOURCE:$SOURCENAME:$PACKAGENAME

This means that the source was downloaded ok from the upstream site,
but doesn't match the md5sum given in the sources file. 
This could be due to needing to strip out content that fedora cannot
ship (but in that case you shouldn't have the full URI in the Source
line). Or upstream following poor release practices and updating
without changing their release.

- BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME

This means that the file was downloaded from the URI given, and the
md5sum did not match the file thats present in CVS (not the lookaside).
This might be due to timestamps, or any of the above reasons. 

kevin
--
jmoskovc:BADURL:acl_2.2.39-1.tar.gz:acl
rmeggins:BADURL:adminutil-1.1.4.tar.bz2:adminutil
rdieter:BADURL:30375-akode-2.0.1.tar.bz2:akode
timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime
tagoh:BADURL:anthy-9100b.tar.gz:anthy
tagoh:BADURL:alt-cannadic-070805.tar.bz2:anthy
dwmw2:BADURL:apmud-1.0.0.tgz:apmud
than:BADURL:arts-1.5.8.tar.bz2:arts
chrisw:BADURL:asciidoc-8.2.2.tar.gz:asciidoc
awjb:BADURL:atitvout_0.4-2.diff.gz:atitvout
qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas
karsten:BADURL:automake-1.5.tar.bz2:automake15
sindrepb:BADSOURCE:avant-window-navigator-0.1.1.tar.gz:avant-window-navigator
stransky:BADURL:awesfx-0.5.0d.tar.gz:awesfx
stransky:BADURL:gu11-rom.zip:awesfx
zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar
zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar
jwrdegoede:BADSOURCE:BASS-Floppy.zip:beneath-a-steel-sky
walters:BADURL:bigboard-0.5.22.tar.gz:bigboard
atkac:BADURL:bind-9.5.0a6.tar.gz:bind
atkac:BAD_CVS_SOURCE:dnszone.schema:bind
mdomsch:BADURL:biosdevname-0.2.4.tar.gz:biosdevname
spot:BADSOURCE:mpiblacs.tgz:blacs
s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender
sandeen:BADURL:blktrace-git-20070730162628.tar.gz:blktrace
odvorace:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd
nomis80:BADURL:camstream-0.26.3.tar.gz:camstream
tagoh:BADURL:Canna37p3.tar.bz2:Canna
tagoh:BADURL:shion.tar.gz:Canna
tagoh:BADURL:zipcode-20030204.tar.bz2:Canna
pfj:BADURL:CastPodder-5.0.tar.bz2:CastPodder
oddsocks:BADURL:cbios-0.21.zip:cbios
rrelyea:BADSOURCE:ccid-1.2.1.tar.gz:ccid
pjones:BADSOURCE:cdparanoia-III-alpha9.8.src.tgz:cdparanoia
gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb
dwalsh:BADSOURCE:checkpolicy-2.0.4.tgz:checkpolicy
athimm:BADURL:chrpath-0.13.tar.gz:chrpath
fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail
awjb:BADURL:claws-mail-extra-plugins-3.0.1.tar.bz2:claws-mail-plugins
jkeating:BADURL:cleanfeed-0.95.7b.tar.gz:cleanfeed
jmrcpn:BADURL:clement-2.1-241.tar.gz:clement
chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito
jnovy:BADSOURCE:db-4.2.52.tar.gz:compat-db
jnovy:BADSOURCE:db-4.3.29.tar.gz:compat-db
pmachata:BADURL:flex-2.5.4a.tar.gz:compat-flex
chitlesh:BADURL:guile-1.6.7.tar.gz:compat-guile-16
drago01:BADURL:compiz-fusion-plugins-main-09b700.tar.bz2:compiz-fusion
drago01:BADURL:compiz-fusion-plugins-extra-6871d0.tar.bz2:compiz-fusion-extras
jwilson:BADURL:conman-0.1.9.2.tar.bz2:conman
bpeck:BADURL:conmux-493svn.tar.gz:conmux
stingray:BADURL:conntrack-1.00beta2.tar.bz2:conntrack
gemi:BADSOURCE:cook-2.30.tar.gz:cook
rathann:BADURL:crm114-20070301-BlameBaltar.no-TRE.src.tar.bz2:crm114
chitlesh:BADURL:13969-crystal-1.0.5.tar.bz2:crystal
chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear
chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project
nhorman:BADURL:cscope-15.5.tar.gz:cscope
dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound
twaugh:BADURL:cups-1.3.3-source.tar.bz2:cups
gemi:BADSOURCE:curry-0.9.11.tar.gz:curry
corsepiu:BADURL:cvsutils-0.2.3.tar.gz:cvsutils
sconklin:BADURL:db-4.6.19.tar.gz:cyrus-sasl
pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o
davidz:BADURL:dbus-glib-0.73.tar.gz:dbus-glib
davidz:BADURL:dbus-python-0.82.0.tar.gz:dbus-python
ixs:BADSOURCE:dd_rhelp-0.0.6.tar.gz:dd_rescue
petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk
faucamp:BADURL:dekorator-0.3.tar.gz:dekorator
pgordon:BADURL:deluge-0.5.5.tar.gz:deluge
mbarnes:BADURL:devhelp-0.16.1.tar.bz2:devhelp
schmidtw:BADURL:dfu-programmer-0.4.3.tar.gz:dfu-programmer
ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder
ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder
dcantrel:BADURL:dhcp-0.10.tgz:dhcpv6
icon:BADURL:diction-1.10-rc4.tar.gz:diction
mgarski:BADURL:digikam-doc-0.9.2-beta2.tar.bz2:digikam-doc
lvm-team:BADURL:dmraid-1.0.0.rc14.tar.bz2:dmraid
tjanouse:BADURL:dovecot-1.0.5.tar.gz:dovecot
jjohnstn:BADURL:eclipse-changelog-src-2.5.1.zip:eclipse-changelog
overholt:BADSOURCE:fedoraeclipse-mylynbugzilla-0.0.1.zip:eclipse-mylyn
alexl:BADURL:eel-2.20.0.tar.bz2:eel2
than:BADURL:eject-2.1.5.tar.gz:eject
veillard:BADURL:ekiga-2.0.11.tar.gz:ekiga
pmachata:BADURL:ElectricFence-2.2.2.tar.gz:ElectricFence
coldwell:BADURL:emacs-22.1.tar.gz:emacs
coldwell:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs
rdieter:BADURL:gen_python_api_20050605.tar.gz:eric
rdieter:BADURL:gen_sip_api_20060711.tar.gz:eric
bpepple:BADSOURCE:evolution-brutus-1.1.28.7.tar.gz:evolution-brutus
dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc
dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc
vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect
jlayton:BADURL:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate
jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate
athimm:BADURL:fakeroot_1.6.4.tar.gz:fakeroot
mclasen:BADURL:fast-user-switch-applet-2.20.0.tar.bz2:fast-user-switch-applet
davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival
davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival
ascii:BADURL:fish-1.22.3.tar.bz2:fish
rdieter:BADURL:fltk-1.1.x-r5750.tar.bz2:fltk
awjb:BADURL:fluxbox-1.0.0.tar.bz2:fluxbox
rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2
tagoh:BADURL:k14-oldkanji.tar.gz:fonts-japanese
tagoh:BADURL:mplus_bitmap_fonts-2.2.4.tar.gz:fonts-japanese
than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R
than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R
twaugh:BADURL:foomatic-db-engine-3.0-20070614.tar.gz:foomatic
twaugh:BADURL:foomatic-filters-3.0-20070919.tar.gz:foomatic
twaugh:BADURL:foomatic-db-3.0-20070919.tar.gz:foomatic
twaugh:BADURL:foomatic-db-hpijs-20070614.tar.gz:foomatic
sheltren:BADURL:fortune-tao.tar.gz:fortune-mod
sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod
sheltren:BADURL:osfortune.tar.gz:fortune-mod
joost:BADURL:fpc-2.2.0.compiler.bin.tar.gz:fpc
kaboom:BADURL:fping-2.4b2_to-ipv6.tar.gz:fping
bpepple:BADURL:freeciv-2.0.9.tar.bz2:freeciv
bpepple:BADURL:stdsounds3.tar.gz:freeciv
tanguy:BADURL:freehdl-0.0.4.tar.gz:freehdl
athimm:BADURL:freenx-0.7.0.tar.gz:freenx
cgrau:BADURL:frotz-2.43.tar.gz:frotz
oddsocks:BADSOURCE:fuse-0.8.0.1.tar.gz:fuse-emulator
peter:BADURL:fuse-python-0.2.tar.gz:fuse-python
cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym
cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym
rvokal:BADURL:gaim-guifications-2.13beta6.tar.bz2:gaim-guifications
icon:BADURL:gazpacho-0.7.2.tar.bz2:gazpacho
belegdol:BADURL:gchempaint-0.8.3.tar.bz2:gchempaint
odvorace:BADURL:gdbm-1.8.0.tar.gz:gdbm
luya:BADURL:gDesklets-0.35.4.tar.bz2:gdesklets
owentl:BADURL:Calendar-0.41.tar.gz:gdesklets-calendar
owentl:BADURL:GoodWeather-0.3.tar.gz:gdesklets-goodweather
kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf
orion:BADURL:gdl-0.9pre5.tar.gz:gdl
rstrode:BADURL:gdm-2.99.0.tar.gz:gdm
chitlesh:BADSOURCE:gdsto3d-20070815.tar.bz2:gds2pov
chitlesh:BADURL:geda-docs-1.2.0.tar.gz:geda-docs
chitlesh:BADURL:geda-examples-1.2.0.tar.gz:geda-examples
chitlesh:BADURL:geda-gattrib-1.2.0.tar.gz:geda-gattrib
chitlesh:BADURL:geda-gnetlist-1.2.0.tar.gz:geda-gnetlist
chitlesh:BADURL:geda-gschem-1.2.0.tar.gz:geda-gschem
chitlesh:BADURL:geda-gsymcheck-1.2.0.tar.gz:geda-gsymcheck
chitlesh:BADURL:geda-symbols-1.2.0.tar.gz:geda-symbols
chitlesh:BADURL:geda-utils-1.2.0.tar.gz:geda-utils
pmachata:BADURL:genromfs-0.5.1.tar.gz:genromfs
rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview
bos:BADURL:ghc-6.8.0.20070928-src.tar.bz2:ghc
bos:BADURL:ghc-6.8.0.20070928-src-extralibs.tar.bz2:ghc
denis:BADURL:gimmage-0.2.3.tar.gz:gimmage
mclasen:BADURL:glade-2.12.1.tar.bz2:glade2
mclasen:BADURL:glib-2.14.2.tar.bz2:glib2
rafalzaq:BADSOURCE:glob2-0.9.1.tar.gz:glob2
alexl:BADURL:gmime-2.2.10.tar.bz2:gmime
rstrode:BADURL:gnome-applets-2.20.0.tar.bz2:gnome-applets
tsmetana:BADURL:gnomebaker-0.6.2.tar.gz:gnomebaker
bpepple:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog
belegdol:BADURL:gnome-chemistry-utils-0.8.3.tar.bz2:gnome-chemistry-utils
cwickert:BADURL:gnome-ppp-0.3.23.tar.bz2:gnome-ppp
mbarnes:BADURL:gnome-python-2.20.0.tar.bz2:gnome-python2
deji:BADSOURCE:gnomescan-0.4.0.2.tar.gz:gnomescan
davidz:BADSOURCE:gnome-speech-0.4.16.tar.bz2:gnome-speech
pgordon:BADURL:Clearlooks-Big_Pack-0.6.x.tar.gz:gnome-theme-clearlooks-bigpack
alexl:BADURL:gnome-vfs-2.20.0.tar.bz2:gnome-vfs2
orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum
bpepple:BADURL:gnonlin-0.10.9.tar.bz2:gnonlin
nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp
belegdol:BADURL:goffice-0.4.3.tar.bz2:goffice04
jspaleta:BADURL:gpodder-0.10.0.tar.gz:gpodder
jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt
vlg:BADURL:granule-1.2.4.tar.gz:granule
ixs:BADSOURCE:GraphicsMagick-1.1.8.tar.bz2:GraphicsMagick
cbalint:BADURL:grass-6.2.2-fedora.tar.gz:grass
athimm:BADURL:greylistd_0.8.3.2.tar.gz:greylistd
orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins
bos:BADURL:gtk2hs-0.9.12.20071008.tar.gz:gtk2hs
gemi:BADURL:GtkAda-gpl-2.8.0.tgz:GtkAda
mclasen:BADURL:gtk-doc-1.9.tar.bz2:gtk-doc
dionysos:BAD_CVS_SOURCE:gtk+extra-2.1.1.tar.gz:gtk+extra
maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine
pfj:BADURL:gtksourceview-sharp-2.0-0.10.tar.gz:gtksourceview-sharp
varekova:BADURL:gzip-1.3.12.tar.gz:gzip
orion:BADURL:4.2r1-hrepack-p4.tar.gz:hdf
karsten:BADURL:hdparm-7.7.tar.gz:hdparm
ixs:BADURL:hevea-1.09.tar.gz:hevea
cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools
cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools
dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils
walters:BADURL:hippo-canvas-0.2.24.tar.gz:hippo-canvas
walters:BADURL:hotwire-0.599.zip:hotwire
caolanm:BADURL:alt-myspell-pl-20071004.zip:hunspell-pl
caolanm:BADURL:hunspell-pt_PT-20071003.tar.gz:hunspell-pt
ensc:BADURL:hunt-1.5.tgz:hunt
gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm
cgrau:BADURL:ifm-5.1.tar.gz:ifm
pfj:BADURL:ikvm-0.22.tar.gz:ikvm
tagoh:BADURL:im-chooser-0.5.3.tar.gz:im-chooser
danielm:BADURL:initng-ifiles-0.1.4.tar.bz2:initng-ifiles
gajownik:BADURL:inotify-tools-3.11.tar.gz:inotify-tools
mclasen:BADURL:intltool-0.36.2.tar.bz2:intltool
sconklin:BADURL:ipsec-tools-0.7.tar.bz2:ipsec-tools
ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel
thias:BADSOURCE:ipvsadm-1.24.tar.gz:ipvsadm
than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils
jspaleta:BADURL:istanbul-0.2.2.tar.bz2:istanbul
adrian:BADURL:jabberd-2.0s11.tar.gz:jabberd
mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler
dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator
robmv:BADURL:org.tmatesoft.svn_1.1.0.beta4.src.zip:javasvn
mtasaka:BADURL:jd-1.9.7-svn1407.tgz:jd
mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend
snecker:BADURL:jokosher-20070929svn.tar.gz:jokosher
ecik:BADURL:dcopexport-0.11.1-20060320-0.5.0-svn.tar.bz2:kadu
ecik:BADURL:kadu-profiles-0.1.tar.gz:kadu
robmv:BADURL:kanatest-0.4.4.tar.gz:kanatest
dionysos:BADURL:kbackup-0.5.2.tar.bz2:kbackup
pertusus:BADSOURCE:kchmviewer-3.1.tar.gz:kchmviewer
oddsocks:BADSOURCE:kcometen3-1.1.tar.gz:kcometen3
kkofler:BADURL:kdebase-3.93.0.tar.bz2:kdebase4
than:BADURL:kde-i18n-ar-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-bg-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-et-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-fi-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-fr-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-he-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-hi-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-hu-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-is-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-it-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ja-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nb-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-bn-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nl-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-nn-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pa-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pl-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pt-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-pt_BR-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ro-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ru-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sk-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sl-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ca-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sr-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-sv-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ta-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-tr-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-uk-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-zh_CN-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-zh_TW-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-lt-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-ko-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-cs-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-da-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-de-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-el-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-en_GB-3.5.8.tar.bz2:kde-i18n
than:BADURL:kde-i18n-es-3.5.8.tar.bz2:kde-i18n
kkofler:BADURL:kdelibs-3.93.0.tar.bz2:kdelibs4
than:BADURL:kdemultimedia-3.5.8-patched.tar.bz2:kdemultimedia
than:BADURL:kdepimlibs-3.93.0.tar.bz2:kdepimlibs
oddsocks:BADURL:kdetv-0.8.9.tar.bz2:kdetv
than:BADURL:kdevelop-3.4.1.tar.bz2:kdevelop
than:BADSOURCE:css.tar.bz2:kdewebdev
than:BADSOURCE:html.tar.bz2:kdewebdev
than:BADSOURCE:javascript.tar.bz2:kdewebdev
thias:BADSOURCE:keepalived-1.1.15.tar.gz:keepalived
ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup
chitlesh:BADURL:keurocalc-0.9.7.tgz:keurocalc
dionysos:BADURL:kicad-sources--2007-07-09.zip:kicad
chitlesh:BADURL:26521-kio_resources-0.2.tar.bz2:kio_resources
chitlesh:BADURL:31025-kmenu-gnome-0.6.8.tar.gz:kmenu-gnome
rdieter:BADURL:kmymoney2-0.8.7.tar.gz:kmymoney2
faucamp:BADURL:12956-knemo-0.4.7.tar.bz2:knemo
tagoh:BADURL:knm_new.tar.gz:knm_new-fonts
chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome
pwouters:BADURL:ks3switch-0.1.tar.gz:ks3switch
tsmetana:BADURL:ast-ksh.2007-06-28.tgz:ksh
tsmetana:BADURL:INIT.2007-06-28.tgz:ksh
tsmetana:BADURL:ast-base-locale.2007-03-28.tgz:ksh
rafalzaq:BADURL:ksudoku-0.4.tar.gz:ksudoku
chitlesh:BADURL:ktechlab-0.3.69.tar.bz2:ktechlab
corsepiu:BADURL:lib3ds-1.2.0.tar.gz:lib3ds
thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex
behdad:BADURL:libao-0.8.6.tar.gz:libao
bojan:BADURL:libapreq2-2.09.tar.gz:libapreq2
vlg:BADSOURCE:libassa-3.4.2.tar.gz:libassa
terjeros:BADURL:libast-0.7.1.tar.gz:libast
jorton:BADURL:imap-2004g.tar.Z:libc-client
thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml
ensc:BADURL:libextractor-0.5.18a.tar.gz.sig:libextractor
mclasen:BADURL:libgail-gnome-1.20.0.tar.bz2:libgail-gnome
chitlesh:BADURL:libgeda-1.2.0.tar.gz:libgeda
cbalint:BADURL:libgeotiff-1.2.4RC1.tar.gz:libgeotiff
splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm
zhu:BADSOURCE:libhangul-0.0.6.tar.gz:libhangul
mclasen:BADURL:libIDL-0.8.9.tar.bz2:libIDL
twaugh:BADURL:libieee1284-0.2.11.tar.bz2:libieee1284
caillon:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice
tgl:BADURL:jpegsrc.v6b.tar.bz2:libjpeg
snirkel:BADURL:libmtp-0.2.2.tar.gz:libmtp
rdieter:BADURL:libofa-0.9.3.tar.gz:libofa
thomasvs:BADSOURCE:liboggz-0.9.5.tar.gz:liboggz
jcollie:BADURL:libosip-0.9.7.tar.gz:libosip
bpostle:BADURL:libpano13-2.9.12.tar.bz2:libpano13
tgl:BADURL:libpng-1.2.16.tar.bz2:libpng
tscherf:BADURL:libprelude-0.9.13.tar.gz:libprelude
tscherf:BADURL:libpreludedb-0.9.11.1.tar.gz:libpreludedb
spot:BADURL:rx-1.5.tar.bz2:librx
dwalsh:BADURL:libselinux-2.0.37.tgz:libselinux
dwalsh:BADURL:libsemanage-2.0.12.tgz:libsemanage
dwalsh:BADSOURCE:libsepol-2.0.11.tgz:libsepol
denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++
mlichvar:BADURL:termcap-2.0.8.tar.bz2:libtermcap
kasal:BADURL:libvte-java-0.12.1.tar.bz2:libvte-java
ssp:BADURL:libXinerama-1.0.2.tar.bz2:libXinerama
ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile
rstrode:BADURL:libxklavier-3.3.tar.gz:libxklavier
icon:BADURL:libxml++-2.20.0.tar.bz2:libxml++
veillard:BADURL:libxml2-2.6.30.tar.gz:libxml2
jwrdegoede:BADSOURCE:nvidia-settings-1.0.tar.gz:libXNVCtrl
veillard:BADURL:libxslt-1.1.22.tar.gz:libxslt
s4504kr:BADURL:lightning-1.2.tar.gz:lightning
xris:BADURL:lineak-kdeplugins-0.9.tar.gz:lineak-kdeplugins
thias:BADSOURCE:linux_logo-5.01.tar.gz:linux_logo
bpepple:BADURL:loudmouth-1.2.3.tar.bz2:loudmouth
spot:BADURL:user.ps.gz:lout
kzak:BADURL:lslk_1.29_W.tar.gz:lslk
dbhole:BADURL:lucene-1.9.1-src.tar.gz:lucene
s4504kr:BADURL:luma-2.3.tar.bz2:luma
varekova:BADURL:lynx2.8.6.tar.bz2:lynx
bjohnson:BADURL:mailgraph-1.13.tar.gz:mailgraph
varekova:BADURL:mailx-8.1.1.tar.gz:mailx
mtasaka:BADSOURCE:manedit-0.8.1.tar.bz2:manedit
varekova:BADURL:manpages-da-0.1.1.tar.gz:man-pages-da
dchen:BADURL:man-pages-es-1.28.tar.bz2:man-pages-es
mmaslano:BADSOURCE:mansupfr.tar.bz2:man-pages-fr
dchen:BADURL:man-pages-it-0.3.0.tar.gz:man-pages-it
varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl
varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru
rdieter:BADURL:mtextralic.htm:mathml-fonts
rdieter:BADURL:macref.pdf:maxima
jnovy:BADURL:mc-2007-06-04-22.tar.gz:mc
dwalsh:BADURL:mcstrans-0.2.6.tgz:mcstrans
wtogami:BADURL:memtest86+-1.70.tar.gz:memtest86+
thias:BADSOURCE:metakit-2.4.9.7.tar.gz:metakit
ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel
tagoh:BADURL:mew-5.2.50.tar.gz:mew
jmoskovc:BADURL:micq-0.5.4.2.tgz:micq
jorge:BADSOURCE:mimetex.zip:mimetex
jkeating:BADURL:mock-0.7.6.tar.gz:mock
thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex
jcm:BADSOURCE:module-init-tools-3.4.tar.bz2:module-init-tools
jcm:BADSOURCE:module-init-tools-3.4.tar.bz2.sign:module-init-tools
rmeggins:BADSOURCE:mozldap-6.0.4.tar.gz:mozldap
than:BADURL:mozplugger-1.7.3.tar.gz:mozplugger
addutko:BADSOURCE:mrxvt-0.5.2.tar.gz:mrxvt
otaylor:BADURL:mugshot-1.1.56.tar.gz:mugshot
jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican
tgl:BADURL:mysql-5.0.45.tar.gz:mysql
tgl:BADURL:mysql-3.23.58.tar.gz:mysqlclient10
tgl:BADURL:mysql-4.1.14.tar.gz:mysqlclient14
tgl:BADURL:mysql-connector-odbc-3.51.14r248.tar.gz:mysql-connector-odbc
ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools
lmacken:BADURL:naim-0.11.8.3.1.tar.bz2:naim
dwmw2:BADURL:nano-2.0.6.tar.gz:nano
frankb:BAD_CVS_SOURCE:nasd.init:nas
alexl:BADURL:nautilus-cd-burner-2.20.0.tar.bz2:nautilus-cd-burner
meme:BADURL:vultures-2.1.0-full.tar.bz2:nethack-vultures
sconklin:BADURL:netlabel_tools-0.17.tar.gz:netlabel_tools
steved:BADURL:nfs.doc.tar.gz:nfs-utils
cchance:BADURL:nhpf-1.42.tar.gz:nhpf
jwrdegoede:BADSOURCE:njam-1.25-src.tar.gz:njam
snirkel:BADURL:njb-sharp-0.3.0.tar.bz2:njb-sharp
tagoh:BADURL:nkf-2.0.8b.tar.gz:nkf
nalin:BADURL:nss_db-2.2.tar.gz:nss_db
nalin:BADSOURCE:nss_ldap-257.tar.gz:nss_ldap
nalin:BADSOURCE:pam_ldap-184.tar.gz:nss_ldap
jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx
walters:BADURL:online-desktop-0.2.19.tar.gz:online-desktop
veillard:BADURL:opal-2.2.11.tar.gz:opal
pknirsch:BADSOURCE:ipmitool-1.8.9.tar.gz:OpenIPMI
jsafrane:BADSOURCE:db-4.4.20.tar.gz:openldap
caolanm:BADURL:evolocal.odb:openoffice.org
corsepiu:BADURL:OpenSceneGraph-2.0.zip:OpenSceneGraph
mclasen:BADURL:ORBit2-2.14.10.tar.bz2:ORBit2
denis:BADURL:pam_keyring-0.0.9.tar.gz:pam_keyring
rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11
orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script
adalloz:BADURL:pan-0.132.tar.bz2:pan
orion:BADURL:paraview-3.0.2.tar.gz:paraview
ovasik:BADURL:passivetex-1.25.zip:passivetex
stahnma:BADSOURCE:pastebin.tar.gz:pastebin
jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2
leo:BADURL:pcmanx-gtk2.tar.gz:pcmanx-gtk2
rrelyea:BADSOURCE:pcsc-lite-1.3.3.tar.gz:pcsc-lite
maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube
jpo:BADURL:AppConfig-1.65.tar.gz:perl-AppConfig
spot:BADURL:Class-Data-Inheritable-0.06.tar.gz:perl-Class-Data-Inheritable
spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship
spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg
jpo:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles
sindrepb:BADURL:DBIx-SQLite-Simple-0.34.tar.gz:perl-DBIx-SQLite-Simple
jpo:BADURL:Email-Simple-1.999.tar.gz:perl-Email-Simple
steve:BADURL:eperl_2.2.14-13.diff.gz:perl-eperl
iburrell:BADURL:File-chdir-0.06.tar.gz:perl-File-chdir
spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree
spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body
spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI
wtogami:BADURL:IO-Socket-SSL-1.02.tar.gz:perl-IO-Socket-SSL
jpo:BADSOURCE:Log-Log4perl-1.12.tar.gz:perl-Log-Log4perl
jpo:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record
ixs:BADURL:MD5-2.03.tar.gz:perl-MD5
rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP
rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP
iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class
cweyl:BADURL:POE-0.9989.tar.gz:perl-POE
cweyl:BADURL:POE-Filter-Zlib-1.8.tar.gz:perl-POE-Filter-Zlib
jpo:BADURL:SNMP_Session-1.08.tar.gz:perl-SNMP_Session
mmcgrath:BADURL:SOAP-Lite-0.68.tar.gz:perl-SOAP-Lite
jpo:BADURL:Test-Exception-0.21.tar.gz:perl-Test-Exception
jpo:BADURL:Test-File-1.16.tar.gz:perl-Test-File
jpo:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa
cweyl:BADURL:WWW-Myspace-0.60.tar.gz:perl-WWW-Myspace
rnorwood:BADURL:XML-Grove-0.46alpha.tar.bz2:perl-XML-Grove
splinux:BADURL:pessulus-2.16.2.tar.bz2:pessulus
dwmw2:BADSOURCE:petitboot-0.0.1.tar.gz:petitboot
dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot
ghenry:BADURL:pgadmin3-1.6.3.tar.gz:pgadmin3
mdomsch:BADSOURCE:signing-party_0.4.12.orig.tar.gz:pgp-tools
robert:BADSOURCE:magickwand-0.1.8.tar.gz:php-magickwand
timj:BADSOURCE:php_manual_en.tar.gz:php-manual-en
mmcgrath:BADURL:phpMyAdmin-2.11.0-all-languages.tar.bz2:phpMyAdmin
xulchris:BADSOURCE:PHPUnit2-2.3.6.tgz:php-pear-PHPUnit2
devrim:BADSOURCE:phpPgAdmin-4.1.3.tar.bz2:phpPgAdmin
jcollie:BADURL:pitivi-0.10.3.tar.bz2:pitivi
gemi:BADSOURCE:pl-5.6.35.tar.gz:pl
gemi:BADSOURCE:HTMLmanual.tar.gz:pl
gemi:BADSOURCE:userguide.html.tgz:pl
dcbw:BADURL:plague-0.4.4.1.tar.bz2:plague
twaugh:BADURL:ppa-0.8.6.tar.gz:pnm2ppa
athimm:BADSOURCE:po4a-0.32.tar.gz:po4a
dwalsh:BADURL:policycoreutils-2.0.31.tgz:policycoreutils
dwalsh:BADSOURCE:sepolgen-1.0.10.tgz:policycoreutils
tgl:BADURL:postgresql-8.2.1-US.pdf:postgresql
tgl:BADSOURCE:pgtcl1.6.0.tar.gz:postgresql
tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql
tgl:BADURL:psqlodbc-08.02.0200.tar.gz:postgresql-odbc
devrim:BADSOURCE:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin
jwilson:BADURL:powerman-1.0.25.tar.bz2:powerman
thias:BADSOURCE:powermanga-0.90.tgz:powermanga
dcantrel:BADURL:ps3pf_utils-1.0.9.tar.bz2:ppc64-utils
jakub:BADURL:prelink-20071009.tar.bz2:prelink
tscherf:BADURL:prelude-lml-0.9.8.1.tar.gz:prelude-lml
tscherf:BADURL:prelude-manager-0.9.7.1.tar.gz:prelude-manager
tscherf:BADURL:prewikka-0.9.10.tar.gz:prewikka
karsten:BADURL:privoxy-3.0.6-stable-src.tar.gz:privoxy
smccann:BAD_CVS_SOURCE:proj.copyright:proj
varekova:BADURL:acct-6.3.2.tar.gz:psacct
scop:BADURL:pscan.tar.gz:pscan
scop:BADURL:pscan_1.2-5.diff.gz:pscan
tsmetana:BADURL:psmisc-22.5.tar.gz:psmisc
bpepple:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago
veillard:BADURL:pwlib-1.10.10.tar.gz:pwlib
misa:BADURL:pyOpenSSL-0.6.tar.gz:pyOpenSSL
than:BADURL:PyQt-x11-gpl-3.17.1.tar.gz:PyQt
rdieter:BADURL:PyQt-x11-gpl-4.2.tar.gz:PyQt4
rdieter:BADURL:PyQt-x11-gpl-3.17.1.tar.gz:PyQt-qscintilla
zmc:BADSOURCE:pyspi-0.6.1.tar.gz:pyspi
xulchris:BADURL:fpconst-0.7.3.tar.gz:python-fpconst
jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen
icon:BADURL:kid-0.9.6.tar.gz:python-kid
mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV
lmacken:BADURL:Myghty-1.1.tar.gz:python-myghty
thias:BADSOURCE:Nevow-0.9.18.tar.gz:python-nevow
shahms:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols
lmacken:BADURL:RuleDispatch-0.5a0.dev-r2306.tar.gz:python-ruledispatch
lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears
silfreed:BADURL:qgis-0.9.0.tar.gz:qgis
aconway:BADSOURCE:qpidc-0.2.tar.gz:qpidc
frankb:BADSOURCE:qsa-x11-opensource-1.2.2.tar.gz:qt4-qsa
belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa
bjohnson:BADSOURCE:queuegraph.tar.gz:queuegraph
steved:BADURL:quota-3.14.tar.gz:quota
jcollie:BADURL:radiusclient-ng-0.5.6.tar.gz:radiusclient-ng
timj:BADURL:rapidsvn-0.9.4.tar.gz:rapidsvn
mbarnes:BADURL:rarian-0.6.0.tar.bz2:rarian
pgordon:BADURL:libtorrent-0.12.tar.gz:rb_libtorrent
jmoskovc:BADURL:rdate-1.4.tar.gz:rdate
jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist
pingou:BADURL:DynDoc_1.14.0.tar.gz:R-DynDoc
mlichvar:BADURL:readline-5.2.tar.gz:readline
llim:BAD_CVS_SOURCE:lsb-release-2.0.tar.gz:redhat-lsb
icon:BADURL:repoview-0.6.1.tar.gz:repoview
jsteffan:BADURL:revisor-2.0.4.3.tar.gz:revisor
tgl:BADURL:pg_filedump-8.2.0.tar:rhdb-utils
aconway:BADURL:rhm-0.1.tar.gz:rhm
clumens:BADURL:rhpxl-0.49.tar.gz:rhpxl
hadess:BADURL:rhythmbox-0.11.2.tar.bz2:rhythmbox
peter:BADSOURCE:rlog-1.3.7.tgz:rlog
stingray:BADURL:roundup-1.3.3.tar.gz:roundup
timj:BADURL:rpl_1.5.3.tar.gz:rpl
than:BADURL:rp-pppoe-3.8.tar.gz:rp-pppoe
atkac:BADURL:rexec-1.5.tar.gz:rsh
liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak
thl:BADSOURCE:CHANGELOG:rss2email
simo:BADURL:rsync-3.0.0pre2.tar.gz:rsync
pvrabec:BADURL:rsyslog-1.19.6.tar.gz:rsyslog
tagoh:BADURL:ruby-1.8.6-p110.tar.bz2:ruby
tagoh:BADURL:ruby-refm-rdp-1.8.1-ja-html.tar.gz:ruby
lutter:BADSOURCE:activesupport-1.4.0.tgz:ruby-activesupport
mtasaka:BADURL:ruby-bsearch-1.5.tar.gz:ruby-bsearch
jcollie:BADURL:schroedinger-0.6.1.tar.gz:schroedinger
petersen:BADSOURCE:scim-1.4.7.tar.gz:scim
tagoh:BADURL:scim-anthy-1.2.4.tar.gz:scim-anthy
dchen:BADSOURCE:scim-array-0.0.2.tar.gz:scim-array
pnemade:BADURL:scim-sinhala-trans-0.2.0-20060825.tar.gz:scim-sinhala
ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk
dwalsh:BADSOURCE:selinux-doc-1.26.tgz:selinux-doc
pknirsch:BADURL:sg3_utils-1.23.tgz:sg3_utils
pvrabec:BADURL:shadow-4.0.18.1.tar.bz2:shadow-utils
smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib
than:BADURL:sip-4.6.tar.gz:sip
gemi:BADURL:skencil-0.6.tar.gz:skencil
afb:BADURL:slim-1.3.0.tar.gz:slim
mgarski:BADURL:smb4k-0.8.5.tar.bz2:smb4k
ecik:BADURL:sonata-1.2.3.tar.bz2:sonata
rdieter:BADURL:soprano-1.95.0-beta2.tar.bz2:soprano
denis:BADURL:soundconverter-0.9.7.tar.gz:soundconverter
jwb:BADSOURCE:blacklists.tar.gz:squidGuard
s4504kr:BADURL:stellarium_user_guide-0.9.0-1.pdf:stellarium
s4504kr:BADURL:suck-4.3.2.tar.gz:suck
jwrdegoede:BADURL:supertuxkart-0.3-src.tar.bz2:supertuxkart
gemi:BADURL:sweep-0.9.2.tar.bz2:sweep
pjones:BADURL:syslinux-3.36.tar.bz2:syslinux
mbarabas:BADSOURCE:system-config-vsftpd-0.4.5.tar.gz:system-config-vsftpd
fche:BADURL:systemtap-0.5.14.tar.gz:systemtap
errr:BADSOURCE:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg
mlichvar:BADURL:ncurses-5.5.tar.gz:termcap
mlichvar:BADURL:patch-5.5-20060625.sh.gz:termcap
mlichvar:BADURL:ncurses-5.5-20060701.patch.gz:termcap
jnovy:BADURL:tetex-src-3.0.tar.bz2:tetex
jnovy:BADURL:tetex-texmf-3.0.tar.bz2:tetex
jnovy:BADURL:ptex-src-3.1.9.tar.bz2:tetex
jnovy:BADURL:ptex-texmf-2.4.tar.bz2:tetex
jnovy:BADURL:platex209.tar.bz2:tetex
jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:tetex
jnovy:BADURL:mendexk2.6d.tar.bz2:tetex
dionysos:BADURL:eurofont.tar.gz:tetex-eurofont
pertusus:BADURL:tex4ht-1.0.2007_09_04_0340.tar.gz:tetex-tex4ht
thias:BADSOURCE:thttpd-2.25b.tar.gz:thttpd
rstrode:BADURL:tomboy-0.8.1.tar.bz2:tomboy
mbacovsk:BADURL:traceroute-2.0.9.tar.gz:traceroute
awjb:BADURL:treecc-0.3.8.tar.gz:treecc
davidz:BADURL:tsclient-0.150.tar.gz:tsclient
tagoh:BADURL:uim-1.4.1.tar.bz2:uim
varekova:BADURL:unzip552.tar.gz:unzip
kzak:BADURL:util-linux-2.13-pre7.tar.bz2:util-linux
rdieter:BADURL:imap-2006k.DEV.SNAP-0709171900.tar.Z:uw-imap
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/f18ac654/attachment.sig>

From jkeating at redhat.com  Fri Oct 19 20:02:22 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 16:02:22 -0400
Subject: source file audit - 2007-10-17
In-Reply-To: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
Message-ID: <20071019160222.4a7fc9b0@redhat.com>

On Fri, 19 Oct 2007 14:01:26 -0600
Kevin Fenzi <kevin at scrye.com> wrote:

> - Should I try and spam maintainers? Or just keep posting in the list?

You should get with Will Woods and use the python-bugzilla.py tool to
file bugs for these, potentially blocking a tracker bug.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/4342cadf/attachment.sig>

From mattdm at mattdm.org  Fri Oct 19 20:10:30 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 19 Oct 2007 16:10:30 -0400
Subject: festival src urls [was Re: source file audit - 2007-10-17]
In-Reply-To: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
Message-ID: <20071019201030.GA7091@jadzia.bu.edu>

On Fri, Oct 19, 2007 at 02:01:26PM -0600, Kevin Fenzi wrote:
> davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival
> davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival
> davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival
> davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival
> davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival
> davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival

As noted in the comment in the spec file, the web site didn't provide a
direct-download link for the voices -- it all went through a script. So
there was no canonical URL. At my request, the upstream people fixed this
for future releases of the voices, which are included in my in-progress
(haven't worked on it in a while, though) next update to the package, which
you can find info about at
<https://bugzilla.redhat.com/show_bug.cgi?id=235051>.

(I e-mailed David a while ago about becoming a co-maintainer; got no
response.)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From louisg00 at bellsouth.net  Fri Oct 19 21:04:54 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Fri, 19 Oct 2007 17:04:54 -0400
Subject: Anything being done for the irqbalence daemon?
Message-ID: <1192827894.2466.2.camel@tiger>

the irqbalence deamon keeps dying right after starting. Is there a
bugzilla for this? Should be a blocker in my opinion.

-Louis





From johannbg at hi.is  Fri Oct 19 21:12:16 2007
From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=)
Date: Fri, 19 Oct 2007 21:12:16 -0000 (GMT)
Subject: Hum.. Fedora....
Message-ID: <14194.88.149.97.225.1192828336.squirrel@webmail.hi.is>

Has legal taken a look at this..

http://www.linux.com/feature/119608

http://www.fedora.info/

http://www.fedora-commons.org/

Best regards.
          Johann B.



From selinux at gmail.com  Fri Oct 19 21:13:10 2007
From: selinux at gmail.com (Tom London)
Date: Fri, 19 Oct 2007 14:13:10 -0700
Subject: Anything being done for the irqbalence daemon?
In-Reply-To: <1192827894.2466.2.camel@tiger>
References: <1192827894.2466.2.camel@tiger>
Message-ID: <4c4ba1530710191413k4f4b6154j433b971dfc91ed7d@mail.gmail.com>

On 10/19/07, Louis E Garcia II <louisg00 at bellsouth.net> wrote:
> the irqbalence deamon keeps dying right after starting. Is there a
> bugzilla for this? Should be a blocker in my opinion.
>
> -Louis

I filed this a bit ago here: https://bugzilla.redhat.com/show_bug.cgi?id=321491

Per comment 3, this has been closed as NOTABUG:

Oh, I see the issue.  This is actually working as designed.  You're system has
two cores, but they share a cache.  As such, its beneficial to distribute the
irq workload accrosss the cores, but its not beneficial to migrate the irqs
periodically since they the likelyhood of cacheline misses is independent of
which core services the irq.  As such irqbalance enters a one_shot_mode where it
balances the irqs once, then exits.

I added a comment about figuring out how to sort circuit the FAILED
message on shutdown.

Does that describe your system?

tom
-- 
Tom London



From duffy at redhat.com  Fri Oct 19 21:18:49 2007
From: duffy at redhat.com (=?ISO-8859-1?Q?M=E1ir=EDn_Duffy?=)
Date: Fri, 19 Oct 2007 17:18:49 -0400
Subject: Hum.. Fedora....
In-Reply-To: <14194.88.149.97.225.1192828336.squirrel@webmail.hi.is>
References: <14194.88.149.97.225.1192828336.squirrel@webmail.hi.is>
Message-ID: <47191F39.5040504@redhat.com>

J?hann B. Gu?mundsson wrote:
> Has legal taken a look at this..
> 
> http://www.linux.com/feature/119608
> 
> http://www.fedora.info/
> 
> http://www.fedora-commons.org/

dejavu (not the font, haha)? Didn't we just have a thread about this?

~m



From ricky at fedoraproject.org  Fri Oct 19 21:18:54 2007
From: ricky at fedoraproject.org (Ricky Zhou)
Date: Fri, 19 Oct 2007 17:18:54 -0400
Subject: Hum.. Fedora....
In-Reply-To: <14194.88.149.97.225.1192828336.squirrel@webmail.hi.is>
References: <14194.88.149.97.225.1192828336.squirrel@webmail.hi.is>
Message-ID: <20071019211854.GB944@Max.example.com>

On Fri, Oct 19, 2007 at 09:12:16PM -0000, J?hann B. Gu?mundsson wrote:
> Has legal taken a look at this..
> 
> http://www.linux.com/feature/119608
> 
> http://www.fedora.info/
> 
> http://www.fedora-commons.org/
This was actually brought up on the fedora-marketing-list list
yesterday/today.  See this thread:
https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00245.html

Thanks,
Ricky
-------------- 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/20071019/a048cd29/attachment.sig>

From ml at deadbabylon.de  Fri Oct 19 21:41:36 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Fri, 19 Oct 2007 23:41:36 +0200
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
Message-ID: <200710192341.37182.ml@deadbabylon.de>

Am Mi 17.Oktober 2007 schrieb Jarod Wilson:
> Author: jwilson
>
> Update of /cvs/pkgs/rpms/beryl-manager/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8532
>
> Added Files:
> 	dead.package
> Removed Files:
> 	Makefile beryl-manager-0.1.4-pidof.patch beryl-manager.spec
> 	sources
> Log Message:
> Mark beryl bits as dead, since its merged back with current compiz

Is it? As far as I know the former beryl-manager and beryl-settings are not in 
compiz-0.6. And so compiz(-fusion) is only really usuable in Gnome, not in 
KDE.

# rpm -qlp compiz-kde-0.6.0-2.fc8.i386.rpm
/usr/bin/kde-window-decorator


Please correct me if I'm wrong here.


Sebastian
-------------- 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/20071019/990aee31/attachment.sig>

From chris.stone at gmail.com  Fri Oct 19 22:02:16 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Fri, 19 Oct 2007 15:02:16 -0700
Subject: Multiarch conflicts on devel packages with %doc files
Message-ID: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>

I am getting a multiarch conflict on %doc files in a devel
subpackage[1].  Are we supposed to avoid %doc files in devel packages
for multiarch purposes, or am I doing something wrong in my spec, or
is this a multiarch rpm bug?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=340771



From sandeen at redhat.com  Fri Oct 19 22:07:57 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 19 Oct 2007 17:07:57 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
Message-ID: <47192ABD.6090108@redhat.com>

Christopher Stone wrote:
> I am getting a multiarch conflict on %doc files in a devel
> subpackage[1].  Are we supposed to avoid %doc files in devel packages
> for multiarch purposes, or am I doing something wrong in my spec, or
> is this a multiarch rpm bug?
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
> 

What differs between the files on the 2 arches?  Any chance there are
timestamps?  Oh, yeah:

      "Generated at Wed Jan 31 13:22:54 2007 by ..."

you might want to supress that or filter it out; it'll cause the files
to have different checksums.

-Eric



From chris.stone at gmail.com  Fri Oct 19 22:15:02 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Fri, 19 Oct 2007 15:15:02 -0700
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <47192ABD.6090108@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
Message-ID: <d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>

On 10/19/07, Eric Sandeen <sandeen at redhat.com> wrote:
> Christopher Stone wrote:
> > I am getting a multiarch conflict on %doc files in a devel
> > subpackage[1].  Are we supposed to avoid %doc files in devel packages
> > for multiarch purposes, or am I doing something wrong in my spec, or
> > is this a multiarch rpm bug?
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
> >
>
> What differs between the files on the 2 arches?  Any chance there are
> timestamps?  Oh, yeah:
>
>       "Generated at Wed Jan 31 13:22:54 2007 by ..."
>
> you might want to supress that or filter it out; it'll cause the files
> to have different checksums.

oh shoot, this sucks.  okay ill see what I can do.  Thanks for
figuring that out for me.



From sandeen at redhat.com  Fri Oct 19 22:18:15 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 19 Oct 2007 17:18:15 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
Message-ID: <47192D27.4070700@redhat.com>

Christopher Stone wrote:
> On 10/19/07, Eric Sandeen <sandeen at redhat.com> wrote:
>> Christopher Stone wrote:
>>> I am getting a multiarch conflict on %doc files in a devel
>>> subpackage[1].  Are we supposed to avoid %doc files in devel packages
>>> for multiarch purposes, or am I doing something wrong in my spec, or
>>> is this a multiarch rpm bug?
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
>>>
>> What differs between the files on the 2 arches?  Any chance there are
>> timestamps?  Oh, yeah:
>>
>>       "Generated at Wed Jan 31 13:22:54 2007 by ..."
>>
>> you might want to supress that or filter it out; it'll cause the files
>> to have different checksums.
> 
> oh shoot, this sucks.  okay ill see what I can do.  Thanks for
> figuring that out for me.

You could probably just add a patch to modify the shipped
docs/api_footer.html file to remove the timestamp?

-Eric



From ml at deadbabylon.de  Fri Oct 19 22:48:19 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Sat, 20 Oct 2007 00:48:19 +0200
Subject: KDE-SIG weekly report (42/2007)
Message-ID: <200710200048.19929.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the topics 
that were discussed.
If you want to add a comment please reply to this email or add it to the 
related meeting page.

----------------------------------------------------------

= Weekly KDE Summary =

Week: 42/2007

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-16

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-16?action=AttachFile&do=get&target=fedora-kde-sig-2007-10-16.txt

= Participants =

RexDieter 
ThanNgo 
KevinKofler 
SebastianVahl 
RobertScheck

= Agenda = 

* KDE 3.5.8 
* KDE 4 status/update 
* /usr/share/dbus-1/interfaces ownership (#334681) [1]
* Web Release Notes (did we missed something important?) 
* How to get more people involved in KDE-Sig? (Rediscuss meeting from 
2007-09-25) ?[2]
* Should we send weekly reports to fedora-devel-ml and/or Fedora Weekly News?

= Summary = 

o KDE 3.5.8: 
- All packages are built for rawhide (kde-i18n is building right now) 
- KDE 3.5.8 will get into F8 
- Updates for F-7 and FC-6 should be ready in the next week 
- Some file lists overlaps introduced by splitting the packages into libs and 
extras sub-packages will be adressed by RexDieter after the meeting 

o KDE 4 status/update: 
- KevinKofler is committing soprano-1.95.0 for F-9 only 
- F8 is branched for KDE4-related stuff 
- KDE 3.94 (KDE4Beta3) will go into devel/F-9 
- /usr/share/dbus-1/interfaces ownership: 
- KDE4 seems to be the only application that uses this directory 
- the easiest solution for the moment is to have soprano 
own /usr/share/dbus-1/interfaces 

o Release notes: 
- The following things should be mentioned: 
? - KDE 3.5.8 (instead of KDE 3.5.7) 
? - kdepim-enterprise as a replacement of normal (but broken) kdepim 
? - knetworkmanager is replaced by nm-applet as a workaround because it not 
building against newest NetworkManager 

o How to get more people involved in KDE-Sig? 
- The actual list of 16 "participants" is not really matching the few 
active "developers" 
- The solution for this may be: 
? - Write to the listed participants and ask for more active involvement 
? - ask for help on fedora-devel-ml and announce that we are going to cull 
down the list 
? - cull down the list to the known-as-active contributors after one or two 
week. Leave the willing to help participants from the old list. 
- Some more things should be mentioned in the wiki before writing the 
announcement (i.e. bug hunters) 

o Should we send weekly reports to fedora-devel-ml and/or Fedora Weekly News? 
- SebastianVahl will sent weekly reports after the meetings to the 
fedora-devel-mailinglist 

o Open discussion: 
- The NetworkManager hack is only included on the live images, not the DVD 
- knetworkmanager is still not building against NetworkManager 
- knetworkmanager should maybe requested for removal from F8 until it works 
again 
- krusader was removed from the livecd again to free some space for nm-applet 
- It maybe could be re-added if the accident that perl is depending on 
db4-devel is fixed


= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=334681
[2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-09-25
-------------- 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/20071020/c941491f/attachment.sig>

From jspaleta at gmail.com  Fri Oct 19 23:10:34 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 19 Oct 2007 15:10:34 -0800
Subject: source file audit - 2007-10-17
In-Reply-To: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
Message-ID: <604aa7910710191610x6605b298u96a29de50bcc993b@mail.gmail.com>

On 10/19/07, Kevin Fenzi <kevin at scrye.com> wrote:
> - BADURL:base-file-name:$PACKAGENAME
>
> This means that the URI provided in the Source(s) line didn't result in
> a download of the source. This could be any of: URL changed, version
> changed and URL wasn't updated, Site is down, Site is gone, etc.
> Also there are a number of packages with incorrect sourceforge links.
> (BTW, there are still some packages with ftp://people.redhat.com/
> URLs).

jspaleta:BADURL:gpodder-0.10.0.tar.gz:gpodder


Explain to how you are checking for the url to download.

wgetting the URL in the spec generated by spectool locally on my
system works just fine.

both using the URL generated by spectool run  against the specfile in
the cvs co out of gpodder/devel and a run of spectool run against the
specfile contained in the srpm I download with yumdownloader
--enablerepo=development --source gpodder

Istanbul source url was broken, and i've updated the spec in cvs.  I'm
happy to see this script run...but is there a way to perhaps lower the
chance of a false positive before we start having these sort of checks
spawn automatic bug tickets. If the download sources script can't
reach a host for some reason that I can't reproduce locally, I don't
want to have the same bug filed automatically over and over again.

-jef



From kevin at scrye.com  Fri Oct 19 23:40:59 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Fri, 19 Oct 2007 17:40:59 -0600
Subject: source file audit - 2007-10-17
In-Reply-To: <604aa7910710191610x6605b298u96a29de50bcc993b@mail.gmail.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
	<604aa7910710191610x6605b298u96a29de50bcc993b@mail.gmail.com>
Message-ID: <20071019174059.541ddd78@ghistelwchlohm.scrye.com>

On Fri, 19 Oct 2007 15:10:34 -0800
jspaleta at gmail.com ("Jeff Spaleta") wrote:

> On 10/19/07, Kevin Fenzi <kevin at scrye.com> wrote:
> > - BADURL:base-file-name:$PACKAGENAME
> >
> > This means that the URI provided in the Source(s) line didn't
> > result in a download of the source. This could be any of: URL
> > changed, version changed and URL wasn't updated, Site is down, Site
> > is gone, etc. Also there are a number of packages with incorrect
> > sourceforge links. (BTW, there are still some packages with
> > ftp://people.redhat.com/ URLs).
> 
> jspaleta:BADURL:gpodder-0.10.0.tar.gz:gpodder
> 
> 
> Explain to how you are checking for the url to download.

It's using 'spectool -g' on the spec. 
> 
> wgetting the URL in the spec generated by spectool locally on my
> system works just fine.
> 
> both using the URL generated by spectool run  against the specfile in
> the cvs co out of gpodder/devel and a run of spectool run against the
> specfile contained in the srpm I download with yumdownloader
> --enablerepo=development --source gpodder

Alas, it was berlios again being broken. ;( 

--00:46:22--  http://download.berlios.de/gpodder/gpodder-0.10.0.tar.gz
           => `./gpodder-0.10.0.tar.gz'
Resolving download.berlios.de... 195.37.77.141
Connecting to download.berlios.de|195.37.77.141|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location:
http://download.berlios.de/error/HTTP_SERVICE_UNAVAILABLE.html.var
[following] --00:46:23--
http://download.berlios.de/error/HTTP_SERVICE_UNAVAILABLE.html.var =>
`./HTTP_SERVICE_UNAVAILABLE.html.var' Reusing existing connection to
download.berlios.de:80. HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html] Last-modified header missing --
time-stamps turned off. --00:46:26--
http://download.berlios.de/error/HTTP_SERVICE_UNAVAILABLE.html.var =>
`./HTTP_SERVICE_UNAVAILABLE.html.var' Connecting to
download.berlios.de|195.37.77.141|:80... connected. HTTP request sent,
awaiting response... 200 OK Length: unspecified [text/html]

    0K .                                                        23.92
MB/s

00:46:26 (23.92 MB/s) - `./HTTP_SERVICE_UNAVAILABLE.html.var' saved
[1058]

I thought I had a check for this, but I guess it didn't work right. 

> Istanbul source url was broken, and i've updated the spec in cvs.  I'm
> happy to see this script run...but is there a way to perhaps lower the
> chance of a false positive before we start having these sort of checks
> spawn automatic bug tickets.

I quite agree... thats one reason I haven't started doing auto filing
or mailing people yet. 

>  If the download sources script can't
> reach a host for some reason that I can't reproduce locally, I don't
> want to have the same bug filed automatically over and over again.

Sure. It's sad, berlios is looking less reliable for downloads than
sourceforge used to be. :( 

I will try and fix my script to detect this better...

> -jef
> 

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

From jkeating at redhat.com  Sat Oct 20 02:58:36 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 22:58:36 -0400
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <47192D27.4070700@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com>
Message-ID: <20071019225836.18a17d23@redhat.com>

On Fri, 19 Oct 2007 17:18:15 -0500
Eric Sandeen <sandeen at redhat.com> wrote:

> You could probably just add a patch to modify the shipped
> docs/api_footer.html file to remove the timestamp?

Are these docs generated at build time?  If so the timestamps will
still differ and conflict.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/0d122b26/attachment.sig>

From rc040203 at freenet.de  Sat Oct 20 03:07:23 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 20 Oct 2007 05:07:23 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071019225836.18a17d23@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com>  <20071019225836.18a17d23@redhat.com>
Message-ID: <1192849643.25729.11.camel@mccallum.corsepiu.local>

On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
> On Fri, 19 Oct 2007 17:18:15 -0500
> Eric Sandeen <sandeen at redhat.com> wrote:
> 
> > You could probably just add a patch to modify the shipped
> > docs/api_footer.html file to remove the timestamp?
> 
> Are these docs generated at build time?  If so the timestamps will
> still differ and conflict.

Does rpm complain about differing timestamps on files, while the
contents is identical?

I thought rpm would only complain if "contents" differs.

Ralf




From jkeating at redhat.com  Sat Oct 20 03:12:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 23:12:38 -0400
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192849643.25729.11.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
Message-ID: <20071019231238.4b6bca23@redhat.com>

On Sat, 20 Oct 2007 05:07:23 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> Does rpm complain about differing timestamps on files, while the
> contents is identical?
> 
> I thought rpm would only complain if "contents" differs.

You might be right there.  I honestly don't have evidence in front of
me one way or the other.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/bf7c3b63/attachment.sig>

From jkeating at redhat.com  Sat Oct 20 03:13:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 19 Oct 2007 23:13:26 -0400
Subject: Mass Branching for F-8 (round 2)
Message-ID: <20071019231326.607bf89d@redhat.com>

We're ready to try the branching again.  CVS will be disabled for
commits in a few moments.  I will reply when the branching is done.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071019/c687123d/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From Matt_Domsch at dell.com  Sat Oct 20 03:54:18 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 19 Oct 2007 22:54:18 -0500
Subject: Fedora x86_64 rawhide rebuild in mock status 2007-10-19
Message-ID: <20071019225418.A28857@humbolt.us.dell.com>

Fedora Rawhide-in-Mock Build Results for x86_64 Fri Oct 19 22:11:58 CDT 2007

Huge thanks to Spot for fixing ~150 perl packages this week.  Note
these were also built using Michael Brown's prerelease of mock 0.8 but
I didn't note any failures that can be attributed to mock.  If you
think you see one, please let the fedora-buildsys-list know.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 4840
Number failed to build: 234
Number expected to fail due to ExclusiveArch or ExcludeArch: 35
Leaving:  199
(there may be some duplicates if rawhide has 2 versions of a package)

Of those expected to have worked...
Without a bug filed: 199
----------------------------------
airsnort-0.2.7e-11.fc7 (build/make) awjb
alacarte-0.11.3-4.fc8 (build/make) rstrode,jpmahowa,sindrepb
amsn-0.96-7.fc7 (build/make) tjikkun
apt-0.5.15lorg3.93-2.fc8 (build/make) athimm,pmatilai
avr-binutils-2.17-4.fc8 (build/make) jwrdegoede
awesfx-0.5.0d-4.fc7 (build/make) stransky
blitz-0.9-3.fc8 (build/make) sergiopr
callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2
camstream-0.26.3-12.fc8 (open_missing_mode) nomis80
castor-0.9.5-1jpp.7 (build/make) pcheung
checkstyle-4.1-4jpp.1.fc7 (build/make) nsantos,dbhole
chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig
clips-6.24-22.fc7 (build/make) rvinyard
compat-erlang-R10B-10.7.fc7 (build/make) gemi
compat-gcc-32-3.2.3-62 (build/make) jakub
compat-gcc-34-3.4.6-8 (build/make) jakub
conexus-0.5.3-2.fc8 (build/make) rvinyard
cryptix-3.2.0-9jpp.1 (build/make) mwringe
cryptix-asn1-20011119-7jpp.2 (build/make) vivekl
d4x-2.5.7.1-3.fc7 (build/make) thias
dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus
eclipse-emf-2.2.2-1.fc7 (build/make) overholt
eiciel-0.9.4-1.fc7 (build/make) cweyl
em8300-kmod-0.16.3-5.2.6.23_0.220.rc9.git2.fc8 (build/make) scop
emelfm2-0.3.5-2.fc8 (build/make) cwickert
fluxstyle-1.0.1-2.fc7 (build/make) errr
fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig
freetennis-0.4.8-6.fc7 (build/make) rjones
gajim-0.11.1-1.fc7 (build/make) gajownik
gdb-6.6-34.fc8 (build/make) jkratoch
gdmap-0.7.5-6.fc6 (build/make) splinux
gedit-plugins-2.18.0-2.fc7 (build/make) trondd
genius-0.7.7-2.fc7 (build/make) gemi
gfa-0.4.1-4.fc7 (build/make) splinux
glipper-0.95.1-2.fc7 (build/make) splinux
gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak
gnome-specimen-0.3-1.fc8 (build/make) splinux
gnomescan-0.4.0.2-1.fc7 (build/make) deji
grub-0.97-19 (build/make) pjones
gstm-1.2-6.fc7 (build/make) splinux
gtk-sharp-1.0.10-12.fc7 (build/make) pfj
gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog
gtranslator-1.1.7-3.fc8 (build/make) sindrepb,roozbeh
htop-0.6.5-1.fc7 (build/make) gajownik
inkscape-0.45.1-1.fc7 (needs_popt-devel) denis
jgroups-2.2.9.2-3jpp.2 (build/make) vivekl
jogl-1.0.0-5.7.beta5.fc6 (build/make) green
kbibtex-0.1.5.52-10.fc7 (build/make) noltec
kdissert-1.0.7-1.fc7 (build/make) icon
kgtk-0.8-2.fc7 (build/make) faucamp
knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil,mmcgrath,liquidat
kvm-36-7.fc8 (build/make) katzj,berrange
ladspa-1.12-8.fc7 (build/make) thomasvs
ldapjdk-4.17-1jpp.7 (build/make) vivekl
libprelude-0.9.13-1.fc7 (build/make) tscherf
libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf
liferea-1.2.23-1.fc8 (build/make) bpepple
lilypond-doc-2.10.13-1.fc7 (build/make) qspencer
ltrace-0.5-9.45svn.fc8 (build/make) pmachata
maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe
mbuffer-20070502-1.fc7 (open_missing_mode) adalloz
memtest86+-1.70-2.fc8.src.rpm  
memtest86+-1.70-3.fc8 (build/make) wtogami
mikmod-3.2.2-2.fc7 (build/make) jnovy
moto4lin-0.3-6.fc7 (build/make) jafo
muine-0.8.7-3.fc7 (build/make) sindrepb
mx4j-3.0.1-6jpp.4 (build/make) fnasser
nagios-2.9-3.fc8 (build/make) mmcgrath,wtogami
nant-0.85-12.fc7 (build/make) pfj
nemiver-0.4.0-1.fc8 (build/make) pgordon
nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb
ntfs-config-1.0-0.5.rc5.fc8 (build/make) laxathom
openais-0.80.1-6 (open_missing_mode) sdake,sdake
orpie-1.4.3-5.fc6 (build/make) xris
pam_abl-0.2.3-3.fc7 (build/make) adalloz
pari-2.3.0-5.fc7 (build/make) gemi
pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo
perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,perl-sig,ghenry
perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig
perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig
perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,perl-sig
perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,perl-sig
perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig
perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig
perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig
perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,perl-sig
perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,perl-sig
perl-DateTime-Set-0.25-4.fc7 (build/make) steve,perl-sig
perl-Devel-Caller-0.11-1.fc7 (build/make) steve,perl-sig
perl-Exception-Class-1.23-3.fc7 (build/make) steve,perl-sig
perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,perl-sig,laxathom
perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,perl-sig
perl-File-Type-0.22-4.fc7 (build/make) steve,perl-sig
perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl,perl-sig
perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl,perl-sig
perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,perl-sig
perl-IO-All-0.38-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-0.39-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,perl-sig
perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig
perl-Log-Message-0.01-3.fc7 (build/make) steve,perl-sig
perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,perl-sig
perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig
perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig
perl-Module-Install-0.67-1.fc8 (build/make) steve,perl-sig
perl-Module-Loaded-0.01-3.fc7 (build/make) steve,perl-sig
perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,perl-sig
perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig
perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,perl-sig
perl-Object-Accessor-0.32-2.fc7 (build/make) steve,perl-sig
perl-OpenFrame-3.05-6.fc7 (build/make) steve,perl-sig
perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,perl-sig
perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig
perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig
perl-PPI-Tester-0.06-2.fc6 (build/make) jpo,perl-sig
perl-Package-Constants-0.01-3.fc7 (build/make) steve,perl-sig
perl-Params-Check-0.26-1.fc7 (build/make) steve,perl-sig
perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,perl-sig
perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig
perl-Pipeline-3.12-4.fc7 (build/make) steve,perl-sig
perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig
perl-SUPER-1.16-1.fc7 (build/make) cweyl,perl-sig
perl-Set-Infinite-0.61-3.fc7 (build/make) steve,perl-sig
perl-Spiffy-0.30-7.fc7 (build/make) steve,perl-sig
perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters
perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig
perl-Test-Expect-0.30-1.fc6 (build/make) jpo,perl-sig
perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,perl-sig
perl-Tk-804.027-12.fc8 (build/make) awjb,perl-sig
perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo,perl-sig
perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig
perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig
perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig
perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver
pexpect-2.1-5.fc8 (build/make) robert
pikloops-0.2.5-1.fc8 (build/make) dionysos
pinot-0.76-2.fc8 (build/make) drago01
polyxmass-bin-0.9.3-2.fc6 (build/make) awjb
prelink-0.4.0-1 (build/make) jakub
prewikka-0.9.8-1.fc7 (build/make) tscherf
python-boto-0.9b-1.fc8 (build/make) robert
python-docs-2.5.1-1.fc8 (build/make) james,katzj
python-psyco-1.5.1-5.fc7 (build/make) shahms
python-reportlab-2.1-1.fc8 (build/make) bpepple
python-tag-0.91-5 (build/make) thias
python-urljr-1.0.1-1.fc7 (build/make) jcollie
qa-assistant-0.4.90.5-2.fc6 (build/make) toshio
qpidc-0.2-5.fc7 (build/make) aconway,nsantos
rekall-2.4.5-6.fc8.1 (build/make) spot
rhm-0.1-3.fc7 (build/make) aconway,nsantos
ruby-activerecord-1.15.1-1.fc7 (build/make) lutter
ruby-bdb-0.6.0-1.fc7 (build/make) errr
rxvt-unicode-8.3-1.fc8 (build/make) awjb
seahorse-1.0.1-9.fc8 (build/make) skvidal
shapelib-1.2.10-12.20060304cvs (build/make) smccann
synce-software-manager-0.9.0-7.fc6 (build/make) awjb
synce-trayicon-0.9.0-8.fc6 (build/make) awjb
syslinux-3.36-7.fc8 (build/make) pjones
syslog-ng-2.0.5-1.fc8 (build/make) jpo,pvrabec
sysprof-kmod-1.0.8-1.2.6.23_0.142.rc3.git10.fc8 (build/make) giallu
tclabc-1.0.9-1.fc7 (build/make) gemi
tetex-3.0-41.fc8 (build/make) jnovy
unison-2.13.16-3.fc6 (build/make) gemi
valgrind-3.2.3-7 (build/make) jakub
xaos-3.2.3-1.fc7 (build/make) gemi
xdaliclock-2.23-3.fc6 (build/make) kaboom
xen-3.1.0-12.fc8 (build/make) xen-maint
xferstats-2.16-14.1 (build/make) than
xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser
xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung
xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint
xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint
xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint
xsri-2.1.0-12.fc8 (build/make) ssp
zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie

With bugs filed: 0
----------------------------------



-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From Matt_Domsch at dell.com  Sat Oct 20 03:55:37 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 19 Oct 2007 22:55:37 -0500
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
Message-ID: <20071019225537.A29006@humbolt.us.dell.com>

Fedora Rawhide-in-Mock Build Results for i386 Fri Oct 19 22:19:35 CDT 2007

Huge thanks to Spot for fixing ~150 perl packages this week.  Note
these were also built using Michael Brown's prerelease of mock 0.8 but
I didn't note any failures that can be attributed to mock.  If you
think you see one, please let the fedora-buildsys-list know.

Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/

Total packages: 4842
Number failed to build: 214
Number expected to fail due to ExclusiveArch or ExcludeArch: 13
Leaving:  201
(there may be some duplicates if rawhide has 2 versions of a package)

Of those expected to have worked...
Without a bug filed: 201
----------------------------------
R-widgetTools-1.12.0-12.fc8 (buildroot) pingou
airsnort-0.2.7e-11.fc7 (build/make) awjb
amsn-0.96-7.fc7 (build/make) tjikkun
apt-0.5.15lorg3.93-2.fc8 (build/make) athimm,pmatilai
athcool-0.3.11-5.fc6 (build/make) gajownik
avr-binutils-2.17-4.fc8 (build/make) jwrdegoede
awesfx-0.5.0d-4.fc7 (build/make) stransky
bes-3.5.1-3.fc8 (build/make) pertusus
binutils-2.17.50.0.18-1 (build/make) jakub
blitz-0.9-3.fc8 (build/make) sergiopr
callweaver-1.2-0.3.rc4.20070822 (needs_popt-devel) dwmw2
camstream-0.26.3-12.fc8 (open_missing_mode) nomis80
castor-0.9.5-1jpp.7 (build/make) pcheung
checkstyle-4.1-4jpp.1.fc7 (build/make) nsantos,dbhole
chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig
clips-6.24-22.fc7 (build/make) rvinyard
compat-erlang-R10B-10.7.fc7 (build/make) gemi
conexus-0.5.3-2.fc8 (build/make) rvinyard
cryptix-3.2.0-9jpp.1 (build/make) mwringe
cryptix-asn1-20011119-7jpp.2 (build/make) vivekl
cvs-1.11.22-12.fc8 (build/make) jmoskovc
cyrus-sasl-2.1.22-7 (build/make) sconklin
d4x-2.5.7.1-3.fc7 (build/make) thias
dap-hdf4_handler-3.7.5-3.fc8 (open_missing_mode) pertusus
eclipse-emf-2.2.2-1.fc7 (build/make) overholt
eclipse-mylyn-2.0.0-9.fc8 (build/make) overholt
eiciel-0.9.4-1.fc7 (build/make) cweyl
emelfm2-0.3.5-2.fc8 (build/make) cwickert
fetchmail-6.3.8-3.fc8 (build/make) vcrhonek
fluxstyle-1.0.1-2.fc7 (build/make) errr
fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig
freetennis-0.4.8-6.fc7 (build/make) rjones
gaim-otr-3.0.1-0.6.20060712cvs.fc7.src.rpm  
gajim-0.11.1-1.fc7 (build/make) gajownik
gdmap-0.7.5-6.fc6 (build/make) splinux
gedit-plugins-2.18.0-2.fc7 (build/make) trondd
genchemlab-1.0-5.fc6 (build/make) pfj
genius-0.7.7-2.fc7 (build/make) gemi
gfa-0.4.1-4.fc7 (build/make) splinux
gjots2-2.3.4-7.fc7 (build/make) rvokal
glipper-0.95.1-2.fc7 (build/make) splinux
gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak
gnomescan-0.4.0.2-1.fc7 (build/make) deji
gquilt-0.20-1.fc7 (build/make) jwboyer
gstm-1.2-6.fc7 (build/make) splinux
gtk-sharp-1.0.10-12.fc7 (build/make) pfj
gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog
gtranslator-1.1.7-3.fc8 (build/make) sindrepb,roozbeh
ht2html-2.0-5.fc6 (build/make) ifoox
htop-0.6.5-1.fc7 (build/make) gajownik
icon-slicer-0.3-8 (build/make) davidz,caolanm,rstrode,behdad,johnp,jrb,hadess,rhughes,alexl,ajax,krh,xiphmont,mclasen,rnorwood,mbarnes,ssp,cworth
inkscape-0.45.1-1.fc7 (needs_popt-devel) denis
jgroups-2.2.9.2-3jpp.2 (build/make) vivekl
jogl-1.0.0-5.7.beta5.fc6 (build/make) green
kbibtex-0.1.5.52-10.fc7 (build/make) noltec
kdissert-1.0.7-1.fc7 (build/make) icon
kgtk-0.8-2.fc7 (build/make) faucamp
klibido-0.2.5-8.fc8 (build/make) faucamp
knetworkmanager-0.2-0.1.svn20070815.fc8 (build/make) ausil,mmcgrath,liquidat
koverartist-0.5-8.fc8 (build/make) svahl
ktorrent-2.2.2-1.fc8 (build/make) liquidat,rdieter
ladspa-1.12-8.fc7 (build/make) thomasvs
ldapjdk-4.17-1jpp.7 (build/make) vivekl
ldns-1.2.1-1.fc8 (build/make) pwouters
libprelude-0.9.13-1.fc7 (build/make) tscherf
libpreludedb-0.9.11.1-2.fc7 (build/make) tscherf
liferea-1.2.23-1.fc8 (build/make) bpepple
lilypond-doc-2.10.13-1.fc7 (build/make) qspencer
ltrace-0.5-9.45svn.fc8 (build/make) pmachata
maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe
mbuffer-20070502-1.fc7 (open_missing_mode) adalloz
memtest86+-1.70-2.fc8.src.rpm  
mikmod-3.2.2-2.fc7 (build/make) jnovy
mosml-2.01-9.fc7 (build/make) gemi
moto4lin-0.3-6.fc7 (build/make) jafo
muine-0.8.7-3.fc7 (build/make) sindrepb
mx4j-3.0.1-6jpp.4 (build/make) fnasser
nagios-2.9-3.fc8 (build/make) mmcgrath,wtogami
nant-0.85-12.fc7 (build/make) pfj
nemiver-0.4.0-1.fc8 (build/make) pgordon
nessus-core-2.2.9-2.fc7 (open_missing_mode) awjb
openais-0.80.1-6 (open_missing_mode) sdake,sdake
openoffice.org-2.3.0-6.3.fc8.src.rpm  
orpie-1.4.3-5.fc6 (build/make) xris
pam_abl-0.2.3-3.fc7 (build/make) adalloz
pari-2.3.0-5.fc7 (build/make) gemi
pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo
perl-Apache-LogRegex-1.4-2.fc7 (build/make) steve,perl-sig,ghenry
perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig
perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig
perl-Cache-Mmap-0.09-2.fc7 (build/make) steve,perl-sig
perl-Class-Factory-Util-1.7-1.fc7 (build/make) cweyl,perl-sig
perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig
perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig
perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig
perl-DateTime-Event-ICal-0.09-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Event-Recurrence-0.16-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-ICal-0.08-4.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-MySQL-0.04-4.fc6 (build/make) cweyl,perl-sig
perl-DateTime-Format-Strptime-1.0700-3.fc7 (build/make) steve,perl-sig
perl-DateTime-Format-W3CDTF-0.04-2.fc7 (build/make) steve,perl-sig
perl-DateTime-Set-0.25-4.fc7 (build/make) steve,perl-sig
perl-Devel-Caller-0.11-1.fc7 (build/make) steve,perl-sig
perl-Exception-Class-1.23-3.fc7 (build/make) steve,perl-sig
perl-File-Find-Rule-0.30-3.fc7 (build/make) corsepiu,perl-sig,laxathom
perl-File-ReadBackwards-1.04-3.fc7 (build/make) steve,perl-sig
perl-File-Type-0.22-4.fc7 (build/make) steve,perl-sig
perl-Gnome2-GConf-1.043-1.fc6 (build/make) cweyl,perl-sig
perl-Gnome2-VFS-1.061-2.fc7 (build/make) cweyl,perl-sig
perl-HTML-Template-Expr-0.07-4.fc7 (build/make) steve,perl-sig
perl-IO-All-0.38-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-0.39-1.fc7 (build/make) steve,perl-sig
perl-Kwiki-Archive-Rcs-0.15-6.fc7 (build/make) steve,perl-sig
perl-Kwiki-Attachments-0.18-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Diff-0.03-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig
perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig
perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserName-0.14-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig
perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig
perl-Log-Message-0.01-3.fc7 (build/make) steve,perl-sig
perl-Log-Message-Simple-0.02-1.fc8 (build/make) steve,perl-sig
perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig
perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig
perl-Module-Install-0.67-1.fc8 (build/make) steve,perl-sig
perl-Module-Loaded-0.01-3.fc7 (build/make) steve,perl-sig
perl-Module-Pluggable-3.60-1.fc7 (build/make) steve,perl-sig
perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig
perl-Net-XMPP-1.02-2.fc7 (build/make) cweyl,perl-sig
perl-Object-Accessor-0.32-2.fc7 (build/make) steve,perl-sig
perl-OpenFrame-3.05-6.fc7 (build/make) steve,perl-sig
perl-POE-API-Peek-1.0802-1.fc7 (build/make) cweyl,perl-sig
perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig
perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig
perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig
perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig
perl-PPI-Tester-0.06-2.fc6 (build/make) jpo,perl-sig
perl-Package-Constants-0.01-3.fc7 (build/make) steve,perl-sig
perl-Params-Check-0.26-1.fc7 (build/make) steve,perl-sig
perl-Parse-CPAN-Packages-2.26-4.fc7 (build/make) steve,perl-sig
perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig
perl-Pipeline-3.12-4.fc7 (build/make) steve,perl-sig
perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig
perl-SUPER-1.16-1.fc7 (build/make) cweyl,perl-sig
perl-Set-Infinite-0.61-3.fc7 (build/make) steve,perl-sig
perl-Spiffy-0.30-7.fc7 (build/make) steve,perl-sig
perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters
perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig
perl-Test-Expect-0.30-1.fc6 (build/make) jpo,perl-sig
perl-Test-Portability-Files-0.05-4.fc7 (build/make) steve,perl-sig
perl-Text-Levenshtein-0.05-4.fc7 (build/make) steve,perl-sig
perl-Tk-804.027-12.fc8 (build/make) awjb,perl-sig
perl-UNIVERSAL-isa-0.06-2.fc6 (build/make) jpo,perl-sig
perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig
perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig
perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig
perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver
pikloops-0.2.5-1.fc8 (build/make) dionysos
pinot-0.76-2.fc8 (build/make) drago01
polyxmass-bin-0.9.3-2.fc6 (build/make) awjb
prelink-0.4.0-1 (build/make) jakub
python-docs-2.5.1-1.fc8 (build/make) james,katzj
python-tag-0.91-5 (build/make) thias
python-urljr-1.0.1-1.fc7 (build/make) jcollie
qa-assistant-0.4.90.5-2.fc6 (build/make) toshio
qpidc-0.2-5.fc7 (build/make) aconway,nsantos
rekall-2.4.5-6.fc8.1 (build/make) spot
rhm-0.1-3.fc7 (build/make) aconway,nsantos
ruby-activerecord-1.15.1-1.fc7 (build/make) lutter
ruby-bdb-0.6.0-1.fc7 (build/make) errr
rxvt-unicode-8.3-1.fc8 (build/make) awjb
seahorse-1.0.1-9.fc8 (build/make) skvidal
setools-3.3.1-6.fc8.src.rpm  
shapelib-1.2.10-12.20060304cvs (build/make) smccann
synce-software-manager-0.9.0-7.fc6 (build/make) awjb
synce-trayicon-0.9.0-8.fc6 (build/make) awjb
syslog-ng-2.0.5-1.fc8 (build/make) jpo,pvrabec
tclabc-1.0.9-1.fc7 (build/make) gemi
tetex-3.0-41.fc8 (build/make) jnovy
unison-2.13.16-3.fc6 (build/make) gemi
xaos-3.2.3-1.fc7 (build/make) gemi
xdaliclock-2.23-3.fc6 (build/make) kaboom
xferstats-2.16-14.1 (build/make) than
xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser
xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung
xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint
xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint
xorg-x11-drv-evdev-1.1.2-5.fc8 (build/make) xgl-maint
xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint
xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint
xsri-2.1.0-12.fc8 (build/make) ssp
zaptel-1.4.2.1-1.fc7 (open_missing_mode) jcollie

With bugs filed: 0
----------------------------------



-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From jonathan at jonmasters.org  Sat Oct 20 06:38:54 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Sat, 20 Oct 2007 02:38:54 -0400
Subject: does cdrecord work these days?
Message-ID: <1192862335.4422.2.camel@perihelion>

Yo,

So growisofs in F8T3 seems to be able to actually burn a DVD, but
cdrecord, while about to scan a bus, won't burn using any of the options
I've historically used, and do in fact use on RHEL5.

Question is, should it (where it is whatever reincarnation exists these
days since whatever latest issue of cdrecord played out...) be working
or am I encountering known behavior?

Jon.




From debarshi.ray at gmail.com  Sat Oct 20 07:13:46 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sat, 20 Oct 2007 12:43:46 +0530
Subject: does cdrecord work these days?
In-Reply-To: <1192862335.4422.2.camel@perihelion>
References: <1192862335.4422.2.camel@perihelion>
Message-ID: <3170f42f0710200013g7d8a083er31c6f23e91bf9f45@mail.gmail.com>

> So growisofs in F8T3 seems to be able to actually burn a DVD, but
> cdrecord, while about to scan a bus, won't burn using any of the options
> I've historically used, and do in fact use on RHEL5.

cdrecord has been replaced by Wodim. The cdrecord command is a symlink to wodim.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From pmatilai at laiskiainen.org  Sat Oct 20 07:50:07 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 20 Oct 2007 10:50:07 +0300 (EEST)
Subject: Fedora x86_64 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071019225418.A28857@humbolt.us.dell.com>
References: <20071019225418.A28857@humbolt.us.dell.com>
Message-ID: <alpine.DEB.0.9999.0710201047460.6691@gotcha.dreamhost.com>

On Fri, 19 Oct 2007, Matt Domsch wrote:

> Fedora Rawhide-in-Mock Build Results for x86_64 Fri Oct 19 22:11:58 CDT 2007
> apt-0.5.15lorg3.93-2.fc8 (build/make) athimm,pmatilai

Hmm, this is caused by missing "Requires: popt-devel" in rpm-devel. Doh.
Will fix when the branching is over...

 	- Panu -



From ivazqueznet at gmail.com  Sat Oct 20 08:08:31 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 20 Oct 2007 04:08:31 -0400
Subject: Fedora x86_64 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071019225418.A28857@humbolt.us.dell.com>
References: <20071019225418.A28857@humbolt.us.dell.com>
Message-ID: <1192867711.28608.21.camel@ignacio.lan>

On Fri, 2007-10-19 at 22:54 -0500, Matt Domsch wrote:
> Number expected to fail due to ExclusiveArch or ExcludeArch: 35
> Leaving:  199
> (there may be some duplicates if rawhide has 2 versions of a package)
> 
> Of those expected to have worked...
> Without a bug filed: 199
> ----------------------------------

> python-psyco-1.5.1-5.fc7 (build/make) shahms

%define srcname psyco

Name:           python-%{srcname}
Version:        1.5.1
Release:        5%{?dist}
  ...
ExclusiveArch:  i386

Something's just a tad off...

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071020/45e66285/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Sat Oct 20 08:31:46 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sat, 20 Oct 2007 10:31:46 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192849643.25729.11.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
Message-ID: <20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>

On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:

> On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
> > On Fri, 19 Oct 2007 17:18:15 -0500
> > Eric Sandeen <sandeen redhat com> wrote:
> > 
> > > You could probably just add a patch to modify the shipped
> > > docs/api_footer.html file to remove the timestamp?
> > 
> > Are these docs generated at build time?  If so the timestamps will
> > still differ and conflict.
> 
> Does rpm complain about differing timestamps on files, while the
> contents is identical?

Eric refers to timestamps _in_ the files, however.



From pertusus at free.fr  Sat Oct 20 08:42:30 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Oct 2007 10:42:30 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192849643.25729.11.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
Message-ID: <20071020084230.GA14246@free.fr>

On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> 
> Does rpm complain about differing timestamps on files, while the
> contents is identical?

It doesn't complain but rpm -V shows the differences, it is better if
the stamps are the same for common files coming from different packages.

--
Pat



From fedora at leemhuis.info  Sat Oct 20 08:52:07 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 20 Oct 2007 10:52:07 +0200
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1, 
 NONE beryl-manager-0.1.4-pidof.patch, 1.1, NONE beryl-manager.spec,
 1.12, NONE sources, 1.9, NONE
In-Reply-To: <200710192341.37182.ml@deadbabylon.de>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<200710192341.37182.ml@deadbabylon.de>
Message-ID: <4719C1B7.3080304@leemhuis.info>



On 19.10.2007 23:41, Sebastian Vahl wrote:
> Am Mi 17.Oktober 2007 schrieb Jarod Wilson:
>> Author: jwilson
>>
>> Update of /cvs/pkgs/rpms/beryl-manager/devel
>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8532
>>
>> Added Files:
>> 	dead.package
>> Removed Files:
>> 	Makefile beryl-manager-0.1.4-pidof.patch beryl-manager.spec
>> 	sources
>> Log Message:
>> Mark beryl bits as dead, since its merged back with current compiz
> 
> Is it? As far as I know the former beryl-manager and beryl-settings are not in 
> compiz-0.6.

Just a note FYI: ccsm (successor of beryl-settings afaics) is under
review in https://bugzilla.redhat.com/show_bug.cgi?id=328981

I've no idea is something like beryl-manager still exists in the new
merged world.

CU
knurd



From pmatilai at laiskiainen.org  Sat Oct 20 08:52:46 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 20 Oct 2007 11:52:46 +0300 (EEST)
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192707207.19550.18.camel@rousalka.dyndns.org>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
	<1192707207.19550.18.camel@rousalka.dyndns.org>
Message-ID: <alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>

On Thu, 18 Oct 2007, Nicolas Mailhot wrote:

>
> Le jeudi 18 octobre 2007 ? 10:57 +0300, Panu Matilainen a ?crit :
>> On Thu, 18 Oct 2007, Nicolas Mailhot wrote:
>
>>> You could make the same arguments for user names, unix permissions or
>>> file location ? a lot them have different values in the wild than in
>>> Fedora and yet we store our policy in rpm.
>>
>> The difference here is that we don't even try to support several
>> different policies (including custom local policies on top of the distro
>> policies) for user names, permissions etc. If we did, we'd be in the very
>> same swamp as with SELinux currently.
>
> And the swamp root is not in-spec definition of our security policy the
> swamp root is trying to manage several set of security policies without
> getting one right distro-wide first.
>
> The more I think about it the more I'm convinced we should have started
> by adopting a lax Fedora selinux policy (and get it supported by all
> packages and distro tools including getting selinux labels in-spec like
> all our other policies) and then spent the following releases tightening
> it instead of doing all at once, compromising on tool support to be a
> jack-of-all-trades, and get nowhere.
>
> We don't do file relocation. We don't do debian suggests. We forced a
> single encoding on everyone. We don't do a lot of things that would mean
> letting users choose instead of getting our Fedora policy right.
>
> For selinux we went the other way and everyone can see the resulting
> disaster.
>
>> I'm not claiming there is no problem. What I'm saying is that storing the
>> labels within RPM doesn't fix a thing.
>
> It stops the pretense selinux is special and can not be integrated
> properly.

It'll stop the pretense alright, by breaking all over the place as 
things currently are ;)

Mind you, I don't think we're in that much disagreement really, just 
different POV. If each package were fully in control of it's own policies, 
storing the labels in packages themselves might make sense. But then to 
create new policies, you'd have to make changes to every single package 
instead of just creating + updating a single central policy.

It's not entirely unlike the case of package translations: having them in 
specs themselves vs specspo both have severe issues, specspo is used 
because the alternative is just so impossible in practise.

 	- Panu -



From fedora at leemhuis.info  Sat Oct 20 09:06:31 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 20 Oct 2007 11:06:31 +0200
Subject: source file audit - 2007-10-17
In-Reply-To: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
Message-ID: <4719C517.2090601@leemhuis.info>

On 19.10.2007 22:01, Kevin Fenzi wrote:
> 
> - Should I keep running this? Do folks find it useful? 

You IMHO not -- we instead should put up a xen instance somewhere where
this and similar scripts get regularly started by cron.

BTW, sorting the list by owner's username would make finding the
packages that are owned by me a little bit easier IMHO.

> - Should I try and spam maintainers? Or just keep posting in the list?

I suppose list once a week and maintainers as well.

> [...]
> Lines in the output are of three forms: 
> [...] 
> - BADSOURCE:$SOURCENAME:$PACKAGENAME
> 
> This means that the source was downloaded ok from the upstream site,
> but doesn't match the md5sum given in the sources file. 
> This could be due to needing to strip out content that fedora cannot
> ship (but in that case you shouldn't have the full URI in the Source
> line). Or upstream following poor release practices and updating
> without changing their release.
> [...] 
> thl:BADSOURCE:CHANGELOG:rss2email

Hmmmm:

diff -u CHANGELOG.from_CVS CHANGELOG.freshly_downloaded
--- CHANGELOG   2007-03-26 09:48:51.000000000 +0200
+++ CHANGELOG.old       2006-08-25 20:36:11.000000000 +0200
@@ -119,7 +119,7 @@
 </ul>

 <p class="dateline"><span style="border: 1px solid #c3d9ff;
padding-left: 4px; ">
-    last updated 6 months ago
+    last updated 1 year ago
     <a href="/CHANGELOG">#</a>
 </span>
 </p>


Tracking such stuff seems not worth the trouble to me. Should we
blacklist this specific file? Or does anybody have a better idea
(besides converting upstream to put a proper changelog somewhere that
doesn't have unnecessary dynamic updates)?

CU
knurd



From nicolas.mailhot at laposte.net  Sat Oct 20 09:12:11 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Oct 2007 11:12:11 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
	<1192707207.19550.18.camel@rousalka.dyndns.org>
	<alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
Message-ID: <1192871531.29939.17.camel@rousalka.dyndns.org>


Le samedi 20 octobre 2007 ? 11:52 +0300, Panu Matilainen a ?crit :

> It's not entirely unlike the case of package translations:

Yes package translations need to return in-package too (not necessarily
in-spec, but in-srpm) ;)

> specspo is used 
> because the alternative is just so impossible in practise.

And non-rh translators complain about it because specspo forces
ultra-centralised non-community workflow

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

From andy at smile.org.ua  Sat Oct 20 09:21:58 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sat, 20 Oct 2007 12:21:58 +0300
Subject: something wrong?
Message-ID: <20071020092158.GA1156@serv.smile.org.ua>

Hi!

I'm try to upload fix for some bug, but I've got

  **** Access denied: andriy is not in ACL for rpms/jack-audio-connection-kit/devel
  cvs commit: Pre-commit check failed
  cvs [commit aborted]: correct above errors first!

from today.

What's happen? Am I wrong?

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From pingoufc4 at yahoo.fr  Sat Oct 20 09:23:45 2007
From: pingoufc4 at yahoo.fr (pingou)
Date: Sat, 20 Oct 2007 11:23:45 +0200
Subject: something wrong?
In-Reply-To: <20071020092158.GA1156@serv.smile.org.ua>
References: <20071020092158.GA1156@serv.smile.org.ua>
Message-ID: <4719C921.6010802@yahoo.fr>

Andy Shevchenko wrote:
> Hi!
> 
> I'm try to upload fix for some bug, but I've got
> 
>   **** Access denied: andriy is not in ACL for rpms/jack-audio-connection-kit/devel
>   cvs commit: Pre-commit check failed
>   cvs [commit aborted]: correct above errors first!
> 
> from today.
> 
> What's happen? Am I wrong?
> 
something like I guess.. :)

"We're ready to try the branching again.  CVS will be disabled for
commits in a few moments.  I will reply when the branching is done.

-- Jesse Keating Fedora -- All my bits are free, are yours? "


Cheer,

P.Yves

	

	
		
___________________________________________________________________________ 
Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
http://fr.mail.yahoo.com



From andy at smile.org.ua  Sat Oct 20 09:27:48 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sat, 20 Oct 2007 12:27:48 +0300
Subject: something wrong?
In-Reply-To: <4719C921.6010802@yahoo.fr>
References: <20071020092158.GA1156@serv.smile.org.ua>
	<4719C921.6010802@yahoo.fr>
Message-ID: <20071020092748.GB1156@serv.smile.org.ua>

Hi pingou!

 On Sat, Oct 20, 2007 at 11:23:45AM +0200, pingou wrote next:

>  something like I guess.. :)
I've  read this one, but...
>  "We're ready to try the branching again.  CVS will be disabled for
>  commits in a few moments.  I will reply when the branching is done.
May be good is to make _informative_ message instead of this.


-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From pertusus at free.fr  Sat Oct 20 09:31:26 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Oct 2007 11:31:26 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071019225537.A29006@humbolt.us.dell.com>
References: <20071019225537.A29006@humbolt.us.dell.com>
Message-ID: <20071020093126.GB14246@free.fr>

On Fri, Oct 19, 2007 at 10:55:37PM -0500, Matt Domsch wrote:
> bes-3.5.1-3.fc8 (build/make) pertusus

I don't see anything wrong in the logs?

--
Pat



From pingoufc4 at yahoo.fr  Sat Oct 20 09:38:44 2007
From: pingoufc4 at yahoo.fr (pingou)
Date: Sat, 20 Oct 2007 11:38:44 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071020093126.GB14246@free.fr>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<20071020093126.GB14246@free.fr>
Message-ID: <4719CCA4.9040100@yahoo.fr>

Patrice Dumas wrote:
> On Fri, Oct 19, 2007 at 10:55:37PM -0500, Matt Domsch wrote:
>> bes-3.5.1-3.fc8 (build/make) pertusus
> 
> I don't see anything wrong in the logs?

May be there
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/bes-3.5.1-3.fc8.src.rpm/result/rpmlint.log

Regards,
P.Yves


	

	
		
___________________________________________________________________________ 
Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
http://fr.mail.yahoo.com



From andy at smile.org.ua  Sat Oct 20 09:43:43 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sat, 20 Oct 2007 12:43:43 +0300
Subject: something wrong?
In-Reply-To: <20071020092748.GB1156@serv.smile.org.ua>
References: <20071020092158.GA1156@serv.smile.org.ua>
	<4719C921.6010802@yahoo.fr>
	<20071020092748.GB1156@serv.smile.org.ua>
Message-ID: <20071020094343.GC1156@serv.smile.org.ua>

Hi Andy Shevchenko!

 On Sat, Oct 20, 2007 at 12:27:48PM +0300, Andy Shevchenko wrote next:

> >  "We're ready to try the branching again.  CVS will be disabled for
> >  commits in a few moments.  I will reply when the branching is done.
> May be good is to make _informative_ message instead of this.
Sorry for possible misspelling. I mean to correct CVS error message.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From enrico.scholz at informatik.tu-chemnitz.de  Sat Oct 20 09:55:28 2007
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sat, 20 Oct 2007 11:55:28 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <47192D27.4070700@redhat.com> (Eric Sandeen's message of "Fri,
	19 Oct 2007 17:18:15 -0500")
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com>
Message-ID: <87zlyef6un.fsf@kosh.bigo.ensc.de>

Eric Sandeen <sandeen at redhat.com> writes:

> You could probably just add a patch to modify the shipped
> docs/api_footer.html file to remove the timestamp?

will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
anchors are named with unique random identifiers.


Enrico



From pertusus at free.fr  Sat Oct 20 10:22:52 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Oct 2007 12:22:52 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <4719CCA4.9040100@yahoo.fr>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<20071020093126.GB14246@free.fr> <4719CCA4.9040100@yahoo.fr>
Message-ID: <20071020102252.GC14246@free.fr>

On Sat, Oct 20, 2007 at 11:38:44AM +0200, pingou wrote:
> Patrice Dumas wrote:
>> On Fri, Oct 19, 2007 at 10:55:37PM -0500, Matt Domsch wrote:
>>> bes-3.5.1-3.fc8 (build/make) pertusus
>> I don't see anything wrong in the logs?
>
> May be there
> http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/bes-3.5.1-3.fc8.src.rpm/result/rpmlint.log

I guess that rpmlint output is only informative? In that case
there is nothing really problematic.

--
Pat



From buildsys at redhat.com  Sat Oct 20 11:20:08 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 20 Oct 2007 07:20:08 -0400
Subject: rawhide report: 20071020 changes
Message-ID: <200710201120.l9KBK8ZE019270@porkchop.devel.redhat.com>

 

 
Updated Packages:

fedora-logos-8.0.0-2.fc8
------------------------
* Fri Oct 19 2007 Matthias Clasen <mclasen at redhat.com> - 8.0.0-2
- Silence %post (#340551)

fonts-arabic-2.1-2.fc8
----------------------
* Thu Oct 18 2007 Rahul Bhalerao <rbhalera at redhat.com> -2.1-2.fc8
- SPEC corrections

fonts-hebrew-0.101-2.fc8
------------------------
* Thu Oct 18 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.101-2.fc8
- SPEC corrections

fonts-sinhala-0.2.2-3.fc8
-------------------------
* Thu Oct 18 2007 Rahul Bhalerao <rbhalera at redhat.com> - 0.2.2-3.fc8
- SPEC corrections

gdb-6.6-35.fc8
--------------
* Fri Oct 19 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.6-35
- Fix hiding unexpected breakpoints on intentional step/next commands.
- Fix s390 compilation warning/failure due to a wrongly sized type-cast.

gnome-utils-1:2.20.0.1-2.fc8
----------------------------
* Thu Oct 18 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0.1-2
- Fix some crashes when scrolling (#321701)

libX11-1.1.3-4.fc8
------------------
* Fri Oct 19 2007 Kristian H??gsberg <krh at redhat.com> - 1.1.3-4
- Add patch from upstream to add keysyms for brightness buttons (#330491).

libpng-2:1.2.22-1.fc8
---------------------
* Thu Oct 18 2007 Tom Lane <tgl at redhat.com> 2:1.2.22-1
- Update to libpng 1.2.22, primarily to fix CVE-2007-5269
Related: #324771

metacity-2.20.0-3.fc8
---------------------
* Thu Oct 18 2007 Colin Walters <walters at redhat.com> - 2.20.0-3
- Add patch to fix workspace behavior when presenting normal windows

pirut-1.3.25-2.fc8
------------------
* Fri Oct 19 2007 Jeremy Katz <katzj at redhat.com> - 1.3.25-2
- Fix build error

* Wed Oct 17 2007 Jeremy Katz <katzj at redhat.com> - 1.3.25-1
- Fix handling of bad repo edits so that you're not stuck (#334501)
- Take into account updated urls with repo editor
- system-install-packages only needs repos to be available if we have
  to depsolve

* Thu Oct 11 2007 Jeremy Katz <katzj at redhat.com> - 1.3.24-1
- Improve handling of login before NM brings the network up
- Don't escape all characters in descriptions (#325891)
- Don't traceback if hal isn't running (#325901)
- Translation updates

pungi-1.1.6-1.fc8
-----------------
* Fri Oct 19 2007 Jesse Keating <jkeating at redhat.com> - 1.1.6-1
- Update the manifest

rss-glx-0.8.1.p-15.fc8
----------------------
* Fri Oct 19 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-15
- let -xscreensaver require xscreensaver-gl-base (#336331)

scim-1.4.7-7.fc8
----------------
* Fri Oct 19 2007 Jens Petersen <petersen at redhat.com> - 1.4.7-7.fc8
- quote backquotes in xinput config file (#339271)

* Fri Oct 12 2007 Jens Petersen <petersen at redhat.com> - 1.4.7-6
- make scim-lang-*.x86_64 require scim-bridge-gtk multilib (#327151)

* Thu Sep 20 2007 Jens Petersen <petersen at redhat.com> - 1.4.7-5
- /etc/X11/xinit/xinput.d is now owned by im-chooser
- no longer require xorg-x11-xinit

selinux-policy-3.0.8-28.fc8
---------------------------
* Wed Oct 17 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-28
- Fixes for hald_mac 
- Treat unconfined_home_dir_t as a home dir
- dontaudit rhgb writes to fonts and root

* Wed Oct 17 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-27
- Fix dnsmasq
- Allow rshd full login privs

* Tue Oct 16 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-26
- Allow rshd to connect to ports > 1023

tempest-0-0.4.20070929.fc8
--------------------------
* Fri Oct 19 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0-0.4.20070929
- Fix xscreensaver xml file
- Make xscreensaver subpackage xscreensaver-gl-base (bug 336331)
xscreensaver-1:5.03-12.fc8
--------------------------
* Thu Oct 18 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-12
- Create -gl-base subpackage and split xscreensaver-gl-helper 
  into -gl-base subpackage so that external GL screensavers can
  use it (bug 336331)

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From lkundrak at redhat.com  Sat Oct 20 11:47:53 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sat, 20 Oct 2007 13:47:53 +0200
Subject: Codeina security concerns
Message-ID: <1192880873.8914.11.camel@localhost.localdomain>

Hi,

I'm a bit worried about codecs installed from Fluendo. What if a
security problem is found in them, how are they going to be updated? 

I assume the only way would be to ship an updated codeina package and
update the installed codecs via scriptlets. But this would be easy if
the codecs were installed system-wide, currently they are installed into
user's home directory (btw wouldn't this cause trouble if user shares
home directories on machines of different architectures?), which might
make this way terribly painful.

Another way would be to make codeina check for updated packages each
time a media player is started. Or does this already happen?

Regards,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From abo at kth.se  Sat Oct 20 12:59:25 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 20 Oct 2007 14:59:25 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
	<1192707207.19550.18.camel@rousalka.dyndns.org>
	<alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
Message-ID: <1192885165.5560.410.camel@home.alexander.bostrom.net>

l?r 2007-10-20 klockan 11:52 +0300 skrev Panu Matilainen:

> If each package were fully in control of it's own policies, 
> storing the labels in packages themselves might make sense. 

I think it's good to keep in mind that SELinux is, as I see it, separate
from everything else _by design_. It's a firewall, it's a part of
multi-layer security. It's supposed to describe not really a policy but
rather "expected behaviour", in a form that is separate from the actual
policy and behaviour (the software itself).

That way, if the behaviour of the software is not what we expected it to
be (a security problem), maybe the description of the behaviour (the
SELinux policy) is what was expected, and thus this layer of security
catches the problem.

Thus, it's not strange that it's perhaps a bit difficult to integrate
SELinux with the rest of the system.

I maintain a package that I'd like to submit to Fedora. But before I do
that I need to figure out how to make it play nicely with SELinux. (It's
the Heimdal Kerberos implementation. It has a telnetd that is launched
from xinetd, so it needs to break out of the context xinetd is running
as before exec:ing the user's shell.) It works if you setsebool the
right config key, but I don't really know how to solve it the proper
way.

Would putting the policy in the package actually help make my problem
easier? Since I don't understand the problem fully and don't know how to
fix it, I would still need to talk to the people who know SELinux well.
That means it's not really a problem to let them update the central
policy files instead of me doing whatever needs to be done in the
package.

/abo



From Matt_Domsch at dell.com  Sat Oct 20 13:38:29 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sat, 20 Oct 2007 08:38:29 -0500
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071020102252.GC14246@free.fr>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<20071020093126.GB14246@free.fr> <4719CCA4.9040100@yahoo.fr>
	<20071020102252.GC14246@free.fr>
Message-ID: <20071020133829.GA12287@auslistsprd01.us.dell.com>

On Sat, Oct 20, 2007 at 12:22:52PM +0200, Patrice Dumas wrote:
> On Sat, Oct 20, 2007 at 11:38:44AM +0200, pingou wrote:
> > Patrice Dumas wrote:
> >> On Fri, Oct 19, 2007 at 10:55:37PM -0500, Matt Domsch wrote:
> >>> bes-3.5.1-3.fc8 (build/make) pertusus
> >> I don't see anything wrong in the logs?
> >
> > May be there
> > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/bes-3.5.1-3.fc8.src.rpm/result/rpmlint.log
> 
> I guess that rpmlint output is only informative? In that case
> there is nothing really problematic.

Sorry, I thought the build results had synced out to the server before
that email went out. They're syncing now.  In this case:

2007-10-19 13:21:34,860 - util.py:194:DEBUG: Generating page index...
2007-10-19 13:21:34,860 - util.py:194:DEBUG: + rm -rf __fedora_docs
2007-10-19 13:21:34,860 - util.py:194:DEBUG: + cp -pr docs __fedora_docs
2007-10-19 13:21:34,860 - util.py:194:DEBUG: + mv __fedora_docs/html __fedora_docs/api-html
2007-10-19 13:21:34,860 - util.py:194:DEBUG: + rm '__fedora_docs/api-html/*.map'
2007-10-19 13:21:34,860 - util.py:194:DEBUG: rm: cannot remove `__fedora_docs/api-html/*.map': No such file or directory
2007-10-19 13:21:34,861 - util.py:194:DEBUG: error: Bad exit status from /var/tmp/rpm-tmp.9342 (%build)


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From sundaram at fedoraproject.org  Sat Oct 20 12:41:48 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 20 Oct 2007 19:11:48 +0630
Subject: Live Upgrade Special Interest Group
Message-ID: <4719F78C.8080500@fedoraproject.org>

Hi

Here you go. Join the group and help make live upgrades work smoothly.

http://fedoraproject.org/wiki/SIGs/LiveUpgrade

Rahul



From jkeating at redhat.com  Sat Oct 20 13:52:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Oct 2007 09:52:12 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071019231326.607bf89d@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
Message-ID: <20071020095212.402c5849@redhat.com>

On Fri, 19 Oct 2007 23:13:26 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> We're ready to try the branching again.  CVS will be disabled for
> commits in a few moments.  I will reply when the branching is done.

Just an update on this.

The branching is going well, it just takes a long time to branch all of
our packages.  We did this alphabetically (sort style) and have made it
well into the perl packages.  I expect the rest of the packages to take
a few more hours yet.

I'm going to keep an eye on it as best as possible, but it is my
weekend and I'll be doing a lot of house work so there may be a slight
lag between when it finishes and when I open CVS back up.  No more than
an hour or so though.

This was our first trial of using pkgdb completely for the branching of
the system.  We have identified some parts where we could possible
speed things up for the next time we mass branch so I expect it to go
faster next time, however if our package growth rate continues the
speed ups we get may be surpassed by just branching that many more
packages.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/78f854b9/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Oct 20 14:19:49 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 20 Oct 2007 16:19:49 +0200
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192885165.5560.410.camel@home.alexander.bostrom.net>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
	<1192707207.19550.18.camel@rousalka.dyndns.org>
	<alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
	<1192885165.5560.410.camel@home.alexander.bostrom.net>
Message-ID: <1192889989.32143.3.camel@rousalka.dyndns.org>


Le samedi 20 octobre 2007 ? 14:59 +0200, Alexander Bostr?m a ?crit :

> Would putting the policy in the package actually help make my problem
> easier? Since I don't understand the problem fully and don't know how to
> fix it, I would still need to talk to the people who know SELinux well.

You can talk and you can offload. Most people just offload so selinux is
only mastered by a little core.

> That means it's not really a problem to let them update the central
> policy files instead of me doing whatever needs to be done in the
> package.

That's a problem for everything that is not 100% Fedora, such a spins
with custom modifications corporations or universities create. Since the
current system is overly centralised, they just disable selinux by
default.

And its not their fault it's the fault of a model that deems having a
few experts and letting everyone else in the dark is acceptable.

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

From myfedora at richip.dhs.org  Sat Oct 20 15:37:21 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 20 Oct 2007 09:37:21 -0600
Subject: If you are maintinaing of developing a Fedora Package.
In-Reply-To: <1192885165.5560.410.camel@home.alexander.bostrom.net>
References: <4710D754.2090101@redhat.com>
	<20071015213117.GA6325@petra.dvoda.cz>
	<20071017111115.GA1758@evileye.englab.brq.redhat.com>
	<1192625250.7342.89.camel@localhost.localdomain>
	<alpine.LFD.0.9999.0710181009420.3339@localhost.localdomain>
	<1192692942.19550.3.camel@rousalka.dyndns.org>
	<alpine.LFD.0.9999.0710181044270.3339@localhost.localdomain>
	<1192707207.19550.18.camel@rousalka.dyndns.org>
	<alpine.DEB.0.9999.0710201132180.6691@gotcha.dreamhost.com>
	<1192885165.5560.410.camel@home.alexander.bostrom.net>
Message-ID: <1192894641.16089.2.camel@localhost6.localdomain6>

On Sat, 2007-10-20 at 14:59 +0200, Alexander Bostr?m wrote:
> l?r 2007-10-20 klockan 11:52 +0300 skrev Panu Matilainen:
> 
> > If each package were fully in control of it's own policies, 
> > storing the labels in packages themselves might make sense. 
> 
> I think it's good to keep in mind that SELinux is, as I see it, separate
> from everything else _by design_. It's a firewall, it's a part of
> multi-layer security. It's supposed to describe not really a policy but
> rather "expected behaviour", in a form that is separate from the actual
> policy and behaviour (the software itself).

And have a separate package for its selinux parts, <package>-selinux
(a'la *-debuginfo). That way, non-SELinux installs don't need to install
them and the selinux bits can call on functions that only exist when
SELinux is installed. And who knows ... if down-the-line fedora decides
to shift to a different security policy, it'll be easier because it was
cleanly separated in the packages.
--
Richi Plana



From sandeen at redhat.com  Sat Oct 20 16:18:09 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 11:18:09 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071020084230.GA14246@free.fr>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>	<47192D27.4070700@redhat.com>
	<20071019225836.18a17d23@redhat.com>	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020084230.GA14246@free.fr>
Message-ID: <471A2A41.7030907@redhat.com>

Patrice Dumas wrote:
> On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
>> Does rpm complain about differing timestamps on files, while the
>> contents is identical?
> 
> It doesn't complain but rpm -V shows the differences, it is better if
> the stamps are the same for common files coming from different packages.

Waiiit a minute... are you talking about the installed filesystem
timestamps, the mtime that affects the T flag on -V verify?  That sounds
like a lot of hoop-jumping to me, although I guess I can see the use for it.

If I look at e2fsprogs-devel for example, and I install x86_64, then
i386, I do get T mtime mismatches.  The timestamps on the files are
related to when the rpm was built, presumeably the time at which they
were %installed during the rpm *build*

I suppose that if you made sure that every file install kept the
original timestamp from the upstream tarball, and every generated file
pulled tricks to make sure that the mtime was something (what?) that
matched between all arches you could avoid this... but this sounds like
it needs some infrastructure to make it do-able.

-Eric



From sandeen at redhat.com  Sat Oct 20 16:22:55 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 11:22:55 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <87zlyef6un.fsf@kosh.bigo.ensc.de>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>	<47192D27.4070700@redhat.com>
	<87zlyef6un.fsf@kosh.bigo.ensc.de>
Message-ID: <471A2B5F.7050705@redhat.com>

Enrico Scholz wrote:
> Eric Sandeen <sandeen at redhat.com> writes:
> 
>> You could probably just add a patch to modify the shipped
>> docs/api_footer.html file to remove the timestamp?
> 
> will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
> anchors are named with unique random identifiers.

Yeesh.  For things that contain simple generation timestamps, we could
probably make some filters to take those out.  e2fsprogs has something
like that:

[root at localhost e2fsprogs-1.40.2]# cat ./po/remove-potcdate.sin
# Sed script that remove the POT-Creation-Date line in the header entry
# from a POT file.
....

but for anything which contains uuids generated at build time... good
luck I guess! :)

-Eric



From sandeen at redhat.com  Sat Oct 20 16:51:45 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 11:51:45 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <471A2B5F.7050705@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>	<47192D27.4070700@redhat.com>	<87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com>
Message-ID: <471A3221.6040109@redhat.com>

Eric Sandeen wrote:
> Enrico Scholz wrote:
>> Eric Sandeen <sandeen at redhat.com> writes:
>>
>>> You could probably just add a patch to modify the shipped
>>> docs/api_footer.html file to remove the timestamp?
>> will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
>> anchors are named with unique random identifiers.
> 
> Yeesh.  For things that contain simple generation timestamps, we could
> probably make some filters to take those out.  e2fsprogs has something
> like that:
> 
> [root at localhost e2fsprogs-1.40.2]# cat ./po/remove-potcdate.sin
> # Sed script that remove the POT-Creation-Date line in the header entry
> # from a POT file.
> ....
> 
> but for anything which contains uuids generated at build time... good
> luck I guess! :)

And I'm afraid this does apply to you, Christopher, I should have looked
more closely.  If for example you diff classcal3d_1_1RefCounted.html
between x86_64 and x86, you'll see this.

(pseudodiff):

-<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
+<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>

-Eric



From tmz at pobox.com  Sat Oct 20 17:01:18 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 20 Oct 2007 13:01:18 -0400
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <471A3221.6040109@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
Message-ID: <20071020170118.GF4413@psilocybe.teonanacatl.org>

Eric Sandeen wrote:
> And I'm afraid this does apply to you, Christopher, I should have
> looked more closely.  If for example you diff
> classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> this.
>
> (pseudodiff):
> 
> -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>

Could docs like this be split out into noarch subpackages?  Or perhaps
pre-generated and then installed from a Source1: line so that they'd
match across arches?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The marvel of all history is the patience with which men and women
submit to burdens unnecessarily laid upon them by their governments.
    -- William H. Borah

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

From rohan at rs3net.net  Sat Oct 20 17:03:27 2007
From: rohan at rs3net.net (Rohan Sheth)
Date: Sat, 20 Oct 2007 10:03:27 -0700
Subject: functionality similar to apt-get autoclean?
Message-ID: <20071020100327.1301f856@rnslappy.sonic.net>

Debian has this nifty feature of apt-get which is the option to
'autoclean'

It has two purposes, first it removes files from the local repository
which can no longer be downloaded and are useless.  Second it removes
packages that used to depend on a package which no longer exists.

Example:

I install claws-mail which depends on (among other things) libetpan11.

Then I decide I don't like claws-mail and remove the package claws-mail.

The next time I run autoclean (presuming that no other installed
package depends on libetpan11) it will remove the package libetpan11
since it it no longer required by the system.

Is there any similar functionality with yum/rpm?

Thanks,
Rohan Sheth



From tmz at pobox.com  Sat Oct 20 17:15:27 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 20 Oct 2007 13:15:27 -0400
Subject: functionality similar to apt-get autoclean?
In-Reply-To: <20071020100327.1301f856@rnslappy.sonic.net>
References: <20071020100327.1301f856@rnslappy.sonic.net>
Message-ID: <20071020171527.GG4413@psilocybe.teonanacatl.org>

Rohan Sheth wrote:
> Debian has this nifty feature of apt-get which is the option to
> 'autoclean'
> 
> It has two purposes, first it removes files from the local
> repository which can no longer be downloaded and are useless.
> Second it removes packages that used to depend on a package which no
> longer exists.
> 
> Example:
> 
> I install claws-mail which depends on (among other things)
> libetpan11.
> 
> Then I decide I don't like claws-mail and remove the package
> claws-mail.
> 
> The next time I run autoclean (presuming that no other installed
> package depends on libetpan11) it will remove the package libetpan11
> since it it no longer required by the system.
> 
> Is there any similar functionality with yum/rpm?

The package-cleanup script from yum-utils can do part of this.  Using
the --leaves option gets you a list of packages that are not required
by any other packages.  The --orphans option lists packages that are
not available from any configured repos.  You would have to feed these
lists to yum remove to uninstall packages you wanted to remove, but
that may work for you.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why does a slight tax increase cost you two hundred dollars and a
substantial tax cut save you thirty cents?
    -- Peg Bracken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/18946b96/attachment.sig>

From sundaram at fedoraproject.org  Sat Oct 20 16:23:46 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 20 Oct 2007 22:53:46 +0630
Subject: functionality similar to apt-get autoclean?
In-Reply-To: <20071020100327.1301f856@rnslappy.sonic.net>
References: <20071020100327.1301f856@rnslappy.sonic.net>
Message-ID: <471A2B92.5070803@fedoraproject.org>

Rohan Sheth wrote:
> Debian has this nifty feature of apt-get which is the option to
> 'autoclean'
> 
> It has two purposes, first it removes files from the local repository
> which can no longer be downloaded and are useless.  Second it removes
> packages that used to depend on a package which no longer exists.
> 
> Example:
> 
> I install claws-mail which depends on (among other things) libetpan11.
> 
> Then I decide I don't like claws-mail and remove the package claws-mail.
> 
> The next time I run autoclean (presuming that no other installed
> package depends on libetpan11) it will remove the package libetpan11
> since it it no longer required by the system.
> 
> Is there any similar functionality with yum/rpm?

Other than what Todd has already said, note that apt-rpm is available in 
Fedora. If you need it

# yum install apt

Rahul



From sandeen at redhat.com  Sat Oct 20 17:37:55 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 12:37:55 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <471A2A41.7030907@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>	<47192D27.4070700@redhat.com>	<20071019225836.18a17d23@redhat.com>	<1192849643.25729.11.camel@mccallum.corsepiu.local>	<20071020084230.GA14246@free.fr>
	<471A2A41.7030907@redhat.com>
Message-ID: <471A3CF3.30801@redhat.com>

Eric Sandeen wrote:
> Patrice Dumas wrote:
>> On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
>>> Does rpm complain about differing timestamps on files, while the
>>> contents is identical?
>> It doesn't complain but rpm -V shows the differences, it is better if
>> the stamps are the same for common files coming from different packages.
> 
> Waiiit a minute... are you talking about the installed filesystem
> timestamps, the mtime that affects the T flag on -V verify?  That sounds
> like a lot of hoop-jumping to me, although I guess I can see the use for it.
> 
> If I look at e2fsprogs-devel for example, and I install x86_64, then
> i386, I do get T mtime mismatches.  The timestamps on the files are
> related to when the rpm was built, presumeably the time at which they
> were %installed during the rpm *build*
> 
> I suppose that if you made sure that every file install kept the
> original timestamp from the upstream tarball, and every generated file
> pulled tricks to make sure that the mtime was something (what?) that
> matched between all arches you could avoid this... but this sounds like
> it needs some infrastructure to make it do-able.

Urgh... install -p, touch -r ... sorry.  I'll shut up now.

-Eric



From kevin.kofler at chello.at  Sat Oct 20 17:49:18 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 20 Oct 2007 17:49:18 +0000 (UTC)
Subject: functionality similar to apt-get autoclean?
References: <20071020100327.1301f856@rnslappy.sonic.net>
	<471A2B92.5070803@fedoraproject.org>
Message-ID: <loom.20071020T174814-347@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> Other than what Todd has already said, note that apt-rpm is available in 
> Fedora. If you need it
> 
> # yum install apt

But note that autoclean in apt-rpm (at least in the version currently in Fedora 
7) only cleans the apt cache (removes downloaded files no longer in the repo), 
it doesn't remove any installed packages.

        Kevin Kofler



From pertusus at free.fr  Sat Oct 20 18:05:37 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 20 Oct 2007 20:05:37 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <471A3CF3.30801@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020084230.GA14246@free.fr> <471A2A41.7030907@redhat.com>
	<471A3CF3.30801@redhat.com>
Message-ID: <20071020180537.GA2595@free.fr>

On Sat, Oct 20, 2007 at 12:37:55PM -0500, Eric Sandeen wrote:
> Eric Sandeen wrote:
> 
> Urgh... install -p, touch -r ... sorry.  I'll shut up now.

To be honest, even though the commands exist, I guess that for complex
packages having to have stamps on all arches the same, even for
generated files seems a bit of a burden to me. In my opinion it should
be optional.

--
Pat



From kagesenshi.87 at gmail.com  Sat Oct 20 19:42:42 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Sun, 21 Oct 2007 03:42:42 +0800
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <4719C1B7.3080304@leemhuis.info>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<200710192341.37182.ml@deadbabylon.de>
	<4719C1B7.3080304@leemhuis.info>
Message-ID: <c44298520710201242u13a865fag41ea31b3dd19850b@mail.gmail.com>

On 10/20/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>
>
> On 19.10.2007 23:41, Sebastian Vahl wrote:
> > Am Mi 17.Oktober 2007 schrieb Jarod Wilson:
> >> Author: jwilson
> >>
> >> Update of /cvs/pkgs/rpms/beryl-manager/devel
> >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8532
> >>
> >> Added Files:
> >>      dead.package
> >> Removed Files:
> >>      Makefile beryl-manager-0.1.4-pidof.patch beryl-manager.spec
> >>      sources
> >> Log Message:
> >> Mark beryl bits as dead, since its merged back with current compiz
> >
> > Is it? As far as I know the former beryl-manager and beryl-settings are not in
> > compiz-0.6.
>
> Just a note FYI: ccsm (successor of beryl-settings afaics) is under
> review in https://bugzilla.redhat.com/show_bug.cgi?id=328981
>
> I've no idea is something like beryl-manager still exists in the new
> merged world.

it still exist, with the name fusion-icon (I think they call it
compiz-fusion-icon now) .. however, upstream keep changing the name
and the installation method, causing it hard to be packaged and
reviewed ..

maybe after upstream released a stable release, i'll package it ..

>
> CU
> knurd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From kanarip at kanarip.com  Sat Oct 20 19:44:04 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 21:44:04 +0200
Subject: Merging totem and totem-xine
In-Reply-To: <1191890955.14085.11.camel@Diffingo.localdomain>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
Message-ID: <471A5A84.2050707@kanarip.com>

Stewart Adam wrote:
> Hi,
> 
> Since xine-lib has been moved to Fedora, I realized so could totem-xine.
> I've been working on a totem spec that includes both gstreamer and xine
> backends. As of now, the spec generates the usual subpackages plus
> 'totem-gstreamer' and 'totem-xine' which contain the binaries for the
> gstreamer- and xine-based binary totem. I've used --program-suffix at
> compile time, so they are parallel installable.
> 
> What do you think the best approach is to packaging this, if at all? Two
> options I'm thinking of are having the two engines conflict or using
> alternatives to have a configurable backend (switching "on demand").
> 
> Stewart
> 

I've not read the entire thread yet but does this apply to 
totem-xine-plarser and totem-plparser as well?

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From rohan at rs3net.net  Sat Oct 20 19:45:27 2007
From: rohan at rs3net.net (Rohan Sheth)
Date: Sat, 20 Oct 2007 12:45:27 -0700
Subject: functionality similar to apt-get autoclean?
In-Reply-To: <loom.20071020T174814-347@post.gmane.org>
References: <20071020100327.1301f856@rnslappy.sonic.net>
	<471A2B92.5070803@fedoraproject.org>
	<loom.20071020T174814-347@post.gmane.org>
Message-ID: <20071020124527.79ba1448@rnslappy.sonic.net>

The yum-utils options mentioned by Todd worked perfectly.  Thanks!

--Rohan

On Sat, 20 Oct 2007 17:49:18 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> > Other than what Todd has already said, note that apt-rpm is
> > available in Fedora. If you need it
> > 
> > # yum install apt
> 
> But note that autoclean in apt-rpm (at least in the version currently
> in Fedora 7) only cleans the apt cache (removes downloaded files no
> longer in the repo), it doesn't remove any installed packages.
> 
>         Kevin Kofler
> 



From kanarip at kanarip.com  Sat Oct 20 19:46:51 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 21:46:51 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <470D81BB.2070404@redhat.com>
References: <470D81BB.2070404@redhat.com>
Message-ID: <471A5B2B.1090800@kanarip.com>

Mike McGrath wrote:
> History: Up until Fedora 7 all RH family products had an install CD that 
> people could download, stick in their drive and install a minimal set of 
> packages or at least specify a method to install from.
> 
> Problem: As of Fedora 7 (and soon with Fedora 8) they cannot do this.  
> The installable live cd can install but not in the traditional sense of 
> what people are used to.  It has no package selection and cannot upgrade.
> 
> Opinion: I believe, in part, this has contributed to the dip in numbers 
> we saw between FC6 and F7.
> 
> Future problem: as of F8 for an individual arch a user could download 
> boot.iso, live cd, installable DVD, and a few respins.  Respins are 
> going to get linked to a spins site, the torrents and public mirrors 
> site will be linked to as well.  So the real question is what do we 
> 'suggest' our default install be?
> 
> 1) Live CD: Can't upgrade, do package selection or specify install method.
> 2) DVD: isn't live (duh :)  but requires DVD burner and drive to do 
> installs.
> 3) boot.iso: a little too advanced for causal users, etc.
> 
> So which one do we link to directly from get-fedora?  The public mirror 
> list will be there as it was in the past.
> 
>    -Mike
> 

Maybe you could co-locate on spins.fedoraproject.org the torrent I've 
set up almost immediately after the CD showed to be a big deal to a big 
number of people:

http://fedora.kanarip.com/torrents/

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From kanarip at kanarip.com  Sat Oct 20 19:49:34 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 21:49:34 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <1192075110.19308.21.camel@cutter>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>
Message-ID: <471A5BCE.5060708@kanarip.com>

seth vidal wrote:
> On Wed, 2007-10-10 at 22:46 -0500, Mike McGrath wrote:
>> John Reiser wrote:
>>>> So the real question is what do we 'suggest' our default install be?
>>>>
>>>> 1) Live CD: Can't upgrade, do package selection or specify install method.
>>>>     
>>> Why can't a system that is installed from the Live CD be upgraded?
>>> What would it take to make such an installation upgradeable?
>>> I believe it is reasonable if the upgrade is possible, even if it
>>> requires a separate step after initial installation from Live CD.
>>> [Specifying install method and package selection is a natural for the
>>> Rescue CD; see #3 below.]
>>>   
>> Because the live cd install does an image copy and not an install.  The 
>> workings behind the scenes are not the same right now in anaconda for 
>> the live cd and the normal install.
> 
> Wait - you can upgrade after you boot into the installed livecd image.
> You just can't upgrade it FROM the boot live image.
> 
> -sv
> 
> 

Isn't that like telling people to use the method of upgrading we tell 
everyone is not recommended and most definitely not supported in any way?

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From cra at WPI.EDU  Sat Oct 20 20:08:54 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 20 Oct 2007 16:08:54 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A5BCE.5060708@kanarip.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
Message-ID: <20071020200854.GA25455@angus.ind.WPI.EDU>

> >>>Why can't a system that is installed from the Live CD be upgraded?
> >>>What would it take to make such an installation upgradeable?

> >Wait - you can upgrade after you boot into the installed livecd image.
> >You just can't upgrade it FROM the boot live image.

> Isn't that like telling people to use the method of upgrading we tell 
> everyone is not recommended and most definitely not supported in any way?

I think people are confused about a LiveCD installation.  Once you 
tell the LiveCD to install to the hard disk, it becomes a regular 
installation on the hard disk.  You can then upgrade that at a future 
date just like any other install, using anaconda to upgrade the system 
via new media, HTTP, FTP, NFS, etc.  Of course, you can also try to 
"yum upgrade" it, which isn't recommended.



From kanarip at kanarip.com  Sat Oct 20 20:31:50 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 22:31:50 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071020200854.GA25455@angus.ind.WPI.EDU>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
Message-ID: <471A65B6.8010808@kanarip.com>

Chuck Anderson wrote:
>>>>> Why can't a system that is installed from the Live CD be upgraded?
>>>>> What would it take to make such an installation upgradeable?
> 
>>> Wait - you can upgrade after you boot into the installed livecd image.
>>> You just can't upgrade it FROM the boot live image.
> 
>> Isn't that like telling people to use the method of upgrading we tell 
>> everyone is not recommended and most definitely not supported in any way?
> 
> I think people are confused about a LiveCD installation.  Once you 
> tell the LiveCD to install to the hard disk, it becomes a regular 
> installation on the hard disk.  You can then upgrade that at a future 
> date just like any other install, using anaconda to upgrade the system 
> via new media, HTTP, FTP, NFS, etc.  Of course, you can also try to 
> "yum upgrade" it, which isn't recommended.
> 

Right what I was saying was you install from LiveCD, then boot into the 
installed OS and 6 months later you want to upgrade. You're two options 
are to use yum upgrade or use any of the regular install/upgrade methods 
like NFS/FTP/HTTP/DVD; the point being, you cannot upgrade using a CD so 
you either need a fast link, the infrastructure to host NFS/FTP/HTTP, 
the knowledge and spirit of mind to partition your hard drive such that 
it can hold a DVD image you can upgrade from, or you must be willing to 
take the risk and yum upgrade.

I'm not misunderstanding the concept of a LiveCD in any way, I'm just 
disagreeing about how important having CD media released by the Fedora 
Project is exactly.

So, not releasing CD sets is like saying you need to yum upgrade 
although it is not recommended just because someone out there isn't 
using the LiveCD installer because they tried Fedora and felt 
comfortable. Someone is actually needing CD sets, and based on the 
numbers that has been at least 760 people in the last 4 weeks.

Kind regards,

Jeroen van Meeuwen
-kanarip



From sundaram at fedoraproject.org  Sat Oct 20 19:38:17 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 21 Oct 2007 02:08:17 +0630
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A65B6.8010808@kanarip.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com>
Message-ID: <471A5929.10605@fedoraproject.org>

Jeroen van Meeuwen wrote:

> I'm not misunderstanding the concept of a LiveCD in any way, I'm just 
> disagreeing about how important having CD media released by the Fedora 
> Project is exactly.
> 
> So, not releasing CD sets is like saying you need to yum upgrade 
> although it is not recommended just because someone out there isn't 
> using the LiveCD installer because they tried Fedora and felt 
> comfortable. Someone is actually needing CD sets, and based on the 
> numbers that has been at least 760 people in the last 4 weeks.

I think the better solution is to support live upgrades better and don't 
do multi arch in live images by default so that they fit into a CD for 
all architectures.

Rahul



From kanarip at kanarip.com  Sat Oct 20 20:50:16 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 22:50:16 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A5929.10605@fedoraproject.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>
	<471A5929.10605@fedoraproject.org>
Message-ID: <471A6A08.7070507@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
> 
>> I'm not misunderstanding the concept of a LiveCD in any way, I'm just 
>> disagreeing about how important having CD media released by the Fedora 
>> Project is exactly.
>>
>> So, not releasing CD sets is like saying you need to yum upgrade 
>> although it is not recommended just because someone out there isn't 
>> using the LiveCD installer because they tried Fedora and felt 
>> comfortable. Someone is actually needing CD sets, and based on the 
>> numbers that has been at least 760 people in the last 4 weeks.
> 
> I think the better solution is to support live upgrades better and don't 
> do multi arch in live images by default so that they fit into a CD for 
> all architectures.
> 
> Rahul
> 

If only we could fulfill todays needs with whatever the future promises.



From jon at fedoraunity.org  Sat Oct 20 20:50:39 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Sat, 20 Oct 2007 14:50:39 -0600
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071020200854.GA25455@angus.ind.WPI.EDU>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
Message-ID: <471A6A1F.5000302@fedoraunity.org>

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

Does anyone have the *technical* reason we are not doing CDs? Is this
because we don't want to have mirrors hosting the additional data? I can
assume the Live images have taken the space we have dedicated for CD
ISOs in the past, is this the case? Is it the testing load.. or is it we
don't want to have to maintain pkgorder in anaconda anymore? ;-)

I hate to blatantly plug Fedora Unity, but we are doing some neat stuff.
The Fedora Project could utilize some of the work we are doing,
specifically with regards to Jigdo. If the issue is really an issue of
storage space, a Spin of CD ISOs could be built against the GOLD tree
(which wont have a changing package set and will survive the updates
tree madness) and then shared via Jigdo. This would utilize the bits
that are in the exploded GOLD tree (the release Everything tree)... not
requiring mirrors to take on additional bits. Fedora Unity will be
releasing GOLD CD iso images (if the Fedora Project wont), but I think
we would prefer to "pass the buck" with regards to testing the Spin. If
push comes to shove, I expect we'll do it. The only *real* drawback to
Jigdo is the moving target of the updates repo for Re-Spins but this is
another issue. I see *no* drawbacks to appeasing the remaining CD users
by releasing a Spin, Jigdo only.

I think PyJigdo (a python based implementation on top of the existing
Jigdo[1]) should be ready for a beta release by the Fedora 8 release
date, if not sooner. No matter if PyJigdo is ready, we can always use
jigdo-lite, but it doesn't integrate nicely with the mirror lists. We
could do a neat server side rewrite of the .jigdo data for the [Servers]
section to just dump in the geoIP list of servers for a given request
but I have given up on server side solutions in favor of a new and
better client. A spin shared with just jigdo-lite will do mirror
failover, which basically means the first mirror listed will get
pounded. To prevent this, end users will have to edit the [Servers]
section and that is not ideal. If the server-side rewrite of the
[Servers] section (based on geo-IP mirrormanager data) needs to be done,
it should be somewhat trivial but I'm not certain it would be scalable
as my last attempt at server-side solutions to the updates tree issues
was a failure.

Let Fedora Unity know, we are here for the community.

These are our stats for CD images for our Re-Spin:

Re-Spin Jigdo CD, Mirror Member 1: 261
Re-Spin Jigdo CD, Mirror Member 2: 204
GOLD CD Torrent (last 4 weeks): 760

These numbers are not "wow, we need to do CD images" but they would be
exponentially increased if they were for "official images" promoted by
the Fedora Project.

Just my $0.02

Jonathan Steffan
daMaestro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHGmoerRJs5w2Gr1kRAlD4AJ9wygUF0iYkOlygY9XCvBrXtv5maQCePUwn
fQK2LEPdId2eFYTt3qM90Tg=
=T3rb
-----END PGP SIGNATURE-----



From sundaram at fedoraproject.org  Sat Oct 20 20:00:34 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 21 Oct 2007 02:30:34 +0630
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A08.7070507@kanarip.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com>
Message-ID: <471A5E62.1050801@fedoraproject.org>

Jeroen van Meeuwen wrote:
> Rahul Sundaram wrote:
>> Jeroen van Meeuwen wrote:
>>
>>> I'm not misunderstanding the concept of a LiveCD in any way, I'm just 
>>> disagreeing about how important having CD media released by the 
>>> Fedora Project is exactly.
>>>
>>> So, not releasing CD sets is like saying you need to yum upgrade 
>>> although it is not recommended just because someone out there isn't 
>>> using the LiveCD installer because they tried Fedora and felt 
>>> comfortable. Someone is actually needing CD sets, and based on the 
>>> numbers that has been at least 760 people in the last 4 weeks.
>>
>> I think the better solution is to support live upgrades better and 
>> don't do multi arch in live images by default so that they fit into a 
>> CD for all architectures.
>>
>> Rahul
>>
> 
> If only we could fulfill todays needs with whatever the future promises.

The need is actually for the next release. There is no reason reason we 
couldn't do put more effort into what I had just outlined now onwards 
for the next development cycle. We could release Fedora 8 live images 
and when we release Fedora 9, we make live upgrades a supported option. 
That would solve the actual problem instead of working around it.

Rahul



From cra at WPI.EDU  Sat Oct 20 21:05:32 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 20 Oct 2007 17:05:32 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A1F.5000302@fedoraunity.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
Message-ID: <20071020210532.GE21171@angus.ind.WPI.EDU>

On Sat, Oct 20, 2007 at 02:50:39PM -0600, Jonathan Steffan wrote:
> Does anyone have the *technical* reason we are not doing CDs? Is this
> because we don't want to have mirrors hosting the additional data? I can
> assume the Live images have taken the space we have dedicated for CD
> ISOs in the past, is this the case? Is it the testing load.. or is it we
> don't want to have to maintain pkgorder in anaconda anymore? ;-)
>
... a whole lot about Jigdo and PyJigdo ...
>
> These are our stats for CD images for our Re-Spin:
> 
> Re-Spin Jigdo CD, Mirror Member 1: 261
> Re-Spin Jigdo CD, Mirror Member 2: 204
> GOLD CD Torrent (last 4 weeks): 760
> 
> These numbers are not "wow, we need to do CD images" but they would be
> exponentially increased if they were for "official images" promoted by
> the Fedora Project.

+1

I agree.  We should do CD images for Fedora 8.  Either by the regular 
ISO distribution, or via Jigdo.  Perhaps regular ISO for now, and work 
on Jigdo for Fedora 9.



From kanarip at kanarip.com  Sat Oct 20 21:06:50 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 23:06:50 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A1F.5000302@fedoraunity.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
Message-ID: <471A6DEA.1030805@kanarip.com>

Jonathan Steffan wrote:
> I hate to blatantly plug Fedora Unity, but we are doing some neat stuff.
> The Fedora Project could utilize some of the work we are doing,
> specifically with regards to Jigdo. If the issue is really an issue of
> storage space, a Spin of CD ISOs could be built against the GOLD tree
> (which wont have a changing package set and will survive the updates
> tree madness) and then shared via Jigdo. This would utilize the bits
> that are in the exploded GOLD tree (the release Everything tree)... not
> requiring mirrors to take on additional bits. Fedora Unity will be
> releasing GOLD CD iso images (if the Fedora Project wont), but I think
> we would prefer to "pass the buck" with regards to testing the Spin. If
> push comes to shove, I expect we'll do it. The only *real* drawback to
> Jigdo is the moving target of the updates repo for Re-Spins but this is
> another issue. I see *no* drawbacks to appeasing the remaining CD users
> by releasing a Spin, Jigdo only.
> 

Neither do I. Templates can be as thin as possible while mirrors also 
include the non-RPM parts when composed against the release tree that 
every mirror will carry. Major plus is that most parts can be used from 
the exploded tree, and that the DVD iso could be removed from the 
mirrors also.

> I think PyJigdo (a python based implementation on top of the existing
> Jigdo[1]) should be ready for a beta release by the Fedora 8 release
> date, if not sooner.

Like in the topic of trying jigdo some time ago it whould need to be 
first tested with the test releases... we're done with those. We could 
however try and make this a F9Feature.

> These are our stats for CD images for our Re-Spin:
> 
> Re-Spin Jigdo CD, Mirror Member 1: 261
> Re-Spin Jigdo CD, Mirror Member 2: 204
> GOLD CD Torrent (last 4 weeks): 760
> 

Mind that the GOLD CD sets on my torrents are listed on 
fp.o/wiki/CustomSpins :/

> These numbers are not "wow, we need to do CD images" but they would be
> exponentially increased if they were for "official images" promoted by
> the Fedora Project.
> 

Kind regards,

Jeroen van Meeuwen
-kanarip



From frank-buettner at gmx.net  Sat Oct 20 21:07:08 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sat, 20 Oct 2007 23:07:08 +0200
Subject: when will cvs reopen
Message-ID: <471A6DFC.4000307@gmx.net>

Hello,
has somebody infos when cvs will be reopen?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/d2ffb28a/attachment.bin>

From jon at fedoraunity.org  Sat Oct 20 21:09:40 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Sat, 20 Oct 2007 15:09:40 -0600
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A1F.5000302@fedoraunity.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
Message-ID: <471A6E94.3030900@fedoraunity.org>

Jonathan Steffan wrote:
> I think PyJigdo (a python based implementation on top of the existing
> Jigdo[1]) should be ready for a beta release by the Fedora 8 release
> date, if not sooner.

Ha ha.

[1] https://hosted.fedoraproject.org/projects/pyjigdo/
[1] http://pyjigdo.org/

Jonathan Steffan
daMaestro



From kanarip at kanarip.com  Sat Oct 20 21:17:42 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 23:17:42 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A5E62.1050801@fedoraproject.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>
	<471A5E62.1050801@fedoraproject.org>
Message-ID: <471A7076.5050404@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
>> Rahul Sundaram wrote:
>>> Jeroen van Meeuwen wrote:
>>>
>>>> I'm not misunderstanding the concept of a LiveCD in any way, I'm 
>>>> just disagreeing about how important having CD media released by the 
>>>> Fedora Project is exactly.
>>>>
>>>> So, not releasing CD sets is like saying you need to yum upgrade 
>>>> although it is not recommended just because someone out there isn't 
>>>> using the LiveCD installer because they tried Fedora and felt 
>>>> comfortable. Someone is actually needing CD sets, and based on the 
>>>> numbers that has been at least 760 people in the last 4 weeks.
>>>
>>> I think the better solution is to support live upgrades better and 
>>> don't do multi arch in live images by default so that they fit into a 
>>> CD for all architectures.
>>>
>>> Rahul
>>>
>>
>> If only we could fulfill todays needs with whatever the future promises.
> 
> The need is actually for the next release. There is no reason reason we 
> couldn't do put more effort into what I had just outlined now onwards 
> for the next development cycle. We could release Fedora 8 live images 
> and when we release Fedora 9, we make live upgrades a supported option. 
> That would solve the actual problem instead of working around it.
> 
> Rahul
> 

I'm sorry if I'm misunderstanding you but I don't think you can call 
what we had with FC6 and lost with F7 "a work around" for a problem that 
we've introduced with F8 -no upgrades using CDs.

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From jkeating at redhat.com  Sat Oct 20 21:16:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Oct 2007 17:16:38 -0400
Subject: when will cvs reopen
In-Reply-To: <471A6DFC.4000307@gmx.net>
References: <471A6DFC.4000307@gmx.net>
Message-ID: <20071020171638.6807e3ec@redhat.com>

On Sat, 20 Oct 2007 23:07:08 +0200
"Frank B?ttner" <frank-buettner at gmx.net> wrote:

> has somebody infos when cvs will be reopen?

It is taking longer than I expected, but I am still confident that CVS
will reopen within the next few hours.  There is only about 800
packages left to branch and we've got a slightly faster branching tool
chewing through these.  I'm still keeping my eye on it and will be able
to monitor it closer soon and restart it when necessary.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/a794cb66/attachment.sig>

From kanarip at kanarip.com  Sat Oct 20 21:21:55 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sat, 20 Oct 2007 23:21:55 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071020210532.GE21171@angus.ind.WPI.EDU>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A6A1F.5000302@fedoraunity.org>
	<20071020210532.GE21171@angus.ind.WPI.EDU>
Message-ID: <471A7173.4030806@kanarip.com>

Chuck Anderson wrote:
> On Sat, Oct 20, 2007 at 02:50:39PM -0600, Jonathan Steffan wrote:
>> Does anyone have the *technical* reason we are not doing CDs? Is this
>> because we don't want to have mirrors hosting the additional data? I can
>> assume the Live images have taken the space we have dedicated for CD
>> ISOs in the past, is this the case? Is it the testing load.. or is it we
>> don't want to have to maintain pkgorder in anaconda anymore? ;-)
>>
> ... a whole lot about Jigdo and PyJigdo ...
>> These are our stats for CD images for our Re-Spin:
>>
>> Re-Spin Jigdo CD, Mirror Member 1: 261
>> Re-Spin Jigdo CD, Mirror Member 2: 204
>> GOLD CD Torrent (last 4 weeks): 760
>>
>> These numbers are not "wow, we need to do CD images" but they would be
>> exponentially increased if they were for "official images" promoted by
>> the Fedora Project.
> 
> +1
> 
> I agree.  We should do CD images for Fedora 8.  Either by the regular 
> ISO distribution, or via Jigdo.  Perhaps regular ISO for now, and work 
> on Jigdo for Fedora 9.
> 

We'll have torrents for F8 CDs up in no-time added to 
fp.org/wiki/CustomSpins and the FAQ.

We're gonna want pyJigdo in F9 for mirror(-manager) compatibility 
purposes and the ability of also distributing Re-Spins, Re-Mixes and 
Fedora forks (based on Fedora distributions), perhaps a GUI front-end, 
maybe someone can help us making a multi-platform client. If you do, 
join #fedora-unity-devel on FreeNode.

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From sundaram at fedoraproject.org  Sat Oct 20 20:22:20 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 21 Oct 2007 02:52:20 +0630
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A7076.5050404@kanarip.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com>
Message-ID: <471A637C.9090009@fedoraproject.org>

Jeroen van Meeuwen wrote:

>>
> 
> I'm sorry if I'm misunderstanding you but I don't think you can call 
> what we had with FC6 and lost with F7 "a work around" for a problem that 
> we've introduced with F8 -no upgrades using CDs.

You are trying to workaround the lack of supported live upgrade by 
providing regular CD images.

We had installable live CD's which replace the regular cd's for Fedora 
7. The only problem with the replacement that I can see is that lack of 
a supported live upgrade. The fix IMO is to make it a supported option.

So if we release live images for Fedora 8 and make live upgrades 
supported when we release Fedora 9, what problems are left to solve?

Rahul



From frank-buettner at gmx.net  Sat Oct 20 21:32:18 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sat, 20 Oct 2007 23:32:18 +0200
Subject: when will cvs reopen
In-Reply-To: <20071020171638.6807e3ec@redhat.com>
References: <471A6DFC.4000307@gmx.net> <20071020171638.6807e3ec@redhat.com>
Message-ID: <471A73E2.8010300@gmx.net>

Jesse Keating schrieb:
> On Sat, 20 Oct 2007 23:07:08 +0200
> "Frank B?ttner" <frank-buettner at gmx.net> wrote:
> 
>> has somebody infos when cvs will be reopen?
> 
> It is taking longer than I expected, but I am still confident that CVS
> will reopen within the next few hours.  There is only about 800
> packages left to branch and we've got a slightly faster branching tool
> chewing through these.  I'm still keeping my eye on it and will be able
> to monitor it closer soon and restart it when necessary.
> 
> 
Thanks for the information.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/89cf5194/attachment.bin>

From ml at deadbabylon.de  Sat Oct 20 21:47:05 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Sat, 20 Oct 2007 23:47:05 +0200
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <c44298520710201242u13a865fag41ea31b3dd19850b@mail.gmail.com>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<4719C1B7.3080304@leemhuis.info>
	<c44298520710201242u13a865fag41ea31b3dd19850b@mail.gmail.com>
Message-ID: <200710202347.11135.ml@deadbabylon.de>

Am Sa 20.Oktober 2007 schrieb Hikaru Amano:
> On 10/20/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> > On 19.10.2007 23:41, Sebastian Vahl wrote:
> > > Am Mi 17.Oktober 2007 schrieb Jarod Wilson:
> > >> Author: jwilson
> > >>
> > >> Update of /cvs/pkgs/rpms/beryl-manager/devel
> > >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8532
> > >>
> > >> Added Files:
> > >>      dead.package
> > >> Removed Files:
> > >>      Makefile beryl-manager-0.1.4-pidof.patch beryl-manager.spec
> > >>      sources
> > >> Log Message:
> > >> Mark beryl bits as dead, since its merged back with current compiz
> > >
> > > Is it? As far as I know the former beryl-manager and beryl-settings are
> > > not in compiz-0.6.
> >
> > Just a note FYI: ccsm (successor of beryl-settings afaics) is under
> > review in https://bugzilla.redhat.com/show_bug.cgi?id=328981
> >
> > I've no idea is something like beryl-manager still exists in the new
> > merged world.
>
> it still exist, with the name fusion-icon (I think they call it
> compiz-fusion-icon now) .. however, upstream keep changing the name
> and the installation method, causing it hard to be packaged and
> reviewed ..
>
> maybe after upstream released a stable release, i'll package it ..

Do you mean this one? 
http://gitweb.opencompositing.org/?p=users/crdlb/fusion-icon;a=tree

There are existing two fusion-icon trees in compiz' git. Both of them are in 
the subtree for users. The other one seems to be quite old. 
The one above seems to be easy to package because it's based on python.  In a 
five-minutes-test based on an initially spec it also seems to work quite 
well. But your right: There should be released an official tarball/version 
first.

Sebastian
-------------- 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/20071020/3e29bea9/attachment.sig>

From ml at deadbabylon.de  Sat Oct 20 21:51:00 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Sat, 20 Oct 2007 23:51:00 +0200
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <4719C1B7.3080304@leemhuis.info>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<200710192341.37182.ml@deadbabylon.de>
	<4719C1B7.3080304@leemhuis.info>
Message-ID: <200710202351.00715.ml@deadbabylon.de>

Am Sa 20.Oktober 2007 schrieb Thorsten Leemhuis:
> On 19.10.2007 23:41, Sebastian Vahl wrote:
> > Am Mi 17.Oktober 2007 schrieb Jarod Wilson:
> >> Author: jwilson
> >>
> >> Update of /cvs/pkgs/rpms/beryl-manager/devel
> >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8532
> >>
> >> Added Files:
> >> 	dead.package
> >> Removed Files:
> >> 	Makefile beryl-manager-0.1.4-pidof.patch beryl-manager.spec
> >> 	sources
> >> Log Message:
> >> Mark beryl bits as dead, since its merged back with current compiz
> >
> > Is it? As far as I know the former beryl-manager and beryl-settings are
> > not in compiz-0.6.
>
> Just a note FYI: ccsm (successor of beryl-settings afaics) is under
> review in https://bugzilla.redhat.com/show_bug.cgi?id=328981

Thanks. I wasn't aware of this one. And also not that libcompizconfig and 
compizconfig-backend-gconf are also in review. So there's maybe time to get 
also compizconfig-backend-kconf in a review. At least that they also have 
released a tarball for compiz 0.6: 
http://releases.compiz-fusion.org/0.6.0/compizconfig-backend-kconfig-0.6.0.tar.bz2

Sebastian
-------------- 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/20071020/a48e7ba0/attachment.sig>

From kanarip at kanarip.com  Sat Oct 20 22:12:24 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 21 Oct 2007 00:12:24 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A637C.9090009@fedoraproject.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>
	<471A637C.9090009@fedoraproject.org>
Message-ID: <471A7D48.7070803@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
> 
>>>
>>
>> I'm sorry if I'm misunderstanding you but I don't think you can call 
>> what we had with FC6 and lost with F7 "a work around" for a problem 
>> that we've introduced with F8 -no upgrades using CDs.
> 
> You are trying to workaround the lack of supported live upgrade by 
> providing regular CD images.
> 

I'm providing CDs to fulfill what (obviously) many people need, you can 
hardly consider that a workaround rather then providing what was in FC6 
and lost in F7.

Sure the lack of supported for live upgrades is a problem that possibly 
could be delt with for F9, but that isn't the point here. When F9 is 
released some people will not have been able to upgrade for over a year. 
As the original post in this thread shows, this may have caused a dip in 
the F7 number of installs. Again, I'm providing those CD sets to enable 
people to deal with the Fedora Project not releasing any, and frankly, 
because I can. Not because I want to workaround the non-upgradeable but 
installable LiveCD, no matter how many times you repeat yourself and try 
and convince me it is a workaround from your point of view.

> We had installable live CD's which replace the regular cd's for Fedora 
> 7.

Obviously what we're arguing about here is that someone decided the 
installable LiveCDs were a perfect *replacement* and as many may have 
argued then, now it shows to be an incomplete replacement as not 
everything we could do with the CD sets we can do with LiveCDs.

  The only problem with the replacement that I can see is that lack of
> a supported live upgrade. The fix IMO is to make it a supported option.
> 
> So if we release live images for Fedora 8 and make live upgrades 
> supported when we release Fedora 9, what problems are left to solve?
> 

Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8 
using *just* CDs.

People may be running FC6 still because they haven't been able to 
upgrade to F7 -I guess some if not most of them moved on to another 
distribution.

So again if the Fedora Project doesn't actually release any CD sets for 
installation or upgrade, another set of off-site torrents will spawn and 
they'll be listed in CustomSpins (as non-official and non-approved), and 
they'll be listed in the FAQ (with all the not-released-by-FP notices). 
This will go on until there is a feasible successor. What the Fedora 
Project could do (as mentioned in my original reply to Mike) is link 
those torrents and/or provide a seed.

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From rodd at clarkson.id.au  Sat Oct 20 22:12:46 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 21 Oct 2007 08:12:46 +1000
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
	interaction for Fedora 8.
In-Reply-To: <20071019101244.7a7d62c7@redhat.com>
References: <20071019095919.54791e62@redhat.com>
	<1192803165.7047.29.camel@oneill.fubar.dk>
	<20071019101244.7a7d62c7@redhat.com>
Message-ID: <1192918382.2988.5.camel@localhost.localdomain>


On Fri, 2007-10-19 at 10:12 -0400, Jesse Keating wrote:
> On Fri, 19 Oct 2007 10:12:45 -0400
> David Zeuthen <david at fubar.dk> wrote:
> 
> > It's worse than that. When using Metacity, firefox jumps to the
> > workspace thus ruining your carefully set up workspaces. That's bug
> > 307581 which is almost certainly the same problem. Keep in mind that
> > our *default* install includes this very combo (multiple workspaces,
> > metacity, firefox). Yet, some people told me this wasn't a blocker...
> > Go figure. The good news is that there is patch.
> 
> and a build of metacity is done to fix this, and will be in Fedora 8.
> I'm not as concerned about the metacity case, mostly because I don't
> use it (:

Okay, and I know this opens a new can of worms, but I think it's
important that this is consistent across metacity and compiz (and
others?)

You shouldn't have to learn a new behavior because you switch your
desktop manager, especially since this is mostly about how to handle the
multiple desktop issue.

Granted, the different desktops work in different ways, but where
possible they should mimic each others behaviors.  After all, compiz is
the 3D version of Metacity (given that you're not adding compiz like
rendering into metacity since compiz does it).


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From sundaram at fedoraproject.org  Sat Oct 20 21:21:38 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 21 Oct 2007 03:51:38 +0630
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A7D48.7070803@kanarip.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>	<471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com>
Message-ID: <471A7162.4080004@fedoraproject.org>

Jeroen van Meeuwen wrote:


> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8 
> using *just* CDs.

Now we are talking about an actual problem which wasn't clear to me 
earlier. So if Fedora Project released regular CD's for this release and 
makes live upgrades a supported option from Fedora 9 onwards, do you see 
any need for a regular CD variant in the future?

Rahul




From valent.turkovic at gmail.com  Sat Oct 20 22:28:13 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 21 Oct 2007 00:28:13 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
Message-ID: <64b14b300710201528j9c58933ua90dc6da9d917743@mail.gmail.com>

I'm back on my original question.

On HP Pavilion dv6426us GPM shows:
Current Charge: 50.5 Wh
Designed charge: 88.8 Wh

and /proc show this:

# cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         6000 mAh
last full capacity:      4032 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 207 mAh
design capacity low:     125 mAh
capacity granularity 1:  10 mAh
capacity granularity 2:  25 mAh
model number:            Primary
serial number:
battery type:            LION
OEM info:                Hewlett-Packard


But I pulled the battery out and on the back of the battery on the
label it says:
10.8V and 47Wh

that is 4350 mAh not 6000 mAh as /proc info says... and design voltage
is also wrong.

On 10/18/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> Sorry for long subject, but what to do when gnome power manager shows
> wrong battery capacity?
>
> I have two laptops for who I see that battery capacity is stated as
> 88.8Wh but it is not! So when gnome starts I get an error message
> saying I have a faulty battery. What do I need to do? Submit a bug? To
> what component? Send an email? To whom?
>
> Thank you,
> Valent.
>
> --
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From mmcgrath at redhat.com  Sat Oct 20 22:27:27 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 20 Oct 2007 17:27:27 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A1F.5000302@fedoraunity.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
Message-ID: <471A80CF.1000300@redhat.com>

Jonathan Steffan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Does anyone have the *technical* reason we are not doing CDs? Is this
> because we don't want to have mirrors hosting the additional data? I can
> assume the Live images have taken the space we have dedicated for CD
> ISOs in the past, is this the case? Is it the testing load.. or is it we
> don't want to have to maintain pkgorder in anaconda anymore? ;-)
>   

I think the reason was just that the x86_64 install with multilib was 
not CD sized anymore.  At least not for one CD with a 'minimal' 
install.  Perhaps we should put a bounty out there for a single CD 
x86_64 install and see if anyone can do it :)

    -Mike



From pertusus at free.fr  Sat Oct 20 22:53:38 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Oct 2007 00:53:38 +0200
Subject: fortran 90 .mod files
Message-ID: <20071020225338.GC23353@free.fr>

Hello,

Currently there is no guideline regarding fortran 90 .mod, it seems to
me that one is needed. These files are generated by gfortran when
building a module. These are text files, but not intended to be read by
humans. They are architecture dependent. When compiling some code that
uses the module, the .mod has to be found in the include path (for
example in a directory specified by -I).

Where should the .mod be installed? I propose

%_libdir
%_libdir/include
%_libdir/modules
%_libdir/mod
%_libdir/f90
%_includedir/%_lib
%_includedir/%_lib/modules
%_includedir/%_lib/mod
%_includedir/%_lib/f90

(f90 may also be replaced by another meaningfull subdirectory name).

This directory could be called %_fmoddir

And add -I%_fmoddir in FFLAGS when compiling some code that
requires the module.


The optimal situation would be to have %_fmoddir defined in rpm macros
and -I%_fmoddir added to default FFLAGS.


So my first question is what is your advice about fortran modules
directories?

My second is, in case it is meaningful, what about my proposal regarding
rpm macros?

--
Pat



From jon at fedoraunity.org  Sat Oct 20 23:02:00 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Sat, 20 Oct 2007 17:02:00 -0600
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A80CF.1000300@redhat.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A6A1F.5000302@fedoraunity.org>
	<471A80CF.1000300@redhat.com>
Message-ID: <471A88E8.4090805@fedoraunity.org>

Mike McGrath wrote:
> I think the reason was just that the x86_64 install with multilib was
> not CD sized anymore.  At least not for one CD with a 'minimal'
> install.  Perhaps we should put a bounty out there for a single CD
> x86_64 install and see if anyone can do it :)

Ah, so it is pkgorder... (with regards to getting a base that is
multilib to fit in ~700MB) ;-)

So the problem is our "Base" group? Aka, we need to spend time on our
comps to list much more as optional? I suppose this also would affect
the x86 spin, making the "Base" install much smaller and thus not
utilizing the available 700MB? Is this a bad thing? (proposing
modifications to our groups definitions to bring multilib inline,
however, having the side-effect of reducing the package payload for a
"base" x86 install)

Jonathan Steffan
daMaestro



From jkeating at redhat.com  Sat Oct 20 23:15:46 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Oct 2007 19:15:46 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A6A1F.5000302@fedoraunity.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
Message-ID: <20071020191546.3623ff1f@redhat.com>

On Sat, 20 Oct 2007 14:50:39 -0600
Jonathan Steffan <jon at fedoraunity.org> wrote:

> Does anyone have the *technical* reason we are not doing CDs?

It was a combination of a drop in hardware that has CD only drives (and
still powerful enough to run Fedora), the increase in QA targets with
the introduction of all the Live spins and there was potential for
multiple choose your own adventure spins, which doing CD variants of
all of those again increases the compose times, the QA targets, the
increased duplication of content we're asking mirrors to handle, the
increase in time it would take to rsync those bits around, and it was
an experiment.  We at a project level didn't see a whole lot of yelling
and screaming about missing CD images so we did it again with F8, but
late in F8 the noise swell has reached something of a critical mass,
add to that we're only doing one choose your own adventure set so a
matching CD set just for that isn't too unreasonable.  Unfortunately
it's way too late for F8 to re-introduce another install method and
jump the size of the tree by a good chunk.  We'll likely introduce CDs
to complement the Fedora DVD install with the Alpha (should we go the
Alpha/Beta/RC/Final route) of F9.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/f817ac66/attachment.sig>

From sundaram at fedoraproject.org  Sat Oct 20 22:29:26 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 21 Oct 2007 04:59:26 +0630
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071020191546.3623ff1f@redhat.com>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A6A1F.5000302@fedoraunity.org>
	<20071020191546.3623ff1f@redhat.com>
Message-ID: <471A8146.8060506@fedoraproject.org>

Jesse Keating wrote:
   We at a project level didn't see a whole lot of yelling
> and screaming about missing CD images so we did it again with F8, but
> late in F8 the noise swell has reached something of a critical mass,
> add to that we're only doing one choose your own adventure set so a
> matching CD set just for that isn't too unreasonable.  

I am not sure what channels you were watching to get user feedback but 
both in users lists, forums and elsewhere there was a lot of users 
asking for CD variants. This I understood as a combination of several things

1) The download page and other documentation didn't make it entirely 
obvious that live images are installable.

2) The x86_64 image is not regular CD size

3) Lack of a supported live upgrade path.

We are in the process of solving 1) but the rest of the problems still 
remain and IMO 2) should be solved by reducing the package set or 
dropping multi-lib and default and 3) can be solved by a commitment to 
supporting live upgrades better for the next release.

Unfortunately
> it's way too late for F8 to re-introduce another install method and
> jump the size of the tree by a good chunk. 

We could do a torrent only release still. Some mirrors might be willing 
to carry it if we ask.

Rahul



From jkeating at redhat.com  Sun Oct 21 00:34:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Oct 2007 20:34:28 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A8146.8060506@fedoraproject.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A6A1F.5000302@fedoraunity.org>
	<20071020191546.3623ff1f@redhat.com>
	<471A8146.8060506@fedoraproject.org>
Message-ID: <20071020203428.38a780d1@redhat.com>

On Sun, 21 Oct 2007 04:59:26 +0630
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> We could do a torrent only release still. Some mirrors might be
> willing to carry it if we ask.

That only solves part of the problem.  We haven't done CD based
installs at all this development cycle and there is a lot of code path
for those that just hasn't seen work, certainly not work in the wide
variety of usage cases that our community throws at it.  I'm not
comfortable putting an install type out there as an official release
without having the benefit of at least a couple pre-release gauntlets. 

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/76590e6a/attachment.sig>

From kagesenshi.87 at gmail.com  Sun Oct 21 01:06:21 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Sun, 21 Oct 2007 09:06:21 +0800
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <200710202347.11135.ml@deadbabylon.de>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<4719C1B7.3080304@leemhuis.info>
	<c44298520710201242u13a865fag41ea31b3dd19850b@mail.gmail.com>
	<200710202347.11135.ml@deadbabylon.de>
Message-ID: <c44298520710201806t14f5784agb75c4af3004429e@mail.gmail.com>

On 10/21/07, Sebastian Vahl <ml at deadbabylon.de> wrote:
> Do you mean this one?
> http://gitweb.opencompositing.org/?p=users/crdlb/fusion-icon;a=tree
>
> There are existing two fusion-icon trees in compiz' git. Both of them are in
> the subtree for users. The other one seems to be quite old.
> The one above seems to be easy to package because it's based on python.  In a
> five-minutes-test based on an initially spec it also seems to work quite
> well. But your right: There should be released an official tarball/version
> first.

once the installer uses a Makefile .. then setup.py .. then they added
some new files .. then they removed some files ... and just recently
they've done a full rewrite ... thats why i think its better for them
to release an official tarball first before started doing any real
packaging for it ..

On 10/21/07, Sebastian Vahl <ml at deadbabylon.de> wrote:
> Thanks. I wasn't aware of this one. And also not that libcompizconfig and
> compizconfig-backend-gconf are also in review. So there's maybe time to get

libcompizconfig barely made it before the freeze ...ccs-backend-gconf
and ccs-python just passed review and waiting for cvs .. ccsm still
under review .. i'll add ccs-backend-kconfig later

> also compizconfig-backend-kconf in a review. At least that they also have
> released a tarball for compiz 0.6:
> http://releases.compiz-fusion.org/0.6.0/compizconfig-backend-kconfig-0.6.0.tar.bz2

ey? .. they already put the tarball there? .. on 18th oct they
announce they are still preparing for 0.6.0 release, but seems like
they've put some bits there ...



-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From kagesenshi.87 at gmail.com  Sun Oct 21 02:00:10 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Sun, 21 Oct 2007 10:00:10 +0800
Subject: rpms/beryl-manager/devel dead.package, NONE, 1.1 Makefile, 1.1,
	NONE beryl-manager-0.1.4-pidof.patch, 1.1,
	NONE beryl-manager.spec, 1.12, NONE sources, 1.9, NONE
In-Reply-To: <c44298520710201806t14f5784agb75c4af3004429e@mail.gmail.com>
References: <200710171719.l9HHJKRJ008539@cvs-int.fedora.redhat.com>
	<4719C1B7.3080304@leemhuis.info>
	<c44298520710201242u13a865fag41ea31b3dd19850b@mail.gmail.com>
	<200710202347.11135.ml@deadbabylon.de>
	<c44298520710201806t14f5784agb75c4af3004429e@mail.gmail.com>
Message-ID: <c44298520710201900j25e6adabice28df6fe6b9bf34@mail.gmail.com>

>
> ey? .. they already put the tarball there? .. on 18th oct they
> announce they are still preparing for 0.6.0 release, but seems like
> they've put some bits there ...
>

okay .. the announcement was made half an hour ago :)
http://smspillaz.wordpress.com/2007/10/21/compiz-fusion-060-is-released/

-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From jkeating at redhat.com  Sun Oct 21 02:04:39 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 20 Oct 2007 22:04:39 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071020095212.402c5849@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
Message-ID: <20071020220439.5fa885a1@redhat.com>

On Sat, 20 Oct 2007 09:52:12 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> > We're ready to try the branching again.  CVS will be disabled for
> > commits in a few moments.  I will reply when the branching is
> > done.  

The branching is done.  CVS commits have been re-enabled.  If your
package is missing an F-8 branch please mail rel-eng at fedoraproject.org
and we'll look into it.

Again, sorry for the extended outage.  Happy committing!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071020/87bf253b/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From rc040203 at freenet.de  Sun Oct 21 03:36:04 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Oct 2007 05:36:04 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1192937764.25729.31.camel@mccallum.corsepiu.local>

On Sat, 2007-10-20 at 10:31 +0200, Michael Schwendt wrote:
> On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:
> 
> > On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
> > > On Fri, 19 Oct 2007 17:18:15 -0500
> > > Eric Sandeen <sandeen redhat com> wrote:
> > > 
> > > > You could probably just add a patch to modify the shipped
> > > > docs/api_footer.html file to remove the timestamp?
> > > 
> > > Are these docs generated at build time?  If so the timestamps will
> > > still differ and conflict.
> > 
> > Does rpm complain about differing timestamps on files, while the
> > contents is identical?
> 
> Eric refers to timestamps _in_ the files, however.
That was clear. He used doxygen's textual timestamps as example.

I was referring to filesystem timestamps (stat(2)). They will differ on
generated files in a multiarch'ed setup even if "textual timestamps"
have been filtered/removed.

Ralf





From sandeen at redhat.com  Sun Oct 21 04:12:09 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 23:12:09 -0500
Subject: who pushes fc6 security updates?
Message-ID: <471AD199.8080104@redhat.com>

I have a security update for FC6 (for xfsdump) which addresses
CVE-2007-2654.

I marked it as security, and it seems that perhaps therefore I can't be
the one who pushes it out?  At least the email I get says:

Your update for xfsdump-2.2.45-1.fc6 has not yet been submitted to the
Release Team for Pushing.

To submit this update, please visit the following URL and select "Submit
to Release Team for Pushing"

... but I don't see that option at the given URL, only:

Actions:
	o Edit Update
	o Delete Update
	o Disable periodic notifications regarding this update

Help? :)

-Eric



From sandeen at redhat.com  Sun Oct 21 04:14:41 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 20 Oct 2007 23:14:41 -0500
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192937764.25729.31.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>	<47192ABD.6090108@redhat.com>	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>	<47192D27.4070700@redhat.com>
	<20071019225836.18a17d23@redhat.com>	<1192849643.25729.11.camel@mccallum.corsepiu.local>	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
Message-ID: <471AD231.3050802@redhat.com>

Ralf Corsepius wrote:
> On Sat, 2007-10-20 at 10:31 +0200, Michael Schwendt wrote:
>> On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:
>>
>>> On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
>>>> On Fri, 19 Oct 2007 17:18:15 -0500
>>>> Eric Sandeen <sandeen redhat com> wrote:
>>>>
>>>>> You could probably just add a patch to modify the shipped
>>>>> docs/api_footer.html file to remove the timestamp?
>>>> Are these docs generated at build time?  If so the timestamps will
>>>> still differ and conflict.
>>> Does rpm complain about differing timestamps on files, while the
>>> contents is identical?
>> Eric refers to timestamps _in_ the files, however.
> That was clear. He used doxygen's textual timestamps as example.
> 
> I was referring to filesystem timestamps (stat(2)). They will differ on
> generated files in a multiarch'ed setup even if "textual timestamps"
> have been filtered/removed.

Anyway, I think the answer is: RPM won't complain at install time, near
as I can tell, but if you do rpm -V later you'll see "T" (mtime
mismatch) flags.

...and from elsewhere in the thread, unless you install carefully
(install -p) it's not just generated files that'll mismatch but even
header files that were copied into a devel rpm.

-Eric



From rc040203 at freenet.de  Sun Oct 21 04:55:25 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Oct 2007 06:55:25 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <471AD231.3050802@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
Message-ID: <1192942525.25729.36.camel@mccallum.corsepiu.local>

On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> Ralf Corsepius wrote:

> ...and from elsewhere in the thread, unless you install carefully
> (install -p) it's not just generated files that'll mismatch but even
> header files that were copied into a devel rpm.
Well, my view is converse: "install -p" doesn't solve anything, because
it doesn't work on generated files.

Ralf




From harald at redhat.com  Sat Oct 20 08:37:15 2007
From: harald at redhat.com (Harald Hoyer)
Date: Sat, 20 Oct 2007 10:37:15 +0200
Subject: does cdrecord work these days?
In-Reply-To: <1192862335.4422.2.camel@perihelion>
References: <1192862335.4422.2.camel@perihelion>
Message-ID: <ffcens$hap$1@ger.gmane.org>

Jon Masters wrote:
> Yo,
> 
> So growisofs in F8T3 seems to be able to actually burn a DVD, but
> cdrecord, while about to scan a bus, won't burn using any of the options
> I've historically used, and do in fact use on RHEL5.
> 
> Question is, should it (where it is whatever reincarnation exists these
> days since whatever latest issue of cdrecord played out...) be working
> or am I encountering known behavior?
> 
> Jon.
> 
> 

$ cdrecord dev=/dev/dvdrw image.iso

should work with mmc-compliant drives.



From dan at danny.cz  Sun Oct 21 06:54:53 2007
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 21 Oct 2007 08:54:53 +0200
Subject: Multiarch conflicts on packages with resources
In-Reply-To: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
Message-ID: <1192949693.4270.17.camel@eagle.danny.cz>

Christopher Stone p??e v P? 19. 10. 2007 v 15:02 -0700:
> I am getting a multiarch conflict on %doc files in a devel
> subpackage[1].  Are we supposed to avoid %doc files in devel packages
> for multiarch purposes, or am I doing something wrong in my spec, or
> is this a multiarch rpm bug?

I have similar problem on a subpackage, which contains additional
plugins + their resources [1]. The main source package (codeblocks) is
divided into 4 binary subpackages
- codeblocks - main executable, default plugins + their resources
- codeblocks-libs - shared libraries for the main executable and plugins
- codeblocks-devel - devel libraries and headers
- codeblocks-contrib - additional plugins + their resources

The resources are packed from source files with zip during building of
the package. The -devel and -libs subpackage are multiarch aware AFAIK
[2], but there is no reason to install both 32 and 64 bit version of the
main subpackage and the -contrib subpackage. Does anybody see a way, how
to fix this, when creating noarch subpackages for an arch package is not
possible?


	Thanks
		Dan


[1] https://bugzilla.redhat.com/show_bug.cgi?id=340911
[2] https://bugzilla.redhat.com/show_bug.cgi?id=228356




From valent.turkovic at gmail.com  Sun Oct 21 08:18:23 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 21 Oct 2007 10:18:23 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<1192714622.8542.104.camel@cutter>
	<64b14b300710180717n4210c6e3pe6cf8c4f088b3f2e@mail.gmail.com>
Message-ID: <64b14b300710210118y41b0e1e7ycf5fad72718cb165@mail.gmail.com>

I also checked my old HP nx9030 and the battery label says this:

11.1V and 4400mAh (which is 48.84Wh) but GPM says that design charge is 88.8Wh!

This is obviously not correct - I can provide the photo from the
battery label if you don't trust me.

here is other info from HP nx9030 laptop battery:

# cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         6000 mAh
last full capacity:      2528 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 250 mAh
design capacity low:     150 mAh
capacity granularity 1:  10 mAh
capacity granularity 2:  25 mAh
model number:            JM-6
serial number:           4063
battery type:            LION
OEM info:                Hewlett-Packard

# cat /proc/acpi/battery/BAT0/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1419 mA
remaining capacity:      2272 mAh
present voltage:         11316 mV


On 10/18/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> Here is the info from 2 year oly HP Compaq nx9030:
>
> # cat /proc/acpi/battery/BAT0/info
> present:                 yes
> design capacity:         6000 mAh
> last full capacity:      2784 mAh
> battery technology:      rechargeable
> design voltage:          14800 mV
> design capacity warning: 250 mAh
> design capacity low:     150 mAh
> capacity granularity 1:  10 mAh
> capacity granularity 2:  25 mAh
> model number:            JM-6
> serial number:           4063
> battery type:            LION
> OEM info:                Hewlett-Packard
>
>
> and GPM says this:
>
> Vendor: Hewlett-Packard
> Serial Number: 4063
> Model: JM-6
> Current charge: 34.6 Wh
> Design charge: 88 Wh
>
> Who is showing wrong info?
>
> On 10/18/07, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> > On Thu, 2007-10-18 at 15:35 +0200, Valent Turkovic wrote:
> > > Sorry for long subject, but what to do when gnome power manager shows
> > > wrong battery capacity?
> > >
> > > I have two laptops for who I see that battery capacity is stated as
> > > 88.8Wh but it is not! So when gnome starts I get an error message
> > > saying I have a faulty battery. What do I need to do? Submit a bug? To
> > > what component? Send an email? To whom?
> > >
> > > Thank you,
> > > Valent.
> > >
> >
> > how old are the batteries?
> >
> > If they're more than say, a year old, it's probably true. battery charge
> > life declines. Get the info on your battery by clicking on the
> > gnome-power-manager icon and you can find out the info on your battery.
> >
> > -sv
> >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
>
> --
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From pertusus at free.fr  Sun Oct 21 08:50:28 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Oct 2007 10:50:28 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192942525.25729.36.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
	<1192942525.25729.36.camel@mccallum.corsepiu.local>
Message-ID: <20071021085028.GA2625@free.fr>

On Sun, Oct 21, 2007 at 06:55:25AM +0200, Ralf Corsepius wrote:
> On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > Ralf Corsepius wrote:
> 
> > ...and from elsewhere in the thread, unless you install carefully
> > (install -p) it's not just generated files that'll mismatch but even
> > header files that were copied into a devel rpm.
> Well, my view is converse: "install -p" doesn't solve anything, because
> it doesn't work on generated files.

At least it allows to have timestamps kept for unmodified files. But
indeed some touch -r is needed for generated files timestamps.

http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

--
Pat



From rc040203 at freenet.de  Sun Oct 21 09:08:30 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Oct 2007 11:08:30 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071021085028.GA2625@free.fr>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
	<1192942525.25729.36.camel@mccallum.corsepiu.local>
	<20071021085028.GA2625@free.fr>
Message-ID: <1192957710.25729.41.camel@mccallum.corsepiu.local>

On Sun, 2007-10-21 at 10:50 +0200, Patrice Dumas wrote:
> On Sun, Oct 21, 2007 at 06:55:25AM +0200, Ralf Corsepius wrote:
> > On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > > Ralf Corsepius wrote:
> > 
> > > ...and from elsewhere in the thread, unless you install carefully
> > > (install -p) it's not just generated files that'll mismatch but even
> > > header files that were copied into a devel rpm.
> > Well, my view is converse: "install -p" doesn't solve anything, because
> > it doesn't work on generated files.
> 
> At least it allows to have timestamps kept for unmodified files.
And which problem does this solve?

IMO, the answer is: Nothing.

Ralf




From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 21 09:33:17 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 21 Oct 2007 11:33:17 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192942525.25729.36.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
	<1192942525.25729.36.camel@mccallum.corsepiu.local>
Message-ID: <20071021113317.19ef209b.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 21 Oct 2007 06:55:25 +0200, Ralf Corsepius wrote:

> On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > Ralf Corsepius wrote:
> 
> > ...and from elsewhere in the thread, unless you install carefully
> > (install -p) it's not just generated files that'll mismatch but even
> > header files that were copied into a devel rpm.
> Well, my view is converse: "install -p" doesn't solve anything, because
> it doesn't work on generated files.

Right. Originally, the reason why "install -p" and "cp -p" have made
it into pkg review comments is only that _old_ files from tarballs (or
additional SourceX tags) stay _old_ when copying them into the rpm
buildroot -- i.e. their old timestamps are preserved. That way the pkg
users can see the age of files more easily and see when a file has
been updated last. There is a relevant use-case for %doc and %config
at least. It helps a lot upon deciding which files to revisit, e.g.
after a quarterly update, since a fresh timestamp of a %doc file won't
pretend that a pdf/ps manual is a revision from last month when in
fact it has been created in 2001 once and never updated since.



From kanarip at kanarip.com  Sun Oct 21 10:04:52 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 21 Oct 2007 12:04:52 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471A7162.4080004@fedoraproject.org>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>
	<471A7162.4080004@fedoraproject.org>
Message-ID: <471B2444.8030901@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
> 
> 
>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8 
>> using *just* CDs.
> 
> Now we are talking about an actual problem which wasn't clear to me 
> earlier. So if Fedora Project released regular CD's for this release and 
> makes live upgrades a supported option from Fedora 9 onwards, do you see 
> any need for a regular CD variant in the future?
> 

Other then for it's sentimental value, the impressive number of discs 
for the Everything spin or laptop-in-the-bush cases, there's no real 
need for CD's. The few people that want a customized install with all 
kinds of exotic partitioning schemes (or minimal installs) should either 
be able to create CDs off the DVD iso or get the CDs from any third 
party providing them.

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08



From jcm at redhat.com  Sun Oct 21 10:39:20 2007
From: jcm at redhat.com (Jon Masters)
Date: Sun, 21 Oct 2007 06:39:20 -0400
Subject: does cdrecord work these days?
In-Reply-To: <3170f42f0710200013g7d8a083er31c6f23e91bf9f45@mail.gmail.com>
References: <1192862335.4422.2.camel@perihelion>
	<3170f42f0710200013g7d8a083er31c6f23e91bf9f45@mail.gmail.com>
Message-ID: <1192963161.5168.33.camel@perihelion>


On Sat, 2007-10-20 at 12:43 +0530, Debarshi 'Rishi' Ray wrote:
> > So growisofs in F8T3 seems to be able to actually burn a DVD, but
> > cdrecord, while about to scan a bus, won't burn using any of the options
> > I've historically used, and do in fact use on RHEL5.
> 
> cdrecord has been replaced by Wodim. The cdrecord command is a symlink to wodim.

Granted. But that wasn't really the question - in any case, I'm using
growisofs so it's not a huge problem, cdrecord doesn't work for me (I'm
only using the same command I've used for 4 or 5 years...).

Jon.




From bnocera at redhat.com  Sun Oct 21 11:19:50 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Sun, 21 Oct 2007 12:19:50 +0100
Subject: Merging totem and totem-xine
In-Reply-To: <471A5A84.2050707@kanarip.com>
References: <1191890955.14085.11.camel@Diffingo.localdomain>
	<471A5A84.2050707@kanarip.com>
Message-ID: <1192965590.13923.10.camel@cookie.hadess.net>


On Sat, 2007-10-20 at 21:44 +0200, Jeroen van Meeuwen wrote:
> Stewart Adam wrote:
> > Hi,
> > 
> > Since xine-lib has been moved to Fedora, I realized so could totem-xine.
> > I've been working on a totem spec that includes both gstreamer and xine
> > backends. As of now, the spec generates the usual subpackages plus
> > 'totem-gstreamer' and 'totem-xine' which contain the binaries for the
> > gstreamer- and xine-based binary totem. I've used --program-suffix at
> > compile time, so they are parallel installable.
> > 
> > What do you think the best approach is to packaging this, if at all? Two
> > options I'm thinking of are having the two engines conflict or using
> > alternatives to have a configurable backend (switching "on demand").
> > 
> > Stewart
> > 
> 
> I've not read the entire thread yet but does this apply to 
> totem-xine-plarser and totem-plparser as well?

That's a side-effect of having 2 different source RPMs. There won't be 2
packages containing the exact same library anymore.



From bnocera at redhat.com  Sun Oct 21 11:26:52 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Sun, 21 Oct 2007 12:26:52 +0100
Subject: does cdrecord work these days?
In-Reply-To: <1192963161.5168.33.camel@perihelion>
References: <1192862335.4422.2.camel@perihelion>
	<3170f42f0710200013g7d8a083er31c6f23e91bf9f45@mail.gmail.com>
	<1192963161.5168.33.camel@perihelion>
Message-ID: <1192966012.13923.13.camel@cookie.hadess.net>


On Sun, 2007-10-21 at 06:39 -0400, Jon Masters wrote:
> On Sat, 2007-10-20 at 12:43 +0530, Debarshi 'Rishi' Ray wrote:
> > > So growisofs in F8T3 seems to be able to actually burn a DVD, but
> > > cdrecord, while about to scan a bus, won't burn using any of the options
> > > I've historically used, and do in fact use on RHEL5.
> > 
> > cdrecord has been replaced by Wodim. The cdrecord command is a symlink to wodim.
> 
> Granted. But that wasn't really the question - in any case, I'm using
> growisofs so it's not a huge problem, cdrecord doesn't work for me (I'm
> only using the same command I've used for 4 or 5 years...).

growisofs is for DVDs, cdrecord isn't (unless you're using J?rg's
upstream cdrecord or the hack that's dvdrecord).



From jkeating at redhat.com  Sun Oct 21 11:56:33 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Oct 2007 07:56:33 -0400
Subject: who pushes fc6 security updates?
In-Reply-To: <471AD199.8080104@redhat.com>
References: <471AD199.8080104@redhat.com>
Message-ID: <20071021075633.3d64d9bc@redhat.com>

On Sat, 20 Oct 2007 23:12:09 -0500
Eric Sandeen <sandeen at redhat.com> wrote:

> To submit this update, please visit the following URL and select
> "Submit to Release Team for Pushing"
> 
> ... but I don't see that option at the given URL, only:

Do you see that URL when you edit update?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071021/d08a9c1d/attachment.sig>

From jkeating at redhat.com  Sun Oct 21 11:58:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Oct 2007 07:58:38 -0400
Subject: Multiarch conflicts on packages with resources
In-Reply-To: <1192949693.4270.17.camel@eagle.danny.cz>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192949693.4270.17.camel@eagle.danny.cz>
Message-ID: <20071021075838.0ec06d25@redhat.com>

On Sun, 21 Oct 2007 08:54:53 +0200
"Dan Hor?k" <dan at danny.cz> wrote:

> The resources are packed from source files with zip during building of
> the package. The -devel and -libs subpackage are multiarch aware AFAIK
> [2], but there is no reason to install both 32 and 64 bit version of
> the main subpackage and the -contrib subpackage. Does anybody see a
> way, how to fix this, when creating noarch subpackages for an arch
> package is not possible?

It would be best to discover why both arches of codeblocks are being
tagged as multilib.  Is there still some library left that is in the
codeblocks package?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071021/8042aa8e/attachment.sig>

From rc040203 at freenet.de  Sun Oct 21 12:02:00 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Oct 2007 14:02:00 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071021113317.19ef209b.mschwendt.tmp0701.nospam@arcor.de>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
	<1192942525.25729.36.camel@mccallum.corsepiu.local>
	<20071021113317.19ef209b.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1192968120.25729.50.camel@mccallum.corsepiu.local>

On Sun, 2007-10-21 at 11:33 +0200, Michael Schwendt wrote:
> On Sun, 21 Oct 2007 06:55:25 +0200, Ralf Corsepius wrote:
> 
> > On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > > Ralf Corsepius wrote:
> > 
> > > ...and from elsewhere in the thread, unless you install carefully
> > > (install -p) it's not just generated files that'll mismatch but even
> > > header files that were copied into a devel rpm.
> > Well, my view is converse: "install -p" doesn't solve anything, because
> > it doesn't work on generated files.
> 
> Right. Originally, the reason why "install -p" and "cp -p" have made
> it into pkg review comments is only that _old_ files from tarballs (or
> additional SourceX tags) stay _old_ when copying them into the rpm
> buildroot -- i.e. their old timestamps are preserved. That way the pkg
> users
^^^^^^^ => It's just convenience to cater certain user habits. 

Technically, it's sense-free eye-candy.

>  can see the age of files more easily and see when a file has
> been updated last.

>  There is a relevant use-case for %doc and %config
> at least.
How? %doc are completely irrelevant to an installed system, for %config
it's contents that matters (did the files contents change?), not
timestamps.

There is only one use case, where it really matters: time-based
dependencies. Such cases normally only occur for back ups and for
expanded build-trees. 

Ralf






From rc040203 at freenet.de  Sun Oct 21 12:04:49 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 21 Oct 2007 14:04:49 +0200
Subject: Multiarch conflicts on packages with resources
In-Reply-To: <20071021075838.0ec06d25@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192949693.4270.17.camel@eagle.danny.cz>
	<20071021075838.0ec06d25@redhat.com>
Message-ID: <1192968289.25729.54.camel@mccallum.corsepiu.local>

On Sun, 2007-10-21 at 07:58 -0400, Jesse Keating wrote:
> On Sun, 21 Oct 2007 08:54:53 +0200
> "Dan Hor?k" <dan at danny.cz> wrote:
> 
> > The resources are packed from source files with zip during building of
> > the package. The -devel and -libs subpackage are multiarch aware AFAIK
> > [2], but there is no reason to install both 32 and 64 bit version of
> > the main subpackage and the -contrib subpackage. Does anybody see a
> > way, how to fix this, when creating noarch subpackages for an arch
> > package is not possible?
> 
> It would be best to discover why both arches of codeblocks are being
> tagged as multilib.  Is there still some library left that is in the
> codeblocks package?
The codeblocks issue seems to be timestamps on otherwise identical files
inside of *.zip's archives. I would assume touch and timestamp magic
during building these packages would be able to fix this issue.

Ralf





From jkeating at redhat.com  Sun Oct 21 12:05:25 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Oct 2007 08:05:25 -0400
Subject: Multiarch conflicts on packages with resources
In-Reply-To: <20071021075838.0ec06d25@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192949693.4270.17.camel@eagle.danny.cz>
	<20071021075838.0ec06d25@redhat.com>
Message-ID: <20071021080525.4703e2db@redhat.com>

On Sun, 21 Oct 2007 07:58:38 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> > The resources are packed from source files with zip during building
> > of the package. The -devel and -libs subpackage are multiarch aware
> > AFAIK [2], but there is no reason to install both 32 and 64 bit
> > version of the main subpackage and the -contrib subpackage. Does
> > anybody see a way, how to fix this, when creating noarch
> > subpackages for an arch package is not possible?  
> 
> It would be best to discover why both arches of codeblocks are being
> tagged as multilib.  Is there still some library left that is in the
> codeblocks package?

Bingo.  The main subpackage isn't multilib.  However the
codeblocks-contrib package /is/ because it installs a library in the
standard library path:

/usr/lib64/libwxsmithlib.so.0
/usr/lib64/libwxsmithlib.so.0.0.1


-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071021/cd6effec/attachment.sig>

From dan at danny.cz  Sun Oct 21 12:30:51 2007
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 21 Oct 2007 14:30:51 +0200
Subject: Multiarch conflicts on packages with resources
In-Reply-To: <20071021080525.4703e2db@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192949693.4270.17.camel@eagle.danny.cz>
	<20071021075838.0ec06d25@redhat.com>
	<20071021080525.4703e2db@redhat.com>
Message-ID: <1192969851.3298.2.camel@certp>

Jesse Keating p??e v Ne 21. 10. 2007 v 08:05 -0400:
> On Sun, 21 Oct 2007 07:58:38 -0400
> Jesse Keating <jkeating at redhat.com> wrote:
> 
> > > The resources are packed from source files with zip during building
> > > of the package. The -devel and -libs subpackage are multiarch aware
> > > AFAIK [2], but there is no reason to install both 32 and 64 bit
> > > version of the main subpackage and the -contrib subpackage. Does
> > > anybody see a way, how to fix this, when creating noarch
> > > subpackages for an arch package is not possible?  
> > 
> > It would be best to discover why both arches of codeblocks are being
> > tagged as multilib.  Is there still some library left that is in the
> > codeblocks package?
> 
> Bingo.  The main subpackage isn't multilib.  However the
> codeblocks-contrib package /is/ because it installs a library in the
> standard library path:
> 
> /usr/lib64/libwxsmithlib.so.0
> /usr/lib64/libwxsmithlib.so.0.0.1

Then I will create a new subpackage -contrib-libs, thanks Jesse.


		Dan




From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 21 13:18:41 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 21 Oct 2007 15:18:41 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1192968120.25729.50.camel@mccallum.corsepiu.local>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <20071019225836.18a17d23@redhat.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020103146.d644c95f.mschwendt.tmp0701.nospam@arcor.de>
	<1192937764.25729.31.camel@mccallum.corsepiu.local>
	<471AD231.3050802@redhat.com>
	<1192942525.25729.36.camel@mccallum.corsepiu.local>
	<20071021113317.19ef209b.mschwendt.tmp0701.nospam@arcor.de>
	<1192968120.25729.50.camel@mccallum.corsepiu.local>
Message-ID: <20071021151841.c741c238.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 21 Oct 2007 14:02:00 +0200, Ralf Corsepius wrote:

> > > > ...and from elsewhere in the thread, unless you install carefully
> > > > (install -p) it's not just generated files that'll mismatch but even
> > > > header files that were copied into a devel rpm.
> > > Well, my view is converse: "install -p" doesn't solve anything, because
> > > it doesn't work on generated files.
> > 
> > Right. Originally, the reason why "install -p" and "cp -p" have made
> > it into pkg review comments is only that _old_ files from tarballs (or
> > additional SourceX tags) stay _old_ when copying them into the rpm
> > buildroot -- i.e. their old timestamps are preserved. That way the pkg
> > users
> ^^^^^^^ => It's just convenience to cater certain user habits. 
> 
> Technically, it's sense-free eye-candy.

I don't disagree.

Except that I see the value in preserving [old!] timestamps as explained
in the prev.msg.

> >  can see the age of files more easily and see when a file has
> > been updated last.
> 
> >  There is a relevant use-case for %doc and %config
> > at least.
> How? %doc are completely irrelevant to an installed system,

Why?

> for %config
> it's contents that matters (did the files contents change?), not
> timestamps.

Yes, sure, but for changed contents we have the *.rpmnew/*.rpmsave
mechanism already. For config file templates, default config files or
[init]scripts we don't. Why pretend that a config file (or a file added
via SourceX) is from 2007-10-21 when in fact it has not been changed
for several years? Such a superfluous change in the timestamps also
can result in an unneeded IDS report everytime a pkg is updated.



From pmatilai at laiskiainen.org  Sun Oct 21 13:19:51 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 21 Oct 2007 16:19:51 +0300 (EEST)
Subject: functionality similar to apt-get autoclean?
In-Reply-To: <loom.20071020T174814-347@post.gmane.org>
References: <20071020100327.1301f856@rnslappy.sonic.net>
	<471A2B92.5070803@fedoraproject.org>
	<loom.20071020T174814-347@post.gmane.org>
Message-ID: <alpine.DEB.0.9999.0710211618310.28202@gotcha.dreamhost.com>

On Sat, 20 Oct 2007, Kevin Kofler wrote:

> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>> Other than what Todd has already said, note that apt-rpm is available in
>> Fedora. If you need it
>>
>> # yum install apt
>
> But note that autoclean in apt-rpm (at least in the version currently in 
> Fedora 7) only cleans the apt cache (removes downloaded files no longer 
> in the repo), it doesn't remove any installed packages.

Debian apt "autoclean" doesn't remove any installed packages either. It 
might have orphan removal implemented one way or the other but "autoclean" 
is all about cleaning things in the download cache.

 	- Panu -



From valent.turkovic at gmail.com  Sun Oct 21 14:22:16 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 21 Oct 2007 16:22:16 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
Message-ID: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>

Hi,
using Fedora Core 6 I had lots of wireless issues; mainly some
troublesome wireless drivers. In Fedora 7 and now in Fedora 8 test 3
all wireless chips from various laptops work ok.

I know my way with iwconfig and I'm the admin of large municipal
wireless network in my home town of Osijek. So for me configuring
wireless in fedora is peace of cake, but I must say that for my
girlfriend it would be a real issue if I wasn't around.

I also watched my sister connect to our home wireless adls without any
problems using windows xp but I can't say that she would manage to
connect to the same wireless adsl if she was using fedora.

So my question is how can I (and other that can't code if they life
depended on it) help you make wireless more user-friendly for novice
users?

Thank you in advance,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From cra at WPI.EDU  Sun Oct 21 14:29:21 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 21 Oct 2007 10:29:21 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
Message-ID: <20071021142921.GC25455@angus.ind.WPI.EDU>

On Sun, Oct 21, 2007 at 04:22:16PM +0200, Valent Turkovic wrote:
> So my question is how can I (and other that can't code if they life
> depended on it) help you make wireless more user-friendly for novice
> users?

Have you seen NetworkManager?  In Fedora 7, it usually just works for 
connecting to most kinds of wireless networks.  Unfortunately in 
Fedora 8, the new NM 0.7 is missing support for some kinds of wireless 
networks, and as such is a regression from Fedora 7 [1].

[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=336531



From hughsient at gmail.com  Sun Oct 21 15:18:32 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 21 Oct 2007 16:18:32 +0100
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710201528j9c58933ua90dc6da9d917743@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<64b14b300710201528j9c58933ua90dc6da9d917743@mail.gmail.com>
Message-ID: <1192979912.4707.3.camel@hughsie-laptop>

On Sun, 2007-10-21 at 00:28 +0200, Valent Turkovic wrote:
> But I pulled the battery out and on the back of the battery on the
> label it says: 10.8V and 47Wh

Either the label is wrong, or the "smart" controller chip in the battery
is wrong. If the battery is giving us wrong information, then it's not
our fault.

Richard.




From Matt_Domsch at dell.com  Sun Oct 21 15:24:04 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 21 Oct 2007 10:24:04 -0500
Subject: yum groupinstall single arch?
Message-ID: <20071021152404.GC21526@auslistsprd01.us.dell.com>

I'm doing my semi-annual penance by doing yum upgrade to rawhide.
I'll write up my notes soonish (it's not that bad, but not exactly for
beginners), but had a question.

I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
update several yum groups, with:

yum groupinstall Base
yum groupinstall 'GNOME Desktop Environment'

unfortunately, this pulls in piles of i386 packages for no obvious
reason, when I really only need a few new x86_64 packages.

How can I get yum groupinstall to not pull in the i386 packages?

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From lmacken at redhat.com  Sun Oct 21 16:01:40 2007
From: lmacken at redhat.com (Luke Macken)
Date: Sun, 21 Oct 2007 12:01:40 -0400
Subject: who pushes fc6 security updates?
In-Reply-To: <471AD199.8080104@redhat.com>
References: <471AD199.8080104@redhat.com>
Message-ID: <20071021160140.GA8813@crow.myhome.westell.com>

On Sat, Oct 20, 2007 at 11:12:09PM -0500, Eric Sandeen wrote:
> I have a security update for FC6 (for xfsdump) which addresses
> CVE-2007-2654.
> 
> I marked it as security, and it seems that perhaps therefore I can't be
> the one who pushes it out?  At least the email I get says:
> 
> Your update for xfsdump-2.2.45-1.fc6 has not yet been submitted to the
> Release Team for Pushing.
> 
> To submit this update, please visit the following URL and select "Submit
> to Release Team for Pushing"
> 
> ... but I don't see that option at the given URL, only:
> 
> Actions:
> 	o Edit Update
> 	o Delete Update
> 	o Disable periodic notifications regarding this update
> 
> Help? :)

FC6 security updates need approval from the Red Hat Security Response
Team.  When you added the update, they should have received an email.
Once approved, it will automatically be submitted to the release team.

I'll make sure someone approves it ASAP.

luke



From chris.stone at gmail.com  Sun Oct 21 16:01:52 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 21 Oct 2007 09:01:52 -0700
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071020170118.GF4413@psilocybe.teonanacatl.org>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
Message-ID: <d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>

On 10/20/07, Todd Zullinger <tmz at pobox.com> wrote:
> Eric Sandeen wrote:
> > And I'm afraid this does apply to you, Christopher, I should have
> > looked more closely.  If for example you diff
> > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > this.
> >
> > (pseudodiff):
> >
> > -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> > +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
>
> Could docs like this be split out into noarch subpackages?  Or perhaps
> pre-generated and then installed from a Source1: line so that they'd
> match across arches?

Wow, please don't ask me to do this, the bug is clearly yum or doxygen.



From chris.stone at gmail.com  Sun Oct 21 16:06:32 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 21 Oct 2007 09:06:32 -0700
Subject: yum groupinstall single arch?
In-Reply-To: <20071021152404.GC21526@auslistsprd01.us.dell.com>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>
Message-ID: <d9c612bf0710210906k195b8e37se5b1e350d3da2633@mail.gmail.com>

On 10/21/07, Matt Domsch <Matt_Domsch at dell.com> wrote:
> I'm doing my semi-annual penance by doing yum upgrade to rawhide.
> I'll write up my notes soonish (it's not that bad, but not exactly for
> beginners), but had a question.
>
> I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
> update several yum groups, with:
>
> yum groupinstall Base
> yum groupinstall 'GNOME Desktop Environment'
>
> unfortunately, this pulls in piles of i386 packages for no obvious
> reason, when I really only need a few new x86_64 packages.
>
> How can I get yum groupinstall to not pull in the i386 packages?

Does yum install yum-basearchonly work?



From valent.turkovic at gmail.com  Sun Oct 21 16:13:56 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 21 Oct 2007 18:13:56 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <1192979912.4707.3.camel@hughsie-laptop>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<64b14b300710201528j9c58933ua90dc6da9d917743@mail.gmail.com>
	<1192979912.4707.3.camel@hughsie-laptop>
Message-ID: <64b14b300710210913t419adc1dg2cd7c225aac2c1fe@mail.gmail.com>

On 10/21/07, Richard Hughes <hughsient at gmail.com> wrote:
> On Sun, 2007-10-21 at 00:28 +0200, Valent Turkovic wrote:
> > But I pulled the battery out and on the back of the battery on the
> > label it says: 10.8V and 47Wh
>
> Either the label is wrong, or the "smart" controller chip in the battery
> is wrong. If the battery is giving us wrong information, then it's not
> our fault.
>
> Richard.

I'm a but suspicious because I see same maximum capacity for different
batteries and different laptops...

Can you correct battery info if users like me give you feedback and
correct info?

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From fedora at leemhuis.info  Sun Oct 21 17:17:29 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 21 Oct 2007 19:17:29 +0200
Subject: EPEL report week 42 2007
Message-ID: <471B89A9.5060100@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week42

----
= Weekly EPEL Summary =

Week 42/2007

== Most important happenings ==

 * regarding the yum-cron issue: CentOS yum-cron maintainer answered
EPELs yum-cron maintainer -- iow: there is progress (but still slow)

== Meeting ==

Next meeting: 20071024

No meeting in the past week.

== Stats ==

=== General ===

Number of EPEL Contributors: 137

=== EPEL 5 ===

Number of source packages: 699

Number of binary packages:  1345

There are 8 new Packages:

 * bzrtools | A collection of utilities and plugins for Bazaar-NG
 * icewm | Light and configurable window manager
 * kcbench-data | Kernel sources to be used by kcbench
 * kcbench | Kernel compile benchmark
 * python-meld3 | An HTML/XML templating system for Python
 * spamass-milter | Sendmail milter for spamassassin
 * supervisor | A System for Allowing the Control of Process State on UNIX
 * wxMaxima | Graphical user interface for Maxima

=== EPEL 4 ===

Number of source packages: 435

Number of binary packages:  884

There are 4 new Packages:

 * fuse | File System in Userspace (FUSE) utilities
 * mod_extract_forwarded | Extract real source IP for forwarded HTTP
requests
 * ntfs-3g | Linux NTFS userspace driver
 * spamass-milter | Sendmail milter for spamassassin

----
["CategoryEPELReports"]



From tmz at pobox.com  Sun Oct 21 17:40:44 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 21 Oct 2007 13:40:44 -0400
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
Message-ID: <20071021174044.GI4413@psilocybe.teonanacatl.org>

Christopher Stone wrote:
>> Could docs like this be split out into noarch subpackages?  Or
>> perhaps pre-generated and then installed from a Source1: line so
>> that they'd match across arches?
> 
> Wow, please don't ask me to do this, the bug is clearly yum or
> doxygen.

Perhaps, but sometimes it's necessary to work around problems in the
underlying tools in order to provide a better end user experience.  If
there is an easy to fix bug in yum or doxygen, then someone will fix
it soon enough.  Until/unless that happens, what would be wrong with
pre-generating the docs and including them that way?  See the id3lib
package for an example.  Hans just did this there to fix multilib
problems.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071021/3e0416fb/attachment.sig>

From curtis at GreenKey.net  Sun Oct 21 17:45:26 2007
From: curtis at GreenKey.net (Curtis Doty)
Date: Sun, 21 Oct 2007 10:45:26 -0700 (PDT)
Subject: [PATCH] bootchart: grub uninstall bug & splitting package
Message-ID: <20071021174527.159EA6F1C5@alopias.GreenKey.net>

The %preun script in the current F8 bootchart will actually remove itself 
from the grub.conf the next time you try and upgrade bootchart. Therefore 
this really should be fixed now before F8 release.

Also, I took the liberty of splitting out the init script into a separate 
package so it can be deployed on systems that don't need all the 
heavyweight java deps. In hindsight, maybe the subpackage name could be 
"init" rather than "daemon".

../C

Index: bootchart.spec
===================================================================
RCS file: /cvs/pkgs/rpms/bootchart/devel/bootchart.spec,v
retrieving revision 1.1
diff -u -r1.1 bootchart.spec
--- bootchart.spec	27 Aug 2007 17:07:25 -0000	1.1
+++ bootchart.spec	11 Oct 2007 20:52:45 -0000
@@ -1,6 +1,6 @@
  Name:           bootchart
  Version:        0.9
-Release:        5%{?dist}
+Release:        6%{?dist}
  Summary:        Boot Process Performance Visualization
  License:        GPLv3+
  URL:            http://www.bootchart.org/
@@ -22,6 +22,15 @@
  process. Resource utilization and process information are collected during
  the boot process and are later rendered in a PNG, SVG or EPS encoded chart.

+%package daemon
+Summary:	Bootchart logger script
+Group:		Applications/System
+
+%description daemon
+A tool for performance analysis and visualization of the GNU/Linux boot
+process. This package includes the standalone logger daemon and config
+file without any java dependencies.
+
  %prep
  %setup -q

@@ -53,20 +62,22 @@
  %clean
  rm -rf $RPM_BUILD_ROOT

-%post
+%post daemon
  # Add a new grub/lilo entry
  if [ -x /sbin/grubby ]; then
      grubby --update-kernel=ALL --args="init=/sbin/bootchartd"
  fi
+%post
  if [ -x %{_bindir}/rebuild-gcj-db ]; then
      %{_bindir}/rebuild-gcj-db
  fi

-%preun
+%preun daemon
  # Remove the grub/lilo entry
-if [ -x /sbin/grubby ]; then
+if [ $1 -eq 0 -a -x /sbin/grubby ]; then
      grubby --update-kernel=ALL --remove-args="init=/sbin/bootchartd"
  fi
+%preun
  if [ -x %{_bindir}/rebuild-gcj-db ]; then
     %{_bindir}/rebuild-gcj-db
  fi
@@ -76,12 +87,19 @@
  %doc ChangeLog COPYING INSTALL README README.logger TODO lib/LICENSE.cli.txt lib/LICENSE.compress.txt lib/LICENSE.epsgraphics.txt lib/NOTICE.txt
  %{_javadocdir}/%{name}-%{version}
  %{_javadir}/*
-%attr(0755,root,root) /sbin/bootchartd
-%config(noreplace) %{_sysconfdir}/bootchartd.conf
  %dir %attr(0755,root,root) %{_bindir}/bootchart
  %{_libdir}/gcj/%{name}

+%files daemon
+%defattr(-,root,root,-)
+%attr(0755,root,root) /sbin/bootchartd
+%config(noreplace) %{_sysconfdir}/bootchartd.conf
+
  %changelog
+* Wed Oct 10 2007 Curtis Doty <Curtis at GreenKey.net> 0.9-6
+- separate package for bootchart-daemon without java deps
+- bugfix: upgrade was removing grub changes rather than adding
+
  * Mon Aug 27 2007 Adam Jackson <ajax at redhat.com> 0.9-5
  - Additional minor spec cleanups from review bug (#219889)



From pertusus at free.fr  Sun Oct 21 17:46:35 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Oct 2007 19:46:35 +0200
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071021174044.GI4413@psilocybe.teonanacatl.org>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<20071021174044.GI4413@psilocybe.teonanacatl.org>
Message-ID: <20071021174635.GB2602@free.fr>

On Sun, Oct 21, 2007 at 01:40:44PM -0400, Todd Zullinger wrote:
> 
> Perhaps, but sometimes it's necessary to work around problems in the
> underlying tools in order to provide a better end user experience.  If
> there is an easy to fix bug in yum or doxygen, then someone will fix
> it soon enough.  Until/unless that happens, what would be wrong with
> pre-generating the docs and including them that way?  See the id3lib
> package for an example.  Hans just did this there to fix multilib
> problems.

It is good that Hans fixed it, but I don't think that it should be
mandatory, if yum or doxygen is broken (in my opinion doxygen should
produce reproducable documents).

--
Pat



From packages at amiga-hardware.com  Sun Oct 21 17:55:29 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Sun, 21 Oct 2007 18:55:29 +0100
Subject: Multiarch crazyiness
Message-ID: <471B9291.4060800@amiga-hardware.com>

If yum/rpm is patched  so that when arch conflicts occur in %{_bindir} 
for example, it chooses the preferred architecture, ie 64bit over 32bit 
for X86 and 32bit over 64bit for PPC, is there a technical reason why 
this cannot be applied to anything under %doc?


-- 
Ian Chapman.



From j.w.r.degoede at hhs.nl  Sun Oct 21 18:40:17 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 21 Oct 2007 20:40:17 +0200
Subject: Multiarch crazyiness
In-Reply-To: <471B9291.4060800@amiga-hardware.com>
References: <471B9291.4060800@amiga-hardware.com>
Message-ID: <471B9D11.7020504@hhs.nl>

Ian Chapman wrote:
> If yum/rpm is patched  so that when arch conflicts occur in %{_bindir} 
> for example, it chooses the preferred architecture, ie 64bit over 32bit 
> for X86 and 32bit over 64bit for PPC, is there a technical reason why 
> this cannot be applied to anything under %doc?
> 

The current multilib solution in rpm is far from pretty, it works well, but 
definitively has downsides. I think as is its a reasonable comprimise, lets not 
add bandaids and patches to it for issues which should be solved elsewhere, I 
feel the pain of maintainers getting these bugs (I got 15 of them), but they 
are fixable without requiring the addition of yet another multilib kludge to rpm.

Regards,

Hans




From Matt_Domsch at dell.com  Sun Oct 21 19:03:10 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 21 Oct 2007 14:03:10 -0500
Subject: yum groupinstall single arch?
In-Reply-To: <d9c612bf0710210906k195b8e37se5b1e350d3da2633@mail.gmail.com>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>
	<d9c612bf0710210906k195b8e37se5b1e350d3da2633@mail.gmail.com>
Message-ID: <20071021190310.GA2088@auslistsprd01.us.dell.com>

On Sun, Oct 21, 2007 at 09:06:32AM -0700, Christopher Stone wrote:
> On 10/21/07, Matt Domsch <Matt_Domsch at dell.com> wrote:
> > I'm doing my semi-annual penance by doing yum upgrade to rawhide.
> > I'll write up my notes soonish (it's not that bad, but not exactly for
> > beginners), but had a question.
> >
> > I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
> > update several yum groups, with:
> >
> > yum groupinstall Base
> > yum groupinstall 'GNOME Desktop Environment'
> >
> > unfortunately, this pulls in piles of i386 packages for no obvious
> > reason, when I really only need a few new x86_64 packages.
> >
> > How can I get yum groupinstall to not pull in the i386 packages?
> 
> Does yum install yum-basearchonly work?

Thanks for the pointer, but no, it doesn't help.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From sandeen at redhat.com  Sun Oct 21 19:19:02 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Oct 2007 14:19:02 -0500
Subject: who pushes fc6 security updates?
In-Reply-To: <20071021075633.3d64d9bc@redhat.com>
References: <471AD199.8080104@redhat.com> <20071021075633.3d64d9bc@redhat.com>
Message-ID: <471BA626.1020205@redhat.com>

Jesse Keating wrote:
> On Sat, 20 Oct 2007 23:12:09 -0500
> Eric Sandeen <sandeen at redhat.com> wrote:
> 
>> To submit this update, please visit the following URL and select
>> "Submit to Release Team for Pushing"
>>
>> ... but I don't see that option at the given URL, only:
> 
> Do you see that URL when you edit update?
> 
> 
No, the only way I get it is if I un-check [ ] security.

(hmm forgot to mention that this is an "extras" package... if that matters.)

-Eric



From kanarip at kanarip.com  Sun Oct 21 19:19:18 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 21 Oct 2007 21:19:18 +0200
Subject: yum groupinstall single arch?
In-Reply-To: <20071021190310.GA2088@auslistsprd01.us.dell.com>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>	<d9c612bf0710210906k195b8e37se5b1e350d3da2633@mail.gmail.com>
	<20071021190310.GA2088@auslistsprd01.us.dell.com>
Message-ID: <471BA636.2010100@kanarip.com>

Matt Domsch wrote:
> On Sun, Oct 21, 2007 at 09:06:32AM -0700, Christopher Stone wrote:
>> On 10/21/07, Matt Domsch <Matt_Domsch at dell.com> wrote:
>>> I'm doing my semi-annual penance by doing yum upgrade to rawhide.
>>> I'll write up my notes soonish (it's not that bad, but not exactly for
>>> beginners), but had a question.
>>>
>>> I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
>>> update several yum groups, with:
>>>
>>> yum groupinstall Base
>>> yum groupinstall 'GNOME Desktop Environment'
>>>
>>> unfortunately, this pulls in piles of i386 packages for no obvious
>>> reason, when I really only need a few new x86_64 packages.
>>>
>>> How can I get yum groupinstall to not pull in the i386 packages?
>> Does yum install yum-basearchonly work?
> 
> Thanks for the pointer, but no, it doesn't help.
> 

Adding a exclude=*.i?86 to the yum configuration should help.

Kind regards,

Jeroen van Meeuwen
-kanarip



From lkundrak at redhat.com  Sun Oct 21 19:34:20 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 21 Oct 2007 21:34:20 +0200
Subject: who pushes fc6 security updates?
In-Reply-To: <471BA626.1020205@redhat.com>
References: <471AD199.8080104@redhat.com>
	<20071021075633.3d64d9bc@redhat.com>  <471BA626.1020205@redhat.com>
Message-ID: <1192995260.13152.2.camel@localhost.localdomain>


On Sun, 2007-10-21 at 14:19 -0500, Eric Sandeen wrote:
> Jesse Keating wrote:
> > On Sat, 20 Oct 2007 23:12:09 -0500
> > Eric Sandeen <sandeen at redhat.com> wrote:
> > 
> >> To submit this update, please visit the following URL and select
> >> "Submit to Release Team for Pushing"
> >>
> >> ... but I don't see that option at the given URL, only:
> > 
> > Do you see that URL when you edit update?
> > 
> > 
> No, the only way I get it is if I un-check [ ] security.
> 
> (hmm forgot to mention that this is an "extras" package... if that matters.)

No need to do anything to push those -- those get to repositories once
built in plague.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From jwboyer at jdub.homelinux.org  Sun Oct 21 19:40:08 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 21 Oct 2007 14:40:08 -0500
Subject: Thinkpad button regression
Message-ID: <20071021144008.0fd8f81e@vader.jdub.homelinux.org>

Up until rebooting this morning, I used to be able to use the
Fn+<button> combinations just fine with rawhide.  Now, FN+Home, FN+End
don't adjust the backlight level.  This is pretty annoying, because I
also can't dim the backlight through any of the gnome-* apps either.
What changed and how the hell to I get rid of it?

josh



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 21 19:59:01 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 21 Oct 2007 21:59:01 +0200
Subject: who pushes fc6 security updates?
In-Reply-To: <1192995260.13152.2.camel@localhost.localdomain>
References: <471AD199.8080104@redhat.com> <20071021075633.3d64d9bc@redhat.com>
	<471BA626.1020205@redhat.com>
	<1192995260.13152.2.camel@localhost.localdomain>
Message-ID: <20071021215901.b0d6b57c.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 21 Oct 2007 21:34:20 +0200, Lubomir Kundrak wrote:

> 
> On Sun, 2007-10-21 at 14:19 -0500, Eric Sandeen wrote:
> > Jesse Keating wrote:
> > > On Sat, 20 Oct 2007 23:12:09 -0500
> > > Eric Sandeen <sandeen redhat com> wrote:
> > > 
> > >> To submit this update, please visit the following URL and select
> > >> "Submit to Release Team for Pushing"
> > >>
> > >> ... but I don't see that option at the given URL, only:
> > > 
> > > Do you see that URL when you edit update?
> > > 
> > > 
> > No, the only way I get it is if I un-check [ ] security.
> > 
> > (hmm forgot to mention that this is an "extras" package... if that matters.)
> 
> No need to do anything to push those -- those get to repositories once
> built in plague.

Hmm, pardon? What do you mean with "extras" here? 

The Fedora Extras for Fedora Core 6 packages are not published
automatically. They sit and wait in the "plague-results" (= needsign)
repository until they are pushed by the Extras' signers.

Further, there is no pending xfsdump-2.2.45-1.fc6 build in the
needsign queue:

$ lspen
fedora-6-extras:
    alsa-tools-1.0.14-1.fc6
    ctapi-cyberjack-3.0.5-1.fc6
    dkms-2.0.17.5-1.fc6

Checking CVS, I find in rpms/xfsdump/FC-6 the following:

* Thu May 31 2007 Eric Sandeen <sandeen redhat com> - 2.2.45-1
- Update to xfsdump 2.2.45



From dcbw at redhat.com  Sun Oct 21 20:17:08 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 21 Oct 2007 16:17:08 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071021142921.GC25455@angus.ind.WPI.EDU>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
	<20071021142921.GC25455@angus.ind.WPI.EDU>
Message-ID: <1192997828.1006.23.camel@localhost.localdomain>

On Sun, 2007-10-21 at 10:29 -0400, Chuck Anderson wrote:
> On Sun, Oct 21, 2007 at 04:22:16PM +0200, Valent Turkovic wrote:
> > So my question is how can I (and other that can't code if they life
> > depended on it) help you make wireless more user-friendly for novice
> > users?
> 
> Have you seen NetworkManager?  In Fedora 7, it usually just works for 
> connecting to most kinds of wireless networks.  Unfortunately in 
> Fedora 8, the new NM 0.7 is missing support for some kinds of wireless 
> networks, and as such is a regression from Fedora 7 [1].

Hope to get those last bits fixed up tonight and push a new build for
testing that has options for all the types, including hidden networks.

Dan




From valent.turkovic at gmail.com  Sun Oct 21 20:19:29 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 21 Oct 2007 22:19:29 +0200
Subject: what to do when gnome power manager shows wrong battery
	capacity?
In-Reply-To: <64b14b300710210913t419adc1dg2cd7c225aac2c1fe@mail.gmail.com>
References: <64b14b300710180635m63f7f223t7d0e64a578f5f52a@mail.gmail.com>
	<64b14b300710201528j9c58933ua90dc6da9d917743@mail.gmail.com>
	<1192979912.4707.3.camel@hughsie-laptop>
	<64b14b300710210913t419adc1dg2cd7c225aac2c1fe@mail.gmail.com>
Message-ID: <64b14b300710211319r61075e86w28492e389414e9b6@mail.gmail.com>

On 10/21/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> On 10/21/07, Richard Hughes <hughsient at gmail.com> wrote:
> > On Sun, 2007-10-21 at 00:28 +0200, Valent Turkovic wrote:
> > > But I pulled the battery out and on the back of the battery on the
> > > label it says: 10.8V and 47Wh
> >
> > Either the label is wrong, or the "smart" controller chip in the battery
> > is wrong. If the battery is giving us wrong information, then it's not
> > our fault.
> >
> > Richard.
>
> I'm a but suspicious because I see same maximum capacity for different
> batteries and different laptops...

I wasn't implying that fedora/gpm or any other component is wrong or
that you made some mistake I am only asking how can I fix it. If I
know exactly what are my battery specs and their "smart" electronics
reports some bogus data I would like to have some way of correcting
the wrong info.

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 21 20:40:34 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 21 Oct 2007 22:40:34 +0200
Subject: who pushes fc6 security updates?
In-Reply-To: <471BA626.1020205@redhat.com>
References: <471AD199.8080104@redhat.com> <20071021075633.3d64d9bc@redhat.com>
	<471BA626.1020205@redhat.com>
Message-ID: <20071021224034.f293b42f.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 21 Oct 2007 14:19:02 -0500, Eric Sandeen wrote:

> Jesse Keating wrote:
> > On Sat, 20 Oct 2007 23:12:09 -0500
> > Eric Sandeen <sandeen at redhat.com> wrote:
> > 
> >> To submit this update, please visit the following URL and select
> >> "Submit to Release Team for Pushing"
> >>
> >> ... but I don't see that option at the given URL, only:
> > 
> > Do you see that URL when you edit update?
> > 
> > 
> No, the only way I get it is if I un-check [ ] security.
> 
> (hmm forgot to mention that this is an "extras" package... if that matters.)

Pushed over a month ago:

http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/xfsdump.html

The cvs log:

revision 1.2
date: 2007/09/10 16:38:16;  author: sandeen;  state: Exp;  lines: +7 -4
* Thu May 31 2007 Eric Sandeen <sandeen redhat com> - 2.2.45-1
- Update to xfsdump 2.2.45



From jwboyer at jdub.homelinux.org  Sun Oct 21 20:48:40 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 21 Oct 2007 15:48:40 -0500
Subject: Thinkpad button regression
In-Reply-To: <20071021144008.0fd8f81e@vader.jdub.homelinux.org>
References: <20071021144008.0fd8f81e@vader.jdub.homelinux.org>
Message-ID: <20071021154840.02a9011c@vader.jdub.homelinux.org>

On Sun, 21 Oct 2007 14:40:08 -0500
Josh Boyer <jwboyer at jdub.homelinux.org> wrote:

> Up until rebooting this morning, I used to be able to use the
> Fn+<button> combinations just fine with rawhide.  Now, FN+Home, FN+End
> don't adjust the backlight level.  This is pretty annoying, because I
> also can't dim the backlight through any of the gnome-* apps either.
> What changed and how the hell to I get rid of it?

Oh, and my FN+F5 combo hasn't worked for the bluetooth switch in a
while.  Grr.

josh



From sandeen at redhat.com  Sun Oct 21 21:06:40 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Oct 2007 16:06:40 -0500
Subject: who pushes fc6 security updates?
In-Reply-To: <20071021224034.f293b42f.mschwendt.tmp0701.nospam@arcor.de>
References: <471AD199.8080104@redhat.com>
	<20071021075633.3d64d9bc@redhat.com>	<471BA626.1020205@redhat.com>
	<20071021224034.f293b42f.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <471BBF60.3040401@redhat.com>

Michael Schwendt wrote:
> On Sun, 21 Oct 2007 14:19:02 -0500, Eric Sandeen wrote:
> 
>> Jesse Keating wrote:
>>> On Sat, 20 Oct 2007 23:12:09 -0500
>>> Eric Sandeen <sandeen at redhat.com> wrote:
>>>
>>>> To submit this update, please visit the following URL and select
>>>> "Submit to Release Team for Pushing"
>>>>
>>>> ... but I don't see that option at the given URL, only:
>>> Do you see that URL when you edit update?
>>>
>>>
>> No, the only way I get it is if I un-check [ ] security.
>>
>> (hmm forgot to mention that this is an "extras" package... if that matters.)
> 
> Pushed over a month ago:
> 
> http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/xfsdump.html

Hrmph ok.  Emails saying "not pushed" threw me off.. ;-)  I'll just
delete the update then.  *shrug*  Sorry....

-Eric



From packages at amiga-hardware.com  Sun Oct 21 21:18:37 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Sun, 21 Oct 2007 22:18:37 +0100
Subject: Multiarch crazyiness
In-Reply-To: <471B9D11.7020504@hhs.nl>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
Message-ID: <471BC22D.4000908@amiga-hardware.com>

Hans de Goede wrote:

> The current multilib solution in rpm is far from pretty, it works well, 
> but definitively has downsides. I think as is its a reasonable 
> comprimise, lets not add bandaids and patches to it for issues which 
> should be solved elsewhere, I feel the pain of maintainers getting these 
> bugs (I got 15 of them), but they are fixable without requiring the 
> addition of yet another multilib kludge to rpm.

Well the question is still really where should these issues ultimately 
be solved? Is kludging the rpms any more elegant than patching rpm? I 
must admit I have no idea how other distro's deal with these kind of 
issues.

-- 
Ian Chapman.



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 21 21:44:03 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 21 Oct 2007 23:44:03 +0200
Subject: who pushes fc6 security updates?
In-Reply-To: <471BBF60.3040401@redhat.com>
References: <471AD199.8080104@redhat.com> <20071021075633.3d64d9bc@redhat.com>
	<471BA626.1020205@redhat.com>
	<20071021224034.f293b42f.mschwendt.tmp0701.nospam@arcor.de>
	<471BBF60.3040401@redhat.com>
Message-ID: <20071021234403.561d98c4.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 21 Oct 2007 16:06:40 -0500, Eric Sandeen wrote:

> > http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/xfsdump.html
> 
> Hrmph ok.  Emails saying "not pushed" threw me off.. ;-)  I'll just
> delete the update then.  *shrug*  Sorry....

Core != Extras  

for Fedora 6 and older. Different buildsys, different push tools. The
internal Fedora Core 6 build infrastructure does not know about Fedora
Extras' packages.

Only for Fedora 7 things are merged with koji/bodhi.



From pertusus at free.fr  Sun Oct 21 21:44:05 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 21 Oct 2007 23:44:05 +0200
Subject: multiarch conflicts
Message-ID: <20071021214405.GB23187@free.fr>

Hello,

How are the multilib conflicts tested? I'd like to verify that there are
no conflicts anymore before building.

Also will this be extended to binary files?

And last what to do when the conflict is 'logical'? I have 2 examples in
the bes package:

* there is a bes-config file which specifies the directory where
  dlopened backend modules are, this is a %_libdir subdirectory, so,
  it is logical to have a difference between arches.

* in the /etc/bes/bes.conf file there is also a conflict because in
  that file the dlopened modules are specified, and therefore the libdir
  is different.

Any idea?

--
Pat



From tonynelson at georgeanelson.com  Sun Oct 21 22:04:51 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Sun, 21 Oct 2007 18:04:51 -0400
Subject: yum groupinstall single arch?
In-Reply-To: <20071021152404.GC21526@auslistsprd01.us.dell.com>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>
Message-ID: <p04330102c34177e5509f@[192.168.123.162]>

At 10:24 AM -0500 10/21/07, Matt Domsch wrote:
>I'm doing my semi-annual penance by doing yum upgrade to rawhide.
>I'll write up my notes soonish (it's not that bad, but not exactly for
>beginners), but had a question.
>
>I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
>update several yum groups, with:
>
>yum groupinstall Base
>yum groupinstall 'GNOME Desktop Environment'
>
>unfortunately, this pulls in piles of i386 packages for no obvious
>reason, when I really only need a few new x86_64 packages.
>
>How can I get yum groupinstall to not pull in the i386 packages?

WAG:  "yum groupinstall 'GNOME Desktop Environment'.x86_64"?

I can't even pretend to try it right now, sorry.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From skvidal at fedoraproject.org  Sun Oct 21 22:18:53 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 21 Oct 2007 22:18:53 +0000
Subject: yum groupinstall single arch?
In-Reply-To: <p04330102c34177e5509f@[192.168.123.162]>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>
	<p04330102c34177e5509f@[192.168.123.162]>
Message-ID: <1193005133.8542.260.camel@cutter>


On Sun, 2007-10-21 at 18:04 -0400, Tony Nelson wrote:
> At 10:24 AM -0500 10/21/07, Matt Domsch wrote:
> >I'm doing my semi-annual penance by doing yum upgrade to rawhide.
> >I'll write up my notes soonish (it's not that bad, but not exactly for
> >beginners), but had a question.
> >
> >I'm on x86_64, and I've removed all the i386 packages. :-)  I want to
> >update several yum groups, with:
> >
> >yum groupinstall Base
> >yum groupinstall 'GNOME Desktop Environment'
> >
> >unfortunately, this pulls in piles of i386 packages for no obvious
> >reason, when I really only need a few new x86_64 packages.
> >
> >How can I get yum groupinstall to not pull in the i386 packages?
> 
> WAG:  "yum groupinstall 'GNOME Desktop Environment'.x86_64"?
> 
> I can't even pretend to try it right now, sorry.

I can assure you that won't do anything at all.

-sv




From laurent.rineau__fedora at normalesup.org  Sun Oct 21 22:29:30 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Mon, 22 Oct 2007 00:29:30 +0200
Subject: License review for new itext version
In-Reply-To: <46BF752E.4030500@herr-schmitt.de>
References: <46BF752E.4030500@herr-schmitt.de>
Message-ID: <200710220029.30090@rineau.tsetse>

On Sunday 12 August 2007 23:01:34 Jochen Schmitt wrote:
> Hello,
>
> in the past we have removed itext and pdftk which depends on itext from
> the Fedora distribution due
> license issue.
>
> In the new iText package itext-2.0.4 I have found a text file about the
> licensing situation of the
> source file coming from Sun Corporation Inc.
>
> I have uploaded this file for review on
>
> http://www.herr-schmitt.de/pub/itext/sun.txt
>
> I want to know, it this ok for Fedora. But I assume, that the last term
> about usage this
> file for nuclear weapons may be a blocker.

Jochen, do you have an update of the situation? Will upstream agree to modify 
the license scheme a bit?

I use pdftk randomly in my job, several times a year, but I really need it. It 
is not so nice to see one usefull package go away from Fedora.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From mattdm at mattdm.org  Sun Oct 21 23:54:24 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 21 Oct 2007 19:54:24 -0400
Subject: yum groupinstall single arch?
In-Reply-To: <20071021190310.GA2088@auslistsprd01.us.dell.com>
References: <20071021152404.GC21526@auslistsprd01.us.dell.com>
	<d9c612bf0710210906k195b8e37se5b1e350d3da2633@mail.gmail.com>
	<20071021190310.GA2088@auslistsprd01.us.dell.com>
Message-ID: <20071021235423.GA22351@jadzia.bu.edu>

On Sun, Oct 21, 2007 at 02:03:10PM -0500, Matt Domsch wrote:
> > > How can I get yum groupinstall to not pull in the i386 packages?
> > Does yum install yum-basearchonly work?
> Thanks for the pointer, but no, it doesn't help.

It should be fixed so it does help.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jonathan at jonmasters.org  Mon Oct 22 00:11:37 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 21 Oct 2007 20:11:37 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471BC22D.4000908@amiga-hardware.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
Message-ID: <1193011897.5168.52.camel@perihelion>


On Sun, 2007-10-21 at 22:18 +0100, Ian Chapman wrote:
> Hans de Goede wrote:
> 
> > The current multilib solution in rpm is far from pretty, it works well, 
> > but definitively has downsides. I think as is its a reasonable 
> > comprimise, lets not add bandaids and patches to it for issues which 
> > should be solved elsewhere, I feel the pain of maintainers getting these 
> > bugs (I got 15 of them), but they are fixable without requiring the 
> > addition of yet another multilib kludge to rpm.
> 
> Well the question is still really where should these issues ultimately 
> be solved? Is kludging the rpms any more elegant than patching rpm? I 
> must admit I have no idea how other distro's deal with these kind of 
> issues.

Without ranting aimlessly, IMO the only real solution is to stop
kludging rpm, yum, etc. and split out multilib libraries properly - and
if needed, seek and get approval for a bin64/bin32 with alternatives
system. Hacking RPM to simply ignore the fact that two packages provide
the same file is not the solution.

AFAIK, the only things in the way of a real solution are:

* Standards. These can be changed/updated.
* Packages. These can be fixed.

I'll shutup now ;-)

Jon.




From airlied at redhat.com  Mon Oct 22 10:14:36 2007
From: airlied at redhat.com (Dave Airlie)
Date: Mon, 22 Oct 2007 20:14:36 +1000
Subject: Multiarch crazyiness
In-Reply-To: <1193011897.5168.52.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
Message-ID: <1193048076.26495.5.camel@clockmaker.usersys.redhat.com>

On Sun, 2007-10-21 at 20:11 -0400, Jon Masters wrote:
> On Sun, 2007-10-21 at 22:18 +0100, Ian Chapman wrote:
> > Hans de Goede wrote:
> > 
> > > The current multilib solution in rpm is far from pretty, it works well, 
> > > but definitively has downsides. I think as is its a reasonable 
> > > comprimise, lets not add bandaids and patches to it for issues which 
> > > should be solved elsewhere, I feel the pain of maintainers getting these 
> > > bugs (I got 15 of them), but they are fixable without requiring the 
> > > addition of yet another multilib kludge to rpm.
> > 
> > Well the question is still really where should these issues ultimately 
> > be solved? Is kludging the rpms any more elegant than patching rpm? I 
> > must admit I have no idea how other distro's deal with these kind of 
> > issues.
> 
> Without ranting aimlessly, IMO the only real solution is to stop
> kludging rpm, yum, etc. and split out multilib libraries properly - and
> if needed, seek and get approval for a bin64/bin32 with alternatives
> system. Hacking RPM to simply ignore the fact that two packages provide
> the same file is not the solution.
> 

I have to agree, I didn't know about the stupid bin behaviour and
recently started flushing 64-bit packages from my ppc64 machine, and
ended up removing a fair few files from /usr/bin that were still being
provided by the 32-bit packages.

it just screamed kludge to me..

Dave.



From jonathan at jonmasters.org  Mon Oct 22 00:30:05 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 21 Oct 2007 20:30:05 -0400
Subject: NSCD, Fedora, and busted DNS
Message-ID: <1193013005.5168.65.camel@perihelion>

Yo,

Working out a few things that bug me about Fedora apps and DNS (many).
Specifically, handling of a busted network connection (I often reboot
with a vpnc-afflicted resolv.conf remaining...). So far, I can see that
the initscripts don't really handle a connection that's semi-up but not
really. I guess this waits for upstart/whatever. Annoying, but ok.

But most randomly annoying today, an strace shows that the Rhythmbox
application[0] thinks it's a good idea to do a DNS lookup *every* time
one changes track...lovely. Really stupid.

We have NSCD installed on my F8T3, why is it not running by default?

[jcm at perihelion ~]$ sudo /etc/init.d/nscd status
nscd is stopped

Jon.

[0] I'm a die-hard XMMS fanboy, but I'm told I'm living in history and
should move with the times...like ditching use of cdrecord ;-)




From jonathan at jonmasters.org  Mon Oct 22 00:32:01 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 21 Oct 2007 20:32:01 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
Message-ID: <1193013121.5168.68.camel@perihelion>


On Mon, 2007-10-22 at 20:14 +1000, Dave Airlie wrote:
> On Sun, 2007-10-21 at 20:11 -0400, Jon Masters wrote:
> > On Sun, 2007-10-21 at 22:18 +0100, Ian Chapman wrote:
> > > Hans de Goede wrote:
> > > 
> > > > The current multilib solution in rpm is far from pretty, it works well, 
> > > > but definitively has downsides. I think as is its a reasonable 
> > > > comprimise, lets not add bandaids and patches to it for issues which 
> > > > should be solved elsewhere, I feel the pain of maintainers getting these 
> > > > bugs (I got 15 of them), but they are fixable without requiring the 
> > > > addition of yet another multilib kludge to rpm.
> > > 
> > > Well the question is still really where should these issues ultimately 
> > > be solved? Is kludging the rpms any more elegant than patching rpm? I 
> > > must admit I have no idea how other distro's deal with these kind of 
> > > issues.
> > 
> > Without ranting aimlessly, IMO the only real solution is to stop
> > kludging rpm, yum, etc. and split out multilib libraries properly - and
> > if needed, seek and get approval for a bin64/bin32 with alternatives
> > system. Hacking RPM to simply ignore the fact that two packages provide
> > the same file is not the solution.
> > 
> 
> I have to agree, I didn't know about the stupid bin behaviour and
> recently started flushing 64-bit packages from my ppc64 machine, and
> ended up removing a fair few files from /usr/bin that were still being
> provided by the 32-bit packages.
> 
> it just screamed kludge to me..

It obviously was a kludge. And a great one - Jeremy, Bill, and other
*smart* people (so don't get me wrong guys!) had to come up with a
solution at some point when this came up, but it's long since time to
take a big breath and think about a longer term fix.

Can we agree that needs to happen? If so, I'll happily actually get
involved in implementing a fix, as I've said to these folks in face to
face conversations about multilib before!

Jon.




From bnocera at redhat.com  Mon Oct 22 00:42:16 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 22 Oct 2007 01:42:16 +0100
Subject: NSCD, Fedora, and busted DNS
In-Reply-To: <1193013005.5168.65.camel@perihelion>
References: <1193013005.5168.65.camel@perihelion>
Message-ID: <1193013736.25405.21.camel@cookie.hadess.net>


On Sun, 2007-10-21 at 20:30 -0400, Jon Masters wrote:
> Yo,
<snip>
> But most randomly annoying today, an strace shows that the Rhythmbox
> application[0] thinks it's a good idea to do a DNS lookup *every* time
> one changes track...lovely. Really stupid.

And what domain would that be? It wouldn't happen to be:
- Amazon.com (covers)
or
- one of the lyrics websites (lyrics plugin)
or
- audioscrobbler.com (for the last.fm functionality)

We're working upstream on making all those disabled if NetworkManager
doesn't see a network connection. See:
http://bugzilla.gnome.org/show_bug.cgi?id=322266

In the meanwhile, those lookups would be normal.



From bnocera at redhat.com  Mon Oct 22 00:44:04 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 22 Oct 2007 01:44:04 +0100
Subject: Thinkpad button regression
In-Reply-To: <20071021154840.02a9011c@vader.jdub.homelinux.org>
References: <20071021144008.0fd8f81e@vader.jdub.homelinux.org>
	<20071021154840.02a9011c@vader.jdub.homelinux.org>
Message-ID: <1193013844.25405.23.camel@cookie.hadess.net>


On Sun, 2007-10-21 at 15:48 -0500, Josh Boyer wrote:
> On Sun, 21 Oct 2007 14:40:08 -0500
> Josh Boyer <jwboyer at jdub.homelinux.org> wrote:
> 
> > Up until rebooting this morning, I used to be able to use the
> > Fn+<button> combinations just fine with rawhide.  Now, FN+Home, FN+End
> > don't adjust the backlight level.  This is pretty annoying, because I
> > also can't dim the backlight through any of the gnome-* apps either.
> > What changed and how the hell to I get rid of it?
> 
> Oh, and my FN+F5 combo hasn't worked for the bluetooth switch in a
> while.  Grr.

Read the list more carefully, it's been pointed out it's a kernel bug,
although no one posted a bug link.



From packages at amiga-hardware.com  Mon Oct 22 00:54:37 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Mon, 22 Oct 2007 01:54:37 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193013121.5168.68.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>
Message-ID: <471BF4CD.6060808@amiga-hardware.com>

Jon Masters wrote:

> Can we agree that needs to happen? If so, I'll happily actually get
> involved in implementing a fix, as I've said to these folks in face to
> face conversations about multilib before! 

FWIW, it gets my vote.

-- 
Ian Chapman.



From skvidal at fedoraproject.org  Mon Oct 22 02:19:50 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 22 Oct 2007 02:19:50 +0000
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
Message-ID: <1193019590.8542.265.camel@cutter>


On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> On 10/20/07, Todd Zullinger <tmz at pobox.com> wrote:
> > Eric Sandeen wrote:
> > > And I'm afraid this does apply to you, Christopher, I should have
> > > looked more closely.  If for example you diff
> > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > this.
> > >
> > > (pseudodiff):
> > >
> > > -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> >
> > Could docs like this be split out into noarch subpackages?  Or perhaps
> > pre-generated and then installed from a Source1: line so that they'd
> > match across arches?
> 
> Wow, please don't ask me to do this, the bug is clearly yum or doxygen.

rpmlib is complaining about the files not matching. Not yum. And I
actually don't think this is a bug in rpm, either.

-sv




From jonathan at jonmasters.org  Mon Oct 22 02:56:13 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 21 Oct 2007 22:56:13 -0400
Subject: NSCD, Fedora, and busted DNS
In-Reply-To: <1193013736.25405.21.camel@cookie.hadess.net>
References: <1193013005.5168.65.camel@perihelion>
	<1193013736.25405.21.camel@cookie.hadess.net>
Message-ID: <1193021774.5168.129.camel@perihelion>


On Mon, 2007-10-22 at 01:42 +0100, Bastien Nocera wrote:
> On Sun, 2007-10-21 at 20:30 -0400, Jon Masters wrote:
> > Yo,
> <snip>
> > But most randomly annoying today, an strace shows that the Rhythmbox
> > application[0] thinks it's a good idea to do a DNS lookup *every* time
> > one changes track...lovely. Really stupid.
> 
> And what domain would that be? It wouldn't happen to be:
> - Amazon.com (covers)
> or
> - one of the lyrics websites (lyrics plugin)
> or
> - audioscrobbler.com (for the last.fm functionality)
> 
> We're working upstream on making all those disabled if NetworkManager
> doesn't see a network connection. See:
> http://bugzilla.gnome.org/show_bug.cgi?id=322266
> 
> In the meanwhile, those lookups would be normal.

Right. But even if NetworkManager detects a connection, that doesn't
mean it's actually working - moving to the track shouldn't block, the
lookup should be asynchronous ideally. It's still great software! :-)

Jon.




From chris.stone at gmail.com  Mon Oct 22 03:04:57 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 21 Oct 2007 20:04:57 -0700
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1193019590.8542.265.camel@cutter>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<1193019590.8542.265.camel@cutter>
Message-ID: <d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>

On 10/21/07, seth vidal <skvidal at fedoraproject.org> wrote:
>
> On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> > On 10/20/07, Todd Zullinger <tmz at pobox.com> wrote:
> > > Eric Sandeen wrote:
> > > > And I'm afraid this does apply to you, Christopher, I should have
> > > > looked more closely.  If for example you diff
> > > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > > this.
> > > >
> > > > (pseudodiff):
> > > >
> > > > -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > > +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> > >
> > > Could docs like this be split out into noarch subpackages?  Or perhaps
> > > pre-generated and then installed from a Source1: line so that they'd
> > > match across arches?
> >
> > Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
>
> rpmlib is complaining about the files not matching. Not yum. And I
> actually don't think this is a bug in rpm, either.

Except for the fact that you can install both arches just fine using
rpm, but it fails with yum.



From skvidal at fedoraproject.org  Mon Oct 22 03:04:05 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 22 Oct 2007 03:04:05 +0000
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192ABD.6090108@redhat.com>
	<d9c612bf0710191515k308e877l3fe1c41958da823b@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<1193019590.8542.265.camel@cutter>
	<d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>
Message-ID: <1193022245.8542.271.camel@cutter>


On Sun, 2007-10-21 at 20:04 -0700, Christopher Stone wrote:
> On 10/21/07, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> > On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> > > On 10/20/07, Todd Zullinger <tmz at pobox.com> wrote:
> > > > Eric Sandeen wrote:
> > > > > And I'm afraid this does apply to you, Christopher, I should have
> > > > > looked more closely.  If for example you diff
> > > > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > > > this.
> > > > >
> > > > > (pseudodiff):
> > > > >
> > > > > -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > > > +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> > > >
> > > > Could docs like this be split out into noarch subpackages?  Or perhaps
> > > > pre-generated and then installed from a Source1: line so that they'd
> > > > match across arches?
> > >
> > > Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
> >
> > rpmlib is complaining about the files not matching. Not yum. And I
> > actually don't think this is a bug in rpm, either.
> 
> Except for the fact that you can install both arches just fine using
> rpm, but it fails with yum.

really? That's interesting. It should be consistent b/c at the point
where the error is coming from in yum, all of the operation is inisde
rpmlib.

-sv




From chris.stone at gmail.com  Mon Oct 22 03:10:41 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 21 Oct 2007 20:10:41 -0700
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <1193022245.8542.271.camel@cutter>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<1193019590.8542.265.camel@cutter>
	<d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>
	<1193022245.8542.271.camel@cutter>
Message-ID: <d9c612bf0710212010r6a7a1fedy70dd2da696a4be8d@mail.gmail.com>

On 10/21/07, seth vidal <skvidal at fedoraproject.org> wrote:
>
> On Sun, 2007-10-21 at 20:04 -0700, Christopher Stone wrote:
> > On 10/21/07, seth vidal <skvidal at fedoraproject.org> wrote:
> > >
> > > On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> > > > On 10/20/07, Todd Zullinger <tmz at pobox.com> wrote:
> > > > > Eric Sandeen wrote:
> > > > > > And I'm afraid this does apply to you, Christopher, I should have
> > > > > > looked more closely.  If for example you diff
> > > > > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > > > > this.
> > > > > >
> > > > > > (pseudodiff):
> > > > > >
> > > > > > -<a class="anchor" name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > > > > +<a class="anchor" name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> > > > >
> > > > > Could docs like this be split out into noarch subpackages?  Or perhaps
> > > > > pre-generated and then installed from a Source1: line so that they'd
> > > > > match across arches?
> > > >
> > > > Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
> > >
> > > rpmlib is complaining about the files not matching. Not yum. And I
> > > actually don't think this is a bug in rpm, either.
> >
> > Except for the fact that you can install both arches just fine using
> > rpm, but it fails with yum.
>
> really? That's interesting. It should be consistent b/c at the point
> where the error is coming from in yum, all of the operation is inisde
> rpmlib.

yep,

rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm cal3d-devel-0.11.0-5.fc8.i386.rpm

works like a charm.

not so well using yum localinstall...



From jkeating at redhat.com  Mon Oct 22 03:11:04 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 21 Oct 2007 23:11:04 -0400
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <d9c612bf0710212010r6a7a1fedy70dd2da696a4be8d@mail.gmail.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<47192D27.4070700@redhat.com> <87zlyef6un.fsf@kosh.bigo.ensc.de>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<1193019590.8542.265.camel@cutter>
	<d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>
	<1193022245.8542.271.camel@cutter>
	<d9c612bf0710212010r6a7a1fedy70dd2da696a4be8d@mail.gmail.com>
Message-ID: <20071021231104.71b8d991@redhat.com>

On Sun, 21 Oct 2007 20:10:41 -0700
"Christopher Stone" <chris.stone at gmail.com> wrote:

> yep,
> 
> rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm
> cal3d-devel-0.11.0-5.fc8.i386.rpm
> 
> works like a charm.
> 
> not so well using yum localinstall...


Erm, try installing the x86_64 package.  Then install the i386 one.
Two transactions, not one.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071021/493c3849/attachment.sig>

From chris.stone at gmail.com  Mon Oct 22 03:16:18 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 21 Oct 2007 20:16:18 -0700
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071021231104.71b8d991@redhat.com>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<471A2B5F.7050705@redhat.com> <471A3221.6040109@redhat.com>
	<20071020170118.GF4413@psilocybe.teonanacatl.org>
	<d9c612bf0710210901o3b782e82gbe4668ed1cd3e93c@mail.gmail.com>
	<1193019590.8542.265.camel@cutter>
	<d9c612bf0710212004r22794710j8e1e360a36be4ae9@mail.gmail.com>
	<1193022245.8542.271.camel@cutter>
	<d9c612bf0710212010r6a7a1fedy70dd2da696a4be8d@mail.gmail.com>
	<20071021231104.71b8d991@redhat.com>
Message-ID: <d9c612bf0710212016o13deda49m6abeff013f955910@mail.gmail.com>

On 10/21/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Sun, 21 Oct 2007 20:10:41 -0700
> "Christopher Stone" <chris.stone at gmail.com> wrote:
>
> > yep,
> >
> > rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm
> > cal3d-devel-0.11.0-5.fc8.i386.rpm
> >
> > works like a charm.
> >
> > not so well using yum localinstall...
>
>
> Erm, try installing the x86_64 package.  Then install the i386 one.
> Two transactions, not one.

Thank god there are no plans to remove rpm from Fedora... ;-)



From jwboyer at jdub.homelinux.org  Mon Oct 22 03:24:49 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Sun, 21 Oct 2007 22:24:49 -0500
Subject: Thinkpad button regression
In-Reply-To: <1193013844.25405.23.camel@cookie.hadess.net>
References: <20071021144008.0fd8f81e@vader.jdub.homelinux.org>
	<20071021154840.02a9011c@vader.jdub.homelinux.org>
	<1193013844.25405.23.camel@cookie.hadess.net>
Message-ID: <20071021222449.6bdf8491@vader.jdub.homelinux.org>

On Mon, 22 Oct 2007 01:44:04 +0100
Bastien Nocera <bnocera at redhat.com> wrote:

> 
> On Sun, 2007-10-21 at 15:48 -0500, Josh Boyer wrote:
> > On Sun, 21 Oct 2007 14:40:08 -0500
> > Josh Boyer <jwboyer at jdub.homelinux.org> wrote:
> > 
> > > Up until rebooting this morning, I used to be able to use the
> > > Fn+<button> combinations just fine with rawhide.  Now, FN+Home, FN+End
> > > don't adjust the backlight level.  This is pretty annoying, because I
> > > also can't dim the backlight through any of the gnome-* apps either.
> > > What changed and how the hell to I get rid of it?
> > 
> > Oh, and my FN+F5 combo hasn't worked for the bluetooth switch in a
> > while.  Grr.
> 
> Read the list more carefully, it's been pointed out it's a kernel bug,
> although no one posted a bug link.

I know that.  I was pretending I didn't.  Forgive my frustration.

josh



From j.w.r.degoede at hhs.nl  Mon Oct 22 07:10:43 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 09:10:43 +0200
Subject: License review for new itext version
In-Reply-To: <200710220029.30090@rineau.tsetse>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse>
Message-ID: <471C4CF3.7030200@hhs.nl>

Laurent Rineau wrote:
> On Sunday 12 August 2007 23:01:34 Jochen Schmitt wrote:
>> Hello,
>>
>> in the past we have removed itext and pdftk which depends on itext from
>> the Fedora distribution due
>> license issue.
>>
>> In the new iText package itext-2.0.4 I have found a text file about the
>> licensing situation of the
>> source file coming from Sun Corporation Inc.
>>
>> I have uploaded this file for review on
>>
>> http://www.herr-schmitt.de/pub/itext/sun.txt
>>
>> I want to know, it this ok for Fedora. But I assume, that the last term
>> about usage this
>> file for nuclear weapons may be a blocker.
> 
> Jochen, do you have an update of the situation? Will upstream agree to modify 
> the license scheme a bit?
> 
> I use pdftk randomly in my job, several times a year, but I really need it. It 
> is not so nice to see one usefull package go away from Fedora.
> 

You can try contacting Sun yourself, in the end getting license changes like 
this can take a long breath, multiple contact attempts before finding someone 
who is willing to discuss things, etc. So if you care, please contact Sun. And 
as always, please do so in a polite and friendly manner.

Regards,

Hans



From lemenkov at gmail.com  Mon Oct 22 07:34:55 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Mon, 22 Oct 2007 11:34:55 +0400
Subject: Some thoughts about firmware inclusion.
Message-ID: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>

Hello All.
Since we can include firmware for different devices into Fedora, can
we include win32-binaries for use together with Wine, DOS executables
for dosbox, jars for use with Java stacks , etc (if will be confirmed
that they works).

Reading guidelines about firmware and emulators I don't understand
whether its prohibited or not.

-- 
With best regards!



From nicolas.mailhot at laposte.net  Mon Oct 22 08:06:18 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 10:06:18 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <7678.192.54.193.51.1193040378.squirrel@rousalka.dyndns.org>


Le Lun 22 octobre 2007 09:34, Peter Lemenkov a ?crit :

> Since we can include firmware for different devices into Fedora, can
> we include win32-binaries for use together with Wine, DOS executables
> for dosbox, jars for use with Java stacks , etc (if will be confirmed
> that they works).

These are executed on the main CPU so the answer is no

-- 
Nicolas Mailhot



From aportal at univ-montp2.fr  Mon Oct 22 08:14:59 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Oct 2007 10:14:59 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071019225537.A29006@humbolt.us.dell.com>
References: <20071019225537.A29006@humbolt.us.dell.com>
Message-ID: <200710221014.59487.aportal@univ-montp2.fr>

> pikloops-0.2.5-1.fc8 (build/make) dionysos

2007-10-19 19:05:29,523 - util.py:194:DEBUG: checking for Qt... configure: 
error: Qt (>= Qt 3.1 (20021021) and < 4.0) (headers and libraries) not found. 
Please check your installation!

I don't understand why this failed because pikllops BR kdelibs-devel and 
kdelibs-devel BR qt-devel...

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From lemenkov at gmail.com  Mon Oct 22 08:18:04 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Mon, 22 Oct 2007 12:18:04 +0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <7678.192.54.193.51.1193040378.squirrel@rousalka.dyndns.org>
References: <7678.192.54.193.51.1193040378.squirrel@rousalka.dyndns.org>
Message-ID: <adf480660710220118t70c2d338y6cc79559b1d950@mail.gmail.com>

2007/10/22, Nicolas Mailhot <nicolas.mailhot at laposte.net>:

> > Since we can include firmware for different devices into Fedora, can
> > we include win32-binaries for use together with Wine, DOS executables
> > for dosbox, jars for use with Java stacks , etc (if will be confirmed
> > that they works).

> These are executed on the main CPU so the answer is no

There is no such prohibition.
OTOH we've got policy for emulators from that we may understand that
ROMs may be included (policy prohibits only inclusion of COPYRIGHTED
blobs fr emulators).

-- 
With best regards!



From fedora at leemhuis.info  Mon Oct 22 08:37:28 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 22 Oct 2007 10:37:28 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <adf480660710220118t70c2d338y6cc79559b1d950@mail.gmail.com>
References: <7678.192.54.193.51.1193040378.squirrel@rousalka.dyndns.org>
	<adf480660710220118t70c2d338y6cc79559b1d950@mail.gmail.com>
Message-ID: <471C6148.7010003@leemhuis.info>

On 22.10.2007 10:18, Peter Lemenkov wrote:
> 2007/10/22, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> 
>>> Since we can include firmware for different devices into Fedora, can
>>> we include win32-binaries for use together with Wine, DOS executables
>>> for dosbox, jars for use with Java stacks , etc (if will be confirmed
>>> that they works).
>> These are executed on the main CPU so the answer is no
> There is no such prohibition.

There is, but it's indirectly by the definition of firmware, as we
afaics only call something firmware which is executed in the hardware
and not on the host CPU (just like the BIOS). That's why madwifi's HAL
is no firmware and the current madwifi thus not in Fedora.

> [...]

Cu
knurd



From nicolas.mailhot at laposte.net  Mon Oct 22 08:39:53 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 10:39:53 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>


Le Lun 22 octobre 2007 10:18, Peter Lemenkov a ?crit :
> 2007/10/22, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>> > Since we can include firmware for different devices into Fedora,
>> can
>> > we include win32-binaries for use together with Wine, DOS
>> executables
>> > for dosbox, jars for use with Java stacks , etc (if will be
>> confirmed
>> > that they works).
>
>> These are executed on the main CPU so the answer is no
>
> There is no such prohibition.

There is such a prohibition. The firmware-specific binary blobs
licensing relaxing does not apply to the OP examples.

Every single example he made falls under general Fedora rules: must be
built from source and use FLOSS license.

-- 
Nicolas Mailhot



From rjones at redhat.com  Mon Oct 22 08:52:20 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Oct 2007 09:52:20 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193013121.5168.68.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>
Message-ID: <471C64C4.2090705@redhat.com>

Jon Masters wrote:
>  It obviously was a kludge. And a great one - Jeremy, Bill, and other
> *smart* people (so don't get me wrong guys!) had to come up with a
> solution at some point when this came up, but it's long since time to
> take a big breath and think about a longer term fix.
> 
> Can we agree that needs to happen? If so, I'll happily actually get
> involved in implementing a fix, as I've said to these folks in face to
> face conversations about multilib before!

Why don't we just install 64 bit packages (on x86-64)[1]?  I've been 
running Fedora 7 & 8 systems like this for ages without any problems.  I 
can't see why it isn't the default, with kludges only for the people who 
want 32 bit packages on their shiny 64 bit processor.

Rich.

[1] Or just 32 bit packages on ppc64.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/867c40cd/attachment.bin>

From j.w.r.degoede at hhs.nl  Mon Oct 22 08:52:53 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 10:52:53 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
Message-ID: <471C64E5.4070908@hhs.nl>

Nicolas Mailhot wrote:
> Le Lun 22 octobre 2007 10:18, Peter Lemenkov a ?crit :
>> 2007/10/22, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>>
>>>> Since we can include firmware for different devices into Fedora,
>>> can
>>>> we include win32-binaries for use together with Wine, DOS
>>> executables
>>>> for dosbox, jars for use with Java stacks , etc (if will be
>>> confirmed
>>>> that they works).
>>> These are executed on the main CPU so the answer is no
>> There is no such prohibition.
> 
> There is such a prohibition. The firmware-specific binary blobs
> licensing relaxing does not apply to the OP examples.
> 
> Every single example he made falls under general Fedora rules: must be
> built from source and use FLOSS license.
> 

I fully agree, this discussion does raise one interesting question though: What 
if there is fully floss software, which we can build from source. Which is 
written for another OS, but will run fine under an emulator and is hard to 
port. Do we allow shipping this?

(assuming someone first packages the needed cross toolchain to build this, 
which is something we may want to have independent of the answer to this question).

Regards,

Hans

p.s.

And no I do not have anything particular in mind, for now this is just a 
hypothetical question.



From pertusus at free.fr  Mon Oct 22 08:53:13 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 10:53:13 +0200
Subject: Multiarch crazyiness
In-Reply-To: <471C64C4.2090705@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
Message-ID: <20071022085313.GB2941@free.fr>

On Mon, Oct 22, 2007 at 09:52:20AM +0100, Richard W.M. Jones wrote:
> Jon Masters wrote:
>>  It obviously was a kludge. And a great one - Jeremy, Bill, and other
>> *smart* people (so don't get me wrong guys!) had to come up with a
>> solution at some point when this came up, but it's long since time to
>> take a big breath and think about a longer term fix.
>> Can we agree that needs to happen? If so, I'll happily actually get
>> involved in implementing a fix, as I've said to these folks in face to
>> face conversations about multilib before!
>
> Why don't we just install 64 bit packages (on x86-64)[1]?  I've been 
> running Fedora 7 & 8 systems like this for ages without any problems.  I 
> can't see why it isn't the default, with kludges only for the people who 
> want 32 bit packages on their shiny 64 bit processor.

The idea is to be possible to develop and run together software for all
the supported arches, to let te choice to users.

--
Pat



From lemenkov at gmail.com  Mon Oct 22 08:58:06 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Mon, 22 Oct 2007 12:58:06 +0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471C64E5.4070908@hhs.nl>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
Message-ID: <adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>

> I fully agree, this discussion does raise one interesting question though: What
> if there is fully floss software, which we can build from source. Which is
> written for another OS, but will run fine under an emulator and is hard to
> port. Do we allow shipping this?

BTW there is an obvious example - VirtualDUB.

-- 
With best regards!



From valent.turkovic at gmail.com  Mon Oct 22 08:58:57 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 22 Oct 2007 10:58:57 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071021142921.GC25455@angus.ind.WPI.EDU>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
	<20071021142921.GC25455@angus.ind.WPI.EDU>
Message-ID: <64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>

On 10/21/07, Chuck Anderson <cra at wpi.edu> wrote:
> On Sun, Oct 21, 2007 at 04:22:16PM +0200, Valent Turkovic wrote:
> > So my question is how can I (and other that can't code if they life
> > depended on it) help you make wireless more user-friendly for novice
> > users?
>
> Have you seen NetworkManager?  In Fedora 7, it usually just works for
> connecting to most kinds of wireless networks.  Unfortunately in
> Fedora 8, the new NM 0.7 is missing support for some kinds of wireless
> networks, and as such is a regression from Fedora 7 [1].
>
> [1]
> https://bugzilla.redhat.com/showdependencytree.cgi?id=336531
>

I'm using Fedora 8 test 3 with latest updates and I don't see Network
Manager running after default setup - maybe that is the only issue?

It could be argued that if it is not on by default it is the same as
it doesn't exist - at least for new users.

What is the usage scenario in F7 and F8? What are the expected steps
that users are expected to take in order for them to connect to
wireless network after default install?

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From sundaram at fedoraproject.org  Mon Oct 22 07:59:24 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Oct 2007 14:29:24 +0630
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>
	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>
Message-ID: <471C585C.4070009@fedoraproject.org>

Valent Turkovic wrote:
> On 10/21/07, Chuck Anderson <cra at wpi.edu> wrote:
>> On Sun, Oct 21, 2007 at 04:22:16PM +0200, Valent Turkovic wrote:
>>> So my question is how can I (and other that can't code if they life
>>> depended on it) help you make wireless more user-friendly for novice
>>> users?
>> Have you seen NetworkManager?  In Fedora 7, it usually just works for
>> connecting to most kinds of wireless networks.  Unfortunately in
>> Fedora 8, the new NM 0.7 is missing support for some kinds of wireless
>> networks, and as such is a regression from Fedora 7 [1].
>>
>> [1]
>> https://bugzilla.redhat.com/showdependencytree.cgi?id=336531
>>
> 
> I'm using Fedora 8 test 3 with latest updates and I don't see Network
> Manager running after default setup - maybe that is the only issue?

Note that the Live images do have Network Manager enabled by default 
which is the recommend thing to get if you are a desktop user.

Rahul



From mls at suse.de  Mon Oct 22 09:02:17 2007
From: mls at suse.de (Michael Schroeder)
Date: Mon, 22 Oct 2007 11:02:17 +0200
Subject: Multiarch crazyiness
In-Reply-To: <471BC22D.4000908@amiga-hardware.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
Message-ID: <20071022090217.GB18767@suse.de>

On Sun, Oct 21, 2007 at 10:18:37PM +0100, Ian Chapman wrote:
> Hans de Goede wrote:
> 
> >The current multilib solution in rpm is far from pretty, it works well, 
> >but definitively has downsides. I think as is its a reasonable 
> >comprimise, lets not add bandaids and patches to it for issues which 
> >should be solved elsewhere, I feel the pain of maintainers getting these 
> >bugs (I got 15 of them), but they are fixable without requiring the 
> >addition of yet another multilib kludge to rpm.
> 
> Well the question is still really where should these issues ultimately 
> be solved? Is kludging the rpms any more elegant than patching rpm? I 
> must admit I have no idea how other distro's deal with these kind of 
> issues.

We (SUSE) create extra '-32bit' packages from the 32bit versions that
just contain the needed files (i.e. libs, no doc). As an example,
we have

zlib.i586          the 32bit version
zlib-32bit.x86_64  a subset of the 32bit version
zlib.x86_64        the 64bit version

The big advantage is that don't need to have two packages with
the same name installed, thus no kludges are needed in the solver.
The downside is that the extra packages need a bit more space.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From j.w.r.degoede at hhs.nl  Mon Oct 22 09:06:24 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 11:06:24 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
Message-ID: <471C6810.5070200@hhs.nl>

Peter Lemenkov wrote:
>> I fully agree, this discussion does raise one interesting question though: What
>> if there is fully floss software, which we can build from source. Which is
>> written for another OS, but will run fine under an emulator and is hard to
>> port. Do we allow shipping this?
> 
> BTW there is an obvious example - VirtualDUB.
> 

Which uses all kind of patented stuff and thus is a no go.

Regards,

Hans (who still thinks the question is valid, and the answer is yes)



From bnocera at redhat.com  Mon Oct 22 09:09:34 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 22 Oct 2007 10:09:34 +0100
Subject: NSCD, Fedora, and busted DNS
In-Reply-To: <1193021774.5168.129.camel@perihelion>
References: <1193013005.5168.65.camel@perihelion>
	<1193013736.25405.21.camel@cookie.hadess.net>
	<1193021774.5168.129.camel@perihelion>
Message-ID: <1193044174.25405.25.camel@cookie.hadess.net>


On Sun, 2007-10-21 at 22:56 -0400, Jon Masters wrote:
> On Mon, 2007-10-22 at 01:42 +0100, Bastien Nocera wrote:
> > On Sun, 2007-10-21 at 20:30 -0400, Jon Masters wrote:
> > > Yo,
> > <snip>
> > > But most randomly annoying today, an strace shows that the Rhythmbox
> > > application[0] thinks it's a good idea to do a DNS lookup *every* time
> > > one changes track...lovely. Really stupid.
> > 
> > And what domain would that be? It wouldn't happen to be:
> > - Amazon.com (covers)
> > or
> > - one of the lyrics websites (lyrics plugin)
> > or
> > - audioscrobbler.com (for the last.fm functionality)
> > 
> > We're working upstream on making all those disabled if NetworkManager
> > doesn't see a network connection. See:
> > http://bugzilla.gnome.org/show_bug.cgi?id=322266
> > 
> > In the meanwhile, those lookups would be normal.
> 
> Right. But even if NetworkManager detects a connection, that doesn't
> mean it's actually working - moving to the track shouldn't block, the
> lookup should be asynchronous ideally. It's still great software! :-)

You didn't say it blocked, it shouldn't. File a bug with a backtrace.



From valent.turkovic at gmail.com  Mon Oct 22 09:36:20 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 22 Oct 2007 11:36:20 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <471C585C.4070009@fedoraproject.org>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
	<20071021142921.GC25455@angus.ind.WPI.EDU>
	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>
	<471C585C.4070009@fedoraproject.org>
Message-ID: <64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>

On 10/22/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Valent Turkovic wrote:
> > On 10/21/07, Chuck Anderson <cra at wpi.edu> wrote:
> >> On Sun, Oct 21, 2007 at 04:22:16PM +0200, Valent Turkovic wrote:
> >>> So my question is how can I (and other that can't code if they life
> >>> depended on it) help you make wireless more user-friendly for novice
> >>> users?
> >> Have you seen NetworkManager?  In Fedora 7, it usually just works for
> >> connecting to most kinds of wireless networks.  Unfortunately in
> >> Fedora 8, the new NM 0.7 is missing support for some kinds of wireless
> >> networks, and as such is a regression from Fedora 7 [1].
> >>
> >> [1]
> >> https://bugzilla.redhat.com/showdependencytree.cgi?id=336531
> >>
> >
> > I'm using Fedora 8 test 3 with latest updates and I don't see Network
> > Manager running after default setup - maybe that is the only issue?
>
> Note that the Live images do have Network Manager enabled by default
> which is the recommend thing to get if you are a desktop user.
>
> Rahul

That sounds like a great idea, I support the idea of making it on by
default also in DVD install images.

I tried starting NetworkManager under my user account on F8t3 but I
got an error message "You must be root to run NetworkManager!" :(

Please make it on by default also for DVD install images.

One other small issue; I can't find NetworkManager anywhere in Gnome
menue. Where is it located? There is no shortcut that I can see in
Applications or in System menues. It that on purpose? Why?

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From nicolas.mailhot at laposte.net  Mon Oct 22 09:48:13 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 11:48:13 +0200 (CEST)
Subject: any plans to make wireless more user-friendly in Fedora 9?
Message-ID: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>


Le Lun 22 octobre 2007 11:36, Valent Turkovic a ?crit :

> Please make it on by default also for DVD install images.

Till it works for all the systems Fedora targets (including those with
no permanent GUI session that also need network/wifi connexion) the
answer is no.

Right now NetworkManager is targetting a very small user niche, so
it's only usable as default in the spin dedicated to this niche (and
one could argue the spin desktop target audience is wider than the
laptop-only no-daemon dumbed-down desktop NetworkManager supports)

-- 
Nicolas Mailhot



From caillon at redhat.com  Mon Oct 22 09:51:22 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 22 Oct 2007 05:51:22 -0400
Subject: Opinions needed (in bugzilla please) regarding Firefox/compiz
 interaction for Fedora 8.
In-Reply-To: <1192918382.2988.5.camel@localhost.localdomain>
References: <20071019095919.54791e62@redhat.com>	<1192803165.7047.29.camel@oneill.fubar.dk>	<20071019101244.7a7d62c7@redhat.com>
	<1192918382.2988.5.camel@localhost.localdomain>
Message-ID: <471C729A.6080108@redhat.com>

Rodd Clarkson wrote:
> Granted, the different desktops work in different ways, but where
> possible they should mimic each others behaviors.  After all, compiz is
> the 3D version of Metacity (given that you're not adding compiz like
> rendering into metacity since compiz does it).

Actually, metacity has it's own compositor, though we sort of dropped it 
when everyone started getting all OMGKUBEZ!



From buildsys at redhat.com  Mon Oct 22 10:28:30 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 22 Oct 2007 06:28:30 -0400
Subject: rawhide report: 20071022 changes
Message-ID: <200710221028.l9MASUVr003457@porkchop.devel.redhat.com>

 

Removed package xorg-x11-drv-radeonhd

Updated Packages:

anaconda-11.3.0.43-1
--------------------
* Sun Oct 21 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.43-1
- Fix closing of some fds (pjones)
- Fix ip address used in a few cases (clumens, #336761)
- Filter out non-useful networking devices from being 
  displayed (clumens, #338461)
- Fix a quoting bug with pxelinux (#248170)
- Label lost+found (pjones, #335621)
- Update udev rules to not match wmaster (notting)
- gptsync update (pjones)
- Detect invalid harddrives given to bootloader --driveorder (#33861)

gcc-4.1.2-33
------------
* Sun Oct 21 2007 Jakub Jelinek <jakub at redhat.com> 4.1.2-33
- rebuild to fix multilib conflict between i386 and x86_64 libgcj,
  set java man page timestamp from the timestamp of *.texinfo rather
  than current date to avoid this problem in the future (#341221)
- fix ppc64 unwinding of cr2 register if vdso=0

kernel-2.6.23.1-26.fc8
----------------------
* Thu Oct 18 2007 Dave Jones <davej at redhat.com>
- SIlence i8042 'error' on imacs and such.

* Thu Oct 18 2007 Dave Jones <davej at redhat.com>
- Disable polling before registering netdevice in e100.

* Thu Oct 18 2007 John W. Linville <linville at redhat.com>
- avoid null ptr dereference in rx path of zd1201 driver

libraw1394-1.3.0-2.fc8
----------------------
* Fri Oct 19 2007 Jarod Wilson <jwilson at redhat.com> - 1.3.0-2
- Fix the 'double free' crash on shutdown (#328011)

* Thu Oct 18 2007 Jarod Wilson <jwilson at redhat.com> - 1.3.0-1
- libraw1394 v1.3.0

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From sundaram at fedoraproject.org  Mon Oct 22 09:29:15 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Oct 2007 15:59:15 +0630
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>	<471C585C.4070009@fedoraproject.org>
	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
Message-ID: <471C6D6B.2060405@fedoraproject.org>

Valent Turkovic wrote:

> One other small issue; I can't find NetworkManager anywhere in Gnome
> menue. Where is it located? There is no shortcut that I can see in
> Applications or in System menues. It that on purpose? Why?

You aren't supposed to run it as a command or call it from the menu. See

http://fedoraproject.org/wiki/NetworkManager

Rahul



From caillon at redhat.com  Mon Oct 22 10:44:43 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 22 Oct 2007 06:44:43 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>	<471C585C.4070009@fedoraproject.org>
	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
Message-ID: <471C7F1B.3060005@redhat.com>

Valent Turkovic wrote:
> I tried starting NetworkManager under my user account on F8t3 but I
> got an error message "You must be root to run NetworkManager!" :(
> 
> Please make it on by default also for DVD install images.

In the DVD version, you need to enable the service. 
system-config-services will help you do that.



From buc at odusz.so-cdu.ru  Mon Oct 22 11:53:49 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 22 Oct 2007 15:53:49 +0400
Subject: Live Upgrade Special Interest Group
In-Reply-To: <4719F78C.8080500@fedoraproject.org>
References: <4719F78C.8080500@fedoraproject.org>
Message-ID: <471C8F4D.5040404@odu.neva.ru>

Rahul Sundaram wrote:
> Hi
>
> Here you go. Join the group and help make live upgrades work smoothly.
>
> http://fedoraproject.org/wiki/SIGs/LiveUpgrade
>
Excellent!

I'm already have done FC3-->FC5 by "yum upgrade" only. Yep, some magic 
was needed. :)

And I even have plans to do FC5-->F7 these days immediately.

One thing is:
> Often test upgrading to the current development branch of one of the 
> test releases from the previous general release

but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...

We use Fedora in a production environment, and half-year cycle is too 
fast for us. (CentOS and friends are "too slow" OTOH).

Does such an expirience will be interesting for you?


BTW, the using of "yum upgrade" allows us to minimize an "outage" period 
for critical servers. Instead of up to 60min of update time by Anaconda, 
we do "yum upgrade" on the live system, and have about 5min for reboot 
(to catch new kernel and glibc).

Certainly, some packages from the new release should be ported to the 
previous first -- for cases when "service foo restart" is not enough, 
and we have to edit (new) config files manually (aka apache1-->apache2 etc.)


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy






From bernie at codewiz.org  Mon Oct 22 12:17:01 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Mon, 22 Oct 2007 08:17:01 -0400
Subject: Should we settle on one SSL implementation?
Message-ID: <471C94BD.6080801@codewiz.org>

I remember this topic being discussed some time ago,
but software is fluid and maybe it's time to respin
the topic.

It would seem a worthwhile goal to unify SSL/TLS
implementations like we did for spell checkers.
Or, if it turns out to be too hard, at least it would
be nice to their pki files.

We're now shipping no less than 4 different implementations
of SSL:

 - openssl (OpenBSD's implementation)
 - nss (Netscape's implementation)
 - gnutls (LGPL implementation)
 - puretls (Java implementation)

But which one should replace the others?

It is not clear to me.  Judging from dependencies, OpenSSL,
NSS and gnutls all seem equally popular in Fedora.

If we are to believe a non-independent comparison, gnutls
looks like the best choice:

  http://www.gnu.org/software/gnutls/comparison.html

I couldn't find good benchmarks around, but they would
make an important decision factor.

There are two good reasons not to choose OpenSSL: the
license is GPL incompatible and the ABI gets broken by
upstream very frequently.  Strangely enough, OpenSSL in
F8 is linked against nss instead of openssl.

Thoughts?

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From sundaram at fedoraproject.org  Mon Oct 22 11:21:01 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Oct 2007 17:51:01 +0630
Subject: Live Upgrade Special Interest Group
In-Reply-To: <471C8F4D.5040404@odu.neva.ru>
References: <4719F78C.8080500@fedoraproject.org> <471C8F4D.5040404@odu.neva.ru>
Message-ID: <471C879D.8060905@fedoraproject.org>

Dmitry Butskoy wrote:

> One thing is:
>> Often test upgrading to the current development branch of one of the 
>> test releases from the previous general release
> 
> but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...
> 
> We use Fedora in a production environment, and half-year cycle is too 
> fast for us. (CentOS and friends are "too slow" OTOH).
> 
> Does such an expirience will be interesting for you?

Yes. Skipping a release and upgrading should work. Atleast that is what 
we try to support.

Rahul



From lemenkov at gmail.com  Mon Oct 22 12:27:59 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Mon, 22 Oct 2007 16:27:59 +0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <adf480660710220527j3136c392g74aa45dbd99cad3c@mail.gmail.com>

2007/10/22, Bernardo Innocenti <bernie at codewiz.org>:

> If we are to believe a non-independent comparison, gnutls
> looks like the best choice:

?ake a look at that article:

http://blue-gnu.biz/content/gnutls_release_removes_tls_authorization_due_patent_issue

-- 
With best regards!



From P at draigBrady.com  Mon Oct 22 12:36:06 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 22 Oct 2007 13:36:06 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <471C9936.3080709@draigBrady.com>

Bernardo Innocenti wrote:
> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
> 
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
> 
> We're now shipping no less than 4 different implementations
> of SSL:
> 
> - openssl (OpenBSD's implementation)
> - nss (Netscape's implementation)
> - gnutls (LGPL implementation)
> - puretls (Java implementation)
> 
> But which one should replace the others?
> 
> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.

Fedora is consolidating to NSS isn't it?
http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01594.html

P?draig.



From abartlet at samba.org  Mon Oct 22 12:48:24 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Mon, 22 Oct 2007 22:48:24 +1000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <1193057304.21427.11.camel@naomi>


On Mon, 2007-10-22 at 08:17 -0400, Bernardo Innocenti wrote:
> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
> 
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
> 
> We're now shipping no less than 4 different implementations
> of SSL:
> 
>  - openssl (OpenBSD's implementation)
>  - nss (Netscape's implementation)
>  - gnutls (LGPL implementation)
>  - puretls (Java implementation)
> 
> But which one should replace the others?
> 
> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.

Is there a graph of that around?  It could be really interesting when
looking at what packages to convert/mimic.  (The nss_compat_ossl package
is in the mimic game, as is a package to make gnutls look like
openssl). 

I'm hoping for a nss_compat_gnutls package some day...

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071022/122cdd64/attachment.sig>

From limb at jcomserv.net  Mon Oct 22 12:55:03 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 22 Oct 2007 07:55:03 -0500 (CDT)
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471B2444.8030901@kanarip.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
Message-ID: <53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>


> Rahul Sundaram wrote:
>> Jeroen van Meeuwen wrote:
>>
>>
>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8
>>> using *just* CDs.
>>
>> Now we are talking about an actual problem which wasn't clear to me
>> earlier. So if Fedora Project released regular CD's for this release and
>> makes live upgrades a supported option from Fedora 9 onwards, do you see
>> any need for a regular CD variant in the future?
>>
>
> Other then for it's sentimental value, the impressive number of discs
> for the Everything spin or laptop-in-the-bush cases, there's no real
> need for CD's. The few people that want a customized install with all
> kinds of exotic partitioning schemes (or minimal installs) should either
> be able to create CDs off the DVD iso or get the CDs from any third
> party providing them.

A: I have not DVD drives.

B: So we'll be providing links to "official" 3rd parties who provide CDs,
then?

C: By the time I can create a CD set for F-8 from remote mirrors with
Revisor, F-9 will be at Test3. . .

Jon

> --
> Kind regards,
>
> Jeroen van Meeuwen
> -kanarip
>
> --
> http://www.kanarip.com/
> RHCE, LPIC-2, MCP, CCNA
> C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From lesmikesell at gmail.com  Mon Oct 22 13:07:33 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Oct 2007 08:07:33 -0500
Subject: Live Upgrade Special Interest Group
In-Reply-To: <471C8F4D.5040404@odu.neva.ru>
References: <4719F78C.8080500@fedoraproject.org> <471C8F4D.5040404@odu.neva.ru>
Message-ID: <471CA095.2030106@gmail.com>

Dmitry Butskoy wrote:

>> Often test upgrading to the current development branch of one of the 
>> test releases from the previous general release
> 
> but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...
> 
> We use Fedora in a production environment, and half-year cycle is too 
> fast for us. (CentOS and friends are "too slow" OTOH).

CentOS isn't going to be _that_ much different since it would 
approximate  FC1->FC3->FC6 so far - especially if you wait for some 
updates to stabilize the fedora release before you upgrade.  I'd think 
you would be better off using Centos as the base in production but 
building a few apps that matter to you from fedora src rpms or finding a 
repository that does that.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From jnovy at redhat.com  Mon Oct 22 13:27:53 2007
From: jnovy at redhat.com (Jindrich Novy)
Date: Mon, 22 Oct 2007 15:27:53 +0200
Subject: packaging libcurl separately
Message-ID: <20071022132753.GC2988@dhcp-lab-186.brq.redhat.com>

Hi all,

just a few questions:

1) What is your opinion on packaging libcurl separately (read independently on curl)?
   For references: http://curl.haxx.se/mail/lib-2004-09/0095.html

2) How about compat-libcurl or libcurl3, libcurl4 packages to let users run third
   party software independently on the libcurl version in the distribution?

Thanks,
Jindrich

-- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From jima at beer.tclug.org  Mon Oct 22 13:29:35 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 22 Oct 2007 08:29:35 -0500 (CDT)
Subject: source file audit - 2007-10-17
In-Reply-To: <20071019174059.541ddd78@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
	<604aa7910710191610x6605b298u96a29de50bcc993b@mail.gmail.com>
	<20071019174059.541ddd78@ghistelwchlohm.scrye.com>
Message-ID: <Pine.LNX.4.64.0710220826480.4486@beer.tclug.org>

On Fri, 19 Oct 2007, Kevin Fenzi wrote:
> HTTP request sent, awaiting response... 302 Moved Temporarily
...
> I will try and fix my script to detect this better...

  Exclude 302's?  Look specifically for 404's (this may be iffy)?
  I do appreciate these checks, Kevin, and agree that this should probably 
become a more official part of our process (although I think we can all 
agree it needs a little fine-tuning :).  Thanks!

      Jima



From jkeating at redhat.com  Mon Oct 22 13:33:05 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 09:33:05 -0400
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <200710221014.59487.aportal@univ-montp2.fr>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<200710221014.59487.aportal@univ-montp2.fr>
Message-ID: <20071022093305.7f73ae22@redhat.com>

On Mon, 22 Oct 2007 10:14:59 +0200
Alain PORTAL <aportal at univ-montp2.fr> wrote:

> I don't understand why this failed because pikllops BR kdelibs-devel
> and kdelibs-devel BR qt-devel...

If kdelibs-devel BR's qt-devel that is different from Requires.
BuildRequires are only used when /building/ that particular package.
They are not looked at when just /installing/ that package.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/5f9ecdd7/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Oct 22 13:36:35 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 15:36:35 +0200 (CEST)
Subject: packaging libcurl separately
Message-ID: <51703.192.54.193.51.1193060195.squirrel@rousalka.dyndns.org>


Le Lun 22 octobre 2007 15:27, Jindrich Novy a ?crit :

> 1) What is your opinion on packaging libcurl separately (read
> independently on curl)?
>    For references: http://curl.haxx.se/mail/lib-2004-09/0095.html

Why not

> 2) How about compat-libcurl or libcurl3, libcurl4 packages to let
> users run third
>    party software independently on the libcurl version in the
> distribution?

This can of thing is easy to create but a lot less easy to get rid of
and then livecd/one-cd-spin people hate you

-- 
Nicolas Mailhot



From jkeating at redhat.com  Mon Oct 22 13:35:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 09:35:26 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471C64C4.2090705@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
Message-ID: <20071022093526.3a2941e9@redhat.com>

On Mon, 22 Oct 2007 09:52:20 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:

> [1] Or just 32 bit packages on ppc64.

You still need a 64bit kernel, and a few other 64bit userland packages
to deal with the kernel and whatever other 64bit binaries happen to be
running, and the deps of those, and...

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/03dbb826/attachment.sig>

From ajackson at redhat.com  Mon Oct 22 13:12:18 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 22 Oct 2007 09:12:18 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
Message-ID: <1193058738.26974.3.camel@localhost.localdomain>

On Mon, 2007-10-22 at 11:34 +0400, Peter Lemenkov wrote:
> Hello All.
> Since we can include firmware for different devices into Fedora, can
> we include win32-binaries for use together with Wine, DOS executables
> for dosbox, jars for use with Java stacks , etc (if will be confirmed
> that they works).

If you have the source for them and they're under a free licence, then
sure.  Otherwise, no.

This is not the same thing as a firmware, because firmware doesn't
execute on the host CPU.  Practically speaking, that's where we draw the
line.

- ajax



From jima at beer.tclug.org  Mon Oct 22 13:40:13 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 22 Oct 2007 08:40:13 -0500 (CDT)
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071020095212.402c5849@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
Message-ID: <Pine.LNX.4.64.0710220835070.4486@beer.tclug.org>

On Sat, 20 Oct 2007, Jesse Keating wrote:
> This was our first trial of using pkgdb completely for the branching of
> the system.  We have identified some parts where we could possible
> speed things up for the next time we mass branch so I expect it to go
> faster next time, however if our package growth rate continues the
> speed ups we get may be surpassed by just branching that many more
> packages.

  Out of curiosity, in the next iteration of branching-time, will it be (or 
is it already?) possible for a maintainer to request that pkgdb branch 
their, or ideally, all of their, packages?  It seems to me that a packager 
could kick it off, knowing they're not going to make any modifications to 
their packages until the branching finishes, thereby reducing the need to 
actually lock CVS activity?  (Okay, some coordination with comaintainers 
would be necessary, but it could still be a good idea.)  Unless I'm 
missing something (always a possibility, and often a likely one), that 
would minimize the time needed for the mass branching.
  Thoughts? :-)

      Jima



From ajackson at redhat.com  Mon Oct 22 13:17:03 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 22 Oct 2007 09:17:03 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <1193059023.26974.8.camel@localhost.localdomain>

On Mon, 2007-10-22 at 08:17 -0400, Bernardo Innocenti wrote:

> We're now shipping no less than 4 different implementations
> of SSL:
> 
>  - openssl (OpenBSD's implementation)

You have your history wrong.  OpenSSL was forked from SSLeay because the
original authors stopped maintaining it.

- ajax



From jkeating at redhat.com  Mon Oct 22 13:43:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 09:43:38 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <Pine.LNX.4.64.0710220835070.4486@beer.tclug.org>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<Pine.LNX.4.64.0710220835070.4486@beer.tclug.org>
Message-ID: <20071022094338.1c49c812@redhat.com>

On Mon, 22 Oct 2007 08:40:13 -0500 (CDT)
Jima <jima at beer.tclug.org> wrote:

>   Out of curiosity, in the next iteration of branching-time, will it
> be (or is it already?) possible for a maintainer to request that
> pkgdb branch their, or ideally, all of their, packages?  It seems to
> me that a packager could kick it off, knowing they're not going to
> make any modifications to their packages until the branching
> finishes, thereby reducing the need to actually lock CVS activity?
> (Okay, some coordination with comaintainers would be necessary, but
> it could still be a good idea.)  Unless I'm missing something (always
> a possibility, and often a likely one), that would minimize the time
> needed for the mass branching. Thoughts? :-)

Well it still requires a CVS admin to do the actual branching of CVS.
We will be allowing for early branching of CVS next release just like
we did this release, although a bit more prominently advertised.

One of the other reasons why we lock all CVS during this time is that in
order to prevent mail flooding we disable the loginfo scripts which do
the diffing and sending of mail.  During that time we don't want other
phantom commits happening to the tree.

We're going to be making improvements to the tools before we get to the
next branch point so that hopefully it won't take nearly as long as it
did this time.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/32e37c18/attachment.sig>

From rjones at redhat.com  Mon Oct 22 13:47:12 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Oct 2007 14:47:12 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <471CA9E0.6020503@redhat.com>

Bernardo Innocenti wrote:
> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
> 
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.

I've asked whether we have a standard layout for /etc/pki before, but no 
one seems to know.

> We're now shipping no less than 4 different implementations
> of SSL:
> 
> - openssl (OpenBSD's implementation)
> - nss (Netscape's implementation)
> - gnutls (LGPL implementation)
> - puretls (Java implementation)

Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl.  I'm 
sure Perl & Python probably have their own too.

> But which one should replace the others?

When we implemented encryption in libvirt, we chose gnutls because it 
has excellent examples which allow you to actually write code to use it 
in a short period of time.  The others have (or we perceived them to 
have) hideous, confusing or undocumented APIs.

For a short while I documented the certificate management code in terms 
of the OpenSSL command line tools.  But after I found out about 
'certtool' (part of GnuTLS), I was able to rewrite that documentation 
and make it considerably simpler[1].  'certtool' is a lot more sane than 
the OpenSSL stuff.

Nevertheless, I don't think you're going to get rid of the competing SSL 
libraries.  Rewriting code to use a different API is a lot of make-work 
that no one wants to do, and doesn't contribute much benefit to anyone.

Rich.

[1] http://libvirt.org/remote.html#Remote_certificates

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/16f55bb0/attachment.bin>

From pbrobinson at gmail.com  Mon Oct 22 13:49:14 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 22 Oct 2007 14:49:14 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <5256d0b0710220649t4e68c9b1wfb4e0aed4aada251@mail.gmail.com>

> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
>
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
>
> We're now shipping no less than 4 different implementations
> of SSL:
>
>  - openssl (OpenBSD's implementation)
>  - nss (Netscape's implementation)
>  - gnutls (LGPL implementation)
>  - puretls (Java implementation)
>
> But which one should replace the others?
>
> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.
>
> If we are to believe a non-independent comparison, gnutls
> looks like the best choice:
>
>  http://www.gnu.org/software/gnutls/comparison.html
>
> I couldn't find good benchmarks around, but they would
> make an important decision factor.
>
> There are two good reasons not to choose OpenSSL: the
> license is GPL incompatible and the ABI gets broken by
> upstream very frequently.  Strangely enough, OpenSSL in
> F8 is linked against nss instead of openssl.
>
> Thoughts?

There's discussions about this on the project wiki here
http://fedoraproject.org/wiki/FedoraCryptoConsolidation

Not sure what the current status is though.

Peter



From kraxel at redhat.com  Mon Oct 22 13:59:25 2007
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 22 Oct 2007 15:59:25 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071022085313.GB2941@free.fr>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
Message-ID: <471CACBD.2080706@redhat.com>

Patrice Dumas wrote:
> On Mon, Oct 22, 2007 at 09:52:20AM +0100, Richard W.M. Jones wrote:
>> Why don't we just install 64 bit packages (on x86-64)[1]?  I've been 
>> running Fedora 7 & 8 systems like this for ages without any problems.  I 
>> can't see why it isn't the default, with kludges only for the people who 
>> want 32 bit packages on their shiny 64 bit processor.
> 
> The idea is to be possible to develop and run together software for all
> the supported arches, to let te choice to users.

Sure, but usually there isn't a point in having *both* 32bit and 64bit
versions of applications installed (which happens by default though).

Libraries and -devel packages are another story, although I'd pull the
32bit versions in as needed only too.

cheers,
  Gerd



From rc040203 at freenet.de  Mon Oct 22 14:00:55 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Oct 2007 16:00:55 +0200
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071020220439.5fa885a1@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
Message-ID: <1193061655.2531.14.camel@mccallum.corsepiu.local>

On Sat, 2007-10-20 at 22:04 -0400, Jesse Keating wrote:
> On Sat, 20 Oct 2007 09:52:12 -0400
> Jesse Keating <jkeating at redhat.com> wrote:
> 
> > > We're ready to try the branching again.  CVS will be disabled for
> > > commits in a few moments.  I will reply when the branching is
> > > done.  
> 
> The branching is done.  CVS commits have been re-enabled.  If your
> package is missing an F-8 branch please mail rel-eng at fedoraproject.org
> and we'll look into it.

I am missing FC-8 in bodhi. IMO, it should have been added
simultaneously with CVS-branching.

Ralf




From jkeating at redhat.com  Mon Oct 22 14:00:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:00:40 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <1193061655.2531.14.camel@mccallum.corsepiu.local>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
	<1193061655.2531.14.camel@mccallum.corsepiu.local>
Message-ID: <20071022100040.7a7c713f@redhat.com>

On Mon, 22 Oct 2007 16:00:55 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> I am missing FC-8 in bodhi. IMO, it should have been added
> simultaneously with CVS-branching.

It will be showing up today.  I didn't want to con other people into
working during the weekend.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/6c41d071/attachment.sig>

From jkeating at redhat.com  Mon Oct 22 14:01:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:01:32 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471CACBD.2080706@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
Message-ID: <20071022100132.76f33bbd@redhat.com>

On Mon, 22 Oct 2007 15:59:25 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:

> Sure, but usually there isn't a point in having *both* 32bit and 64bit
> versions of applications installed (which happens by default though).

Applications get dragged in because the libraries aren't split out into
-libs subpackages.  If they were, then the -devel and -libs packages
would be available multilib, but the application itself wouldn't.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/5bddf076/attachment.sig>

From jcm at redhat.com  Mon Oct 22 14:06:24 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 10:06:24 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
Message-ID: <1193061984.32582.20.camel@perihelion>

Yo,

On a tangent, I would like to have a discussion about in-kernel firmware
as it becomes split out and loaded using request_firmware. So that third
parties can supply different firmware updates, can we agree that it's
worthwhile having one firmware package for each firmware file set needed
by the kernel package, in the longer term?

Jon.




From berrange at redhat.com  Mon Oct 22 14:07:55 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 22 Oct 2007 15:07:55 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <20071022140755.GD15264@redhat.com>

On Mon, Oct 22, 2007 at 08:17:01AM -0400, Bernardo Innocenti wrote:
> I remember this topic being discussed some time ago,
> but software is fluid and maybe it's time to respin
> the topic.
> 
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
> 
> We're now shipping no less than 4 different implementations
> of SSL:
> 
> - openssl (OpenBSD's implementation)
> - nss (Netscape's implementation)
> - gnutls (LGPL implementation)
> - puretls (Java implementation)
> 
> But which one should replace the others?
>
> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.

Which is pretty much where your problems start. Re-writing applications to
switch from one impl to another is seriously non-trivial. There is no way
in the world you'd want to carry such patches in the Fedora packages because
they'd be a huge maintainence time sink whenever a new upstream release came
out. So getting any port accepted by the upstream application author has to
be the number 1 priority. To do that you need rather compelling reasons to
convince the upstream authors. And there is new software coming out all the
time using any one of these libraries. IMHO converging on 'one true impl' 
of SSL is an pretty intractable problem unless someone wants to throw alot
of their personal developer time at porting & submitting & merging upstream.

> If we are to believe a non-independent comparison, gnutls
> looks like the best choice:
> 
>  http://www.gnu.org/software/gnutls/comparison.html
>
> I couldn't find good benchmarks around, but they would
> make an important decision factor.

The definition of 'best' is rather in the eye of the beholder. The GNUTLS
guys will say theirs is best because it has most complete SSL spec coverage.
The NSS guys will say theirs is best because it has the FIPS certification
and can interact with smart card readers (you know, that pcscd daemon which
spins burning your CPU time just in case you ever insert a smartcard). The
OpenSSL guys will say, well who knows ?!?!

As an app developer I'll say GNU TLS has the most pleasant API to deal
with, particularly since it doesn't try to hide POSIX behind a abstraction
layer. As a sysadmin GNU TLS certtool is far more pleasant 'openssl' tool.

> There are two good reasons not to choose OpenSSL: the
> license is GPL incompatible and the ABI gets broken by
> upstream very frequently.  Strangely enough, OpenSSL in
> F8 is linked against nss instead of openssl.

Yep, any GPL apps using OpenSSL without an explicit exception need to be
fixed, but aside from that its hard to get excited about porting SSL libs.
The ABI breakages are likely encouraging any new upstream apps to avoid
OpenSSL in favour of GNU TLS too.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From tjb at unh.edu  Mon Oct 22 14:09:22 2007
From: tjb at unh.edu (Thomas J. Baker)
Date: Mon, 22 Oct 2007 10:09:22 -0400
Subject: glibc breaks googleearth?
In-Reply-To: <20071017160423.GS5451@devserv.devel.redhat.com>
References: <1192480014.3757.37.camel@raptor.sr.unh.edu>
	<1192483780.30612.29.camel@localhost.localdomain>
	<1192496794.617.0.camel@neuromancer> <1192497837.18611.1.camel@optimus>
	<1192499340.18611.5.camel@optimus>
	<20071017160423.GS5451@devserv.devel.redhat.com>
Message-ID: <1193062162.6127.4.camel@raptor.sr.unh.edu>


On Wed, 2007-10-17 at 12:04 -0400, Jakub Jelinek wrote:
> On Tue, Oct 16, 2007 at 11:49:00AM +1000, Dave Airlie wrote:
> > Okay I've installed the latest glibc from F7 updates (in a separate
> > directory on my F8 box, and ran
> > 
> > LD_LIBRARY_PATH=.:/home/airlied/test/lib /home/airlied/test/lib//ld-2.6.so ./googleearth-bin
> > 
> > and it appears to start and work.. so what changed in glibc that annoys
> > it?
> 
> Bug in both googleearth (some libraries incorrectly linked, even when they
> use libpthread symbols not linked against -lpthread, which means many
> unversioned symbols) and glibc i?86 sem_post glibc 2.0 compatibility code.
> The latter is fixed in CVS and will be in tonight's glibc build.
> 
> 	Jakub
> 

googleearth now works for me after this update. On intel hardware, it
actually works pretty well too. Can't say the same for nvidia...

Thanks,

tjb
-- 
=======================================================================
| Thomas Baker                                  email: tjb at unh.edu    |
| Systems Programmer                                                  |
| Research Computing Center                     voice: (603) 862-4490 |
| University of New Hampshire                     fax: (603) 862-1761 |
| 332 Morse Hall                                                      |
| Durham, NH 03824 USA              http://wintermute.sr.unh.edu/~tjb |
=======================================================================



From jcm at redhat.com  Mon Oct 22 14:09:45 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 10:09:45 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471C64C4.2090705@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>  <471C64C4.2090705@redhat.com>
Message-ID: <1193062185.32582.24.camel@perihelion>


On Mon, 2007-10-22 at 09:52 +0100, Richard W.M. Jones wrote:
> Jon Masters wrote:
> >  It obviously was a kludge. And a great one - Jeremy, Bill, and other
> > *smart* people (so don't get me wrong guys!) had to come up with a
> > solution at some point when this came up, but it's long since time to
> > take a big breath and think about a longer term fix.
> > 
> > Can we agree that needs to happen? If so, I'll happily actually get
> > involved in implementing a fix, as I've said to these folks in face to
> > face conversations about multilib before!
> 
> Why don't we just install 64 bit packages (on x86-64)[1]?  I've been 
> running Fedora 7 & 8 systems like this for ages without any problems.  I 
> can't see why it isn't the default, with kludges only for the people who 
> want 32 bit packages on their shiny 64 bit processor.

> [1] Or just 32 bit packages on ppc64.

It's still going to be the case that many people will want packages from
both, for a long time, and in some cases that makes more sense - it's
not always better to have 64-bit versions.

For these reasons, I think a better solution is needed, and needed as a
matter of urgency. That solution should also be well documented, with
very obvious policy document(s) - not just mailing list posts - that
make it very easy for package maintainers to understand. It really is
time to fix this properly - can we get a working group setup?

Jon.




From sundaram at fedoraproject.org  Mon Oct 22 13:08:54 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 22 Oct 2007 19:38:54 +0630
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193061984.32582.20.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
Message-ID: <471CA0E6.6040508@fedoraproject.org>

Jon Masters wrote:
> Yo,
> 
> On a tangent, I would like to have a discussion about in-kernel firmware
> as it becomes split out and loaded using request_firmware. So that third
> parties can supply different firmware updates,

+1

It is also useful as there is interest in creating a spin with no 
firmware that is not under a Free software license.

Rahul



From aportal at univ-montp2.fr  Mon Oct 22 14:12:40 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Oct 2007 16:12:40 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071022093305.7f73ae22@redhat.com>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<200710221014.59487.aportal@univ-montp2.fr>
	<20071022093305.7f73ae22@redhat.com>
Message-ID: <200710221612.40456.aportal@univ-montp2.fr>

Le Monday 22 October 2007 15:33:05 Jesse Keating, vous avez ?crit?:
> On Mon, 22 Oct 2007 10:14:59 +0200
>
> Alain PORTAL <aportal at univ-montp2.fr> wrote:
> > I don't understand why this failed because pikllops BR kdelibs-devel
> > and kdelibs-devel BR qt-devel...
>
> If kdelibs-devel BR's qt-devel that is different from Requires.
> BuildRequires are only used when /building/ that particular package.
> They are not looked at when just /installing/ that package.

But report say this is a BuildRequires problem, not a Requires problem.

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From jcm at redhat.com  Mon Oct 22 14:15:03 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 10:15:03 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022100132.76f33bbd@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
Message-ID: <1193062503.32582.29.camel@perihelion>


On Mon, 2007-10-22 at 10:01 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 15:59:25 +0200
> Gerd Hoffmann <kraxel at redhat.com> wrote:
> 
> > Sure, but usually there isn't a point in having *both* 32bit and 64bit
> > versions of applications installed (which happens by default though).
> 
> Applications get dragged in because the libraries aren't split out into
> -libs subpackages.  If they were, then the -devel and -libs packages
> would be available multilib, but the application itself wouldn't.

Right. And here again is one of the major problems. We know what the
problem is, and Fedora has a record of being able to push through
changes once a problem is identified and time thrown at it - why can't
there just be a cut-off date/release by which most of the packages must
have been split out? Then multilib *hacks* can be thrown away.

Jon.




From jkeating at redhat.com  Mon Oct 22 14:16:07 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:16:07 -0400
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <200710221612.40456.aportal@univ-montp2.fr>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<200710221014.59487.aportal@univ-montp2.fr>
	<20071022093305.7f73ae22@redhat.com>
	<200710221612.40456.aportal@univ-montp2.fr>
Message-ID: <20071022101607.247ed547@redhat.com>

On Mon, 22 Oct 2007 16:12:40 +0200
Alain PORTAL <aportal at univ-montp2.fr> wrote:

> But report say this is a BuildRequires problem, not a Requires
> problem.

You have to think carefully.

Your source package has a list of BuildRequires.  That is the starting
point for filling in the buildroot.  You take the list of
BuildRequires and translate them to actual packages (like say
kdelibs-devel).  You then take those packages and depsolve them, IE
process their REQUIRES.  You do this until you have a fully solved set
and then you install it all into the buildroot.

So only /your/ package BuildRequires are processed.  After that it's
all about the Requires.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/3a1ff33e/attachment.sig>

From rc040203 at freenet.de  Mon Oct 22 14:19:03 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 22 Oct 2007 16:19:03 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071022100132.76f33bbd@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
Message-ID: <1193062743.2531.27.camel@mccallum.corsepiu.local>

On Mon, 2007-10-22 at 10:01 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 15:59:25 +0200
> Gerd Hoffmann <kraxel at redhat.com> wrote:
> 
> > Sure, but usually there isn't a point in having *both* 32bit and 64bit
> > versions of applications installed (which happens by default though).
> 
> Applications get dragged in because the libraries aren't split out into
> -libs subpackages.  If they were, then the -devel and -libs packages
> would be available multilib, but the application itself wouldn't.
Not quite.

All of my packages, against which complaints have been BZ'ed, all are
*-devel packages which suffer from
- Conflicts in /usr/bin/* devel tools (typical *-config scripts)
- Conflicts in %doc files below /usr/share (90% of them steming from
doxygen generated docs and __man pages__)

I.e. these packages run-time packages are installable in parallel, but
their *-devel packages conflicts.

So, as it seems to me, the "multiarch" campaign of is aiming at parallel
installation of the *devel packages.

Ralf




From rjones at redhat.com  Mon Oct 22 14:17:46 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 22 Oct 2007 15:17:46 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193062185.32582.24.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
Message-ID: <471CB10A.3070803@redhat.com>

Jon Masters wrote:
> It's still going to be the case that many people will want packages from
> both, for a long time, and in some cases that makes more sense - it's
> not always better to have 64-bit versions.
> 
> For these reasons, I think a better solution is needed, and needed as a
> matter of urgency. That solution should also be well documented, with
> very obvious policy document(s) - not just mailing list posts - that
> make it very easy for package maintainers to understand. It really is
> time to fix this properly - can we get a working group setup?

My original question was to some extent taking the position of devil's 
advocate.

But I think this is interesting: what are the actual choke-points which 
cause ordinary Fedora users to need to use 32 bit libs & apps on their 
64 bit x86-64 machines?

Off the top of my head I could think of:

  - proprietary firefox plugins (could probably be handled using a 
wrapper, in fact _should_ be handled using a wrapper because dlopening 
binary-only plugins in your browser is stupid)

  - proprietary 32 bit binaries (does Fedora care about them?)

  - free software with lots of 32 bit assumptions (OpenOffice used to be 
like this, but IIRC they fixed it ... are there any others?)

  - building 32 bit binaries (but really you should use mock or 
virtualisation, which has other advantages like you can build for lots 
of other architectures)

Perhaps it's just easier to fix this list of choke-points than to 
implement working multiarch support?

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/8c96413b/attachment.bin>

From buc at odusz.so-cdu.ru  Mon Oct 22 14:21:18 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 22 Oct 2007 18:21:18 +0400
Subject: Live Upgrade Special Interest Group
In-Reply-To: <471CA095.2030106@gmail.com>
References: <4719F78C.8080500@fedoraproject.org>
	<471C8F4D.5040404@odu.neva.ru> <471CA095.2030106@gmail.com>
Message-ID: <471CB1DE.4060900@odu.neva.ru>

Les Mikesell wrote:
> Dmitry Butskoy wrote:
>
>>> Often test upgrading to the current development branch of one of the 
>>> test releases from the previous general release
>>
>> but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...
>>
>> We use Fedora in a production environment, and half-year cycle is too 
>> fast for us. (CentOS and friends are "too slow" OTOH).
>
> CentOS isn't going to be _that_ much different since it would 
> approximate  FC1->FC3->FC6 so far - especially if you wait for some 
> updates to stabilize the fedora release before you upgrade.  I'd think 
> you would be better off using Centos as the base in production but 
> building a few apps that matter to you from fedora src rpms or finding 
> a repository that does that.
>

Actually, Fedora is capable for production environment!
For example, see the post 
https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00928.html

Certainly, we have tried the way "RHEL/CentOS in the base plus some apps 
of more new versions". But then we have to re-compile all such "new 
apps" by hand, we have to browse for (security) updates of such apps 
etc. OTOH, comparing "the base" of RHEL and "the base" of Fedora 
(stable, not rawhide) -- in the situation where we are skilled enough -- 
we had chosen Fedora.  And even with the base of Fedora, from time to 
time we are compelled to use the newest versions of some apps.

It is always sadly for me to hear the recommendations to not use Fedora 
in production. At least it is not true! Secondary, it is very harmfully 
for Fedora Project, and even for RHEL.

RHEL is based on Fedora, and expects that software in Fedora is tested 
enough (by community). But if Fedora is actually never used in the real 
critical production environments, then you cannot say "it is tested 
enough". I hope you do not believe that RedHat or anyone else can test 
all the real situations just  in laboratories...

If you can, you should use Fedora. Certainly there are situations where 
you can not, but if you do not use Fedora just because you are afraid, 
or you wish to spend more time for games rather than for filling 
bugzilla reports... No comments.


~buc




From jkeating at redhat.com  Mon Oct 22 14:20:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:20:31 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193061984.32582.20.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
Message-ID: <20071022102031.73786d4a@redhat.com>

On Mon, 22 Oct 2007 10:06:24 -0400
Jon Masters <jcm at redhat.com> wrote:

> On a tangent, I would like to have a discussion about in-kernel
> firmware as it becomes split out and loaded using request_firmware.
> So that third parties can supply different firmware updates, can we
> agree that it's worthwhile having one firmware package for each
> firmware file set needed by the kernel package, in the longer term?

These wouldn't turn into kmod like packages would they, and have all
the same kludges to work with RPM?  Are you going to have to handle
different firmware sets for each kernel version you might have
installed, plus alternatives from upstream?  Obviously I'm a bit
reluctant to reintroduce nightmares like this.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/05d10e2f/attachment.sig>

From jkeating at redhat.com  Mon Oct 22 14:22:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:22:37 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193062503.32582.29.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
Message-ID: <20071022102237.415db663@redhat.com>

On Mon, 22 Oct 2007 10:15:03 -0400
Jon Masters <jcm at redhat.com> wrote:

> Right. And here again is one of the major problems. We know what the
> problem is, and Fedora has a record of being able to push through
> changes once a problem is identified and time thrown at it - why can't
> there just be a cut-off date/release by which most of the packages
> must have been split out? Then multilib *hacks* can be thrown away.

Because while this is a "fix" for our current multilib algorithms, it's
not clear that this is a proper fix in whole.  It is another bandaid
for the bleeding wound we have.  It's not trivial to go splitting a
crapton of packages, so perhaps we'd like some more idea of "this is
The Fix".

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/ffbabf28/attachment.sig>

From jkeating at redhat.com  Mon Oct 22 14:24:05 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:24:05 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193062743.2531.27.camel@mccallum.corsepiu.local>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062743.2531.27.camel@mccallum.corsepiu.local>
Message-ID: <20071022102405.3348ff06@redhat.com>

On Mon, 22 Oct 2007 16:19:03 +0200
Ralf Corsepius <rc040203 at freenet.de> wrote:

> Not quite.
> 
> All of my packages, against which complaints have been BZ'ed, all are
> *-devel packages which suffer from
> - Conflicts in /usr/bin/* devel tools (typical *-config scripts)
> - Conflicts in %doc files below /usr/share (90% of them steming from
> doxygen generated docs and __man pages__)
> 
> I.e. these packages run-time packages are installable in parallel, but
> their *-devel packages conflicts.
> 
> So, as it seems to me, the "multiarch" campaign of is aiming at
> parallel installation of the *devel packages.


This is a second problem space, but doesn't change the fact that one
can avoid having the "application" be multilib if all the libs are
split out of it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/b946b803/attachment.sig>

From jcm at redhat.com  Mon Oct 22 14:33:26 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 10:33:26 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <20071022102031.73786d4a@redhat.com>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
	<20071022102031.73786d4a@redhat.com>
Message-ID: <1193063606.32582.40.camel@perihelion>


On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 10:06:24 -0400
> Jon Masters <jcm at redhat.com> wrote:
> 
> > On a tangent, I would like to have a discussion about in-kernel
> > firmware as it becomes split out and loaded using request_firmware.
> > So that third parties can supply different firmware updates, can we
> > agree that it's worthwhile having one firmware package for each
> > firmware file set needed by the kernel package, in the longer term?
> 
> These wouldn't turn into kmod like packages would they, and have all
> the same kludges to work with RPM?  Are you going to have to handle
> different firmware sets for each kernel version you might have
> installed, plus alternatives from upstream?  Obviously I'm a bit
> reluctant to reintroduce nightmares like this.

The problem is if a user needs to upgrade the firmware for some card,
they can't do this if the file for that firmware lives inside the kernel
package (well, they can abuse the breakage in RPM for multilib and
possibly get away with another package owning the file, but...). If
we're interested in allowing firmware upgrades to happen outside of the
kernel (which is one reason it split out upstream), then this is needed.

Would love to hear comments ;-)

Jon.




From jcm at redhat.com  Mon Oct 22 14:35:00 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 10:35:00 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022102237.415db663@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
Message-ID: <1193063700.32582.43.camel@perihelion>


On Mon, 2007-10-22 at 10:22 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 10:15:03 -0400
> Jon Masters <jcm at redhat.com> wrote:
> 
> > Right. And here again is one of the major problems. We know what the
> > problem is, and Fedora has a record of being able to push through
> > changes once a problem is identified and time thrown at it - why can't
> > there just be a cut-off date/release by which most of the packages
> > must have been split out? Then multilib *hacks* can be thrown away.
> 
> Because while this is a "fix" for our current multilib algorithms, it's
> not clear that this is a proper fix in whole.  It is another bandaid
> for the bleeding wound we have.  It's not trivial to go splitting a
> crapton of packages, so perhaps we'd like some more idea of "this is
> The Fix".

I guess I'm throwing things out there to say "we need to decide what the
real fix is this time" - can we get a few of us together, and
(virtually) sit down and reason through the options?

Jesse - ideas on how to organize this effort?

Jon.




From jkeating at redhat.com  Mon Oct 22 14:33:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:33:11 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193063606.32582.40.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
	<20071022102031.73786d4a@redhat.com>
	<1193063606.32582.40.camel@perihelion>
Message-ID: <20071022103311.2ea59d22@redhat.com>

On Mon, 22 Oct 2007 10:33:26 -0400
Jon Masters <jcm at redhat.com> wrote:

> Would love to hear comments ;-)

Figure out a way to do it that doesn't re-introduce the nastyness that
was kernel module packages.

You know, if we didn't allow for parallel kernel installs this wouldn't
be a problem (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/6f2b7b16/attachment.sig>

From jdieter at gmail.com  Mon Oct 22 14:41:20 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Mon, 22 Oct 2007 17:41:20 +0300
Subject: Live Upgrade Special Interest Group
In-Reply-To: <471CB1DE.4060900@odu.neva.ru>
References: <4719F78C.8080500@fedoraproject.org>
	<471C8F4D.5040404@odu.neva.ru> <471CA095.2030106@gmail.com>
	<471CB1DE.4060900@odu.neva.ru>
Message-ID: <1193064080.27881.18.camel@jndwidescreen.lesbg.loc>

On Mon, 2007-10-22 at 18:21 +0400, Dmitry Butskoy wrote:
<snip>
> It is always sadly for me to hear the recommendations to not use Fedora 
> in production. At least it is not true! Secondary, it is very harmfully 
> for Fedora Project, and even for RHEL.
<snip>

I think it really depends on what you're looking for.  For our school, I
was running three FC4 (later upgraded to FC5 and then FC6) servers and
got quite frustrated with having to upgrade them every 6-12 months,
especially as there were a number of issues I ran into during the
upgrade process (i.e. conf files needing a slightly different format for
something like Samba or BIND; I honestly don't remember exact details).

I ended up switching them over to CentOS 5 when it came out and I'm
quite happy with it, especially because I'm getting much fewer updates
and therefore rarely needing to restart them (think kernel updates).

On the other hand, we switched all of our desktop systems (except three
or four) over to Linux during the summer and Fedora 7 was my
distribution of choice there.

I only have to get the setup perfect once, and then I'm able to image it
to all of our desktops.  That's something I can easily do every six
months, especially when the benefit is that the users get newer and
prettier software every six months.  I've even managed to get beryl
running by default on 20 of the newer computers.

All that to say that CentOS vs. Fedora really comes down to your needs.
I haven't found Fedora to be particularly buggy or anything, but I did
find it a pain to update it as often as I needed to for my servers.  On
the other hand, it's a perfect fit for my desktops.

Jonathan
-------------- 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/20071022/cd71a366/attachment.sig>

From katzj at redhat.com  Mon Oct 22 14:38:07 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 10:38:07 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193061984.32582.20.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
Message-ID: <1193063887.4126.12.camel@localhost.localdomain>

On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
> On a tangent, I would like to have a discussion about in-kernel firmware
> as it becomes split out and loaded using request_firmware. So that third
> parties can supply different firmware updates, can we agree that it's
> worthwhile having one firmware package for each firmware file set needed
> by the kernel package, in the longer term?

This is fine (well, not for F8 obviously, but we can make it okay for
F9), with a few caveats:
1) The module *MUST* have the needed firmware tagged appropriately so
that we can figure out what firmware to pull into initrds, the
installer, etc
2) We should probably follow the path being blazed with wireless
firmware where we include the multiple, incompatible firmware versions
in one package.  Otherwise, the fact that multiple kernels can be
installed leads to a a bit of a quagmire
3) Care needs to be taken so that upgrades will work correctly once the
firmware has moved.  A requires is one answer, and maybe the best, but
there definitely needs to be some thought

Jeremy



From aportal at univ-montp2.fr  Mon Oct 22 14:43:05 2007
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Mon, 22 Oct 2007 16:43:05 +0200
Subject: Fedora i386 rawhide rebuild in mock status 2007-10-19
In-Reply-To: <20071022101607.247ed547@redhat.com>
References: <20071019225537.A29006@humbolt.us.dell.com>
	<200710221612.40456.aportal@univ-montp2.fr>
	<20071022101607.247ed547@redhat.com>
Message-ID: <200710221643.05706.aportal@univ-montp2.fr>

Le Monday 22 October 2007 16:16:07 Jesse Keating, vous avez ?crit?:
> On Mon, 22 Oct 2007 16:12:40 +0200
>
> Alain PORTAL <aportal at univ-montp2.fr> wrote:
> > But report say this is a BuildRequires problem, not a Requires
> > problem.
>
> You have to think carefully.
>
> Your source package has a list of BuildRequires.  That is the starting
> point for filling in the buildroot.  You take the list of
> BuildRequires and translate them to actual packages (like say
> kdelibs-devel).  You then take those packages and depsolve them, IE
> process their REQUIRES.  You do this until you have a fully solved set
> and then you install it all into the buildroot.
>
> So only /your/ package BuildRequires are processed.  After that it's
> all about the Requires.

I think I said something wrong.

pikloops BuildRequires kdelibs-devel
kdelibs-devel Requires qt-devel

I just ask for a built which was successful:
http://koji.fedoraproject.org/koji/taskinfo?taskID=205585

So, I don't understand where is the problem.

-- 
La version fran?aise des pages de manuel Linux
http://manpagesfr.free.fr



From j.w.r.degoede at hhs.nl  Mon Oct 22 14:41:51 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 16:41:51 +0200
Subject: Request permission to break always use system libs rule for asc-2.0
Message-ID: <471CB6AF.3060905@hhs.nl>

Hi All,

I'm currently working on upgrading asc (Advanced Strategic Command) to 2.0.1.0 
When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and paragui-1.0.4.

While packaging SDLmm I had to backport several fixes from a copy included in 
asc to the package, as SDLmm is very much dead upstream.

With 1.16.4.0, paragui was not included so the packaging of it was needed, and 
I packaged the then already old version 1.0.4, as that is what asc 1.16.4.0 wanted.

Now with asc-2.0 there are yet again bugfixes to the included SDLmm-0.1.8, now 
I can port these to the external SDLmm package, and patch asc to use the 
external SDLmm. But since SDLmm upstream has been dead for a long time, and asc 
is the only user of SDLmm, this feels rather silly. So I would like to declare 
SDLmm dead for current devel (F-9 and later) and just use the included copy.

asc-2.0 now uses paragui-1.1.8, which is the latest release from 2004 (again 
very dead upstream, website is down, etc.) and again has it heavily patched. 
Unfortunately some idiot ran indent on there copy, so doing a diff results in 
30000 changed lines. I could go through these manually and port any fixes to 
the official paragui, and patch asc to use the system version. But again asc is 
the only user, so doing this feels really silly (going through a 30000 lines 
diff is no fun). So I would like to declare paragui dead for current devel (F-9 
and later) also, and just use the included copy.

Are there any objections against this?

Regards,

Hans



From mjs at CLEMSON.EDU  Mon Oct 22 14:47:51 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 22 Oct 2007 10:47:51 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193063606.32582.40.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
	<20071022102031.73786d4a@redhat.com>
	<1193063606.32582.40.camel@perihelion>
Message-ID: <1193064471.11781.7.camel@vincent52.localdomain>

On Mon, 2007-10-22 at 10:33 -0400, Jon Masters wrote:
> On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
> > On Mon, 22 Oct 2007 10:06:24 -0400
> > Jon Masters <jcm at redhat.com> wrote:
> > 
> > > On a tangent, I would like to have a discussion about in-kernel
> > > firmware as it becomes split out and loaded using request_firmware.
> > > So that third parties can supply different firmware updates, can we
> > > agree that it's worthwhile having one firmware package for each
> > > firmware file set needed by the kernel package, in the longer term?
> > 
> > These wouldn't turn into kmod like packages would they, and have all
> > the same kludges to work with RPM?  Are you going to have to handle
> > different firmware sets for each kernel version you might have
> > installed, plus alternatives from upstream?  Obviously I'm a bit
> > reluctant to reintroduce nightmares like this.
> 
> The problem is if a user needs to upgrade the firmware for some card,
> they can't do this if the file for that firmware lives inside the kernel
> package (well, they can abuse the breakage in RPM for multilib and
> possibly get away with another package owning the file, but...). If
> we're interested in allowing firmware upgrades to happen outside of the
> kernel (which is one reason it split out upstream), then this is needed.
> 
> Would love to hear comments ;-)

Is it frequently the case that firmware upgrades do not require driver
updates as well in order to function?  Many wireless issues seem to
revolve around the fact that firmware and drivers that are out of sync
just don't work.  If firmware is split out, how will such dependencies
be managed?

> 
> Jon.
> 
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From jkeating at redhat.com  Mon Oct 22 14:46:59 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 10:46:59 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193063700.32582.43.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
Message-ID: <20071022104659.08d252ab@redhat.com>

On Mon, 22 Oct 2007 10:35:00 -0400
Jon Masters <jcm at redhat.com> wrote:

> Jesse - ideas on how to organize this effort?

Start a paper, define what the problem space is, define what goals
should be accomplished to have a solution (not what the solution would
be), identify key people involved, pitch it to somebody with budget to
fly people around and feed/house them for a few days.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/7123fd8e/attachment.sig>

From j.w.r.degoede at hhs.nl  Mon Oct 22 14:46:52 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 16:46:52 +0200
Subject: Multiarch crazyiness
In-Reply-To: <471CB10A.3070803@redhat.com>
References: <471B9291.4060800@amiga-hardware.com>	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>	<471C64C4.2090705@redhat.com>	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com>
Message-ID: <471CB7DC.60604@hhs.nl>

Richard W.M. Jones wrote:
> Jon Masters wrote:
>> It's still going to be the case that many people will want packages from
>> both, for a long time, and in some cases that makes more sense - it's
>> not always better to have 64-bit versions.
>>
>> For these reasons, I think a better solution is needed, and needed as a
>> matter of urgency. That solution should also be well documented, with
>> very obvious policy document(s) - not just mailing list posts - that
>> make it very easy for package maintainers to understand. It really is
>> time to fix this properly - can we get a working group setup?
> 
> My original question was to some extent taking the position of devil's 
> advocate.
> 
> But I think this is interesting: what are the actual choke-points which 
> cause ordinary Fedora users to need to use 32 bit libs & apps on their 
> 64 bit x86-64 machines?
> 
> Off the top of my head I could think of:
> 
>  - proprietary firefox plugins (could probably be handled using a 
> wrapper, in fact _should_ be handled using a wrapper because dlopening 
> binary-only plugins in your browser is stupid)
> 

I fully agree, but that wrapper needs 32 bits libraries both for its own 
plugin-loader part and to satisfy the deps of the plugin.

>  - proprietary 32 bit binaries (does Fedora care about them?)
> 

Well, we just fixed glibc to make googleearth work (although that was really a 
glibc bug), and I'm sure I can think of others like erm, matlab, maple, 
labview, picasse to name a few.

>  - free software with lots of 32 bit assumptions (OpenOffice used to be 
> like this, but IIRC they fixed it ... are there any others?)
> 
warzone2100 to name one, wine is another small player in this area.

> Perhaps it's just easier to fix this list of choke-points than to 
> implement working multiarch support?


32 bit is not going away, I share your wishes, but really it is not going to go 
away anytime soon.

Regards,

Hans



From pertusus at free.fr  Mon Oct 22 14:45:46 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 16:45:46 +0200
Subject: packaging libcurl separately
In-Reply-To: <20071022132753.GC2988@dhcp-lab-186.brq.redhat.com>
References: <20071022132753.GC2988@dhcp-lab-186.brq.redhat.com>
Message-ID: <20071022144546.GA2916@free.fr>

On Mon, Oct 22, 2007 at 03:27:53PM +0200, Jindrich Novy wrote:
> Hi all,
> 
> just a few questions:
> 
> 1) What is your opinion on packaging libcurl separately (read independently on curl)?
>    For references: http://curl.haxx.se/mail/lib-2004-09/0095.html

That would make a lot of sense to me.

> 2) How about compat-libcurl or libcurl3, libcurl4 packages to let users run third
>    party software independently on the libcurl version in the distribution?

If there is a real demand for that, indeed, but not for fedora packages
(though this is what is implied by your wording).

--
Pat



From jonathan.underwood at gmail.com  Mon Oct 22 14:52:31 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 22 Oct 2007 15:52:31 +0100
Subject: Multiarch crazyiness
In-Reply-To: <20071022104659.08d252ab@redhat.com>
References: <471B9291.4060800@amiga-hardware.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
	<20071022104659.08d252ab@redhat.com>
Message-ID: <645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>

On 22/10/2007, Jesse Keating <jkeating at redhat.com> wrote:
> On Mon, 22 Oct 2007 10:35:00 -0400
> Jon Masters <jcm at redhat.com> wrote:
>
> > Jesse - ideas on how to organize this effort?
>
> Start a paper, define what the problem space is, define what goals
> should be accomplished to have a solution (not what the solution would
> be), identify key people involved, pitch it to somebody with budget to
> fly people around and feed/house them for a few days.
>

Two very informative sites about how Debian is approaching the problem:

http://wiki.debian.org/multiarch
http://lackof.org/taggart/hacking/multiarch/

In particular, this paper from canonical does a quite nice job of
laying out the problem:

http://multiarch.alioth.debian.org/multiarch-hp-report.pdf

HTH someone,
Jonathan.

> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From j.w.r.degoede at hhs.nl  Mon Oct 22 14:49:56 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 16:49:56 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193063887.4126.12.camel@localhost.localdomain>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>	<1193061984.32582.20.camel@perihelion>
	<1193063887.4126.12.camel@localhost.localdomain>
Message-ID: <471CB894.5010301@hhs.nl>

Jeremy Katz wrote:
> On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
>> On a tangent, I would like to have a discussion about in-kernel firmware
>> as it becomes split out and loaded using request_firmware. So that third
>> parties can supply different firmware updates, can we agree that it's
>> worthwhile having one firmware package for each firmware file set needed
>> by the kernel package, in the longer term?
> 
> This is fine (well, not for F8 obviously, but we can make it okay for
> F9), with a few caveats:
> 1) The module *MUST* have the needed firmware tagged appropriately so
> that we can figure out what firmware to pull into initrds, the
> installer, etc
> 2) We should probably follow the path being blazed with wireless
> firmware where we include the multiple, incompatible firmware versions
> in one package.  Otherwise, the fact that multiple kernels can be
> installed leads to a a bit of a quagmire
> 3) Care needs to be taken so that upgrades will work correctly once the
> firmware has moved.  A requires is one answer, and maybe the best, but
> there definitely needs to be some thought
> 

4) This effort must be done upstream using the current standard kernel firmware
    mechanisms and then trickle down into Fedora from upstream. I can already
    hear Dave J. screaming in the night if we are going to carry Fedora specific
    kernel patches for this.

Regards,

Hans



From jonathan.underwood at gmail.com  Mon Oct 22 14:55:12 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 22 Oct 2007 15:55:12 +0100
Subject: Multiarch crazyiness
In-Reply-To: <645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>
References: <471B9291.4060800@amiga-hardware.com> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
	<20071022104659.08d252ab@redhat.com>
	<645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>
Message-ID: <645d17210710220755se7f8ed4t85824f1d28433c1a@mail.gmail.com>

On 22/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> On 22/10/2007, Jesse Keating <jkeating at redhat.com> wrote:
> > On Mon, 22 Oct 2007 10:35:00 -0400
> > Jon Masters <jcm at redhat.com> wrote:
> >
> > > Jesse - ideas on how to organize this effort?
> >
> > Start a paper, define what the problem space is, define what goals
> > should be accomplished to have a solution (not what the solution would
> > be), identify key people involved, pitch it to somebody with budget to
> > fly people around and feed/house them for a few days.
> >
>
> Two very informative sites about how Debian is approaching the problem:
>
> http://wiki.debian.org/multiarch
> http://lackof.org/taggart/hacking/multiarch/
>
> In particular, this paper from canonical does a quite nice job of
> laying out the problem:
>
> http://multiarch.alioth.debian.org/multiarch-hp-report.pdf
>

Also, Axel Thimm had what seemed like some reasonable proposals to do
with the multiarch binary installation part of the problem:

http://www.redhat.com/archives/fedora-maintainers/2007-April/msg00511.html

Jonathan (wondering where Axel has gone).



From jcm at redhat.com  Mon Oct 22 15:00:37 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 11:00:37 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022104659.08d252ab@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
	<20071022104659.08d252ab@redhat.com>
Message-ID: <1193065237.32582.45.camel@perihelion>


On Mon, 2007-10-22 at 10:46 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 10:35:00 -0400
> Jon Masters <jcm at redhat.com> wrote:
> 
> > Jesse - ideas on how to organize this effort?
> 
> Start a paper, define what the problem space is, define what goals
> should be accomplished to have a solution (not what the solution would
> be), identify key people involved, pitch it to somebody with budget to
> fly people around and feed/house them for a few days.

Alright, I'll start putting some ideas together and then ask for input.
Will talk to folks internally about the latter once that is done.

Jon.




From katzj at redhat.com  Mon Oct 22 14:59:38 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 10:59:38 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471CB894.5010301@hhs.nl>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
	<1193063887.4126.12.camel@localhost.localdomain>
	<471CB894.5010301@hhs.nl>
Message-ID: <1193065178.4126.14.camel@localhost.localdomain>

On Mon, 2007-10-22 at 16:49 +0200, Hans de Goede wrote:
> Jeremy Katz wrote:
> > On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
> >> On a tangent, I would like to have a discussion about in-kernel firmware
> >> as it becomes split out and loaded using request_firmware. So that third
> >> parties can supply different firmware updates, can we agree that it's
> >> worthwhile having one firmware package for each firmware file set needed
> >> by the kernel package, in the longer term?
> > 
> > This is fine (well, not for F8 obviously, but we can make it okay for
> > F9), with a few caveats:
> > 1) The module *MUST* have the needed firmware tagged appropriately so
> > that we can figure out what firmware to pull into initrds, the
> > installer, etc
> > 2) We should probably follow the path being blazed with wireless
> > firmware where we include the multiple, incompatible firmware versions
> > in one package.  Otherwise, the fact that multiple kernels can be
> > installed leads to a a bit of a quagmire
> > 3) Care needs to be taken so that upgrades will work correctly once the
> > firmware has moved.  A requires is one answer, and maybe the best, but
> > there definitely needs to be some thought
> > 
> 
> 4) This effort must be done upstream using the current standard kernel firmware
>     mechanisms and then trickle down into Fedora from upstream. I can already
>     hear Dave J. screaming in the night if we are going to carry Fedora specific
>     kernel patches for this.

*grin*  I just thought that was a given :-)

Jeremy



From jkeating at redhat.com  Mon Oct 22 15:04:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 11:04:24 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471CB7DC.60604@hhs.nl>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
Message-ID: <20071022110424.3b2395e7@redhat.com>

On Mon, 22 Oct 2007 16:46:52 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> 32 bit is not going away, I share your wishes, but really it is not
> going to go away anytime soon.


Specifically not on arches like ppc64 (you want 32bit runtime) and
Sparc64 (you want 32bit runtime).  See a pattern here?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/1553429e/attachment.sig>

From sgrubb at redhat.com  Mon Oct 22 15:14:41 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 22 Oct 2007 11:14:41 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <200710221114.42090.sgrubb@redhat.com>

On Monday 22 October 2007 08:17:01 Bernardo Innocenti wrote:
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.

Yes, we agree.

> We're now shipping no less than 4 different implementations
> of SSL:
>
>  - openssl (OpenBSD's implementation)
>  - nss (Netscape's implementation)
>  - gnutls (LGPL implementation)
>  - puretls (Java implementation)

There's actually more crypto than that. 


> But which one should replace the others?

Please see an email I sent back in August on this topic. 

https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01594.html

I out line the reasons for the choice of NSS.


> It is not clear to me.  Judging from dependencies, OpenSSL,
> NSS and gnutls all seem equally popular in Fedora.

Yep.

> If we are to believe a non-independent comparison, gnutls
> looks like the best choice

But you are ignoring the fact that gnutls has never been through a FIPS-140-2 
certification and they are very expensive. These certifications find many 
bugs that would otherwise go unnoticed as well and require certain control 
interfaces be developed.

-Steve



From sgrubb at redhat.com  Mon Oct 22 15:17:49 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 22 Oct 2007 11:17:49 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471CA9E0.6020503@redhat.com>
References: <471C94BD.6080801@codewiz.org> <471CA9E0.6020503@redhat.com>
Message-ID: <200710221117.50472.sgrubb@redhat.com>

On Monday 22 October 2007 09:47:12 Richard W.M. Jones wrote:
> Nevertheless, I don't think you're going to get rid of the competing SSL
> libraries. ?Rewriting code to use a different API is a lot of make-work
> that no one wants to do, and doesn't contribute much benefit to anyone.

This is true and not the aim of the crypto consolidation project. What we are 
aiming to do is create a --with-nss option for as many packages as feasible 
and then Fedora can use that in package building. We have also created an 
openssl compatible API to help ease the transition.

-Steve



From sgrubb at redhat.com  Mon Oct 22 15:19:12 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 22 Oct 2007 11:19:12 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <5256d0b0710220649t4e68c9b1wfb4e0aed4aada251@mail.gmail.com>
References: <471C94BD.6080801@codewiz.org>
	<5256d0b0710220649t4e68c9b1wfb4e0aed4aada251@mail.gmail.com>
Message-ID: <200710221119.13449.sgrubb@redhat.com>

On Monday 22 October 2007 09:49:14 Peter Robinson wrote:
> There's discussions about this on the project wiki here
> http://fedoraproject.org/wiki/FedoraCryptoConsolidation
>
> Not sure what the current status is though.

The current status is that we are waiting for F9 to open for business. We did 
2-3 packages in F8 to kickoff the effort. But it will be one of the major 
themes of F9 going forward.

-Steve



From jkeating at redhat.com  Mon Oct 22 15:18:16 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 11:18:16 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <200710221119.13449.sgrubb@redhat.com>
References: <471C94BD.6080801@codewiz.org>
	<5256d0b0710220649t4e68c9b1wfb4e0aed4aada251@mail.gmail.com>
	<200710221119.13449.sgrubb@redhat.com>
Message-ID: <20071022111816.4808ae64@redhat.com>

On Mon, 22 Oct 2007 11:19:12 -0400
Steve Grubb <sgrubb at redhat.com> wrote:

> The current status is that we are waiting for F9 to open for
> business. We did 2-3 packages in F8 to kickoff the effort. But it
> will be one of the major themes of F9 going forward.

Consider F9 open.  All packages have been branched for F-8 leaving the
devel/ for F9.  If you're "done" with F8, no reason why you can't start
working on F9 stuff and get a head start.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/d0916180/attachment.sig>

From billcrawford1970 at gmail.com  Mon Oct 22 15:21:10 2007
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Mon, 22 Oct 2007 16:21:10 +0100
Subject: Request permission to break always use system libs rule for
	asc-2.0
In-Reply-To: <471CB6AF.3060905@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>
Message-ID: <544eb990710220821j1ead6546h146f853cb7a6ec07@mail.gmail.com>

On 22/10/2007, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
...
> asc-2.0 now uses paragui-1.1.8, which is the latest release from 2004 (again
> very dead upstream, website is down, etc.) and again has it heavily patched.
> Unfortunately some idiot ran indent on there copy, so doing a diff results in
> 30000 changed lines. I could go through these manually and port any fixes to
> the official paragui, and patch asc to use the system version. But again asc is
> the only user, so doing this feels really silly (going through a 30000 lines
> diff is no fun). So I would like to declare paragui dead for current devel (F-9
> and later) also, and just use the included copy.

Well, you *could* run indent on the original version of SDLmm, and/or
use the diff flags to ignore whitespace changes etc. "diff -ubB" or
"diff -w" or some combination of the two.

> Are there any objections against this?

Well, I don't actually use it, so it makes no difference to me. But if
you want someone to look at the diffs and update patches to SDLmm, I
could look at that.



From lesmikesell at gmail.com  Mon Oct 22 15:32:34 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 22 Oct 2007 10:32:34 -0500
Subject: Live Upgrade Special Interest Group
In-Reply-To: <471CB1DE.4060900@odu.neva.ru>
References: <4719F78C.8080500@fedoraproject.org>	<471C8F4D.5040404@odu.neva.ru>
	<471CA095.2030106@gmail.com> <471CB1DE.4060900@odu.neva.ru>
Message-ID: <471CC292.9040703@gmail.com>

Dmitry Butskoy wrote:

>>>> Often test upgrading to the current development branch of one of the 
>>>> test releases from the previous general release
>>>
>>> but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...
>>>
>>> We use Fedora in a production environment, and half-year cycle is too 
>>> fast for us. (CentOS and friends are "too slow" OTOH).
>>
>> CentOS isn't going to be _that_ much different since it would 
>> approximate  FC1->FC3->FC6 so far - especially if you wait for some 
>> updates to stabilize the fedora release before you upgrade.  I'd think 
>> you would be better off using Centos as the base in production but 
>> building a few apps that matter to you from fedora src rpms or finding 
>> a repository that does that.
>>
> 
> Actually, Fedora is capable for production environment!
> For example, see the post 
> https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00928.html 

In my opinion, anyone who has kept a fedora box running for any length 
of time has either used extremely common hardware or just been lucky. 
My experience, mostly on Dell and IBM server hardware with MPT scsi
controllers is that every 6 months or so an update kernel won't boot. 
Yes you can select the previous kernel if you are at the console of the 
machine during the reboot, but most of my production boxes are in remote 
locations where that is not a reasonable option, and even if you do 
manage to select the old kernel you have to wonder what security updates 
you don't have installed.

> Certainly, we have tried the way "RHEL/CentOS in the base plus some apps 
> of more new versions". But then we have to re-compile all such "new 
> apps" by hand,

Which generally amounts to taking a fedora source rpm and issuing a
rpmbuild --rebuild  ...  command.

 > we have to browse for (security) updates of such apps
> etc.

Or watch for it to appear in a fedora update that you run on a 
non-production machine.

> OTOH, comparing "the base" of RHEL and "the base" of Fedora 
> (stable, not rawhide) -- in the situation where we are skilled enough -- 
> we had chosen Fedora.  And even with the base of Fedora, from time to 
> time we are compelled to use the newest versions of some apps.

In some cases you can find yum-compatible repositories that you can use 
with RHEL/Centos to get these apps.

> It is always sadly for me to hear the recommendations to not use Fedora 
> in production. At least it is not true!

Let's just say our experiences differ...  I happen to feel rather 
strongly about production servers that fail to boot after updates.

> Secondary, it is very harmfully 
> for Fedora Project, and even for RHEL.

I don't see how it harms RHEL.  The whole point of RHEL vs. fedora is 
the additional testing and stability.  If the Fedora Project wanted 
their product to be used in production they would make stability a priority.

> RHEL is based on Fedora, and expects that software in Fedora is tested 
> enough (by community). But if Fedora is actually never used in the real 
> critical production environments, then you cannot say "it is tested 
> enough". I hope you do not believe that RedHat or anyone else can test 
> all the real situations just  in laboratories...

No, what I believe is that the testing mostly happens in non-production 
environments where you can afford the problems of an update that breaks 
or changes behavior.

> If you can, you should use Fedora. Certainly there are situations where 
> you can not, but if you do not use Fedora just because you are afraid, 
> or you wish to spend more time for games rather than for filling 
> bugzilla reports... No comments.

I don't use fedora in production because of previous experience.  At 
approximately the points in time when the RHEL cuts have been made (late 
FC1,FC3,FC6), my experience has been that fedora became very dependable, 
so it is not impossible for that to happen.  But, each next FCx version 
release after those made wild changes that I wouldn't want anywhere near 
a production machine.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From a.badger at gmail.com  Mon Oct 22 15:32:04 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 22 Oct 2007 08:32:04 -0700
Subject: Request permission to break always use system libs rule for
	asc-2.0
In-Reply-To: <471CB6AF.3060905@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>
Message-ID: <471CC274.9080002@gmail.com>

Hans de Goede wrote:
> Hi All,
> 
> I'm currently working on upgrading asc (Advanced Strategic Command) to 
> 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and 
> paragui-1.0.4.
> 

[snip information on SDLmm and paragui being dead upstream.  Bugfixes
  present in the copies in asc.  Merging of paragui non-trivial due to
  reformat of the source.]

> Are there any objections against this?
> 
The options I see in decreasing order of preference are:

1) Get the asc maintainers to take over maintenance of SDLmm and paragui
2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages from 
the asc source tarball.
3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.

If you've explored #1 and are planning on doing #2 I have no objections.

If you're going to do #3 I'd like to know why you favor it over #2.

-Toshio



From jreiser at BitWagon.com  Mon Oct 22 15:36:22 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 22 Oct 2007 08:36:22 -0700
Subject: Request permission to break always use system libs rule for
	asc-2.0
In-Reply-To: <471CB6AF.3060905@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>
Message-ID: <471CC376.2020600@BitWagon.com>

> Unfortunately some idiot ran indent on there copy, so
> doing a diff results in 30000 changed lines.  ...
> (going through a 30000 lines diff is no fun). ...

I have no comment about the system libs rule or the request for an exception.
But remember that "diff -b" ignores changes to white space.
Going through a diff after 'indent' is still no fun,
yet sometimes "diff -b" helps enough.

-- 



From a.badger at gmail.com  Mon Oct 22 15:50:14 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 22 Oct 2007 08:50:14 -0700
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471C6810.5070200@hhs.nl>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>	<471C64E5.4070908@hhs.nl>	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl>
Message-ID: <471CC6B6.8090503@gmail.com>

Hans de Goede wrote:
> Peter Lemenkov wrote:
>>> I fully agree, this discussion does raise one interesting question 
>>> though: What
>>> if there is fully floss software, which we can build from source. 
>>> Which is
>>> written for another OS, but will run fine under an emulator and is 
>>> hard to
>>> port. Do we allow shipping this?
>>
I'd rather not make a decision on something like this until there's a 
definite piece of software to beat out the corner cases with but my 
initial leaning is yes.

-Toshio



From louisg00 at bellsouth.net  Mon Oct 22 15:55:34 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Mon, 22 Oct 2007 11:55:34 -0400
Subject: GNOME Display settings totally bust for randr-1.2
Message-ID: <1193068534.7713.5.camel@tiger>

I tried to setup duel monitors on my 945g card with the gnome display
capplet and it set Xinerama which the intel driver does not support and
locked up my laptop. Maybe this is an upstream issue but it does affect
fedora.

-Thanks





From mjs at CLEMSON.EDU  Mon Oct 22 16:03:05 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 22 Oct 2007 12:03:05 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022110424.3b2395e7@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion> <471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl>  <20071022110424.3b2395e7@redhat.com>
Message-ID: <1193068985.11781.14.camel@vincent52.localdomain>

On Mon, 2007-10-22 at 11:04 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 16:46:52 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
> > 32 bit is not going away, I share your wishes, but really it is not
> > going to go away anytime soon.
> 
> 
> Specifically not on arches like ppc64 (you want 32bit runtime) and
> Sparc64 (you want 32bit runtime).  See a pattern here?

32-bit runtime in general?  Why?  (Not a critical "why", a genuinely
curious "why"...)

> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From jkeating at redhat.com  Mon Oct 22 16:20:29 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 12:20:29 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193068985.11781.14.camel@vincent52.localdomain>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
Message-ID: <20071022122029.2b39bbea@redhat.com>

On Mon, 22 Oct 2007 12:03:05 -0400
Matthew Saltzman <mjs at CLEMSON.EDU> wrote:

> 32-bit runtime in general?  Why?  (Not a critical "why", a genuinely
> curious "why"...)

On those arches, running 64bit code comes at a penalty.  In fact, even
on x86_64 there is a penalty.  Larger memory overhead.  However on
x86_64 the extra CPU registers gained by running in x86_64 mode
outweigh the memory overhead.  Not the case on ppc/sparc where there
are no 'extra registers' to gain.  Very little software in very few
situations need 64bit.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/921b32ca/attachment.sig>

From tonynelson at georgeanelson.com  Mon Oct 22 16:22:55 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Mon, 22 Oct 2007 12:22:55 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
Message-ID: <p04330102c342779f6e55@[192.168.123.162]>

At 7:55 AM -0500 10/22/07, Jon Ciesla wrote:
>> Rahul Sundaram wrote:
>>> Jeroen van Meeuwen wrote:
>>>
>>>
>>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8
>>>> using *just* CDs.
>>>
>>> Now we are talking about an actual problem which wasn't clear to me
>>> earlier. So if Fedora Project released regular CD's for this release and
>>> makes live upgrades a supported option from Fedora 9 onwards, do you see
>>> any need for a regular CD variant in the future?
>>>
>>
>> Other then for it's sentimental value, the impressive number of discs
>> for the Everything spin or laptop-in-the-bush cases, there's no real
>> need for CD's. The few people that want a customized install with all
>> kinds of exotic partitioning schemes (or minimal installs) should either
>> be able to create CDs off the DVD iso or get the CDs from any third
>> party providing them.
>
>A: I have not DVD drives.
 ...

It could be explained better, but "askmethod" allows installation of a DVD
image with only a (or even no) CD drive, as long as the DVD image is made
available during the install.  I keep mine on C: (sda1,/), but a USB key or
hard drive would also work.  (I have a DVD drive, and I boot the DVD, but
one can just burn the RescueCD image that comes with the DVD, at least with
the torrent).
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From choeger at cs.tu-berlin.de  Mon Oct 22 22:43:37 2007
From: choeger at cs.tu-berlin.de (Christoph Hoeger)
Date: Mon, 22 Oct 2007 18:43:37 -0400
Subject: fontsize in 7.92
Message-ID: <1193093017.3574.3.camel@localhost.localdomain>

hey there,

is it just me or is the default font size in test3 slightly bigger than
in F8? If yes, why? It is nice to sit in some more distance by default,
but especially the window menus and some websites look really ugly now.

Any opinions?

christoph



From choeger at cs.tu-berlin.de  Mon Oct 22 23:07:30 2007
From: choeger at cs.tu-berlin.de (Christoph Hoeger)
Date: Mon, 22 Oct 2007 19:07:30 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193093017.3574.3.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
Message-ID: <1193094450.3574.4.camel@localhost.localdomain>

Ergh, I meant bigger than in _F7_ ...


On Mon, 2007-10-22 at 18:43 -0400, Christoph Hoeger wrote:
> hey there,
> 
> is it just me or is the default font size in test3 slightly bigger than
> in F8? If yes, why? It is nice to sit in some more distance by default,
> but especially the window menus and some websites look really ugly now.
> 
> Any opinions?
> 
> christoph
> 



From mike.cohler at gmail.com  Mon Oct 22 17:10:24 2007
From: mike.cohler at gmail.com (Mike C)
Date: Mon, 22 Oct 2007 17:10:24 +0000 (UTC)
Subject: any plans to make wireless more user-friendly in Fedora 9?
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
Message-ID: <loom.20071022T170516-150@post.gmane.org>

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:

> 
> 
> Le Lun 22 octobre 2007 11:36, Valent Turkovic a ?crit :
> 
> > Please make it on by default also for DVD install images.
> 
> Till it works for all the systems Fedora targets (including those with
> no permanent GUI session that also need network/wifi connexion) the
> answer is no.

Having recently got wpa_supplicant working in F7 with ipw2200 and another
machine with iwl3945, I am now definitely a fan of wpa_supplicant as opposed to
NM. I can configure a machine to bring up a wireless connection at boot now and
it will connect either at home or at work - and that is ideal for a user that
wants to boot and then load a browser and work with the web or then do office
stuff. The many people who have made the in-kernel drivers, wpa_supplicant and
NM as well ought to be congratulated on getting this into a working state.
However there are further developments yet to be done - getting rt2x00 and ath5k
working would be another huge step forward.

Yes, I can configure the necessary admin side in the background but the
non-technical user sometimes would prefer not even to have to select a wireless
AP from the NM menu.

I have several family members who are F7 fans now but are definitely not
technical when it comes to installing or setting up the system.




From nicolas.mailhot at laposte.net  Mon Oct 22 17:15:08 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 19:15:08 +0200
Subject: fontsize in 7.92
In-Reply-To: <1193093017.3574.3.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
Message-ID: <1193073308.28655.5.camel@rousalka.dyndns.org>


Le lundi 22 octobre 2007 ? 18:43 -0400, Christoph Hoeger a ?crit :

> is it just me or is the default font size in test3 slightly bigger than
> in F8? 

It's not bigger but GNOME now honors xorg dpi computations instead of
mindlessly forcing 96dpi. That means if your hardware is not actually
96dpi the font sizes are now computed differently.

You'll just have to get used to correct font scaling (the same as in KDE
BTW). Or adjust DisplaySize in xorg.conf if xorg-detected screen
dimensions is wrong.

Regards,

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

From martin at bugs.unl.edu.ar  Mon Oct 22 17:34:21 2007
From: martin at bugs.unl.edu.ar (Martin Marques)
Date: Mon, 22 Oct 2007 14:34:21 -0300
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <471C6D6B.2060405@fedoraproject.org>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>	<471C585C.4070009@fedoraproject.org>	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
	<471C6D6B.2060405@fedoraproject.org>
Message-ID: <471CDF1D.9060607@bugs.unl.edu.ar>

Rahul Sundaram wrote:
> Valent Turkovic wrote:
> 
>> One other small issue; I can't find NetworkManager anywhere in Gnome
>> menue. Where is it located? There is no shortcut that I can see in
>> Applications or in System menues. It that on purpose? Why?
> 
> You aren't supposed to run it as a command or call it from the menu. See
> 
> http://fedoraproject.org/wiki/NetworkManager

Does this mean that Gnome starts automatically NetworkManager?

Anyway, I use KDE. ;-)

-- 
  21:50:04 up 2 days,  9:07,  0 users,  load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Mart?n Marqu?s         |   SELECT 'mmarques' ||
Centro de Telem?tica        |       '@' || 'unl.edu.ar';
Universidad Nacional        |   DBA, Programador,
     del Litoral             |   Administrador
---------------------------------------------------------



From notting at redhat.com  Mon Oct 22 18:25:51 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 14:25:51 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193011897.5168.52.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
Message-ID: <20071022182551.GB9625@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> Without ranting aimlessly, IMO the only real solution is to stop
> kludging rpm, yum, etc. and split out multilib libraries properly - and
> if needed, seek and get approval for a bin64/bin32 with alternatives
> system. Hacking RPM to simply ignore the fact that two packages provide
> the same file is not the solution.

Congrats. You just suggested /usr/bin64 to solve conflicting files in
/usr/share/doc. How does that work, exactly?

Bill



From notting at redhat.com  Mon Oct 22 18:32:13 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 14:32:13 -0400
Subject: Multiarch crazyiness
In-Reply-To: <645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>
References: <1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
	<471CACBD.2080706@redhat.com> <20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
	<20071022104659.08d252ab@redhat.com>
	<645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>
Message-ID: <20071022183213.GC9625@nostromo.devel.redhat.com>

Jonathan Underwood (jonathan.underwood at gmail.com) said: 
> Two very informative sites about how Debian is approaching the problem:
> 
> http://wiki.debian.org/multiarch
> http://lackof.org/taggart/hacking/multiarch/

I've read them. In short, it's:

- don't put conflicting files in library packages

And these bugs are filed because:

- we put conflicting files in library packages

It ain't rocket science, and it certainly doesn't require /bin64.

Bill



From jcm at redhat.com  Mon Oct 22 18:36:40 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 14:36:40 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022182551.GB9625@nostromo.devel.redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
Message-ID: <1193078200.549.4.camel@jcmlaptop>

On Mon, 2007-10-22 at 14:25 -0400, Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
> > Without ranting aimlessly, IMO the only real solution is to stop
> > kludging rpm, yum, etc. and split out multilib libraries properly - and
> > if needed, seek and get approval for a bin64/bin32 with alternatives
> > system. Hacking RPM to simply ignore the fact that two packages provide
> > the same file is not the solution.
> 
> Congrats. You just suggested /usr/bin64 to solve conflicting files in
> /usr/share/doc. How does that work, exactly?

You're right. I am a fool. More importantly though, I didn't properly
consider the conflicting docs issue - I think in that case it's a case
of the file being in the wrong package.

I know you don't like the bin32/bin64 idea, but I think it's the only
real way to "solve" having both binary flavors of a package installed at
the same time, if that needs to be solved. The lesser issue - more
easily solved - is that of libraries, where I think a general consensus
to split them out into -libs packages over time would do the trick.

Jon.




From notting at redhat.com  Mon Oct 22 18:37:39 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 14:37:39 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193078200.549.4.camel@jcmlaptop>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
Message-ID: <20071022183739.GD9625@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> I know you don't like the bin32/bin64 idea, but I think it's the only
> real way to "solve" having both binary flavors of a package installed at
> the same time, if that needs to be solved.

I'm of the opinion that that doesn't need to be solved.

> The lesser issue - more
> easily solved - is that of libraries, where I think a general consensus
> to split them out into -libs packages over time would do the trick.

Yep. The problem is that, as it stands now, this requires changes to yum
and the metadata to handle upgrades right.

Bill



From notting at redhat.com  Mon Oct 22 18:39:34 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 14:39:34 -0400
Subject: multiarch conflicts
In-Reply-To: <20071021214405.GB23187@free.fr>
References: <20071021214405.GB23187@free.fr>
Message-ID: <20071022183934.GE9625@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> How are the multilib conflicts tested? I'd like to verify that there are
> no conflicts anymore before building.

Install x86_64 package. Then, in separate transaction, install i386 package.

> Also will this be extended to binary files?

Depends. ELF files? No. Other binary files? (data, etc.) - yes.

> And last what to do when the conflict is 'logical'? I have 2 examples in
> the bes package:
> 
> * there is a bes-config file which specifies the directory where
>   dlopened backend modules are, this is a %_libdir subdirectory, so,
>   it is logical to have a difference between arches.

The general way to do this is making the *-config script call pkg-config.


> * in the /etc/bes/bes.conf file there is also a conflict because in
>   that file the dlopened modules are specified, and therefore the libdir
>   is different.

That's a problem.

Bill



From jcm at redhat.com  Mon Oct 22 18:41:31 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 22 Oct 2007 14:41:31 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022183739.GD9625@nostromo.devel.redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
	<20071022183739.GD9625@nostromo.devel.redhat.com>
Message-ID: <1193078491.549.7.camel@jcmlaptop>

On Mon, 2007-10-22 at 14:37 -0400, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
> > I know you don't like the bin32/bin64 idea, but I think it's the only
> > real way to "solve" having both binary flavors of a package installed at
> > the same time, if that needs to be solved.
> 
> I'm of the opinion that that doesn't need to be solved.

I'm not entirely convinced people don't want it solved - but
whatever ;-) I still think a bin32/bin64 would be the only way to
actually address that, if it were to be addressed. I'll shutup.

> > The lesser issue - more
> > easily solved - is that of libraries, where I think a general consensus
> > to split them out into -libs packages over time would do the trick.
> 
> Yep. The problem is that, as it stands now, this requires changes to yum
> and the metadata to handle upgrades right.

Right. I guess I was just frustrated before when I jumped into this
thread, because this does seem to be the solution, so I would like to
see it happen - my only reason for pushing for meetings/whatever is that
we need some kind of mandate/policy to implement such a change. Right?

Jon.




From notting at redhat.com  Mon Oct 22 18:56:44 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 14:56:44 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022100132.76f33bbd@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
	<471CACBD.2080706@redhat.com> <20071022100132.76f33bbd@redhat.com>
Message-ID: <20071022185644.GG9625@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Applications get dragged in because the libraries aren't split out into
> -libs subpackages.  If they were, then the -devel and -libs packages
> would be available multilib, but the application itself wouldn't.

One *big* issue with doing this change across the board is that you'll go
from the repository having:

- foo.i386 and foo.x86_64

to:

- foo.x86_64 and foo-libs.i386 and foo-libs.x86_64

So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
foo.i386 will remain, often leading to conflicts.

Bill



From j.w.r.degoede at hhs.nl  Mon Oct 22 18:47:45 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 22 Oct 2007 20:47:45 +0200
Subject: Request permission to break always use system libs rule
	for	asc-2.0
In-Reply-To: <471CC274.9080002@gmail.com>
References: <471CB6AF.3060905@hhs.nl> <471CC274.9080002@gmail.com>
Message-ID: <471CF051.7010705@hhs.nl>

Toshio Kuratomi wrote:
> Hans de Goede wrote:
>> Hi All,
>>
>> I'm currently working on upgrading asc (Advanced Strategic Command) to 
>> 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and 
>> paragui-1.0.4.
>>
> 
> [snip information on SDLmm and paragui being dead upstream.  Bugfixes
>  present in the copies in asc.  Merging of paragui non-trivial due to
>  reformat of the source.]
> 
>> Are there any objections against this?
>>
> The options I see in decreasing order of preference are:
> 
> 1) Get the asc maintainers to take over maintenance of SDLmm and paragui

They have in a way, but since there are no other users and no upstream, they 
are maintaining them in tree, in a sense they have become part of ASC.

> 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages from 
> the asc source tarball.

To what purpose? There are no other users, if you can name one package out 
there which could be packaged for Fedora which uses either of them I would 
fully agree, which is why I created a seperate package for SDLmm in the first 
place. But there are _no_ other users. Try googling for paragui, the first 2 
links are dead upstream websites then a domain squater, then some old 
mailinglist posts and then we go into rpmsearch hits.

SDLmm, the same the last mailinglist post is from dec 2005!

So I challenge you, give my another (potential) package that needs them and I 
agree.


> 3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.
> 

Which would be the least work, not deviating from what upstream does (wasn't 
our mantra upstream upstream upstream?) and has no downsides.



> If you've explored #1 and are planning on doing #2 I have no objections.
> 
> If you're going to do #3 I'd like to know why you favor it over #2.
> 

See above, there are no users, so its extra work for nothing.

Regards,

Hans



From nicolas.mailhot at laposte.net  Mon Oct 22 19:14:04 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 22 Oct 2007 21:14:04 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071022185644.GG9625@nostromo.devel.redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<20071022185644.GG9625@nostromo.devel.redhat.com>
Message-ID: <1193080444.28655.8.camel@rousalka.dyndns.org>


Le lundi 22 octobre 2007 ? 14:56 -0400, Bill Nottingham a ?crit :

> One *big* issue with doing this change across the board is that you'll go
> from the repository having:
> 
> - foo.i386 and foo.x86_64
> 
> to:
> 
> - foo.x86_64 and foo-libs.i386 and foo-libs.x86_64
> 
> So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
> will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
> foo.i386 will remain, often leading to conflicts.

Wouldn't an Obsoletes: foo < current_version fix this? Unless we want to
ship 32bit & 64bit versions of foo in the same repo

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

From notting at redhat.com  Mon Oct 22 19:20:36 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 15:20:36 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193080444.28655.8.camel@rousalka.dyndns.org>
References: <471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
	<471CACBD.2080706@redhat.com> <20071022100132.76f33bbd@redhat.com>
	<20071022185644.GG9625@nostromo.devel.redhat.com>
	<1193080444.28655.8.camel@rousalka.dyndns.org>
Message-ID: <20071022192036.GH9625@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
> > will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
> > foo.i386 will remain, often leading to conflicts.
> 
> Wouldn't an Obsoletes: foo < current_version fix this? Unless we want to
> ship 32bit & 64bit versions of foo in the same repo

It *should*; need some more testing so this can be 100% codified.

Bill



From Axel.Thimm at ATrpms.net  Mon Oct 22 19:02:23 2007
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 22 Oct 2007 22:02:23 +0300
Subject: Multiarch crazyiness
In-Reply-To: <645d17210710220755se7f8ed4t85824f1d28433c1a@mail.gmail.com>
References: <471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
	<471CACBD.2080706@redhat.com> <20071022100132.76f33bbd@redhat.com>
	<1193062503.32582.29.camel@perihelion>
	<20071022102237.415db663@redhat.com>
	<1193063700.32582.43.camel@perihelion>
	<20071022104659.08d252ab@redhat.com>
	<645d17210710220752u22c5ac9dmb2e754bc639963de@mail.gmail.com>
	<645d17210710220755se7f8ed4t85824f1d28433c1a@mail.gmail.com>
Message-ID: <20071022190223.GD4075@puariko.nirvana>

On Mon, Oct 22, 2007 at 03:55:12PM +0100, Jonathan Underwood wrote:
> On 22/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > On 22/10/2007, Jesse Keating <jkeating at redhat.com> wrote:
> > > On Mon, 22 Oct 2007 10:35:00 -0400
> > > Jon Masters <jcm at redhat.com> wrote:
> > >
> > > > Jesse - ideas on how to organize this effort?
> > >
> > > Start a paper, define what the problem space is, define what goals
> > > should be accomplished to have a solution (not what the solution would
> > > be), identify key people involved, pitch it to somebody with budget to
> > > fly people around and feed/house them for a few days.
> > >
> >
> > Two very informative sites about how Debian is approaching the problem:
> >
> > http://wiki.debian.org/multiarch
> > http://lackof.org/taggart/hacking/multiarch/
> >
> > In particular, this paper from canonical does a quite nice job of
> > laying out the problem:
> >
> > http://multiarch.alioth.debian.org/multiarch-hp-report.pdf
> >
> 
> Also, Axel Thimm had what seemed like some reasonable proposals to do
> with the multiarch binary installation part of the problem:
> 
> http://www.redhat.com/archives/fedora-maintainers/2007-April/msg00511.html
> 
> Jonathan (wondering where Axel has gone).

Greece. :)
-- 
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/20071022/7e81a011/attachment.sig>

From katzj at redhat.com  Mon Oct 22 19:32:11 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 15:32:11 -0400
Subject: multiarch conflicts
In-Reply-To: <20071022183934.GE9625@nostromo.devel.redhat.com>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
Message-ID: <1193081531.10460.2.camel@localhost.localdomain>

On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
> * in the /etc/bes/bes.conf file there is also a conflict because in
> >   that file the dlopened modules are specified, and therefore the
> libdir
> >   is different.
> 
> That's a problem.

You can use $LIB in the path to dlopen iirc

Jeremy



From mjs at CLEMSON.EDU  Mon Oct 22 19:56:38 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Mon, 22 Oct 2007 15:56:38 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022122029.2b39bbea@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion> <471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl> <20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
Message-ID: <1193082998.17860.7.camel@vincent52.localdomain>

On Mon, 2007-10-22 at 12:20 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 12:03:05 -0400
> Matthew Saltzman <mjs at CLEMSON.EDU> wrote:
> 
> > 32-bit runtime in general?  Why?  (Not a critical "why", a genuinely
> > curious "why"...)
> 
> On those arches, running 64bit code comes at a penalty.  In fact, even
> on x86_64 there is a penalty.  Larger memory overhead.  However on
> x86_64 the extra CPU registers gained by running in x86_64 mode
> outweigh the memory overhead.  Not the case on ppc/sparc where there
> are no 'extra registers' to gain.  Very little software in very few
> situations need 64bit.

So on those archs one would want a 64-bit kernel and 32-bit apps, except
for large-memory programs or those needing 64/128-bit numerical types
(self-developed code, for example)?

Is that how it's actually handled by the installer?
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From jkeating at redhat.com  Mon Oct 22 19:56:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 15:56:24 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193082998.17860.7.camel@vincent52.localdomain>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
Message-ID: <20071022155624.39186440@redhat.com>

On Mon, 22 Oct 2007 15:56:38 -0400
Matthew Saltzman <mjs at CLEMSON.EDU> wrote:

> So on those archs one would want a 64-bit kernel and 32-bit apps,
> except for large-memory programs or those needing 64/128-bit
> numerical types (self-developed code, for example)?

Yes.

> Is that how it's actually handled by the installer?

We prefer 32bit on those platforms.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/543a3cd8/attachment.sig>

From halfline at gmail.com  Mon Oct 22 20:18:21 2007
From: halfline at gmail.com (Ray Strode)
Date: Mon, 22 Oct 2007 16:18:21 -0400
Subject: big changes going into F-9
Message-ID: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>

Hi guys,

I'm going to be building a new, unfinished gdm into the devel branch
today.  It's going to be very different than the gdm we are shipping
now and will need quite a bit of development before it's ready for
F-9.

It won't hit rawhide until rawhide switches over to F-9.

Details about it can be found here:

http://live.gnome.org/GDM/NewDesign

As part, of the build process I need to upgrade dbus-glib to 0.74.
This will require a number of package rebuilds.

Anyway, just wanted to give everyone a heads up.

--Ray



From pertusus at free.fr  Mon Oct 22 20:30:02 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 22:30:02 +0200
Subject: multiarch conflicts
In-Reply-To: <20071022183934.GE9625@nostromo.devel.redhat.com>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
Message-ID: <20071022203002.GA2653@free.fr>

On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > How are the multilib conflicts tested? I'd like to verify that there are
> > no conflicts anymore before building.
> 
> Install x86_64 package. Then, in separate transaction, install i386 package.

I can't do that in my system since I have an i386. Were the bugreports
done that way?

> > Also will this be extended to binary files?
> 
> Depends. ELF files? No. Other binary files? (data, etc.) - yes.

Ok. My personal opinion is that it would be better to extend to ELF files
too, but there is considerable controversy on that subject, and on how
to fix the multiarch issue.

> > And last what to do when the conflict is 'logical'? I have 2 examples in
> > the bes package:
> > 
> > * there is a bes-config file which specifies the directory where
> >   dlopened backend modules are, this is a %_libdir subdirectory, so,
> >   it is logical to have a difference between arches.
> 
> The general way to do this is making the *-config script call pkg-config.

Ok. This requires collaboration with upstream, but it is worth pursuing.

--
Pat



From tcallawa at redhat.com  Mon Oct 22 20:30:56 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 22 Oct 2007 16:30:56 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471CC6B6.8090503@gmail.com>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl>  <471CC6B6.8090503@gmail.com>
Message-ID: <1193085056.22958.23.camel@localhost.localdomain>


On Mon, 2007-10-22 at 08:50 -0700, Toshio Kuratomi wrote:

> I'd rather not make a decision on something like this until there's a 
> definite piece of software to beat out the corner cases with but my 
> initial leaning is yes.

I'm with Toshio on this. 

~spot



From pertusus at free.fr  Mon Oct 22 20:33:22 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 22:33:22 +0200
Subject: multiarch conflicts
In-Reply-To: <1193081531.10460.2.camel@localhost.localdomain>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<1193081531.10460.2.camel@localhost.localdomain>
Message-ID: <20071022203322.GB2653@free.fr>

On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
> On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
> > * in the /etc/bes/bes.conf file there is also a conflict because in
> > >   that file the dlopened modules are specified, and therefore the
> > libdir
> > >   is different.
> > 
> > That's a problem.
> 
> You can use $LIB in the path to dlopen iirc

The idea upstream is to specify the full path such that users may place
files to be dlopened anywhere and it seems to me that it makes sense,
especially since some may be packaged and other site specific (and in
the case of bes, it makes much sense to have site specific software that
is not meant to be packaged even if it is free software, for example if
there is acquisition of data in real time or the like).

--
Pat



From notting at redhat.com  Mon Oct 22 20:38:03 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 22 Oct 2007 16:38:03 -0400
Subject: multiarch conflicts
In-Reply-To: <20071022203002.GA2653@free.fr>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<20071022203002.GA2653@free.fr>
Message-ID: <20071022203803.GA22098@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
> > Patrice Dumas (pertusus at free.fr) said: 
> > > How are the multilib conflicts tested? I'd like to verify that there are
> > > no conflicts anymore before building.
> > 
> > Install x86_64 package. Then, in separate transaction, install i386 package.
> 
> I can't do that in my system since I have an i386. Were the bugreports
> done that way?

Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio
and diff them.

Bill



From pertusus at free.fr  Mon Oct 22 20:45:36 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 22:45:36 +0200
Subject: multiarch conflicts
In-Reply-To: <20071022203803.GA22098@nostromo.devel.redhat.com>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<20071022203002.GA2653@free.fr>
	<20071022203803.GA22098@nostromo.devel.redhat.com>
Message-ID: <20071022204536.GC2653@free.fr>

On Mon, Oct 22, 2007 at 04:38:03PM -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
> > > Patrice Dumas (pertusus at free.fr) said: 
> > > > How are the multilib conflicts tested? I'd like to verify that there are
> > > > no conflicts anymore before building.
> > > 
> > > Install x86_64 package. Then, in separate transaction, install i386 package.
> > 
> > I can't do that in my system since I have an i386. Were the bugreports
> > done that way?
> 
> Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio
> and diff them.

That's what I do currently, but manually. I'll try to see what I can do
with a scratch build, automatic download and rpm2cpio followed by a
diff...

--
Pat



From katzj at redhat.com  Mon Oct 22 20:43:49 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 16:43:49 -0400
Subject: multiarch conflicts
In-Reply-To: <20071022203322.GB2653@free.fr>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<1193081531.10460.2.camel@localhost.localdomain>
	<20071022203322.GB2653@free.fr>
Message-ID: <1193085829.10460.15.camel@localhost.localdomain>

On Mon, 2007-10-22 at 22:33 +0200, Patrice Dumas wrote:
> On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
> > On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
> > > * in the /etc/bes/bes.conf file there is also a conflict because in
> > > >   that file the dlopened modules are specified, and therefore the
> > > libdir
> > > >   is different.
> > > 
> > > That's a problem.
> > 
> > You can use $LIB in the path to dlopen iirc
> 
> The idea upstream is to specify the full path such that users may place
> files to be dlopened anywhere and it seems to me that it makes sense,
> especially since some may be packaged and other site specific (and in
> the case of bes, it makes much sense to have site specific software that
> is not meant to be packaged even if it is free software, for example if
> there is acquisition of data in real time or the like).

If people are adding site-specific bits, then having them add a full
path is perfectly reasonable.  But in the configuration that we ship, it
makes a lot more sense to have 
  paths=/usr/$LIB/libfoo.so /usr/$LIB/libbar.so

and then the right thing will happen depending on whether or not you're
running a 32bit or a 64bit binary.

Jeremy



From katzj at redhat.com  Mon Oct 22 20:45:16 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 16:45:16 -0400
Subject: multiarch conflicts
In-Reply-To: <20071022203803.GA22098@nostromo.devel.redhat.com>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<20071022203002.GA2653@free.fr>
	<20071022203803.GA22098@nostromo.devel.redhat.com>
Message-ID: <1193085916.10460.18.camel@localhost.localdomain>

On Mon, 2007-10-22 at 16:38 -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
> > > Patrice Dumas (pertusus at free.fr) said: 
> > > > How are the multilib conflicts tested? I'd like to verify that there are
> > > > no conflicts anymore before building.
> > > 
> > > Install x86_64 package. Then, in separate transaction, install i386 package.
> > 
> > I can't do that in my system since I have an i386. Were the bugreports
> > done that way?
> 
> Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio
> and diff them.

Or even easier is to use a script like
http://katzj.fedorapeople.org/multilib-cmp.py

Jeremy



From lmacken at redhat.com  Mon Oct 22 20:37:16 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 22 Oct 2007 16:37:16 -0400
Subject: Bodhi & Fedora 8 Updates
Message-ID: <20071022203716.GE8813@crow.myhome.westell.com>

I just upgraded our Bodhi production instance, which will now allow you
to enqueue your Fedora 8 Updates.

    http://bodhi.fedoraproject.org

Some notable changes since the last update:

  ? Updates will automatically get unpushed once they reach a karma of -3
  ? No more confusing legacy move/push terminology.  Available update requests are 'testing' and 'stable'.
  ? Unpushing/obsoleting is now instant.
  ? ACL validation against the pkgdb for new update submissions.

As always, please direct your bugs and enhancement requests here:

    https://hosted.fedoraproject.org/projects/bodhi/newticket


luke

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From laurent.rineau__fedora at normalesup.org  Mon Oct 22 20:54:35 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Mon, 22 Oct 2007 22:54:35 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071022155624.39186440@redhat.com>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
Message-ID: <200710222254.35624@rineau.tsetse>

On Monday 22 October 2007 21:56:24 Jesse Keating wrote:
> On Mon, 22 Oct 2007 15:56:38 -0400
>
> Matthew Saltzman <mjs at CLEMSON.EDU> wrote:
> > So on those archs one would want a 64-bit kernel and 32-bit apps,
> > except for large-memory programs or those needing 64/128-bit
> > numerical types (self-developed code, for example)?
>
> Yes.
>
> > Is that how it's actually handled by the installer?
>
> We prefer 32bit on those platforms.

What if I have a x86_64 platform and nevertheless want only a 64-bits kernel 
and almost all 32-bits apps??

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From pertusus at free.fr  Mon Oct 22 20:58:57 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 22 Oct 2007 22:58:57 +0200
Subject: multiarch conflicts
In-Reply-To: <1193085829.10460.15.camel@localhost.localdomain>
References: <20071021214405.GB23187@free.fr>
	<20071022183934.GE9625@nostromo.devel.redhat.com>
	<1193081531.10460.2.camel@localhost.localdomain>
	<20071022203322.GB2653@free.fr>
	<1193085829.10460.15.camel@localhost.localdomain>
Message-ID: <20071022205857.GE2653@free.fr>

On Mon, Oct 22, 2007 at 04:43:49PM -0400, Jeremy Katz wrote:
> 
> If people are adding site-specific bits, then having them add a full
> path is perfectly reasonable.  But in the configuration that we ship, it
> makes a lot more sense to have 
>   paths=/usr/$LIB/libfoo.so /usr/$LIB/libbar.so
> 
> and then the right thing will happen depending on whether or not you're
> running a 32bit or a 64bit binary.

Right, I didn't understood how it works. I'll propose that upstream.
Thanks.

--
Pat



From daryll.strauss at gmail.com  Mon Oct 22 21:00:08 2007
From: daryll.strauss at gmail.com (Daryll Strauss)
Date: Mon, 22 Oct 2007 14:00:08 -0700
Subject: License Attribution in Documentation?
Message-ID: <471D0F58.3040000@gmail.com>


Various packages in Fedora have licenses that say something like:

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

I'm trying to figure out where Fedora is satisfying these terms, but I 
must be missing it somewhere. If I get a live CD or other binary only 
distribution, where are these listed in the documentation?

I'm asking, not because I want to stir up flames, but I wanted to make 
sure I was following all the terms, and frankly, I hoped to crib from 
Fedora to make sure I'm doing it right. :)

					- |Daryll



From jkeating at redhat.com  Mon Oct 22 21:04:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 17:04:35 -0400
Subject: Multiarch crazyiness
In-Reply-To: <200710222254.35624@rineau.tsetse>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
	<200710222254.35624@rineau.tsetse>
Message-ID: <20071022170435.47944c9e@redhat.com>

On Mon, 22 Oct 2007 22:54:35 +0200
Laurent Rineau <laurent.rineau__fedora at normalesup.org> wrote:

> What if I have a x86_64 platform and nevertheless want only a 64-bits
> kernel and almost all 32-bits apps??

You'll have to do some fun by hand stuff with yum repos and
excludes/includes.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/cb337ad9/attachment.sig>

From cmadams at hiwaay.net  Mon Oct 22 21:07:09 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 22 Oct 2007 16:07:09 -0500
Subject: License Attribution in Documentation?
In-Reply-To: <471D0F58.3040000@gmail.com>
References: <471D0F58.3040000@gmail.com>
Message-ID: <20071022210709.GA963789@hiwaay.net>

Once upon a time, Daryll Strauss <daryll.strauss at gmail.com> said:
> Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in the
> documentation and/or other materials provided with the distribution.

The source DVD is material provided with the distrobution, isn't it?

Also, typically such license files are installed as documentation, so
that would be reproducing right in the binary package itself.

-- 
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 a.badger at gmail.com  Mon Oct 22 21:16:30 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 22 Oct 2007 14:16:30 -0700
Subject: multiarch conflicts
In-Reply-To: <20071022203322.GB2653@free.fr>
References: <20071021214405.GB23187@free.fr>	<20071022183934.GE9625@nostromo.devel.redhat.com>	<1193081531.10460.2.camel@localhost.localdomain>
	<20071022203322.GB2653@free.fr>
Message-ID: <471D132E.6010904@gmail.com>

Patrice Dumas wrote:
> On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
>> On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
>>> * in the /etc/bes/bes.conf file there is also a conflict because in
>>>>   that file the dlopened modules are specified, and therefore the
>>> libdir
>>>>   is different.
>>> That's a problem.
>> You can use $LIB in the path to dlopen iirc
> 
> The idea upstream is to specify the full path such that users may place
> files to be dlopened anywhere and it seems to me that it makes sense,
> especially since some may be packaged and other site specific (and in
> the case of bes, it makes much sense to have site specific software that
> is not meant to be packaged even if it is free software, for example if
> there is acquisition of data in real time or the like).
> 
Another possibility is to copy what pango does:
   /etc/pango/i686-redhat-linux-gnu/pango.modules
   /etc/pango/x86_64-redhat-linux-gnu/pango.modules

-Toshio



From jima at beer.tclug.org  Mon Oct 22 21:22:44 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 22 Oct 2007 16:22:44 -0500 (CDT)
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <20071022203716.GE8813@crow.myhome.westell.com>
References: <20071022203716.GE8813@crow.myhome.westell.com>
Message-ID: <Pine.LNX.4.64.0710221622030.4486@beer.tclug.org>

On Mon, 22 Oct 2007, Luke Macken wrote:
> As always, please direct your bugs and enhancement requests here:

  But where do we send the hate mail!?
  Kidding!  Thanks for the update, Luke.

      Jima



From choeger at cs.tu-berlin.de  Tue Oct 23 04:01:52 2007
From: choeger at cs.tu-berlin.de (Christoph Hoeger)
Date: Tue, 23 Oct 2007 00:01:52 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193073308.28655.5.camel@rousalka.dyndns.org>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
Message-ID: <1193112112.3773.4.camel@localhost.localdomain>

Hi,

is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
Display to see more information on my screen simultaneously and what
now? Gnome makes all bigger so I don't see anything more (by default, I
know I can change it) than on my old notebook! That seems to be
something that should be discussed, before somebody gets mad about
interface nazis again ;)

regards

christoph


On Mon, 2007-10-22 at 19:15 +0200, Nicolas Mailhot wrote:
> Le lundi 22 octobre 2007 ? 18:43 -0400, Christoph Hoeger a ?crit :
> 
> > is it just me or is the default font size in test3 slightly bigger than
> > in F8? 
> 
> It's not bigger but GNOME now honors xorg dpi computations instead of
> mindlessly forcing 96dpi. That means if your hardware is not actually
> 96dpi the font sizes are now computed differently.
> 
> You'll just have to get used to correct font scaling (the same as in KDE
> BTW). Or adjust DisplaySize in xorg.conf if xorg-detected screen
> dimensions is wrong.
> 
> Regards,
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From nicolas.mailhot at laposte.net  Mon Oct 22 22:24:43 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 00:24:43 +0200
Subject: fontsize in 7.92
In-Reply-To: <1193112112.3773.4.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
Message-ID: <1193091883.4605.13.camel@rousalka.dyndns.org>


Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :

> is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> Display to see more information on my screen simultaneously 

If you want small fonts just lower the size in points of your fonts in
your app preferences. Gnome font preferences use pt as unit. Till now
the GNOME pt unit had no relation with the pt unit the rest of the world
uses. Now it's the same, so if you want small fonts you need to actually
configure small fonts and not change the unit meaning on your system
(and likewise if you want big fonts).

That also means BTW that when you change laptop again your text will
stay the same size regardless of the screen resolution, so you can
invest the time to find good settings you'll keep them a long time.

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

From sberry at northlc.com  Mon Oct 22 22:31:16 2007
From: sberry at northlc.com (Scott Berry)
Date: Mon, 22 Oct 2007 17:31:16 -0500
Subject: big changes going into F-9
In-Reply-To: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>
References: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>
Message-ID: <8C4C2231F8154AED8BA5C070A6859ADF@Scott>

Ray,

Any ideas how this will work for accessibility?  I read the web site you 
sited but I didn't see any new accessibility items.  Are you aware of any? 
Just curious as I am totally blind.

Scott


----- Original Message ----- 
From: "Ray Strode" <halfline at gmail.com>
To: "Development discussions related to Fedora" 
<fedora-devel-list at redhat.com>
Sent: Monday, October 22, 2007 3:18 PM
Subject: big changes going into F-9


> Hi guys,
>
> I'm going to be building a new, unfinished gdm into the devel branch
> today.  It's going to be very different than the gdm we are shipping
> now and will need quite a bit of development before it's ready for
> F-9.
>
> It won't hit rawhide until rawhide switches over to F-9.
>
> Details about it can be found here:
>
> http://live.gnome.org/GDM/NewDesign
>
> As part, of the build process I need to upgrade dbus-glib to 0.74.
> This will require a number of package rebuilds.
>
> Anyway, just wanted to give everyone a heads up.
>
> --Ray
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.15.5/1085 - Release Date: 
> 10/22/2007 10:35 AM
>
> 



From otaylor at redhat.com  Mon Oct 22 22:36:41 2007
From: otaylor at redhat.com (Owen Taylor)
Date: Mon, 22 Oct 2007 18:36:41 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193091883.4605.13.camel@rousalka.dyndns.org>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
Message-ID: <1193092601.17037.1.camel@localhost.localdomain>

On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote: 
> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
> 
> > is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> > Display to see more information on my screen simultaneously 
> 
> If you want small fonts just lower the size in points of your fonts in
> your app preferences. Gnome font preferences use pt as unit. Till now
> the GNOME pt unit had no relation with the pt unit the rest of the world
> uses. Now it's the same, so if you want small fonts you need to actually
> configure small fonts and not change the unit meaning on your system
> (and likewise if you want big fonts).
> 
> That also means BTW that when you change laptop again your text will
> stay the same size regardless of the screen resolution, so you can
> invest the time to find good settings you'll keep them a long time.

I'd be interested in a pointer to the discussion that led to this policy
change.

- Owen




From poelstra at redhat.com  Mon Oct 22 22:42:37 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 22 Oct 2007 15:42:37 -0700
Subject: boot a live image from an ipod?
Message-ID: <471D275D.7040903@redhat.com>

Working from this page http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo 

I don't have a USB stick yet to try this so I'm wondering if anyone has successfully used their ipod as a USB boot device?  I am reluctant to change the partition flag on the ipod to be bootable because I don't have time right now to setting up my ipod again if it gets hosed.

Also curious if it is possible to have multiple live images on a flash device and boot different ones?  If so , how would that be done?

Thanks,
John



From tibbs at math.uh.edu  Mon Oct 22 22:59:37 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 22 Oct 2007 17:59:37 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193085056.22958.23.camel@localhost.localdomain>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl> <471CC6B6.8090503@gmail.com>
	<1193085056.22958.23.camel@localhost.localdomain>
Message-ID: <ufa640yah7q.fsf@epithumia.math.uh.edu>

>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:

TC> I'm with Toshio on this.

Which would then lead to the analogous corner case of something that's
open-source but expects to be compiled with a non-free compiler or one
that's not in Fedora for some reason.

There's at least one piece of free (GPL) software which we can't
include because it requires some commercial BASIC compiler.

 - J<



From pertusus at free.fr  Mon Oct 22 23:02:33 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 01:02:33 +0200
Subject: cannot make build after updating cert
In-Reply-To: <200708282258.46580.opensource@till.name>
References: <20070828205322.GC2958@free.fr>
	<200708282258.46580.opensource@till.name>
Message-ID: <20071022230233.GA17484@free.fr>

On Tue, Aug 28, 2007 at 10:58:41PM +0200, Till Maas wrote:
> On Di August 28 2007, Patrice Dumas wrote:
> 
> > I just updated my .fedora.cert, but i still cannot require builds:
> 
> > Is it an issue known to others? How can I provide more info?
> 
> Afaik you need to re-run /usr/bin/fedora-packager-setup.sh from koji.

It was not documented, at least not in
http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq
it should be now.

--
Pat



From tmus at tmus.dk  Mon Oct 22 23:03:46 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 22 Oct 2007 21:03:46 -0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471C94BD.6080801@codewiz.org>
References: <471C94BD.6080801@codewiz.org>
Message-ID: <ffja8k$dj7$1@ger.gmane.org>

Bernardo Innocenti wrote:
>
> It would seem a worthwhile goal to unify SSL/TLS
> implementations like we did for spell checkers.
> Or, if it turns out to be too hard, at least it would
> be nice to their pki files.
> 

I really don't think its our job to decide which SSL implementation is 
used by the various different projects. Those projects have already 
chosen which implementation they prefer - It's not for us to decide. 
Also, Fedora aims to be as close to upstream as possible, so unless we 
can convince the project to change their preferred SSL implementation, 
I'm all for simply leaving it alone.

Compatibility layers and Fedora-only patchsets, all means added 
complexity and more Fedora-only bugs.

That said, we could pick our favorite implementation and use that, 
whenever a project supports multiple implementations (not sure if this 
is the case for any project).

Just my 5 cents

/Thomas



From dmc.fedora at filteredperception.org  Mon Oct 22 23:08:14 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Mon, 22 Oct 2007 18:08:14 -0500
Subject: boot a live image from an ipod?
In-Reply-To: <471D275D.7040903@redhat.com>
References: <471D275D.7040903@redhat.com>
Message-ID: <471D2D5E.4060305@filteredperception.org>

John Poelstra wrote:

> Also curious if it is possible to have multiple live images on a flash 
> device and boot different ones?  If so , how would that be done?

Currently the livecd-tools generated initramfs is not smart enough to 
deal with distinguishing multiple live images.  A while back I submitted 
several livecd filesystem layout changes.  The ones that would have 
begun to  facilite distinguishable images haven't been merged yet.  And 
there is certainly room for discussion on alternate approaches.

But either way it's just a matter of bash scripting...

(Though actually I just looked again.  What I mentioned above was about 
the issues of storing multiple images on a single partition.  It may 
actually be much easier to already accomplish this with multiple 
partitions.  Still nothing that works out of the box, but perhaps doable 
already without changes to the initramfs)

-dmc



From bnocera at redhat.com  Mon Oct 22 23:15:13 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 23 Oct 2007 00:15:13 +0100
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193063606.32582.40.camel@perihelion>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193061984.32582.20.camel@perihelion>
	<20071022102031.73786d4a@redhat.com>
	<1193063606.32582.40.camel@perihelion>
Message-ID: <1193094913.25405.55.camel@cookie.hadess.net>


On Mon, 2007-10-22 at 10:33 -0400, Jon Masters wrote:
> On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
> > On Mon, 22 Oct 2007 10:06:24 -0400
> > Jon Masters <jcm at redhat.com> wrote:
> > 
> > > On a tangent, I would like to have a discussion about in-kernel
> > > firmware as it becomes split out and loaded using request_firmware.
> > > So that third parties can supply different firmware updates, can we
> > > agree that it's worthwhile having one firmware package for each
> > > firmware file set needed by the kernel package, in the longer term?
> > 
> > These wouldn't turn into kmod like packages would they, and have all
> > the same kludges to work with RPM?  Are you going to have to handle
> > different firmware sets for each kernel version you might have
> > installed, plus alternatives from upstream?  Obviously I'm a bit
> > reluctant to reintroduce nightmares like this.
> 
> The problem is if a user needs to upgrade the firmware for some card,
> they can't do this if the file for that firmware lives inside the kernel
> package (well, they can abuse the breakage in RPM for multilib and
> possibly get away with another package owning the file, but...). If
> we're interested in allowing firmware upgrades to happen outside of the
> kernel (which is one reason it split out upstream), then this is needed.
> 
> Would love to hear comments ;-)

99% of the time, the driver and firmware[1] are closely knit. Try
upgrade the firmware of a QLogic card without the driver following, and
watch bad things happen.

I'm sure there are exceptions, which should be dealt with, but sometimes
there are reasons why this is the case. I also seem to remember similar
issues with cciss controllers which would lead to corruption with a
driver/firmware mismatch.

[1]: when the firmware is shipped as part of the driver



From bnocera at redhat.com  Mon Oct 22 23:18:45 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 23 Oct 2007 00:18:45 +0100
Subject: boot a live image from an ipod?
In-Reply-To: <471D275D.7040903@redhat.com>
References: <471D275D.7040903@redhat.com>
Message-ID: <1193095125.25405.59.camel@cookie.hadess.net>


On Mon, 2007-10-22 at 15:42 -0700, John Poelstra wrote:
> Working from this page http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo 
> 
> I don't have a USB stick yet to try this so I'm wondering if anyone
> has successfully used their ipod as a USB boot device?  I am reluctant
> to change the partition flag on the ipod to be bootable because I
> don't have time right now to setting up my ipod again if it gets
> hosed.
> 
> Also curious if it is possible to have multiple live images on a flash
> device and boot different ones?  If so , how would that be done?

You'd need to wipe the hard-drive to match whatever your machine expects
in terms of layout. Most of time, it might just mean an MBR change
(might break the iPod).

Consider buying an el-cheapo 64 meg USB key (I'll send you one if you're
desperate, probably more in stamps than the price of the key), and put
the boot.iso on there. The iPod can contain the whole DVD image on its
filesystem.

I used to do my upgrades like that (replacing the USB key with a CD-RW).



From katzj at redhat.com  Mon Oct 22 23:25:03 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 19:25:03 -0400
Subject: boot a live image from an ipod?
In-Reply-To: <471D275D.7040903@redhat.com>
References: <471D275D.7040903@redhat.com>
Message-ID: <1193095503.10460.27.camel@localhost.localdomain>

On Mon, 2007-10-22 at 15:42 -0700, John Poelstra wrote:
> Working from this page http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo 
> 
> I don't have a USB stick yet to try this so I'm wondering if anyone has successfully used their ipod as a USB boot device?  I am reluctant to change the partition flag on the ipod to be bootable because I don't have time right now to setting up my ipod again if it gets hosed.

Current ipods are set up with 2048 byte sectors which syslinux (and
other bootloaders) don't support, so you can't actually boot from them.
Fixing that requires a lot of really grotty work to clean out all of the
"sector size == 512" assumptions through syslinux and even then, no
guarantee that it doesn't brick the iPod

> Also curious if it is possible to have multiple live images on a flash device and boot different ones?  If so , how would that be done?

Right now, you'd have to do it with different partitions.  dmc's mail
has more of the details

Jeremy



From a.badger at gmail.com  Tue Oct 23 00:05:47 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 22 Oct 2007 17:05:47 -0700
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <20071022203716.GE8813@crow.myhome.westell.com>
References: <20071022203716.GE8813@crow.myhome.westell.com>
Message-ID: <471D3ADB.5000809@gmail.com>

Luke Macken wrote:
> I just upgraded our Bodhi production instance, which will now allow you
> to enqueue your Fedora 8 Updates.
> 
>     http://bodhi.fedoraproject.org
> 
> Some notable changes since the last update:
> 
>   ? Updates will automatically get unpushed once they reach a karma of -3
>   ? No more confusing legacy move/push terminology.  Available update requests are 'testing' and 'stable'.
>   ? Unpushing/obsoleting is now instant.
>   ? ACL validation against the pkgdb for new update submissions.
> 
I think this update also fixes the Unicode-characters-in-packager's-name 
error that some people were running into earlier.  (Unless that was 
fixed earlier and I just missed it.)

Thanks Luke!

-Toshio



From halfline at gmail.com  Tue Oct 23 00:16:02 2007
From: halfline at gmail.com (Ray Strode)
Date: Mon, 22 Oct 2007 20:16:02 -0400
Subject: big changes going into F-9
In-Reply-To: <8C4C2231F8154AED8BA5C070A6859ADF@Scott>
References: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>
	<8C4C2231F8154AED8BA5C070A6859ADF@Scott>
Message-ID: <45abe7d80710221716s24bbe310xe9705e15acc9c275@mail.gmail.com>

Hi,

> Any ideas how this will work for accessibility?  I read the web site you
> sited but I didn't see any new accessibility items.  Are you aware of any?
> Just curious as I am totally blind.

It should work better than the old themed greeter, because it doesn't
use (the inaccessible) canvas anymore, and should have a window
manager running to handle struts for the magnifier/orca.

--Ray



From packages at amiga-hardware.com  Tue Oct 23 00:30:59 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Tue, 23 Oct 2007 01:30:59 +0100
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471C64E5.4070908@hhs.nl>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
Message-ID: <471D40C3.9060008@amiga-hardware.com>

Hans de Goede wrote:

> I fully agree, this discussion does raise one interesting question 
> though: What if there is fully floss software, which we can build from 
> source. Which is written for another OS, but will run fine under an 
> emulator and is hard to port. Do we allow shipping this?

I don't see why not. There's already examples analagous to this in 
Fedora, for example the CBIOS firmware (ROMs if you prefer) for OpenMSX 
is compiled from z80 assembly source using sjasm in the RPM. The 
resulting binary blob is of course z80 code designed to run under the 
emulator.

-- 
Ian Chapman.



From dmc.fedora at filteredperception.org  Tue Oct 23 00:29:58 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Mon, 22 Oct 2007 19:29:58 -0500
Subject: boot a live image from an ipod?
In-Reply-To: <1193095503.10460.27.camel@localhost.localdomain>
References: <471D275D.7040903@redhat.com>
	<1193095503.10460.27.camel@localhost.localdomain>
Message-ID: <471D4086.2010909@filteredperception.org>

Jeremy Katz wrote:
> On Mon, 2007-10-22 at 15:42 -0700, John Poelstra wrote:
>> Working from this page http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo 
>> 
> 
>> Also curious if it is possible to have multiple live images on a flash device and boot different ones?  If so , how would that be done?
> 
> Right now, you'd have to do it with different partitions.  dmc's mail
> has more of the details

As for usable details...  It seems like it might work if you use 
livecd-iso-to-disk to set up your liveUSB as is currently supported. 
Then use livecd-iso-to-disk again with more partitions (assuming you had 
it partitioned before all of this).  Then on the last partition that you 
did, you'd want to go into _its_ syslinux.cfg, and merge in entries from 
the syslinux.cfg from the other partitions.  Naturally if the kernels or 
initrds from the different partitions are actually different, you'll 
need to copy them to the partition that syslinux actually uses (last one 
you ran l-i-t-d on (?)), with unique names, adjusting the .cfg.

That was all off the top of my head speculation.  If I'm not forgetting 
something, it might work.

-dmc




From packages at amiga-hardware.com  Tue Oct 23 00:39:07 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Tue, 23 Oct 2007 01:39:07 +0100
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193058738.26974.3.camel@localhost.localdomain>
References: <adf480660710220034q74929eecjf81e8fb43385613b@mail.gmail.com>
	<1193058738.26974.3.camel@localhost.localdomain>
Message-ID: <471D42AB.4010803@amiga-hardware.com>

Adam Jackson wrote:

> This is not the same thing as a firmware, because firmware doesn't
> execute on the host CPU.  Practically speaking, that's where we draw the
> line.

This is not meant as a facetious question but how does this pan out with 
regards to emulators? Most of which require some sort of firmware which 
runs on the 'virtual' CPU which is technically speaking running on the 
real CPU, perhaps even more so in cases where JIT compilation is used. I 
suppose it boils down to an accepted Fedora definition of firmware.

-- 
Ian Chapman.



From halfline at gmail.com  Tue Oct 23 00:48:25 2007
From: halfline at gmail.com (Ray Strode)
Date: Mon, 22 Oct 2007 20:48:25 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193092601.17037.1.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193092601.17037.1.camel@localhost.localdomain>
Message-ID: <45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>

Hi,

On 10/22/07, Owen Taylor <otaylor at redhat.com> wrote:
> > That also means BTW that when you change laptop again your text will
> > stay the same size regardless of the screen resolution, so you can
> > invest the time to find good settings you'll keep them a long time.
>
> I'd be interested in a pointer to the discussion that led to this policy
> change.
>
http://bugzilla.gnome.org/show_bug.cgi?id=378338

Federico blogged about it, too:

http://www.gnome.org/~federico/news-2007-01.html#font-sizes

--Ray



From jkeating at redhat.com  Tue Oct 23 00:41:27 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 20:41:27 -0400
Subject: Koji Garbage Collection
Message-ID: <20071022204127.220d62b8@redhat.com>

We are about to roll out garbage collection for Koji. Please review the 
document linked below.

   http://fedoraproject.org/wiki/Koji/GarbageCollection

As part of garbage collection, builds that are no longer needed will be 
deleted. The owner of the build will receive an email notification of 
the impending deletion and there is a grace period. To reduce the amount 
of email, multiple notifications to the same user will be combined into 
one message.

If you receive such a notification, deleting the builds is most likely 
the right thing. If you feel differently, please see the document linked 
above for instructions.

The initial collection of builds that can be deleted will happen tonight.

Because there is an urgent need to free space on the Koji server, we 
will be shortening the grace period during the initial rollout. This 
means that you will need to act fast if you need to save a build that 
you receive a notification about. The first round of deletions will kick 
in late Friday evening.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/3257021d/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From abartlet at samba.org  Tue Oct 23 01:02:18 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Tue, 23 Oct 2007 11:02:18 +1000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471CA9E0.6020503@redhat.com>
References: <471C94BD.6080801@codewiz.org>  <471CA9E0.6020503@redhat.com>
Message-ID: <1193101338.3860.21.camel@localhost.localdomain>

On Mon, 2007-10-22 at 14:47 +0100, Richard W.M. Jones wrote:
> Bernardo Innocenti wrote:
> > I remember this topic being discussed some time ago,
> > but software is fluid and maybe it's time to respin
> > the topic.
> > 
> > It would seem a worthwhile goal to unify SSL/TLS
> > implementations like we did for spell checkers.
> > Or, if it turns out to be too hard, at least it would
> > be nice to their pki files.
> 
> I've asked whether we have a standard layout for /etc/pki before, but no 
> one seems to know.
> 
> > We're now shipping no less than 4 different implementations
> > of SSL:
> > 
> > - openssl (OpenBSD's implementation)
> > - nss (Netscape's implementation)
> > - gnutls (LGPL implementation)
> > - puretls (Java implementation)
> 
> Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl.  I'm 
> sure Perl & Python probably have their own too.
> 
> > But which one should replace the others?
> 
> When we implemented encryption in libvirt, we chose gnutls because it 
> has excellent examples which allow you to actually write code to use it 
> in a short period of time.  The others have (or we perceived them to 
> have) hideous, confusing or undocumented APIs.

While I'm currently grumpy at gnutls (on debian actually, which is
running 2.0), I do agree it's API and read/write callbacks make
integrating into an existing event system very nice.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.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/20071023/189f6aa4/attachment.sig>

From davej at redhat.com  Tue Oct 23 01:31:27 2007
From: davej at redhat.com (Dave Jones)
Date: Mon, 22 Oct 2007 21:31:27 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071022204127.220d62b8@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
Message-ID: <20071023013127.GD15801@redhat.com>

On Mon, Oct 22, 2007 at 08:41:27PM -0400, Jesse Keating wrote:
 > We are about to roll out garbage collection for Koji. Please review the 
 > document linked below.
 > 
 >    http://fedoraproject.org/wiki/Koji/GarbageCollection
 > 
 > As part of garbage collection, builds that are no longer needed will be 
 > deleted. The owner of the build will receive an email notification of 
 > the impending deletion and there is a grace period. To reduce the amount 
 > of email, multiple notifications to the same user will be combined into 
 > one message.

As owner of one of the biggest offenders in space usage, I completely
understand the need to do this.
However, it's extremely valuable to be able to have users go grab
a bunch of previous RPMs to bisect a problem.  Just this afternoon,
I asked Mike Harris to download 15 2.6.22 based kernels for example
so we can find out exactly when we introduced a "cant boot" bug which
likely affects F8 too.

What I'd like to do, is still keep all these RPMs, but get them out
of koji.  I'm even prepared to give up a few hundred GB of diskspace
on my own machines to keep them.   The question I have though, is
whats the easiest way to get them?  Clicking through the koji web interface
will quickly drive me nuts.   Is there some place I can just scp them from?

	Dave

-- 
http://www.codemonkey.org.uk



From jkeating at redhat.com  Tue Oct 23 01:40:09 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 22 Oct 2007 21:40:09 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071023013127.GD15801@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
Message-ID: <20071022214009.3dad166a@redhat.com>

On Mon, 22 Oct 2007 21:31:27 -0400
Dave Jones <davej at redhat.com> wrote:

> Is there some place I can just scp them from?

wget -r?  http://koji.fedoraproject.org/packages/kernel/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071022/aa3ea33e/attachment.sig>

From katzj at redhat.com  Tue Oct 23 01:49:08 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 22 Oct 2007 21:49:08 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071023013127.GD15801@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
Message-ID: <1193104148.10460.41.camel@localhost.localdomain>

On Mon, 2007-10-22 at 21:31 -0400, Dave Jones wrote:
> On Mon, Oct 22, 2007 at 08:41:27PM -0400, Jesse Keating wrote:
>  > We are about to roll out garbage collection for Koji. Please review the 
>  > document linked below.
>  > 
>  >    http://fedoraproject.org/wiki/Koji/GarbageCollection
>  > 
>  > As part of garbage collection, builds that are no longer needed will be 
>  > deleted. The owner of the build will receive an email notification of 
>  > the impending deletion and there is a grace period. To reduce the amount 
>  > of email, multiple notifications to the same user will be combined into 
>  > one message.
> 
> As owner of one of the biggest offenders in space usage, I completely
> understand the need to do this.
> However, it's extremely valuable to be able to have users go grab
> a bunch of previous RPMs to bisect a problem.  Just this afternoon,
> I asked Mike Harris to download 15 2.6.22 based kernels for example
> so we can find out exactly when we introduced a "cant boot" bug which
> likely affects F8 too.
> 
> What I'd like to do, is still keep all these RPMs, but get them out
> of koji.  I'm even prepared to give up a few hundred GB of diskspace
> on my own machines to keep them.   The question I have though, is
> whats the easiest way to get them?  Clicking through the koji web interface
> will quickly drive me nuts.   Is there some place I can just scp them from?

You can get a list of builds with koji list-tagged or just by getting a
directory listing.  Then, there's koji download-build[1] which will
download all the packages for a specific build into the current
directory

Jeremy

[1] I just found this one a couple of months ago -- it's incredibly
handy for all kinds of things



From sberry at northlc.com  Tue Oct 23 02:15:55 2007
From: sberry at northlc.com (Scott Berry)
Date: Mon, 22 Oct 2007 21:15:55 -0500
Subject: fontsize in 7.92
In-Reply-To: <1193092601.17037.1.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain><1193073308.28655.5.camel@rousalka.dyndns.org><1193112112.3773.4.camel@localhost.localdomain><1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193092601.17037.1.camel@localhost.localdomain>
Message-ID: <DF845F57DA704AF0BC820D3B76187C2F@Scott>

Also my father is noticing some font changes in Open Office.  He tells me 
the font is very small.  Not sure whether to report this as a bug or whether 
it can be changed with in Open Office itself?  If it is able to be changed 
in Open Office how would one do it?

Scott


----- Original Message ----- 
From: "Owen Taylor" <otaylor at redhat.com>
To: "Development discussions related to Fedora" 
<fedora-devel-list at redhat.com>
Sent: Monday, October 22, 2007 5:36 PM
Subject: Re: font size in 7.92


> On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
>> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
>>
>> > is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
>> > Display to see more information on my screen simultaneously
>>
>> If you want small fonts just lower the size in points of your fonts in
>> your app preferences. Gnome font preferences use pt as unit. Till now
>> the GNOME pt unit had no relation with the pt unit the rest of the world
>> uses. Now it's the same, so if you want small fonts you need to actually
>> configure small fonts and not change the unit meaning on your system
>> (and likewise if you want big fonts).
>>
>> That also means BTW that when you change laptop again your text will
>> stay the same size regardless of the screen resolution, so you can
>> invest the time to find good settings you'll keep them a long time.
>
> I'd be interested in a pointer to the discussion that led to this policy
> change.
>
> - Owen
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.15.5/1085 - Release Date: 
> 10/22/2007 10:35 AM
>
> 



From sberry at northlc.com  Tue Oct 23 02:18:38 2007
From: sberry at northlc.com (Scott Berry)
Date: Mon, 22 Oct 2007 21:18:38 -0500
Subject: big changes going into F-9
In-Reply-To: <45abe7d80710221716s24bbe310xe9705e15acc9c275@mail.gmail.com>
References: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com><8C4C2231F8154AED8BA5C070A6859ADF@Scott>
	<45abe7d80710221716s24bbe310xe9705e15acc9c275@mail.gmail.com>
Message-ID: <124D118B056F4AAA9DBAC0B2D6B051BC@Scott>

Cool beans.  I was hoping that you would say that.  Great news.  Linux is 
moving along well for accessibility.

Scott


----- Original Message ----- 
From: "Ray Strode" <halfline at gmail.com>
To: "Development discussions related to Fedora" 
<fedora-devel-list at redhat.com>
Sent: Monday, October 22, 2007 7:16 PM
Subject: Re: big changes going into F-9


> Hi,
>
>> Any ideas how this will work for accessibility?  I read the web site you
>> sited but I didn't see any new accessibility items.  Are you aware of 
>> any?
>> Just curious as I am totally blind.
>
> It should work better than the old themed greeter, because it doesn't
> use (the inaccessible) canvas anymore, and should have a window
> manager running to handle struts for the magnifier/orca.
>
> --Ray
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.15.6/1086 - Release Date: 
> 10/22/2007 7:57 PM
>
> 



From a.badger at gmail.com  Tue Oct 23 02:21:54 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 22 Oct 2007 19:21:54 -0700
Subject: Request permission to break always use system libs
	rule	for	asc-2.0
In-Reply-To: <471CF051.7010705@hhs.nl>
References: <471CB6AF.3060905@hhs.nl> <471CC274.9080002@gmail.com>
	<471CF051.7010705@hhs.nl>
Message-ID: <471D5AC2.3000906@gmail.com>

Hans de Goede wrote:
> Toshio Kuratomi wrote:
>> Hans de Goede wrote:
>>> Hi All,
>>>
>>> I'm currently working on upgrading asc (Advanced Strategic Command) 
>>> to 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 
>>> and paragui-1.0.4.
>>>
>>
>> [snip information on SDLmm and paragui being dead upstream.  Bugfixes
>>  present in the copies in asc.  Merging of paragui non-trivial due to
>>  reformat of the source.]
>>
>>> Are there any objections against this?
>>>
>> The options I see in decreasing order of preference are:
>>
>> 1) Get the asc maintainers to take over maintenance of SDLmm and paragui
> 
> They have in a way, but since there are no other users and no upstream, 
> they are maintaining them in tree, in a sense they have become part of ASC.
> 
Have you asked upstream if they're willing to make separate 
tarballs/releases for SDLmm and paragui since they are the de facto 
maintainers of those code bases at this point?

>> 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages from 
>> the asc source tarball.
> 
> To what purpose? There are no other users, if you can name one package 
> out there which could be packaged for Fedora which uses either of them I 
> would fully agree, which is why I created a seperate package for SDLmm 
> in the first place. But there are _no_ other users. Try googling for 
> paragui, the first 2 links are dead upstream websites then a domain 
> squater, then some old mailinglist posts and then we go into rpmsearch 
> hits.
> 
> SDLmm, the same the last mailinglist post is from dec 2005!
> 
> So I challenge you, give my another (potential) package that needs them 
> and I agree.
> 
> 
That's not great reasoning.  If asc maintained those libraries out of 
tree and made releases as separate tarballs, you'd continue to make 
separate packages, right?  It's not a question of how many consumers 
there are but of how useful the library is outside of the program.

Since these libraries were released outside of the program before and 
you haven't said anything about the build scripts being changed just 
bugfixes and code-formatting I have the impression that they would be 
useful outside of asc.  You could correct me on that by letting me know 
that the asc fixes have made the two code bases dependent on each other 
or some other technical reason that they aren't two separate codebases 
that happen to be maintained in the same tree.

>> 3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.
>>
> 
> Which would be the least work, not deviating from what upstream does 
> (wasn't our mantra upstream upstream upstream?) and has no downsides.
>
If a problem is serious enough we do deviate from upstream.  For 
instance, changing a package to build against system libraries is 
certainly something that we do whether or not upstream.  We also will 
take the time to help upstream do the right thing rather than blindly 
packaging what they hand us.  In this case, it sure looks best to me to 
build those libraries from upstream's tarball as system libraries and 
then have the asc programs use those.

The downsides:
* if you make these private libraries of asc you then have all the 
problems of static libraries should another program be created in the 
future that makes use of their own copy of those libraries.

* There's no attempt to coordinate work on the libraries.  Should 
another developer decide they want to build something that uses 
functionality that could be provided by SDl-mm or paragui they'll be 
unaware that there is active maintenance of these libraries occurring 
and will either fork their own copy or reinvent the wheel.

-Toshio



From seg at haxxed.com  Tue Oct 23 04:13:18 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 22 Oct 2007 23:13:18 -0500
Subject: Multiarch crazyiness
In-Reply-To: <471CB10A.3070803@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>  <471CB10A.3070803@redhat.com>
Message-ID: <1193112798.560.7.camel@localhost>

On Mon, 2007-10-22 at 15:17 +0100, Richard W.M. Jones wrote:
>   - proprietary 32 bit binaries (does Fedora care about them?)

I rather like being able to play Doom 3 on my x86_64 system...

You also missed Wine, which as currently designed, requires you to
install the i386 version to be of much use since most Win32 software is
i386.
-------------- 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/20071022/22565acc/attachment.sig>

From kevin.kofler at chello.at  Tue Oct 23 04:27:47 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 23 Oct 2007 04:27:47 +0000 (UTC)
Subject: Bodhi & Fedora 8 Updates
References: <20071022203716.GE8813@crow.myhome.westell.com>
Message-ID: <loom.20071023T042700-571@post.gmane.org>

Luke Macken <lmacken <at> redhat.com> writes:
>   ? Updates will automatically get unpushed once they reach a karma of -3

Even from stable? Or just from testing? Unpushing updates from stable tends to 
cause a big mess, so I'm not sure doing that without validation is a good idea.

        Kevin Kofler



From otaylor at redhat.com  Tue Oct 23 04:39:13 2007
From: otaylor at redhat.com (Owen Taylor)
Date: Tue, 23 Oct 2007 00:39:13 -0400
Subject: fontsize in 7.92
In-Reply-To: <45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193092601.17037.1.camel@localhost.localdomain>
	<45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>
Message-ID: <1193114353.4389.2.camel@localhost.localdomain>

On Mon, 2007-10-22 at 20:48 -0400, Ray Strode wrote:
> Hi,
> 
> On 10/22/07, Owen Taylor <otaylor at redhat.com> wrote:
> > > That also means BTW that when you change laptop again your text will
> > > stay the same size regardless of the screen resolution, so you can
> > > invest the time to find good settings you'll keep them a long time.
> >
> > I'd be interested in a pointer to the discussion that led to this policy
> > change.
> >
> http://bugzilla.gnome.org/show_bug.cgi?id=378338
> 
> Federico blogged about it, too:
> 
> http://www.gnome.org/~federico/news-2007-01.html#font-sizes

I've now commented in great detail on the bug explaining a few of the
reasons why I chose to hardcode 96dpi years ago. The situation has
changed a bit (and there would be an argument to up the 96dpi to
something higher), but most of the arguments against using the reported
monitor DPI as the logical font DPI still hold.

- Owen




From seg at haxxed.com  Tue Oct 23 05:24:44 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 23 Oct 2007 00:24:44 -0500
Subject: Multiarch crazyiness
In-Reply-To: <20071022122029.2b39bbea@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion> <471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl> <20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
Message-ID: <1193117084.560.36.camel@localhost>

On Mon, 2007-10-22 at 12:20 -0400, Jesse Keating wrote:
> On those arches, running 64bit code comes at a penalty.  In fact, even
> on x86_64 there is a penalty.  Larger memory overhead.  However on
> x86_64 the extra CPU registers gained by running in x86_64 mode
> outweigh the memory overhead.

Not to mention with x86_64, you can assume the presence of cmov, MMX and
SSE2. Whereas on i386, we're still for the most part compiling for 386s.

In fact I've written patches for OpenJPEG that are specifically designed
to take advantage of gcc's ability to perform if conversions with cmovs,
to eliminate branching. Fedora's i386 misses out on this. :)

Passing function arguments, including structures, in registers is part
of the x86_64 ABI.

x86_64 also has an instruction pointer relative addressing mode,
allowing it to support position independent code without a speed hit.

<3 <3 <3 x86_64
-------------- 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/20071023/aab4ce96/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Oct 23 05:48:34 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 07:48:34 +0200
Subject: fontsize in 7.92
In-Reply-To: <1193114353.4389.2.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193092601.17037.1.camel@localhost.localdomain>
	<45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>
	<1193114353.4389.2.camel@localhost.localdomain>
Message-ID: <1193118514.31078.2.camel@rousalka.dyndns.org>


Le mardi 23 octobre 2007 ? 00:39 -0400, Owen Taylor a ?crit :

> I've now commented in great detail on the bug explaining a few of the
> reasons why I chose to hardcode 96dpi years ago.

And you know I disagreed then, and other distributions opened high
priority bugs to reverse your hack. (mandrake then, ubuntu and sus
today).

> The situation has changed a bit

More than a bit, the high dpi screens you've alway said would never
happen did happen (olpc and openmoko are examples).

> (and there would be an argument to up the 96dpi to
> something higher), but most of the arguments against using the reported
> monitor DPI as the logical font DPI still hold.

As much as before that is not at all.

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

From seg at haxxed.com  Tue Oct 23 06:26:53 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 23 Oct 2007 01:26:53 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471CC6B6.8090503@gmail.com>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl>  <471CC6B6.8090503@gmail.com>
Message-ID: <1193120813.560.53.camel@localhost>

On Mon, 2007-10-22 at 08:50 -0700, Toshio Kuratomi wrote:
> I'd rather not make a decision on something like this until there's a 
> definite piece of software to beat out the corner cases with but my 
> initial leaning is yes.

hatari, which is in Fedora now, ships with a copy of EmuTOS, a GPLed
re-impementation of the Atari ROMs. From what I understand, the hatari
source includes a pre-compiled copy of EmuTOS. I don't think we have
m68k-atari-mint cross compilers in Fedora yet. :)

http://emutos.sourceforge.net/en/

I actually argued the case to move hatari from Dribble to Fedora a while
back, and everyone seemed happy with the situation at the time.
-------------- 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/20071023/12fcc4ad/attachment.sig>

From pertusus at free.fr  Tue Oct 23 06:48:30 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 08:48:30 +0200
Subject: Koji Garbage Collection
In-Reply-To: <20071022214009.3dad166a@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<20071022214009.3dad166a@redhat.com>
Message-ID: <20071023064830.GA2675@free.fr>

On Mon, Oct 22, 2007 at 09:40:09PM -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 21:31:27 -0400
> Dave Jones <davej at redhat.com> wrote:
> 
> > Is there some place I can just scp them from?
> 
> wget -r?  http://koji.fedoraproject.org/packages/kernel/

Is there something similar for scratch builds?

--
Pat



From jspaleta at gmail.com  Tue Oct 23 07:15:51 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 22 Oct 2007 23:15:51 -0800
Subject: Koji Garbage Collection
In-Reply-To: <20071022204127.220d62b8@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
Message-ID: <604aa7910710230015w63ee4287w3832e074e27cd554@mail.gmail.com>

On 10/22/07, Jesse Keating <jkeating at redhat.com> wrote:
> We are about to roll out garbage collection for Koji. Please review the
> document linked below.
>
>    http://fedoraproject.org/wiki/Koji/GarbageCollection

Am I reading this correctly, things tagged as updates and gold are
effectively protected in the policy as outlined?  So anything in the
base fedora repo for F7 and anything that was ever pushed to
updates-released for F7 will not be pruned?

-jef



From bruno at wolff.to  Tue Oct 23 08:38:34 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Oct 2007 03:38:34 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051107194854.GC22799@devserv.devel.redhat.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
Message-ID: <20071023083834.GA4704@wolff.to>

Resurected from the past.

On Mon, Nov 07, 2005 at 14:48:55 -0500,
  Bill Nottingham <notting at redhat.com> wrote:
> Denis Ovsienko (linux at pilot.org.ua) said: 
> > Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it.
> > But those who need more than current initscripts (Ok, network part of
> > initscripts) can provide, are left with rc.local and an editor. Here is a
> > list of what currently /etc/net can do but initscripts can't:
> > - QoS
> > - inter-interface dependencies
> > - configuration profiles
> > - multi-host configuration
> > - routing rules
> > - ifrename support
> > - ifplugd support
> > [...]
> > - EXTENSIBLE DESIGN
> > 
> > I (and other people) find solutions of everyday tasks with /etc/net. I don't
> > want to make others think the way I do, but I need a way to give people choice
> > freedom within FC. This freedom is demanded.
> 
> Generally... network-scripts will eventually go away - things will 
> be moved to a framework involving NetworkManager. Hence, I don't
> believe pulling in an entirely different framework in the interim
> is really worth it.
> 
> Bill

NetworkManager doesn't seem to be evolving toward providing full use of
the network tools (e.g. multiple networks on an interface, bridging, routing,
QoS). It seems to be very oriented toward convenient use in simple cases.

If it is not going to ever give access to the more advanced networking
features, I think there is a reason to replace the current network
configuration scripts with something like etcnet.

Sure you can add commands in rc.local to set up the network properly, but
then ifup and ifdown don't work correctly (in the general case) and neither
does changing between run levels where the network gets turned off or on.

etcnet does seem to be continuing to be developed, but it looks like they
aren't continuing to provide Fedora specific installations.



From kanarip at kanarip.com  Tue Oct 23 08:42:44 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 23 Oct 2007 10:42:44 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
Message-ID: <471DB404.6000608@kanarip.com>

Jon Ciesla wrote:
>> Rahul Sundaram wrote:
>>> Jeroen van Meeuwen wrote:
>>>
>>>
>>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8
>>>> using *just* CDs.
>>> Now we are talking about an actual problem which wasn't clear to me
>>> earlier. So if Fedora Project released regular CD's for this release and
>>> makes live upgrades a supported option from Fedora 9 onwards, do you see
>>> any need for a regular CD variant in the future?
>>>
>> Other then for it's sentimental value, the impressive number of discs
>> for the Everything spin or laptop-in-the-bush cases, there's no real
>> need for CD's. The few people that want a customized install with all
>> kinds of exotic partitioning schemes (or minimal installs) should either
>> be able to create CDs off the DVD iso or get the CDs from any third
>> party providing them.
> 
> A: I have not DVD drives.
> 

But with supported live upgrades you would have the functionality you 
_need_, right? Meanwhile CDs are available from me, for example.

> B: So we'll be providing links to "official" 3rd parties who provide CDs,
> then?
> 

I'm not sure, that isn't up to me. CustomSpins will have a link, so will 
the FAQ but I doubt the Fedora Project would dare to make it anything 
official

> C: By the time I can create a CD set for F-8 from remote mirrors with
> Revisor, F-9 will be at Test3. . .
> 

How's that? Being a Revisor developer I'm interested to know what's up.

Kind regards,

Jeroen van Meeuwen



From kanarip at kanarip.com  Tue Oct 23 08:45:01 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 23 Oct 2007 10:45:01 +0200
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <p04330102c342779f6e55@[192.168.123.162]>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
	<p04330102c342779f6e55@[192.168.123.162]>
Message-ID: <471DB48D.6080106@kanarip.com>

Tony Nelson wrote:
> At 7:55 AM -0500 10/22/07, Jon Ciesla wrote:
>>> Rahul Sundaram wrote:
>>>> Jeroen van Meeuwen wrote:
>>>>
>>>>
>>>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8
>>>>> using *just* CDs.
>>>> Now we are talking about an actual problem which wasn't clear to me
>>>> earlier. So if Fedora Project released regular CD's for this release and
>>>> makes live upgrades a supported option from Fedora 9 onwards, do you see
>>>> any need for a regular CD variant in the future?
>>>>
>>> Other then for it's sentimental value, the impressive number of discs
>>> for the Everything spin or laptop-in-the-bush cases, there's no real
>>> need for CD's. The few people that want a customized install with all
>>> kinds of exotic partitioning schemes (or minimal installs) should either
>>> be able to create CDs off the DVD iso or get the CDs from any third
>>> party providing them.
>> A: I have not DVD drives.
>  ...
> 
> It could be explained better, but "askmethod" allows installation of a DVD
> image with only a (or even no) CD drive, as long as the DVD image is made
> available during the install.  I keep mine on C: (sda1,/), but a USB key or
> hard drive would also work.  (I have a DVD drive, and I boot the DVD, but
> one can just burn the RescueCD image that comes with the DVD, at least with
> the torrent).

That's oh so true but askmethod is a long way from "Next, Next, Finish" 
which is the way you'd want to able to tell anyone when they ask "How to 
install Fedora".

Kind regards,

Jeroen van Meeuwen



From rjones at redhat.com  Tue Oct 23 09:04:44 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 10:04:44 +0100
Subject: Multiarch crazyiness
In-Reply-To: <20071022155624.39186440@redhat.com>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com>	<1193062185.32582.24.camel@perihelion>	<471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl>	<20071022110424.3b2395e7@redhat.com>	<1193068985.11781.14.camel@vincent52.localdomain>	<20071022122029.2b39bbea@redhat.com>	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
Message-ID: <471DB92C.7060608@redhat.com>

Jesse Keating wrote:
> On Mon, 22 Oct 2007 15:56:38 -0400
> Matthew Saltzman <mjs at CLEMSON.EDU> wrote:
> 
>> So on those archs one would want a 64-bit kernel and 32-bit apps,
>> except for large-memory programs or those needing 64/128-bit
>> numerical types (self-developed code, for example)?
> 
> Yes.
> 
>> Is that how it's actually handled by the installer?
> 
> We prefer 32bit on those platforms.

That's wrong for OCaml programs, since strings in 32 bit OCaml programs 
are limited to 16 MB (but effectively unlimited on 64 bit platforms). 
So 64 bit should always be preferred.  Having said that we're still 
waiting for someone to port the OCaml compiler to Linux/ppc64 ...

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/76512bae/attachment.bin>

From rjones at redhat.com  Tue Oct 23 09:12:56 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 10:12:56 +0100
Subject: "multiarch conflicts in ..." bugs
Message-ID: <471DBB18.4080607@redhat.com>

I've had the following bug filed at the end of last week:

https://bugzilla.redhat.com/show_bug.cgi?id=342721

and I've read:

http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

but I've still no idea what I need to do to fix the bug.  Can someone 
explain it in simpler terms?

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/33ac1c60/attachment.bin>

From twaugh at redhat.com  Tue Oct 23 09:35:43 2007
From: twaugh at redhat.com (Tim Waugh)
Date: Tue, 23 Oct 2007 10:35:43 +0100
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <471DBB18.4080607@redhat.com>
References: <471DBB18.4080607@redhat.com>
Message-ID: <1193132143.4372.7.camel@cyberelk.elk>

On Tue, 2007-10-23 at 10:12 +0100, Richard W.M. Jones wrote:
> but I've still no idea what I need to do to fix the bug.  Can someone 
> explain it in simpler terms?

I've added two points to that wiki page:

1. when files are gzipped at build time, use -n
2. if you aren't sure what the problem is for architecture-independent
files, extract the files from the packages and compare them.

Sorry, I don't know exactly what the problem is in this case, but a file
comparison ought to shed some light on it.

Tim.
*/

-------------- 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/20071023/902e5aa3/attachment.sig>

From ml at deadbabylon.de  Tue Oct 23 09:43:19 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 23 Oct 2007 11:43:19 +0200
Subject: F8+KDE+PulseAudio
In-Reply-To: <1192738003.2843.34.camel@cookie.hadess.net>
References: <ff8coq$57c$2@ger.gmane.org> <20071018155303.591a9918@redhat.com>
	<1192738003.2843.34.camel@cookie.hadess.net>
Message-ID: <200710231143.25027.ml@deadbabylon.de>

Am Do 18.Oktober 2007 schrieb Bastien Nocera:
> Frankly, we should kill the pref, and always start Pulseaudio. In the
> meanwhile, it would be better if KDE came up with something that just
> starts it for KDE.

Just a notice to that: If pulseaudio is only started in a full session of KDE 
(eg. through /etc/kde/env/pulseaudio.sh) KDE programs that will be started 
outside KDE when pulseaudio isn't running (eg. noatun in a *box) won't have 
sound.
For the short term this works but IMHO should be mentioned in the release 
notes then.

Sebastian

-------------- 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/20071023/88d22ddf/attachment.sig>

From rjones at redhat.com  Tue Oct 23 09:49:12 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 10:49:12 +0100
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <1193132143.4372.7.camel@cyberelk.elk>
References: <471DBB18.4080607@redhat.com>
	<1193132143.4372.7.camel@cyberelk.elk>
Message-ID: <471DC398.6090304@redhat.com>

Tim Waugh wrote:
> On Tue, 2007-10-23 at 10:12 +0100, Richard W.M. Jones wrote:
>> but I've still no idea what I need to do to fix the bug.  Can someone 
>> explain it in simpler terms?
> 
> I've added two points to that wiki page:
> 
> 1. when files are gzipped at build time, use -n
> 2. if you aren't sure what the problem is for architecture-independent
> files, extract the files from the packages and compare them.
> 
> Sorry, I don't know exactly what the problem is in this case, but a file
> comparison ought to shed some light on it.

I get:

$ diff -aqr i386 x86_64
Files i386/usr/bin/camlp4 and x86_64/usr/bin/camlp4 differ
Files i386/usr/bin/camlp4boot and x86_64/usr/bin/camlp4boot differ
Files i386/usr/bin/camlp4o and x86_64/usr/bin/camlp4o differ
Files i386/usr/bin/camlp4of and x86_64/usr/bin/camlp4of differ
Files i386/usr/bin/camlp4of.opt and x86_64/usr/bin/camlp4of.opt differ
Files i386/usr/bin/camlp4oof and x86_64/usr/bin/camlp4oof differ
Files i386/usr/bin/camlp4oof.opt and x86_64/usr/bin/camlp4oof.opt differ
Files i386/usr/bin/camlp4o.opt and x86_64/usr/bin/camlp4o.opt differ
Files i386/usr/bin/camlp4orf and x86_64/usr/bin/camlp4orf differ
Files i386/usr/bin/camlp4orf.opt and x86_64/usr/bin/camlp4orf.opt differ
Files i386/usr/bin/camlp4r and x86_64/usr/bin/camlp4r differ
Files i386/usr/bin/camlp4rf and x86_64/usr/bin/camlp4rf differ
Files i386/usr/bin/camlp4rf.opt and x86_64/usr/bin/camlp4rf.opt differ
Files i386/usr/bin/camlp4r.opt and x86_64/usr/bin/camlp4r.opt differ
Files i386/usr/bin/mkcamlp4 and x86_64/usr/bin/mkcamlp4 differ
Only in i386/usr: lib
Only in x86_64/usr: lib64

This is all to be expected since they are binary files compiled for 
different architectures.

Still not sure what I'm supposed to do.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/9d98032d/attachment.bin>

From pertusus at free.fr  Tue Oct 23 10:19:15 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 12:19:15 +0200
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <471DBB18.4080607@redhat.com>
References: <471DBB18.4080607@redhat.com>
Message-ID: <20071023101914.GE2675@free.fr>

On Tue, Oct 23, 2007 at 10:12:56AM +0100, Richard W.M. Jones wrote:
> I've had the following bug filed at the end of last week:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=342721
>
> and I've read:
>
> http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
>
> but I've still no idea what I need to do to fix the bug.  Can someone 
> explain it in simpler terms?

Looks like there is a bug somewhere since some files look like ELF
files like /usr/bin/camlp4oof.opt? An ocaml weirdness or a bug in rpm?
The ocamlrun scripts also look like binary (arch dependent?) stuff
so it is a logical that there is conflict. It certainly requires
something to be done at the rpm level, but I am far from being an expert
on those issues.

--
Pat



From nicolas.mailhot at laposte.net  Tue Oct 23 10:44:45 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 12:44:45 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <3835.192.54.193.51.1193136285.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 00:59, Jason L Tibbitts III a ?crit :
>>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
>
> TC> I'm with Toshio on this.
>
> Which would then lead to the analogous corner case of something that's
> open-source but expects to be compiled with a non-free compiler or one
> that's not in Fedora for some reason.
>
> There's at least one piece of free (GPL) software which we can't
> include because it requires some commercial BASIC compiler.

Then that's not true free software, and has no place in Fedora. You
can package it in some third-party repo in the hope a free BASIC
compiler emerges someday (that's how java was done till gcj/classpath
matured and SUN liberated Java)

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Oct 23 10:47:29 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 12:47:29 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <18703.192.54.193.51.1193136449.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 01:15, Bastien Nocera a ?crit :

> 99% of the time, the driver and firmware[1] are closely knit. Try
> upgrade the firmware of a QLogic card without the driver following,
> and watch bad things happen.

have the driver request-firmware a different firmware id each time it
breaks compat with old firmware, and package every firmware version a
kernel in a given release may need in a single firmware package

Problem solved.

-- 
Nicolas Mailhot



From rjones at redhat.com  Tue Oct 23 10:48:10 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 11:48:10 +0100
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <20071023101914.GE2675@free.fr>
References: <471DBB18.4080607@redhat.com> <20071023101914.GE2675@free.fr>
Message-ID: <471DD16A.4010500@redhat.com>

Patrice Dumas wrote:
> On Tue, Oct 23, 2007 at 10:12:56AM +0100, Richard W.M. Jones wrote:
>> I've had the following bug filed at the end of last week:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=342721
>>
>> and I've read:
>>
>> http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
>>
>> but I've still no idea what I need to do to fix the bug.  Can someone 
>> explain it in simpler terms?
> 
> Looks like there is a bug somewhere since some files look like ELF
> files like /usr/bin/camlp4oof.opt? An ocaml weirdness or a bug in rpm?

OK, I think I get it now.

All the *.opt files are native ELF binaries.  They're compiled by the 
OCaml compiler (it does its own code generation) and linked by ld, or 
rather by gcc used as a wrapper around ld.

$ file usr/bin/camlp4oof.opt
usr/bin/camlp4oof.opt: ELF 64-bit LSB executable, x86-64, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

> The ocamlrun scripts also look like binary (arch dependent?) stuff
> so it is a logical that there is conflict. It certainly requires
> something to be done at the rpm level, but I am far from being an expert
> on those issues.

The files which begin with #!/usr/bin/ocamlrun are bytecode files.  Even 
though it's called "bytecode" it isn't portable between architectures. 
It's not like Java bytecode.  So consider these to be like binaries too.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/858cb4bf/attachment.bin>

From nicolas.mailhot at laposte.net  Tue Oct 23 10:53:12 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 12:53:12 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 02:39, Ian Chapman a ?crit :
> Adam Jackson wrote:
>
>> This is not the same thing as a firmware, because firmware doesn't
>> execute on the host CPU.  Practically speaking, that's where we draw
>> the
>> line.
>
> This is not meant as a facetious question but how does this pan out
> with
> regards to emulators? Most of which require some sort of firmware
> which
> runs on the 'virtual' CPU which is technically speaking running on the
> real CPU, perhaps even more so in cases where JIT compilation is used.

That probably means you need to package "firmware" building tools in
fedora and use them to build the "firmware" source in the "firmware"
package. And we may have been lax on the subject in the past for games
but as the OP message shows it's a quick path to shipping pre-built
closed java or.Net binaries and effectively having a non-free system.

Bootstrapping may be needed as in every language we've merged.

-- 
Nicolas Mailhot



From lemenkov at gmail.com  Tue Oct 23 10:56:47 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Tue, 23 Oct 2007 14:56:47 +0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>
References: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>
Message-ID: <adf480660710230356u63369178q74a0f9380358be72@mail.gmail.com>

2007/10/23, Nicolas Mailhot <nicolas.mailhot at laposte.net>:

> That probably means you need to package "firmware" building tools in
> fedora and use them to build the "firmware" source in the "firmware"
> package. And we may have been lax on the subject in the past for games
> but as the OP message shows it's a quick path to shipping pre-built
> closed java or.Net binaries and effectively having a non-free system.

Firmware and ROMs for virtual machines is the same thing as graphics
and music for games. We don't package them from sources but we package
existing *prebuilt* graphics/music/maps /etc.
-- 
With best regards!



From nicolas.mailhot at laposte.net  Tue Oct 23 10:57:09 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 12:57:09 +0200 (CEST)
Subject: fontsize in 7.92
Message-ID: <7891.192.54.193.51.1193137029.squirrel@rousalka.dyndns.org>


BTW: please move font-related discussions to the fonts list, or at
least CC it

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Oct 23 11:08:13 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 13:08:13 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 12:56, Peter Lemenkov a ?crit :
> 2007/10/23, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>> That probably means you need to package "firmware" building tools in
>> fedora and use them to build the "firmware" source in the "firmware"
>> package. And we may have been lax on the subject in the past for
>> games
>> but as the OP message shows it's a quick path to shipping pre-built
>> closed java or.Net binaries and effectively having a non-free
>> system.
>
> Firmware and ROMs for virtual machines is the same thing as graphics
> and music for games.

No it's not. One is code the other content.

> We don't package them from sources but we package
> existing *prebuilt* graphics/music/maps /etc.

This is IMHO a misinterpretation of Fedora guidelines, and leads to
shipping (for example) a pre-built Eclipse or any proprietary
Java/.Net app because they're "bytecode" executed in "virtual
machines"

It's clearly more convenient for you not to have to untangle ROM build
systems but it's not what Fedora is supposed to be.

Regards,

-- 
Nicolas Mailhot



From alan at redhat.com  Tue Oct 23 11:14:49 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 23 Oct 2007 07:14:49 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <ufa640yah7q.fsf@epithumia.math.uh.edu>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl> <471CC6B6.8090503@gmail.com>
	<1193085056.22958.23.camel@localhost.localdomain>
	<ufa640yah7q.fsf@epithumia.math.uh.edu>
Message-ID: <20071023111449.GA12433@devserv.devel.redhat.com>

On Mon, Oct 22, 2007 at 05:59:37PM -0500, Jason L Tibbitts III wrote:
> Which would then lead to the analogous corner case of something that's
> open-source but expects to be compiled with a non-free compiler or one
> that's not in Fedora for some reason.

Like java was

> There's at least one piece of free (GPL) software which we can't
> include because it requires some commercial BASIC compiler.

Can it be moved to one of the free basics ?



From jkeating at redhat.com  Tue Oct 23 11:19:29 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 07:19:29 -0400
Subject: Multiarch crazyiness
In-Reply-To: <471DB92C.7060608@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com> <471DB92C.7060608@redhat.com>
Message-ID: <20071023071929.6f94234c@redhat.com>

On Tue, 23 Oct 2007 10:04:44 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:

> That's wrong for OCaml programs, since strings in 32 bit OCaml
> programs are limited to 16 MB (but effectively unlimited on 64 bit
> platforms). So 64 bit should always be preferred.  Having said that
> we're still waiting for someone to port the OCaml compiler to
> Linux/ppc64 ...

Ugh.  You would have something different wouldn't you :/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/d1bf1991/attachment.sig>

From lemenkov at gmail.com  Tue Oct 23 11:25:26 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Tue, 23 Oct 2007 15:25:26 +0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
Message-ID: <adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>

2007/10/23, Nicolas Mailhot <nicolas.mailhot at laposte.net>:

> > Firmware and ROMs for virtual machines is the same thing as graphics
> > and music for games.

> No it's not. One is code the other content.

Frankly speaking content is the code for virtual machine too. Imagine
a jpeg-vewer as virtual machine, which need ROMs (jpeg-images) for
work.

We need to distinguish between *real* code which natively executes on
CPU and any other binary content which not executes natively. Win32
executables, ROMs, JARs are IMHO definitely falls into this category
(content). As pictures, music and text-files they do not runs on CPU
directly.

> > We don't package them from sources but we package
> > existing *prebuilt* graphics/music/maps /etc.

> This is IMHO a misinterpretation of Fedora guidelines,

I don't see any misinterpretations here. Binary code is binary code
(which may runs in CPU), otherwise its a content like pictures or game
maps.

> and leads to
> shipping (for example) a pre-built Eclipse or any proprietary
> Java/.Net app because they're "bytecode" executed in "virtual
> machines"

I don't see any problems here.
-- 
With best regards!



From rjones at redhat.com  Tue Oct 23 11:29:51 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 12:29:51 +0100
Subject: Multiarch crazyiness
In-Reply-To: <20071023071929.6f94234c@redhat.com>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com>	<1193062185.32582.24.camel@perihelion>	<471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl>	<20071022110424.3b2395e7@redhat.com>	<1193068985.11781.14.camel@vincent52.localdomain>	<20071022122029.2b39bbea@redhat.com>	<1193082998.17860.7.camel@vincent52.localdomain>	<20071022155624.39186440@redhat.com>
	<471DB92C.7060608@redhat.com> <20071023071929.6f94234c@redhat.com>
Message-ID: <471DDB2F.9050602@redhat.com>

Jesse Keating wrote:
> On Tue, 23 Oct 2007 10:04:44 +0100
> "Richard W.M. Jones" <rjones at redhat.com> wrote:
> 
>> That's wrong for OCaml programs, since strings in 32 bit OCaml
>> programs are limited to 16 MB (but effectively unlimited on 64 bit
>> platforms). So 64 bit should always be preferred.  Having said that
>> we're still waiting for someone to port the OCaml compiler to
>> Linux/ppc64 ...
> 
> Ugh.  You would have something different wouldn't you :/

Heh, right.  But I bet this isn't the only case where 64 bit would 
always be preferred.  For example libraries which implement lightweight 
threading often have seriously low limits on the number of threads 
supported unless you use 64 bits, because each stack needs a sizable 
piece of virtual address space (not real memory though).  I don't think 
you can make a hard rule that 32 bit userspace is always preferred.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/1e1fa219/attachment.bin>

From j.w.r.degoede at hhs.nl  Tue Oct 23 11:38:42 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 23 Oct 2007 13:38:42 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <20071023111449.GA12433@devserv.devel.redhat.com>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>	<471C64E5.4070908@hhs.nl>	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>	<471C6810.5070200@hhs.nl>
	<471CC6B6.8090503@gmail.com>	<1193085056.22958.23.camel@localhost.localdomain>	<ufa640yah7q.fsf@epithumia.math.uh.edu>
	<20071023111449.GA12433@devserv.devel.redhat.com>
Message-ID: <471DDD42.3030403@hhs.nl>

Alan Cox wrote:
> On Mon, Oct 22, 2007 at 05:59:37PM -0500, Jason L Tibbitts III wrote:
>> Which would then lead to the analogous corner case of something that's
>> open-source but expects to be compiled with a non-free compiler or one
>> that's not in Fedora for some reason.
> 
> Like java was
> 
>> There's at least one piece of free (GPL) software which we can't
>> include because it requires some commercial BASIC compiler.
> 
> Can it be moved to one of the free basics ?
> 

Probably not, as it uses a pretty advanced basic dialect, but it might be worth 
a shot. Anyone got a list of those free basics handy?

Regards,

Hans



From buildsys at redhat.com  Tue Oct 23 11:44:26 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 23 Oct 2007 07:44:26 -0400
Subject: rawhide report: 20071023 changes
Message-ID: <200710231144.l9NBiQ6A022040@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-1:0.7.0-0.3.svn2995.fc8
--------------------------------------
* Mon Oct 22 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2995
- Add Dynamic WEP as a supported authentication/security option

* Sun Oct 21 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2994
- Re-enable "Connect to other network"
- Switch to new GUI bits for wireless security config and password entry

* Tue Oct 16 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2983
- Add rfkill functionality
- Fix applet crash when choosing wired networks from the menu

anaconda-11.3.0.44-1
--------------------
* Mon Oct 22 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.44-1
- Fix warning about arch changes on upgrade (#222424)
- Fix phantom kernels on upgrade (#325871)
- Add some kde packages to the multilib upgrade blacklist (#339981)
- Require policycoreutils (clumens, #343861)
- Fix typo leading to traceback (clumens)
- Fix processing of ks=nfs (clumens)
- Memory freeing cleanups (pjones)

booty-0.91-1.fc8
----------------
* Mon Oct 22 2007 Jeremy Katz <katzj at redhat.com> 0.91-1
- fix up an upgrade traceback that showed up in the process of fixing #325871

checkstyle-0:4.1-4jpp.2.fc8
---------------------------
* Mon Oct 22 2007 Deepak Bhole <dbhole at redhat.com> - 0:4.1-4jpp.2
- Resolve bz#332801. Remove java < 1.5.0 requirement
- Set failonerror=false for xdoc generation, due to a sinjdoc problems

dvgrab-3.0-2.fc8
----------------
* Mon Oct 22 2007 Jarod Wilson <jwilson at redhat.com> - 3.0-2
- Fix segfault on cleanup (#331271)
- fix pipe output in conjunction with file capture
- fix hang at end of reading from stdin
- fix potential data loss due to short writes

fedora-release-8-2
------------------
* Fri Oct 19 2007 Jesse Keating <jkeating at redhat.com> - 8-2
- Disable development, enable release/updates.

* Fri Oct 19 2007 Jesse Keating <jkeating at redhat.com> - 8-1
- Build for Fedora 8, add release name, update compose configs

fedora-release-notes-8.0.0-1
----------------------------
* Mon Oct 22 2007 Paul W. Frields <stickster at gmail.com> - 8.0.0-1
- Update for final release

firstboot-1.4.39-1.fc8
----------------------
* Mon Oct 22 2007 Chris Lumens <clumens at redhat.com> 1.4.39-1
- Remove obsolete Norwegian translation (#332111).

gnome-launch-box-0.4-5.fc8
--------------------------
* Sun Oct 21 2007 - Bastien Nocera <bnocera at redhat.com> - 0.4-5
- Fix autolauncher missing a description (#344381)

gtk2-2.12.1-3.fc8
-----------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-4
- Fix a crash in gnome-system-log (#321701)

kernel-2.6.23.1-30.fc8
----------------------
* Mon Oct 22 2007 Adam Jackson <ajax at redhat.com>
- Add e1000.eeprom_bad_csum_allow

* Sun Oct 21 2007 Jarod Wilson <jwilson at redhat.com>
- Log warning about unimplemented isochronous I/O on
  firewire ohci 1.0 controllers (bz #344851)

* Fri Oct 19 2007 John W. Linville <linville at redhat.com>
- iwl4965-base.c: fix off-by-one errors
- ipw2100: send WEXT scan events
- rt2x00: Add new rt73usb USB ID
- zd1211rw, fix oops when ejecting install media
- rt2x00: Fix residual check in PLCP calculations.
- rtl8187: Fix more frag bit checking, rts duration calc
- iwlwifi: set correct base rate for A band in rs_dbgfs_set_mcs
- iwlwifi: Fix rate setting in probe request for HW scan

knetworkmanager-0.2-0.5.svn20071022.fc8
---------------------------------------
* Mon Oct 22 2007 Dennis Gilmore <dennis at ausil.us> - 0.2-0.5
- we still need to BR desktop-file-utils

* Mon Oct 22 2007 Dennis Gilmore <dennis at ausil.us> - 0.2-0.4
- put in wrapper script to call nm-applet

* Sat Sep 29 2007 Dennis Gilmore <dennis at ausil.us> - 0.2-0.3.svn20070929
- update to 20070929
- should somewhat work with nm-0.7
- fix BR's

krb5-auth-dialog-0.7-5.fc8
--------------------------
* Mon Oct 22 2007 Christopher Aillon <caillon at redhat.com> - 0.7-5
- Don't start multiple times in KDE (#344991)

libwnck-2.20.1-3.fc8
--------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-3
- Fix a small oversight in the previous patch

* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Don't crash if the X resource extension is missing (#343881)

openoffice.org-1:2.3.0-6.5.fc8
------------------------------
* Fri Oct 19 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.5
- Resolves: rhbz#338701 fix openoffice.org.ooo82608.vcl.gtkbadfree.patch

* Tue Oct 16 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.4
- Resolves: rhbz#333201 dangling symlinks
- Resolves: rhbz#334841 fix "all files" glob in in mail merge picker
- Resolves: ooo#82671 print crash

* Fri Oct 12 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.3
- reenable prelink-optimized launchers
- rhbz#326161 make code compiled with icedtea compatible with 1.5.0 so libgcj
  can still be selected as a jvm
- add openoffice.org-2.3.0.ooo53885.raiseannotationpriority.sw.patch

policycoreutils-2.0.31-7.fc8
----------------------------
* Fri Oct 19 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-7
- Fix consolekit link to selinux-polgengui

* Thu Oct 18 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-6
- Fix the generation templates

sabayon-2.20.1-4.fc8
--------------------
* Mon Oct 22 2007 Dan Walsh <dwalsh at redhat.com> - 2.20.1-4
- Break out sabayon-apply from sabayon

selinux-policy-3.0.8-30.fc8
---------------------------
* Mon Oct 22 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-30
- Allow XServer to read /proc/self/cmdline
- Fix unconfined cron jobs
- Allow fetchmail to transition to procmail
- Fixes for hald_mac
- Allow system_mail to transition to exim
- Allow tftpd to upload files
- Allow xdm to manage unconfined_tmp
- Allow udef to read alsa config
- Fix xguest to be able to connect to sound port

udev-116-3.fc8
--------------
* Thu Oct 18 2007 Harald Hoyer <harald at redhat.com> 116-3
- fixed preun chkconfig
- added /sbin path to chkconfig in post section 
- patch: do not generate net rules for type > 256
- fixes glitches appearing in bz#323991

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From P at draigBrady.com  Tue Oct 23 11:47:20 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 23 Oct 2007 12:47:20 +0100
Subject: fontsize in 7.92
In-Reply-To: <1193114353.4389.2.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>	<1193073308.28655.5.camel@rousalka.dyndns.org>	<1193112112.3773.4.camel@localhost.localdomain>	<1193091883.4605.13.camel@rousalka.dyndns.org>	<1193092601.17037.1.camel@localhost.localdomain>	<45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>
	<1193114353.4389.2.camel@localhost.localdomain>
Message-ID: <471DDF48.7020601@draigBrady.com>

Just a data point. I did a complete fresh install
of gutsy beta a few weeks ago and had to spend ages
tweaking the fonts. The defaults were horrendous (too large/thin).

Note the DPI for my monitor was apparently detected correctly:

xdpyinfo | grep -F resolution
  resolution:    112x112 dots per inch

P?draig.



From nicolas.mailhot at laposte.net  Tue Oct 23 11:51:05 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 13:51:05 +0200 (CEST)
Subject: Some thoughts about firmware inclusion.
Message-ID: <13441.192.54.193.51.1193140265.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 13:25, Peter Lemenkov a ?crit :
> 2007/10/23, Nicolas Mailhot <nicolas.mailhot at laposte.net>:

>> and leads to
>> shipping (for example) a pre-built Eclipse or any proprietary
>> Java/.Net app because they're "bytecode" executed in "virtual
>> machines"
>
> I don't see any problems here.

Then you've chosen the wrong distribution

Regards,

-- 
Nicolas Mailhot



From jkeating at redhat.com  Tue Oct 23 11:48:46 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 07:48:46 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071023064830.GA2675@free.fr>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<20071022214009.3dad166a@redhat.com>
	<20071023064830.GA2675@free.fr>
Message-ID: <20071023074846.55485d36@redhat.com>

On Tue, 23 Oct 2007 08:48:30 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> Is there something similar for scratch builds?

http://koji.fedoraproject.org/scratch/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/c2db9db6/attachment.sig>

From jkeating at redhat.com  Tue Oct 23 11:50:23 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 07:50:23 -0400
Subject: Koji Garbage Collection
In-Reply-To: <604aa7910710230015w63ee4287w3832e074e27cd554@mail.gmail.com>
References: <20071022204127.220d62b8@redhat.com>
	<604aa7910710230015w63ee4287w3832e074e27cd554@mail.gmail.com>
Message-ID: <20071023075023.460ff780@redhat.com>

On Mon, 22 Oct 2007 23:15:51 -0800
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> Am I reading this correctly, things tagged as updates and gold are
> effectively protected in the policy as outlined?  So anything in the
> base fedora repo for F7 and anything that was ever pushed to
> updates-released for F7 will not be pruned?

That is correct.  However if we need more pruning we may limit keeping
of pushed updates to the latest 3 or the last month or some combo.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/a50ede63/attachment.sig>

From buildsys at fedoraproject.org  Tue Oct 23 11:52:50 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue, 23 Oct 2007 07:52:50 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-23
Message-ID: <20071023115250.7B92D15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 16

    bugzilla-3.0.2-1.fc6
    climm-0.6.1-1.fc6
    ctapi-cyberjack-3.0.5-1.fc6
    dkms-2.0.17.5-1.fc6
    fwfstab-0.02-2.fc6
    perl-Text-Aspell-0.09-1.fc6
NEW phasex-0.11.1-4.fc6 : PHASEX -- Phase Harmonic Advanced Synthesis EXperiment
    phpMyAdmin-2.11.1.2-1.fc6
    piklab-0.15.0-1.fc6
    poker-network-1.2.0-3.fc6
    poker2d-1.2.0-3.fc6
NEW PySolFC-1.1-3.fc6 : A collection of solitare card games
NEW PySolFC-music-4.40-2 : Music for PySolFC
    rkward-0.4.8-2.fc6
NEW tcputils-0.6.2-2.fc6 : Utilities for TCP programming in shell-scripts
    xcircuit-3.4.27-1.fc6


Changes in Fedora Extras 6: 


bugzilla-3.0.2-1.fc6
--------------------
* Mon Oct 22 2007 John Berninger <john at ncphotography dot com> - 3.0.2-1
- updates to requires and httpd conf for BZ's 279961, 295861, 339531

climm-0.6.1-1.fc6
-----------------
* Mon Oct 22 2007 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 0.6.1-1
- Update to upstream
- Removed glibc patch (fix included upstream)

ctapi-cyberjack-3.0.5-1.fc6
---------------------------
* Sat Oct 20 2007 Frank B?ttner <frank-buettner at gmx.net> - 3.0.5-1
- update to 3.0.5
 - fix project URL
 - fix license

dkms-2.0.17.5-1.fc6
-------------------
* Wed Oct 10 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.17.5
- call udevtrigger if we install a module for the currently running kernel
- uninstall from /extra before DEST_MODULE_LOCATION (Red Hat BZ#264981)
- Run depmod after uninstall

* Wed Sep 19 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.17.4
- upgrade to latest upstream

* Wed Jun 20 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.16.2
- updated for Ubuntu support, other bugfixes.

* Tue Mar 20 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.16.1
- spec file cleanups per re-review in Fedora
- add bash completion, rpmbuild check, pinit, pass-arch patches from
  Mandriva.  These are generic.  The other Mandriva patches appear to
  be distro-specific.
- Look for /etc/sysconfig/module-init-tools to get some values.

* Tue Feb 27 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.16
- fix override_dest_module_location() for historical distro versions
- don't run weak-modules if it doesn't exist

* Mon Feb 26 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.15
- release with no changes

* Fri Feb 23 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.14.1
- After upgrading from older DKMS versions to 2.0.14, any previously
  installed modules wouldn't show status properly, and wouldn't
  uninstall properly, due to the new policy of using /extras/ and
  /updates/.  Needed to take that into account and look in both places.
- SuSE puts weak-modules in /usr/lib/module-init-tools not /sbin.

* Thu Feb 22 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.14
- RHEL5 weak module status report fixed

* Mon Feb 19 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.13.2
- RHEL5 weak module recognition with new state installed-weak
- autoinstaller recognizes installed-weak and doesn't rebuild
- RHEL5 and SLES10 and higher weak module code expects modules to go
  into /lib/modules/$kern/{extra,updates} respectively, so force that.

* Mon Feb 05 2007 Matt Domsch <Matt_Domsch at dell.com>
- patch from http://qa.mandriva.com/show_bug.cgi?id=27985 assigns new
  modprobe.conf alias ordinals starting at zero.

* Fri Jan 12 2007 Matt Domsch <Matt_Domsch at dell.com> 2.0.13.1
- properly create driver disks for Fedora Core 6 and RHEL5
- make .iso, .tar, and floppy .img driver disks for Red Hat and SuSE
- set CLEAN properly even if MAKE[] isn't set.
- fix install.sh buglet installing the manpage

* Thu Jun 29 2006 Matt Domsch <Matt_Domsch at dell.com>
- cleanups to match Fedora Extras spec file

* Thu Jun 29 2006 Matt Domsch <Matt_Domsch at dell.com> 2.0.13
- bump to 2.0.13

fwfstab-0.02-2.fc6
------------------
* Sun Oct 21 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.02-2
- Add pyparted and kudzu requires

perl-Text-Aspell-0.09-1.fc6
---------------------------
* Fri Oct 12 2007 Jerry James <loganjerry at gmail.com> - 0.09-1
- Update to 0.09
- Clarify license

phasex-0.11.1-4.fc6
-------------------
* Mon Oct 22 2007 Anthony Green <green at redhat.com> - 0.11.1-4
- Fix tagging problem.

* Thu Oct 18 2007 Parag AN <panemade at gmail.com> - 0.11.1-3
- Really delete extra .desktop file after installation.

* Tue Oct 16 2007 Anthony Green <green at redhat.com> - 0.11.1-2
- Delete extra .desktop file after installation.
- Clean up .desktop file categories.

* Tue Oct 16 2007 Anthony Green <green at redhat.com> - 0.11.1-1
- First Fedora build.

phpMyAdmin-2.11.1.2-1.fc6
-------------------------
* Mon Oct 22 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.1.2-1
* upstream released new version

piklab-0.15.0-1.fc6
-------------------
* Mon Oct 22 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.15.0-1
- New upstream version
  - Update %patch2

poker-network-1.2.0-3.fc6
-------------------------
* Sun Oct 21 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-3
- Remove devel subpackage and move to poker2d

poker2d-1.2.0-3.fc6
-------------------
* Mon Oct 22 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-3
- Fix up BuildRequires

* Sun Oct 21 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-2
- Move pkgconfig file into this spec since it is arch specific
- Add patch to properly handle libexec

PySolFC-1.1-3.fc6
-----------------
* Mon Oct 22 2007 Stewart Adam <s.adam at diffingo.com> 1.1-3
- s/python-imageing-tk/python-imaging-tk/

* Fri Oct 19 2007 Stewart Adam <s.adam at diffingo.com> 1.1-2
- Add Requires: python-imageing-tk

* Sat Sep 29 2007 Stewart Adam <s.adam at diffingo.com> 1.1-1
- Initial release

PySolFC-music-4.40-2
--------------------
* Mon Oct 22 2007 Stewart Adam <s.adam at diffingo.com> 4.40-2
- This package won't be rebuilt often; removing dist tag.
- Fix description

* Sat Sep 29 2007 Stewart Adam <s.adam at diffingo.com> 4.40-1
- Initial release

rkward-0.4.8-2.fc6
------------------
* Mon Oct 22 2007 Pingou <pingoufc4 at yahoo.fr> 0.4.8-2
- Problem in CVS

* Mon Oct 22 2007 Pingou <pingoufc4 at yahoo.fr> 0.4.8-1
- Update to 0.4.8 and R 2.6

tcputils-0.6.2-2.fc6
--------------------
* Fri Oct 19 2007 Allisson Azevedo <allisson at gmail.com> 0.6.2-2
- Keep timestamps on man files

* Fri Oct 19 2007 Allisson Azevedo <allisson at gmail.com> 0.6.2-1
- Initial RPM release

xcircuit-3.4.27-1.fc6
---------------------
* Sun Oct 21 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.27-1
- new upstream release
- added coreutils and gtk as requires: #339771

* Fri Aug 24 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-23
- mass rebuild for fedora 8 - ppc

* Sun Aug 12 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-22
- fix for x86_64

* Sun Aug 12 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-21
- dump release

* Wed Aug 08 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-20
- patch xcircuit-3.4-memset.patch: Found memset with swapped arguments

* Mon Feb 26 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-19
- Rebuilt for rawhide

* Wed Jan 31 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.26-18
- Fixed presence in Gnome menu



From j.w.r.degoede at hhs.nl  Tue Oct 23 11:50:41 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 23 Oct 2007 13:50:41 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>
References: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>
Message-ID: <471DE011.3050902@hhs.nl>

Nicolas Mailhot wrote:
> Le Mar 23 octobre 2007 02:39, Ian Chapman a ?crit :
>> Adam Jackson wrote:
>>
>>> This is not the same thing as a firmware, because firmware doesn't
>>> execute on the host CPU.  Practically speaking, that's where we draw
>>> the
>>> line.
>> This is not meant as a facetious question but how does this pan out
>> with
>> regards to emulators? Most of which require some sort of firmware
>> which
>> runs on the 'virtual' CPU which is technically speaking running on the
>> real CPU, perhaps even more so in cases where JIT compilation is used.
> 
> That probably means you need to package "firmware" building tools in
> fedora and use them to build the "firmware" source in the "firmware"
> package. And we may have been lax on the subject in the past for games
> but as the OP message shows it's a quick path to shipping pre-built
> closed java or.Net binaries and effectively having a non-free system.
> 
> Bootstrapping may be needed as in every language we've merged.
> 

Although I fully agree with the sentiment of the message, and I don want to see 
prebuilt jars or win32 exe's shipped, I think we need to be carefull here.

I would atleast like to see an exception for existing firmware images which 
execute on the main CPU. Or are we going to take qemu out of the distro until 
we have the toolchain in place to build the bios and vga-rom images from source?

Also where is the line between code and content? Levels for certain games 
contain instructions which get interpreted by the game engine.

So when a level has a button linked to opening a door does it become code?

I think the current rules work well, so lets keep them in place and discuss 
exceptions as they occur.

Regards,

Hans



From sundaram at fedoraproject.org  Tue Oct 23 10:53:04 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 16:23:04 +0530
Subject: F8+KDE+PulseAudio
In-Reply-To: <200710231143.25027.ml@deadbabylon.de>
References: <ff8coq$57c$2@ger.gmane.org>
	<20071018155303.591a9918@redhat.com>	<1192738003.2843.34.camel@cookie.hadess.net>
	<200710231143.25027.ml@deadbabylon.de>
Message-ID: <471DD290.5050100@fedoraproject.org>

Sebastian Vahl wrote:
> Am Do 18.Oktober 2007 schrieb Bastien Nocera:
>> Frankly, we should kill the pref, and always start Pulseaudio. In the
>> meanwhile, it would be better if KDE came up with something that just
>> starts it for KDE.
> 
> Just a notice to that: If pulseaudio is only started in a full session of KDE 
> (eg. through /etc/kde/env/pulseaudio.sh) KDE programs that will be started 
> outside KDE when pulseaudio isn't running (eg. noatun in a *box) won't have 
> sound.
> For the short term this works but IMHO should be mentioned in the release 
> notes then.

Add it to the wiki. It won't be in the ISO but can be pushed in as an 
update.

Rahul



From ml at deadbabylon.de  Tue Oct 23 11:55:39 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 23 Oct 2007 13:55:39 +0200
Subject: F8+KDE+PulseAudio
In-Reply-To: <471DD290.5050100@fedoraproject.org>
References: <ff8coq$57c$2@ger.gmane.org> <200710231143.25027.ml@deadbabylon.de>
	<471DD290.5050100@fedoraproject.org>
Message-ID: <200710231355.50353.ml@deadbabylon.de>

Am Di 23.Oktober 2007 schrieb Rahul Sundaram:
> Sebastian Vahl wrote:
> > Am Do 18.Oktober 2007 schrieb Bastien Nocera:
> >> Frankly, we should kill the pref, and always start Pulseaudio. In the
> >> meanwhile, it would be better if KDE came up with something that just
> >> starts it for KDE.
> >
> > Just a notice to that: If pulseaudio is only started in a full session of
> > KDE (eg. through /etc/kde/env/pulseaudio.sh) KDE programs that will be
> > started outside KDE when pulseaudio isn't running (eg. noatun in a *box)
> > won't have sound.
> > For the short term this works but IMHO should be mentioned in the release
> > notes then.
>
> Add it to the wiki. It won't be in the ISO but can be pushed in as an
> update.

I will do so when we have decided how to use pulseaudio. This is also a topic 
in today's kde-sig-meeting.

Sebastian
-------------- 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/20071023/730e12b8/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct 23 11:10:26 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 16:40:26 +0530
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <471CDF1D.9060607@bugs.unl.edu.ar>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>	<471C585C.4070009@fedoraproject.org>	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>	<471C6D6B.2060405@fedoraproject.org>
	<471CDF1D.9060607@bugs.unl.edu.ar>
Message-ID: <471DD6A2.6070000@fedoraproject.org>

Martin Marques wrote:
> Rahul Sundaram wrote:
>> Valent Turkovic wrote:
>>
>>> One other small issue; I can't find NetworkManager anywhere in Gnome
>>> menue. Where is it located? There is no shortcut that I can see in
>>> Applications or in System menues. It that on purpose? Why?
>>
>> You aren't supposed to run it as a command or call it from the menu. See
>>
>> http://fedoraproject.org/wiki/NetworkManager
> 
> Does this mean that Gnome starts automatically NetworkManager?

In the GNOME and KDE Live images, Network Manager is started by default. 
It is not started by GNOME.

> Anyway, I use KDE. ;-)

Network Manager is a daemon that is DE neutral. nm-applet is used by 
GNOME and KNetworkManager is used by KDE who are both frontends to 
Network Manager.

In Fedora 8, nm-applet is used by KDE too as a workaround in the KDE 
Live images since KNetworkManager does not work with Network Mananger 0.7

Rahul



From alan at redhat.com  Tue Oct 23 12:21:19 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 23 Oct 2007 08:21:19 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471DDD42.3030403@hhs.nl>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl> <471CC6B6.8090503@gmail.com>
	<1193085056.22958.23.camel@localhost.localdomain>
	<ufa640yah7q.fsf@epithumia.math.uh.edu>
	<20071023111449.GA12433@devserv.devel.redhat.com>
	<471DDD42.3030403@hhs.nl>
Message-ID: <20071023122119.GC12433@devserv.devel.redhat.com>

On Tue, Oct 23, 2007 at 01:38:42PM +0200, Hans de Goede wrote:
> Probably not, as it uses a pretty advanced basic dialect, but it might be 
> worth a shot. Anyone got a list of those free basics handy?

If its graphical take a look at wxBasic

FreeBasic tries to follow the MS Quick Basic

HBasic looks interesting but I've never fiddled with it. Built on KDE.

Gambas leans towards visual basic



From alan at redhat.com  Tue Oct 23 12:23:08 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 23 Oct 2007 08:23:08 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471DE011.3050902@hhs.nl>
References: <48327.192.54.193.51.1193136792.squirrel@rousalka.dyndns.org>
	<471DE011.3050902@hhs.nl>
Message-ID: <20071023122308.GD12433@devserv.devel.redhat.com>

On Tue, Oct 23, 2007 at 01:50:41PM +0200, Hans de Goede wrote:
> I would atleast like to see an exception for existing firmware images which 
> execute on the main CPU. Or are we going to take qemu out of the distro 
> until we have the toolchain in place to build the bios and vga-rom images 
> from source?

Thats not a very hard toolchain to build so I don't see it is a problem.

> Also where is the line between code and content? Levels for certain games 
> contain instructions which get interpreted by the game engine.

And if those are shipped in a source format with the game and a build tool
we should include them in that way at least in the srpm. If they were hand
coded in hex well that is genuinely the preferred form so no problem



From ndbecker2 at gmail.com  Tue Oct 23 12:35:35 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 23 Oct 2007 08:35:35 -0400
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
Message-ID: <ffkpqo$cub$1@ger.gmane.org>

Rex Dieter wrote:

> Rex Dieter wrote:
> 
>> Here's some notes on making PulseAudio work with KDE,
>> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
>> which turned out to be painfully easy.
> 
> Really, to make this work, all we needed was pulseaudio getting
> autostarted
> with the session.  After chatting on fedora-desktop, we tried the
> /etc/X11/xinit.d/pulseaudio.sh containing
> pulseaudio -D
> solution (I initially had tried an over-complicated xdg/autostart setup).
> 
> Could this (or something like it) be considered for inclusion in F8's
> pulseaudio pkg?
> 
> -- Rex
>

Did you mean /etc/X11/xinitrc.d ?



From mattdm at mattdm.org  Tue Oct 23 12:39:47 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 23 Oct 2007 08:39:47 -0400
Subject: Multiarch crazyiness
In-Reply-To: <200710222254.35624@rineau.tsetse>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
	<200710222254.35624@rineau.tsetse>
Message-ID: <20071023123947.GA5231@jadzia.bu.edu>

On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > We prefer 32bit on those platforms.
> What if I have a x86_64 platform and nevertheless want only a 64-bits kernel 
> and almost all 32-bits apps??

Given the architecture constraints, why do you want that? Is this a real use
case that should be given serious consideration?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From sgrubb at redhat.com  Tue Oct 23 12:46:24 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Tue, 23 Oct 2007 08:46:24 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <ffja8k$dj7$1@ger.gmane.org>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
Message-ID: <200710230846.25736.sgrubb@redhat.com>

On Monday 22 October 2007 19:03:46 Thomas M Steenholdt wrote:
> Bernardo Innocenti wrote:
> > It would seem a worthwhile goal to unify SSL/TLS
> > implementations like we did for spell checkers.
> > Or, if it turns out to be too hard, at least it would
> > be nice to their pki files.
>
> I really don't think its our job to decide which SSL implementation is
> used by the various different projects.

You are right, we don't want to decide anyone's preference. What we need to 
accomplish is adding another choice for projects. This way it can be compiled 
against either gnutls/openssl/home brew crypto, or NSS which is FIPS-140-2 
certified and has all the right interfaces for central configuration control.

> Those projects have already chosen which implementation they prefer - It's
> not for us to decide.

And the reason why they chose what they did varies with each project. It could 
be that they never considered NSS because its not talked about very much or 
they don't realize its FIPS-140-2 certified, or maybe they just didn't care. 
But there are enough users out there that really want to see certified crypto 
or they can't really use it in their setting.

> Also, Fedora aims to be as close to upstream as possible, so unless we
> can convince the project to change their preferred SSL implementation,
> I'm all for simply leaving it alone.

That is what we want to do. We want to help upstream projects add choice. We 
want to find out what the rough spots are for NSS and improve its 
documentation and API so that we can use it everywhere.

-Steve



From nicolas.mailhot at laposte.net  Tue Oct 23 12:49:02 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 14:49:02 +0200 (CEST)
Subject: Multiarch crazyiness
Message-ID: <51000.192.54.193.51.1193143742.squirrel@rousalka.dyndns.org>


Le Mar 23 octobre 2007 14:39, Matthew Miller a ?crit :
> On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
>> > We prefer 32bit on those platforms.
>> What if I have a x86_64 platform and nevertheless want only a
>> 64-bits kernel
>> and almost all 32-bits apps ?
>
> Given the architecture constraints, why do you want that?

I'd say kernel-side memory management, and legacy 32bit apps

-- 
Nicolas Mailhot



From fabio.comolli at gmail.com  Tue Oct 23 12:50:21 2007
From: fabio.comolli at gmail.com (Fabio Comolli)
Date: Tue, 23 Oct 2007 14:50:21 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <471DD6A2.6070000@fedoraproject.org>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>
	<20071021142921.GC25455@angus.ind.WPI.EDU>
	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>
	<471C585C.4070009@fedoraproject.org>
	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>
	<471C6D6B.2060405@fedoraproject.org>
	<471CDF1D.9060607@bugs.unl.edu.ar>
	<471DD6A2.6070000@fedoraproject.org>
Message-ID: <b637ec0b0710230550x52a51282neea09099d4a8fa7c@mail.gmail.com>

Hi.

On 10/23/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> In Fedora 8, nm-applet is used by KDE too as a workaround in the KDE
> Live images since KNetworkManager does not work with Network Mananger 0.7
>

Is this going to be fixed before the F8 release?

> Rahul
>

Regards,
Fabio



From sundaram at fedoraproject.org  Tue Oct 23 11:55:13 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 17:25:13 +0530
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <b637ec0b0710230550x52a51282neea09099d4a8fa7c@mail.gmail.com>
References: <64b14b300710210722q3f7875cfx7653662bd247043a@mail.gmail.com>	<20071021142921.GC25455@angus.ind.WPI.EDU>	<64b14b300710220158u601009a7v1ac38e8e618634c6@mail.gmail.com>	<471C585C.4070009@fedoraproject.org>	<64b14b300710220236s7051d351kae6a60941fe65ff9@mail.gmail.com>	<471C6D6B.2060405@fedoraproject.org>	<471CDF1D.9060607@bugs.unl.edu.ar>	<471DD6A2.6070000@fedoraproject.org>
	<b637ec0b0710230550x52a51282neea09099d4a8fa7c@mail.gmail.com>
Message-ID: <471DE121.6070904@fedoraproject.org>

Fabio Comolli wrote:
> Hi.
> 
> On 10/23/07, Rahul Sundaram  wrote:
>> In Fedora 8, nm-applet is used by KDE too as a workaround in the KDE
>> Live images since KNetworkManager does not work with Network Mananger 0.7
>>
> 
> Is this going to be fixed before the F8 release?

No. The new Network Manager is a rewrite and KNetworkManager is not 
compatible with it. This is mentioned in the release notes.

Upstream is working on it though.

Rahul



From ndbecker2 at gmail.com  Tue Oct 23 12:57:05 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 23 Oct 2007 08:57:05 -0400
Subject: cvs tag confusion
Message-ID: <ffkr32$i6b$1@ger.gmane.org>

After make tag in devel, I tried in F-8:

make tag
[...]
ERROR: The tag mercurial-0_9_5-1_fc8 is already applied on a different branch
ERROR: You can not forcibly move tags between branches
[...]
mercurial-0_9_5-1_fc8:devel:nbecker:1193106290
mercurial-0_9_5-1_fc8:devel:nbecker:1193106607

What should I do?



From jnovy at redhat.com  Tue Oct 23 13:00:41 2007
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 23 Oct 2007 15:00:41 +0200
Subject: packaging libcurl separately
In-Reply-To: <20071022144546.GA2916@free.fr>
References: <20071022132753.GC2988@dhcp-lab-186.brq.redhat.com>
	<20071022144546.GA2916@free.fr>
Message-ID: <20071023130041.GA2527@dhcp-lab-186.brq.redhat.com>

On Mon, Oct 22, 2007 at 04:45:46PM +0200, Patrice Dumas wrote:
> On Mon, Oct 22, 2007 at 03:27:53PM +0200, Jindrich Novy wrote:
> > Hi all,
> > 
> > just a few questions:
> > 
> > 1) What is your opinion on packaging libcurl separately (read independently on curl)?
> >    For references: http://curl.haxx.se/mail/lib-2004-09/0095.html
> 
> That would make a lot of sense to me.

For me as well. The problem is that after moving libs from curl to libcurl, curl will
turn into non-multilib package, what may break upgrade path. I'm not sure whether yum is
able to cope with that these days, but it didn't recently. If yes, I can commit the
curl/libcurl split just now.

> 
> > 2) How about compat-libcurl or libcurl3, libcurl4 packages to let users run third
> >    party software independently on the libcurl version in the distribution?
> 
> If there is a real demand for that, indeed, but not for fedora packages
> (though this is what is implied by your wording).
> 

Well, I saw no real demand for it, I just asked to get a feedback whether there is
or isn't  any ;-)

Jindrich

-- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From bnocera at redhat.com  Tue Oct 23 13:05:08 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 23 Oct 2007 14:05:08 +0100
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <18703.192.54.193.51.1193136449.squirrel@rousalka.dyndns.org>
References: <18703.192.54.193.51.1193136449.squirrel@rousalka.dyndns.org>
Message-ID: <1193144709.25405.70.camel@cookie.hadess.net>


On Tue, 2007-10-23 at 12:47 +0200, Nicolas Mailhot wrote:
> Le Mar 23 octobre 2007 01:15, Bastien Nocera a ?crit :
> 
> > 99% of the time, the driver and firmware[1] are closely knit. Try
> > upgrade the firmware of a QLogic card without the driver following,
> > and watch bad things happen.
> 
> have the driver request-firmware a different firmware id each time it
> breaks compat with old firmware, and package every firmware version a
> kernel in a given release may need in a single firmware package
> 
> Problem solved.

Yeah, it would work great if most of the drivers with builtin firmwares
weren't storage drivers...



From rdieter at math.unl.edu  Tue Oct 23 13:06:08 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Oct 2007 08:06:08 -0500
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org>
Message-ID: <ffkrk0$juh$1@ger.gmane.org>

Neal Becker wrote:

> Rex Dieter wrote:
> 
>> Rex Dieter wrote:
>> 
>>> Here's some notes on making PulseAudio work with KDE,
>>> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
>>> which turned out to be painfully easy.
>> 
>> Really, to make this work, all we needed was pulseaudio getting
>> autostarted
>> with the session.  After chatting on fedora-desktop, we tried the
>> /etc/X11/xinit.d/pulseaudio.sh containing
>> pulseaudio -D
>> solution (I initially had tried an over-complicated xdg/autostart setup).
>> 
>> Could this (or something like it) be considered for inclusion in F8's
>> pulseaudio pkg?

> Did you mean /etc/X11/xinitrc.d ?

Yes.

-- Rex




From pertusus at free.fr  Tue Oct 23 13:09:03 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 15:09:03 +0200
Subject: Koji Garbage Collection
In-Reply-To: <20071023074846.55485d36@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<20071022214009.3dad166a@redhat.com>
	<20071023064830.GA2675@free.fr>
	<20071023074846.55485d36@redhat.com>
Message-ID: <20071023130903.GA2629@free.fr>

On Tue, Oct 23, 2007 at 07:48:46AM -0400, Jesse Keating wrote:
> On Tue, 23 Oct 2007 08:48:30 +0200
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > Is there something similar for scratch builds?
> 
> http://koji.fedoraproject.org/scratch/

The task number is used in the path, is there an easy way to get that
task number when doing a scratch build? It could be possible to filter
the koji output since it gives an url for the task with the task number
in it, is there another way?

--
Pat



From rdieter at math.unl.edu  Tue Oct 23 13:09:07 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Oct 2007 08:09:07 -0500
Subject: cvs tag confusion
References: <ffkr32$i6b$1@ger.gmane.org>
Message-ID: <ffkrpk$juh$2@ger.gmane.org>

Neal Becker wrote:

> After make tag in devel, I tried in F-8:

> ERROR: The tag mercurial-0_9_5-1_fc8 is already applied on a different
> branch ERROR: You can not forcibly move tags between branches
> [...]
> mercurial-0_9_5-1_fc8:devel:nbecker:1193106290
> mercurial-0_9_5-1_fc8:devel:nbecker:1193106607
> 
> What should I do?

cvs up
Release++
retag.

-- Rex




From jwboyer at jdub.homelinux.org  Tue Oct 23 13:12:58 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 23 Oct 2007 08:12:58 -0500
Subject: cvs tag confusion
In-Reply-To: <ffkrpk$juh$2@ger.gmane.org>
References: <ffkr32$i6b$1@ger.gmane.org>
	<ffkrpk$juh$2@ger.gmane.org>
Message-ID: <20071023081258.78c0ed87@weaponx.rchland.ibm.com>

On Tue, 23 Oct 2007 08:09:07 -0500
Rex Dieter <rdieter at math.unl.edu> wrote:

> Neal Becker wrote:
> 
> > After make tag in devel, I tried in F-8:
> 
> > ERROR: The tag mercurial-0_9_5-1_fc8 is already applied on a different
> > branch ERROR: You can not forcibly move tags between branches
> > [...]
> > mercurial-0_9_5-1_fc8:devel:nbecker:1193106290
> > mercurial-0_9_5-1_fc8:devel:nbecker:1193106607
> > 
> > What should I do?
> 
> cvs up
> Release++
> retag.

cvs up -dPA please.

josh



From billcrawford1970 at gmail.com  Tue Oct 23 13:13:16 2007
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 23 Oct 2007 14:13:16 +0100
Subject: Multiarch crazyiness
In-Reply-To: <20071023123947.GA5231@jadzia.bu.edu>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
	<200710222254.35624@rineau.tsetse>
	<20071023123947.GA5231@jadzia.bu.edu>
Message-ID: <544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>

On 23/10/2007, Matthew Miller <mattdm at mattdm.org> wrote:
> On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > > We prefer 32bit on those platforms.
> > What if I have a x86_64 platform and nevertheless want only a 64-bits kernel
> > and almost all 32-bits apps?
>
> Given the architecture constraints, why do you want that? Is this a real use
> case that should be given serious consideration?

32-bit code for most platforms is smaller *and* uses less memory
(pointers at least being half the size). There is often a speed
penalty too.



From pertusus at free.fr  Tue Oct 23 13:12:58 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 15:12:58 +0200
Subject: cvs tag confusion
In-Reply-To: <ffkrpk$juh$2@ger.gmane.org>
References: <ffkr32$i6b$1@ger.gmane.org> <ffkrpk$juh$2@ger.gmane.org>
Message-ID: <20071023131258.GB2629@free.fr>

On Tue, Oct 23, 2007 at 08:09:07AM -0500, Rex Dieter wrote:
> Neal Becker wrote:
> 
> > After make tag in devel, I tried in F-8:
> 
> > ERROR: The tag mercurial-0_9_5-1_fc8 is already applied on a different
> > branch ERROR: You can not forcibly move tags between branches
> > [...]
> > mercurial-0_9_5-1_fc8:devel:nbecker:1193106290
> > mercurial-0_9_5-1_fc8:devel:nbecker:1193106607
> > 
> > What should I do?
> 
> cvs up
> Release++
> retag.

With care to avoid having devel older than F-8. Maybe using:
http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#head-ddf4d5a367a283811e4ceb9ab7680ed298a7e6b1

--
Pat



From opensource at till.name  Tue Oct 23 13:13:17 2007
From: opensource at till.name (Till Maas)
Date: Tue, 23 Oct 2007 15:13:17 +0200
Subject: cvs tag confusion
In-Reply-To: <ffkr32$i6b$1@ger.gmane.org>
References: <ffkr32$i6b$1@ger.gmane.org>
Message-ID: <200710231513.23168.opensource@till.name>

On Di Oktober 23 2007, Neal Becker wrote:
> After make tag in devel, I tried in F-8:
>
> make tag
> [...]
> ERROR: The tag mercurial-0_9_5-1_fc8 is already applied on a different
> branch ERROR: You can not forcibly move tags between branches
> [...]
> mercurial-0_9_5-1_fc8:devel:nbecker:1193106290
> mercurial-0_9_5-1_fc8:devel:nbecker:1193106607
>
> What should I do?

Afaik, you need to update your Makefile.common in mercurial/common. Then "make 
tag" in devel will make a tag for F-9. Then you can either run "make 
force-tag" in F-8[1] or bump the release and run "make tag".

Regards,
Till

[1] There are rumours that something terrible can happen, when you do this. 
But I do not know what this is and it worked for me.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/94f66ca0/attachment.sig>

From ffesti at redhat.com  Tue Oct 23 13:19:46 2007
From: ffesti at redhat.com (Florian Festi)
Date: Tue, 23 Oct 2007 15:19:46 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071022185644.GG9625@nostromo.devel.redhat.com>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>	<471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr>	<471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<20071022185644.GG9625@nostromo.devel.redhat.com>
Message-ID: <471DF4F2.5000400@redhat.com>

Bill Nottingham wrote:
> Jesse Keating (jkeating at redhat.com) said: 
>> Applications get dragged in because the libraries aren't split out into
>> -libs subpackages.  If they were, then the -devel and -libs packages
>> would be available multilib, but the application itself wouldn't.
> 
> One *big* issue with doing this change across the board is that you'll go
> from the repository having:
> 
> - foo.i386 and foo.x86_64
> 
> to:
> 
> - foo.x86_64 and foo-libs.i386 and foo-libs.x86_64
> 
> So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
> will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
> foo.i386 will remain, often leading to conflicts.

Yes, it is known that yum and multilib does't work well. We are currently 
working on getting this and number of related issues fixed. I am quite sure 
we can come up with an solution for F9.

If 64bit binaries and 32+64bit libs is the wanted solution (didn't say that) 
the current yum behavior shouldn't be seen as blocker.

Florian



From pertusus at free.fr  Tue Oct 23 13:28:20 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 15:28:20 +0200
Subject: packaging libcurl separately
In-Reply-To: <20071023130041.GA2527@dhcp-lab-186.brq.redhat.com>
References: <20071022132753.GC2988@dhcp-lab-186.brq.redhat.com>
	<20071022144546.GA2916@free.fr>
	<20071023130041.GA2527@dhcp-lab-186.brq.redhat.com>
Message-ID: <20071023132820.GC2629@free.fr>

On Tue, Oct 23, 2007 at 03:00:41PM +0200, Jindrich Novy wrote:
> 
> For me as well. The problem is that after moving libs from curl to libcurl, curl will
> turn into non-multilib package, what may break upgrade path. I'm not sure whether yum is
> able to cope with that these days, but it didn't recently. If yes, I can commit the
> curl/libcurl split just now.

Ok, I see. It is not a priority, in my opinion, so we can wait for yum
to be fixed, I guess this is something that is taken care of. You could
add a Provides in the mean time if you want to ease the work of
packagers that depend on curl itself, but my experience is that people
fix the dependency only when they are broken, not in advance.
 
> Well, I saw no real demand for it, I just asked to get a feedback whether there is
> or isn't  any ;-)

Ok, so let's see... However I am not sure that it is the best place to
ask such question since the need for compat libs is certainly more
important outside of the circle of the fedora developpers, and more a
need for some users that are not involved in devel, people in devel is
certainly more used to the speed of fedora change.

--
Pat



From ajackson at redhat.com  Tue Oct 23 13:06:20 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 23 Oct 2007 09:06:20 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193114353.4389.2.camel@localhost.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193092601.17037.1.camel@localhost.localdomain>
	<45abe7d80710221748k53bc04e2vf8015c94f95da3e3@mail.gmail.com>
	<1193114353.4389.2.camel@localhost.localdomain>
Message-ID: <1193144780.26974.30.camel@localhost.localdomain>

On Tue, 2007-10-23 at 00:39 -0400, Owen Taylor wrote:
> On Mon, 2007-10-22 at 20:48 -0400, Ray Strode wrote:
> > Hi, 
> > On 10/22/07, Owen Taylor <otaylor at redhat.com> wrote:
> > > > That also means BTW that when you change laptop again your text will
> > > > stay the same size regardless of the screen resolution, so you can
> > > > invest the time to find good settings you'll keep them a long time.
> > >
> > > I'd be interested in a pointer to the discussion that led to this policy
> > > change.
> > >
> > http://bugzilla.gnome.org/show_bug.cgi?id=378338
> > 
> > Federico blogged about it, too:
> > 
> > http://www.gnome.org/~federico/news-2007-01.html#font-sizes
> 
> I've now commented in great detail on the bug explaining a few of the
> reasons why I chose to hardcode 96dpi years ago. The situation has
> changed a bit (and there would be an argument to up the 96dpi to
> something higher), but most of the arguments against using the reported
> monitor DPI as the logical font DPI still hold.

The flipside of this is I also fixed the X server to report 100 by
default, because it's almost never 75 and extremely commonly 100, and
(as you noted on the bug) 75 is a bad DPI for fonts anyway because
there's just not enough pixels.

For what it's worth, I agree, DPI is not the right unit of measurement
for fonts.  You actually want dots per steradian (or square degree),
which is a measurement you have to infer from display usage since you
can't measure solid angle without knowing viewing distance.  In the
absence of any sort of policy to know this, it's probably better to just
choose a logical font DPI and stick with it.  The rasteriser still wants
to know the physical DPI so it can optimize subpixel coverage, but
that's a detail.

- ajax



From katzj at redhat.com  Tue Oct 23 13:35:11 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 23 Oct 2007 09:35:11 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <200710230846.25736.sgrubb@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
Message-ID: <1193146511.2944.5.camel@localhost.localdomain>

On Tue, 2007-10-23 at 08:46 -0400, Steve Grubb wrote:
> On Monday 22 October 2007 19:03:46 Thomas M Steenholdt wrote:
> > Bernardo Innocenti wrote:
> > > It would seem a worthwhile goal to unify SSL/TLS
> > > implementations like we did for spell checkers.
> > > Or, if it turns out to be too hard, at least it would
> > > be nice to their pki files.
> >
> > I really don't think its our job to decide which SSL implementation is
> > used by the various different projects.
> 
> You are right, we don't want to decide anyone's preference. What we need to 
> accomplish is adding another choice for projects. This way it can be compiled 
> against either gnutls/openssl/home brew crypto, or NSS which is FIPS-140-2 
> certified and has all the right interfaces for central configuration control.

Adding more compile time options isn't necessarily the answer, though.
It makes maintenance a bit of a pain (now I have to maintain two
versions of the same code, oh goodie!) and also ends up making things a
little bit less obvious.  Maybe some projects will be willing to go this
route, but I suspect it's not going to be a slam dunk, especially given
the breadth of software being impacted.  Some of which probably doesn't
even have a real maintained upstream anymore

The idea of getting to where we can just have a fully drop-in
replacement for all of openssl and gnutls that backend to NSS is going
to end up being far more palatable for many packages.  It's not going to
be as easy for those working on said drop-in replacements, though.

It's also probably worth looking into why new projects choose gnutls or
openssl instead of NSS and trying to make that experience better so that
new projects will use NSS

Jeremy



From jdennis at redhat.com  Tue Oct 23 14:01:50 2007
From: jdennis at redhat.com (John Dennis)
Date: Tue, 23 Oct 2007 10:01:50 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <200710230846.25736.sgrubb@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
Message-ID: <471DFECE.5080704@redhat.com>

Steve Grubb wrote:
> On Monday 22 October 2007 19:03:46 Thomas M Steenholdt wrote:
>> Bernardo Innocenti wrote:
>> I really don't think its our job to decide which SSL implementation is
>> used by the various different projects.
> 
> You are right, we don't want to decide anyone's preference.

So why did Peter Vrabec open bugs against a slew of packages a few hours 
ago all with the summary:

"Port XXX to use NSS library for cryptography"

I haven't seen a consensus this how package maintainers should be 
spending their time.
-- 
John Dennis <jdennis at redhat.com>



From jkeating at redhat.com  Tue Oct 23 14:00:18 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 10:00:18 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071023130903.GA2629@free.fr>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<20071022214009.3dad166a@redhat.com>
	<20071023064830.GA2675@free.fr>
	<20071023074846.55485d36@redhat.com>
	<20071023130903.GA2629@free.fr>
Message-ID: <20071023100018.2d01c20f@redhat.com>

On Tue, 23 Oct 2007 15:09:03 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> The task number is used in the path, is there an easy way to get that
> task number when doing a scratch build? It could be possible to filter
> the koji output since it gives an url for the task with the task
> number in it, is there another way?

That's probably the best way to do it for now.  

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/2ca766ba/attachment.sig>

From opensource at till.name  Tue Oct 23 14:03:05 2007
From: opensource at till.name (Till Maas)
Date: Tue, 23 Oct 2007 16:03:05 +0200
Subject: Koji Garbage Collection
In-Reply-To: <20071023074846.55485d36@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023064830.GA2675@free.fr> <20071023074846.55485d36@redhat.com>
Message-ID: <200710231603.12376.opensource@till.name>

On Di Oktober 23 2007, Jesse Keating wrote:
> On Tue, 23 Oct 2007 08:48:30 +0200
>
> Patrice Dumas <pertusus at free.fr> wrote:
> > Is there something similar for scratch builds?
>
> http://koji.fedoraproject.org/scratch/

https works here, too.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/722ebd15/attachment.sig>

From dwmw2 at infradead.org  Tue Oct 23 14:10:39 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 23 Oct 2007 15:10:39 +0100
Subject: Multiarch crazyiness
In-Reply-To: <471DB92C.7060608@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>	<471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl>	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>  <471DB92C.7060608@redhat.com>
Message-ID: <1193148639.20893.93.camel@pmac.infradead.org>

On Tue, 2007-10-23 at 10:04 +0100, Richard W.M. Jones wrote:
> That's wrong for OCaml programs, since strings in 32 bit OCaml programs 
> are limited to 16 MB (but effectively unlimited on 64 bit platforms). 

That doesn't actually affect anything we ship or might _want_ to ship,
though, does it? 

> So 64 bit should always be preferred.  

We can build both and normally default to 32-bit; if a package exists
_only_ in the 64-bit version and not for ppc32 (or i386), then it and
its dependencies will get installed. 

> Having said that we're still waiting for someone to port the OCaml
> compiler to Linux/ppc64 ...

s/port/debug/

Most of the work is done -- it builds, the native compiler works, and
the test cases I tried it with all work.... except for freetennis, which
segfaults after bringing up the first window. I kind of got stuck there
because it was all static libraries and the debug information was
missing; I need to build it all manually to poke at it.

-- 
dwmw2



From rdieter at math.unl.edu  Tue Oct 23 14:11:40 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Oct 2007 09:11:40 -0500
Subject: Should we settle on one SSL implementation?
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com>
Message-ID: <ffkves$49f$1@ger.gmane.org>

John Dennis wrote:

> So why did Peter Vrabec open bugs against a slew of packages a few hours
> ago all with the summary:
> 
> "Port XXX to use NSS library for cryptography"
> 
> I haven't seen a consensus this how package maintainers should be
> spending their time.

I'm assuming those bugs are mostly for tracking purposes.

-- Rex



From skvidal at fedoraproject.org  Tue Oct 23 14:13:18 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 23 Oct 2007 14:13:18 +0000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <ffkves$49f$1@ger.gmane.org>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org>
Message-ID: <1193148798.8542.285.camel@cutter>


On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> John Dennis wrote:
> 
> > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > ago all with the summary:
> > 
> > "Port XXX to use NSS library for cryptography"
> > 
> > I haven't seen a consensus this how package maintainers should be
> > spending their time.
> 
> I'm assuming those bugs are mostly for tracking purposes.
> 

and a lot of them are wrong.

one opened against createrepo and yum each. b/c createrepo and yum use
sha1 from python.

I don't think we'll be fixing that in createrepo nor yum. We'll be
fixing it in python.

-sv




From dwmw2 at infradead.org  Tue Oct 23 14:17:24 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 23 Oct 2007 15:17:24 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193078200.549.4.camel@jcmlaptop>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
Message-ID: <1193149044.20893.100.camel@pmac.infradead.org>

On Mon, 2007-10-22 at 14:36 -0400, Jon Masters wrote:
> I know you don't like the bin32/bin64 idea, but I think it's the only
> real way to "solve" having both binary flavors of a package installed at
> the same time, if that needs to be solved. 

I don't think it _does_ need to be solved. We just shouldn't need to
have both versions of a binary installed at the same time. 

> The lesser issue - more
> easily solved - is that of libraries, where I think a general consensus
> to split them out into -libs packages over time would do the trick.

Indeed. Split binaries from libraries, and _remove_ the hack in RPM
which allows 'conflicting' binaries to install by choosing one or the
other.

-- 
dwmw2



From jkeating at redhat.com  Tue Oct 23 14:18:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 10:18:28 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193148798.8542.285.camel@cutter>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
Message-ID: <20071023101828.28ab1670@redhat.com>

On Tue, 23 Oct 2007 14:13:18 +0000
seth vidal <skvidal at fedoraproject.org> wrote:

> I don't think we'll be fixing that in createrepo nor yum. We'll be
> fixing it in python.

"fixing".  We're not seriously going to remove the ability for python
to create sha1sum hashes are we?  'Cause that would just be silly.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/0a7f1109/attachment.sig>

From lmacken at redhat.com  Tue Oct 23 14:22:33 2007
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 23 Oct 2007 10:22:33 -0400
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <471D3ADB.5000809@gmail.com>
References: <20071022203716.GE8813@crow.myhome.westell.com>
	<471D3ADB.5000809@gmail.com>
Message-ID: <20071023142233.GL8813@crow.myhome.westell.com>

On Mon, Oct 22, 2007 at 05:05:47PM -0700, Toshio Kuratomi wrote:
> Luke Macken wrote:
>> I just upgraded our Bodhi production instance, which will now allow you
>> to enqueue your Fedora 8 Updates.
>>     http://bodhi.fedoraproject.org
>> Some notable changes since the last update:
>>   ? Updates will automatically get unpushed once they reach a karma of 
>> -3
>>   ? No more confusing legacy move/push terminology.  Available update 
>> requests are 'testing' and 'stable'.
>>   ? Unpushing/obsoleting is now instant.
>>   ? ACL validation against the pkgdb for new update submissions.
> I think this update also fixes the Unicode-characters-in-packager's-name 
> error that some people were running into earlier.  (Unless that was fixed 
> earlier and I just missed it.)

Yep!

Thanks to Toshio & Ricky's unicode hackery in the FAS, this should
hopefully be resolved now.

luke



From tmraz at redhat.com  Tue Oct 23 14:23:24 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 23 Oct 2007 16:23:24 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023101828.28ab1670@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
Message-ID: <1193149404.6746.5.camel@vespa.kabelta.loc>


On Tue, 2007-10-23 at 10:18 -0400, Jesse Keating wrote:
> On Tue, 23 Oct 2007 14:13:18 +0000
> seth vidal <skvidal at fedoraproject.org> wrote:
> 
> > I don't think we'll be fixing that in createrepo nor yum. We'll be
> > fixing it in python.
> 
> "fixing".  We're not seriously going to remove the ability for python
> to create sha1sum hashes are we?  'Cause that would just be silly.
Why remove? Just not use a built-in code but call NSS instead.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From lmacken at redhat.com  Tue Oct 23 14:23:39 2007
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 23 Oct 2007 10:23:39 -0400
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <loom.20071023T042700-571@post.gmane.org>
References: <20071022203716.GE8813@crow.myhome.westell.com>
	<loom.20071023T042700-571@post.gmane.org>
Message-ID: <20071023142339.GM8813@crow.myhome.westell.com>

On Tue, Oct 23, 2007 at 04:27:47AM +0000, Kevin Kofler wrote:
> Luke Macken <lmacken <at> redhat.com> writes:
> >   ? Updates will automatically get unpushed once they reach a karma of -3
> 
> Even from stable? Or just from testing? Unpushing updates from stable tends to 
> cause a big mess, so I'm not sure doing that without validation is a good idea.

Good call, Kevin.  I'll make sure that it is not possible.

luke



From aph at redhat.com  Tue Oct 23 14:26:53 2007
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Oct 2007 15:26:53 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193149044.20893.100.camel@pmac.infradead.org>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
	<1193149044.20893.100.camel@pmac.infradead.org>
Message-ID: <18206.1197.185882.20555@zebedee.pink>

David Woodhouse writes:
 > On Mon, 2007-10-22 at 14:36 -0400, Jon Masters wrote:
 > > I know you don't like the bin32/bin64 idea, but I think it's the only
 > > real way to "solve" having both binary flavors of a package installed at
 > > the same time, if that needs to be solved. 
 > 
 > I don't think it _does_ need to be solved. We just shouldn't need
 > to have both versions of a binary installed at the same time.

There is one case where we do.  Sometimes people will have a need for
both 32-bit and 64-bit Java virtual machines.  

For example, one user may have a small Java application that runs best
on a 32-bit VM (or maybe even has a native library that hasn't been
ported to 64 bits) and at the same time another user is running an
application that needs the huge memory of a 64-bit VM.  In that case,
you need two binaries called java, one 32-bit and one 64-bit.  I don't
think there's any way around this.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From dwmw2 at infradead.org  Tue Oct 23 14:30:03 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 23 Oct 2007 15:30:03 +0100
Subject: Multiarch crazyiness
In-Reply-To: <18206.1197.185882.20555@zebedee.pink>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
	<1193149044.20893.100.camel@pmac.infradead.org>
	<18206.1197.185882.20555@zebedee.pink>
Message-ID: <1193149803.20893.105.camel@pmac.infradead.org>


On Tue, 2007-10-23 at 15:26 +0100, Andrew Haley wrote:
> There is one case where we do.  Sometimes people will have a need for
> both 32-bit and 64-bit Java virtual machines.  
> 
> For example, one user may have a small Java application that runs best
> on a 32-bit VM (or maybe even has a native library that hasn't been
> ported to 64 bits) and at the same time another user is running an
> application that needs the huge memory of a 64-bit VM.  In that case,
> you need two binaries called java, one 32-bit and one 64-bit.  I don't
> think there's any way around this.

I thought we'd fixed (or worked around, if you prefer) that a while ago,
by putting it somewhere under %{_libdir}/java/ ?

-- 
dwmw2



From jkeating at redhat.com  Tue Oct 23 14:34:10 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 10:34:10 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193149404.6746.5.camel@vespa.kabelta.loc>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
Message-ID: <20071023103410.46acd566@redhat.com>

On Tue, 23 Oct 2007 16:23:24 +0200
Tomas Mraz <tmraz at redhat.com> wrote:

> Why remove? Just not use a built-in code but call NSS instead.

Call NSS, to make a sha1sum?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/b6d608ca/attachment.sig>

From berrange at redhat.com  Tue Oct 23 14:38:27 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 23 Oct 2007 15:38:27 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193148798.8542.285.camel@cutter>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
Message-ID: <20071023143827.GA2960@redhat.com>

On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> 
> On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > John Dennis wrote:
> > 
> > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > ago all with the summary:
> > > 
> > > "Port XXX to use NSS library for cryptography"
> > > 
> > > I haven't seen a consensus this how package maintainers should be
> > > spending their time.
> > 
> > I'm assuming those bugs are mostly for tracking purposes.
> > 
> 
> and a lot of them are wrong.

Yep, this is just creating yet bug triage work for maintainers. When entering
tickets one could at least check the app in question to see if it actually
uses the crypto libraries we're being told to remove. Not useful.

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From aph at redhat.com  Tue Oct 23 14:39:53 2007
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Oct 2007 15:39:53 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193149803.20893.105.camel@pmac.infradead.org>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<20071022182551.GB9625@nostromo.devel.redhat.com>
	<1193078200.549.4.camel@jcmlaptop>
	<1193149044.20893.100.camel@pmac.infradead.org>
	<18206.1197.185882.20555@zebedee.pink>
	<1193149803.20893.105.camel@pmac.infradead.org>
Message-ID: <18206.1977.122264.782016@zebedee.pink>

David Woodhouse writes:
 > 
 > On Tue, 2007-10-23 at 15:26 +0100, Andrew Haley wrote:
 > > There is one case where we do.  Sometimes people will have a need for
 > > both 32-bit and 64-bit Java virtual machines.  
 > > 
 > > For example, one user may have a small Java application that runs best
 > > on a 32-bit VM (or maybe even has a native library that hasn't been
 > > ported to 64 bits) and at the same time another user is running an
 > > application that needs the huge memory of a 64-bit VM.  In that case,
 > > you need two binaries called java, one 32-bit and one 64-bit.  I don't
 > > think there's any way around this.
 > 
 > I thought we'd fixed (or worked around, if you prefer) that a while ago,
 > by putting it somewhere under %{_libdir}/java/ ?

That's a solution.

All I'm saying is that there _is_ a case where you want "both [32- and
64-bit] versions of a binary installed at the same time".  There are
lots of ways to fix the problem, of course.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From tmraz at redhat.com  Tue Oct 23 14:42:14 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 23 Oct 2007 16:42:14 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023143827.GA2960@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
Message-ID: <1193150534.6746.8.camel@vespa.kabelta.loc>


On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > 
> > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > John Dennis wrote:
> > > 
> > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > ago all with the summary:
> > > > 
> > > > "Port XXX to use NSS library for cryptography"
> > > > 
> > > > I haven't seen a consensus this how package maintainers should be
> > > > spending their time.
> > > 
> > > I'm assuming those bugs are mostly for tracking purposes.
> > > 
> > 
> > and a lot of them are wrong.
> 
> Yep, this is just creating yet bug triage work for maintainers. When entering
> tickets one could at least check the app in question to see if it actually
> uses the crypto libraries we're being told to remove. Not useful.
Not only crypto libraries but built-in code as well. I have checked that
the packages actually contain the code. I hardly could in reasonable
time check whether the code is always used and so on. I'd expect some
help from maintainers in these corner cases.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From vonbrand at inf.utfsm.cl  Tue Oct 23 14:42:03 2007
From: vonbrand at inf.utfsm.cl (vonbrand at inf.utfsm.cl)
Date: Tue, 23 Oct 2007 11:42:03 -0300
Subject: License review for new itext version
In-Reply-To: <471C4CF3.7030200@hhs.nl>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
Message-ID: <200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>

Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Laurent Rineau wrote:
> > On Sunday 12 August 2007 23:01:34 Jochen Schmitt wrote:
> >> Hello,
> >>
> >> in the past we have removed itext and pdftk which depends on itext from
> >> the Fedora distribution due
> >> license issue.
> >>
> >> In the new iText package itext-2.0.4 I have found a text file about the
> >> licensing situation of the
> >> source file coming from Sun Corporation Inc.
> >>
> >> I have uploaded this file for review on
> >>
> >> http://www.herr-schmitt.de/pub/itext/sun.txt
> >>
> >> I want to know, it this ok for Fedora. But I assume, that the last term
> >> about usage this file for nuclear weapons may be a blocker.

I don't see terms /prohibiting/ any use, just saying that you are aware
that the software was not built to the standards required for nuclear power
plant (and such) use. If you use it anyway, the resulting crater is
entirely your fault. Same as with Linux, gcc, and a miriard other Fedora
packages.

> > Jochen, do you have an update of the situation? Will upstream agree
> > to modify the license scheme a bit?
> > I use pdftk randomly in my job, several times a year, but I really
> > need it. It is not so nice to see one usefull package go away from
> > Fedora.
> >
> 
> You can try contacting Sun yourself, in the end getting license
> changes like this can take a long breath, multiple contact attempts
> before finding someone who is willing to discuss things, etc. So if
> you care, please contact Sun. And as always, please do so in a polite
> and friendly manner.

Is this an OSI-approved license? Does it make sense to grind it through
that process?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513



From sundaram at fedoraproject.org  Tue Oct 23 13:43:30 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 19:13:30 +0530
Subject: License review for new itext version
In-Reply-To: <200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
References: <46BF752E.4030500@herr-schmitt.de>	<200710220029.30090@rineau.tsetse>
	<471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
Message-ID: <471DFA82.4050708@fedoraproject.org>

vonbrand at inf.utfsm.cl wrote:

> 
> Is this an OSI-approved license? Does it make sense to grind it through
> that process?

The recommended OSI process is for those who wrote the license to send 
it for approval. We could ask FSF for a review however if that is not 
already done by Spot.

Rahul



From berrange at redhat.com  Tue Oct 23 14:46:04 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 23 Oct 2007 15:46:04 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193150534.6746.8.camel@vespa.kabelta.loc>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
Message-ID: <20071023144604.GC2960@redhat.com>

On Tue, Oct 23, 2007 at 04:42:14PM +0200, Tomas Mraz wrote:
> 
> On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > 
> > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > John Dennis wrote:
> > > > 
> > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > ago all with the summary:
> > > > > 
> > > > > "Port XXX to use NSS library for cryptography"
> > > > > 
> > > > > I haven't seen a consensus this how package maintainers should be
> > > > > spending their time.
> > > > 
> > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > 
> > > 
> > > and a lot of them are wrong.
> > 
> > Yep, this is just creating yet bug triage work for maintainers. When entering
> > tickets one could at least check the app in question to see if it actually
> > uses the crypto libraries we're being told to remove. Not useful.
>
> Not only crypto libraries but built-in code as well. I have checked that
> the packages actually contain the code. 

Clearly not. Virt-manager does not make use of OpenSSL, NSS or GNU TLS, nor
any other random crypto routines & yet a bug was still filed. Now Python
and GTK do have this stuff and virt-manager uses Python & GTK, but it is
not useful to file bugs against every app which uses Python or GTK when
you could file one bug against Python or GTK themselves.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From tmraz at redhat.com  Tue Oct 23 15:01:59 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 23 Oct 2007 17:01:59 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023144604.GC2960@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<20071023144604.GC2960@redhat.com>
Message-ID: <1193151719.6746.17.camel@vespa.kabelta.loc>

On Tue, 2007-10-23 at 15:46 +0100, Daniel P. Berrange wrote:
> On Tue, Oct 23, 2007 at 04:42:14PM +0200, Tomas Mraz wrote:
> > 
> > On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > > 
> > > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > > John Dennis wrote:
> > > > > 
> > > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > > ago all with the summary:
> > > > > > 
> > > > > > "Port XXX to use NSS library for cryptography"
> > > > > > 
> > > > > > I haven't seen a consensus this how package maintainers should be
> > > > > > spending their time.
> > > > > 
> > > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > > 
> > > > 
> > > > and a lot of them are wrong.
> > > 
> > > Yep, this is just creating yet bug triage work for maintainers. When entering
> > > tickets one could at least check the app in question to see if it actually
> > > uses the crypto libraries we're being told to remove. Not useful.
> >
> > Not only crypto libraries but built-in code as well. I have checked that
> > the packages actually contain the code. 
> 
> Clearly not. Virt-manager does not make use of OpenSSL, NSS or GNU TLS, nor
> any other random crypto routines & yet a bug was still filed. Now Python
> and GTK do have this stuff and virt-manager uses Python & GTK, but it is
> not useful to file bugs against every app which uses Python or GTK when
> you could file one bug against Python or GTK themselves.
You're right, the libvirt bug got filled by mistake. It somehow slipped
in from larger list generated by grep which I looked through manually
then.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From bnocera at redhat.com  Tue Oct 23 15:05:05 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 23 Oct 2007 16:05:05 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193150534.6746.8.camel@vespa.kabelta.loc>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
Message-ID: <1193151905.25405.77.camel@cookie.hadess.net>


On Tue, 2007-10-23 at 16:42 +0200, Tomas Mraz wrote:
> On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > 
> > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > John Dennis wrote:
> > > > 
> > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > ago all with the summary:
> > > > > 
> > > > > "Port XXX to use NSS library for cryptography"
> > > > > 
> > > > > I haven't seen a consensus this how package maintainers should be
> > > > > spending their time.
> > > > 
> > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > 
> > > 
> > > and a lot of them are wrong.
> > 
> > Yep, this is just creating yet bug triage work for maintainers. When entering
> > tickets one could at least check the app in question to see if it actually
> > uses the crypto libraries we're being told to remove. Not useful.
> Not only crypto libraries but built-in code as well. I have checked that
> the packages actually contain the code. I hardly could in reasonable
> time check whether the code is always used and so on. I'd expect some
> help from maintainers in these corner cases.

The problem I have with the bugs is the description. Most of my packages
don't use "security" or encryption libraries. But they will have md5 or
sha1 implementations. Do we really expect libraries with barely any
dependencies to drag in NSS to do md5 or sha1?

Why doesn't the bug mention that it's a sha1 or md5 being used that
would need porting rather than mentioning "security" libraries?

glib will soon get SHA1/MD5 as well[1], which is useful when this
functionality is used in GTK+/GNOME applications. Will glib have to
depend on NSS?

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=443648



From jdennis at redhat.com  Tue Oct 23 15:11:19 2007
From: jdennis at redhat.com (John Dennis)
Date: Tue, 23 Oct 2007 11:11:19 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193150534.6746.8.camel@vespa.kabelta.loc>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com>	<ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
Message-ID: <471E0F17.50405@redhat.com>

Tomas Mraz wrote:
> Not only crypto libraries but built-in code as well. I have checked that
> the packages actually contain the code.

I'm not sure how you checked, but it picked up false positives, 
setroubleshoot was flagged but it has no references to ssl, tls, or 
crypto in its sources.

But this still begs the question, was a consensus reached this activity 
represents a good use of maintainers time before a mass filing of bug 
reports?

Note, that question is far different than "We recommend NSS for new 
development", which I do think there is justifiable consensus on.
-- 
John Dennis <jdennis at redhat.com>



From berrange at redhat.com  Tue Oct 23 15:11:35 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 23 Oct 2007 16:11:35 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193151905.25405.77.camel@cookie.hadess.net>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
Message-ID: <20071023151135.GD2960@redhat.com>

On Tue, Oct 23, 2007 at 04:05:05PM +0100, Bastien Nocera wrote:
> 
> On Tue, 2007-10-23 at 16:42 +0200, Tomas Mraz wrote:
> > On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > > 
> > > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > > John Dennis wrote:
> > > > > 
> > > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > > ago all with the summary:
> > > > > > 
> > > > > > "Port XXX to use NSS library for cryptography"
> > > > > > 
> > > > > > I haven't seen a consensus this how package maintainers should be
> > > > > > spending their time.
> > > > > 
> > > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > > 
> > > > 
> > > > and a lot of them are wrong.
> > > 
> > > Yep, this is just creating yet bug triage work for maintainers. When entering
> > > tickets one could at least check the app in question to see if it actually
> > > uses the crypto libraries we're being told to remove. Not useful.
> > Not only crypto libraries but built-in code as well. I have checked that
> > the packages actually contain the code. I hardly could in reasonable
> > time check whether the code is always used and so on. I'd expect some
> > help from maintainers in these corner cases.
> 
> The problem I have with the bugs is the description. Most of my packages
> don't use "security" or encryption libraries. But they will have md5 or
> sha1 implementations. Do we really expect libraries with barely any
> dependencies to drag in NSS to do md5 or sha1?
> 
> Why doesn't the bug mention that it's a sha1 or md5 being used that
> would need porting rather than mentioning "security" libraries?
> 
> glib will soon get SHA1/MD5 as well[1], which is useful when this
> functionality is used in GTK+/GNOME applications. Will glib have to
> depend on NSS?

Well for that matter GLibC itself has MD5 in it....

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From tonynelson at georgeanelson.com  Tue Oct 23 15:13:22 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Tue, 23 Oct 2007 11:13:22 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471DB48D.6080106@kanarip.com>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
	<p04330102c342779f6e55@[192.168.123.162]>
	<471DB48D.6080106@kanarip.com>
Message-ID: <p04330102c343ba524a9e@[192.168.123.162]>

At 10:45 AM +0200 10/23/07, Jeroen van Meeuwen wrote:
>Tony Nelson wrote:
>> At 7:55 AM -0500 10/22/07, Jon Ciesla wrote:
>>>> Rahul Sundaram wrote:
>>>>> Jeroen van Meeuwen wrote:
>>>>>
>>>>>
>>>>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade to F8
>>>>>> using *just* CDs.
>>>>> Now we are talking about an actual problem which wasn't clear to me
>>>>> earlier. So if Fedora Project released regular CD's for this release and
>>>>> makes live upgrades a supported option from Fedora 9 onwards, do you see
>>>>> any need for a regular CD variant in the future?
>>>>>
>>>> Other then for it's sentimental value, the impressive number of discs
>>>> for the Everything spin or laptop-in-the-bush cases, there's no real
>>>> need for CD's. The few people that want a customized install with all
>>>> kinds of exotic partitioning schemes (or minimal installs) should either
>>>> be able to create CDs off the DVD iso or get the CDs from any third
>>>> party providing them.
>>> A: I have not DVD drives.
>>  ...
>>
>> It could be explained better, but "askmethod" allows installation of a DVD
>> image with only a (or even no) CD drive, as long as the DVD image is made
>> available during the install.  I keep mine on C: (sda1,/), but a USB key or
>> hard drive would also work.  (I have a DVD drive, and I boot the DVD, but
>> one can just burn the RescueCD image that comes with the DVD, at least with
>> the torrent).
>
>That's oh so true but askmethod is a long way from "Next, Next, Finish"
>which is the way you'd want to able to tell anyone when they ask "How to
>install Fedora".

Yes.  I think "askmethod" should be a standard choice in the installer
menus, not a secret command, and it should be explained various places,
including the place that says there are no CDs, and the place that says
there are DVDs.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From ssorce at redhat.com  Tue Oct 23 15:19:32 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 23 Oct 2007 11:19:32 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023151135.GD2960@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
	<20071023151135.GD2960@redhat.com>
Message-ID: <1193152772.23200.14.camel@localhost.localdomain>

On Tue, 2007-10-23 at 16:11 +0100, Daniel P. Berrange wrote:
> 
> Well for that matter GLibC itself has MD5 in it....

Quick! Make it depend on NSS! :-)

/simo with 3 packages with the same bug filed I can't possibly fix as
NSS simply do not have the relevant algorithms ...



From sundaram at fedoraproject.org  Tue Oct 23 14:19:00 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 19:49:00 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <p04330102c343ba524a9e@[192.168.123.162]>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>
	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>
	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>
	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>
	<471A7162.4080004@fedoraproject.org>	<471B2444.8030901@kanarip.com>	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>	<p04330102c342779f6e55@[192.168.123.162]>	<471DB48D.6080106@kanarip.com>
	<p04330102c343ba524a9e@[192.168.123.162]>
Message-ID: <471E02D4.7060704@fedoraproject.org>

Tony Nelson wrote:

> 
> Yes.  I think "askmethod" should be a standard choice in the installer
> menus, not a secret command, and it should be explained various places,
> including the place that says there are no CDs, and the place that says
> there are DVDs.

It already should be. If you find anything missing, point out the location.

Rahul



From tmraz at redhat.com  Tue Oct 23 15:21:02 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 23 Oct 2007 17:21:02 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E0F17.50405@redhat.com>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc> <471E0F17.50405@redhat.com>
Message-ID: <1193152862.6746.26.camel@vespa.kabelta.loc>


On Tue, 2007-10-23 at 11:11 -0400, John Dennis wrote:
> Tomas Mraz wrote:
> > Not only crypto libraries but built-in code as well. I have checked that
> > the packages actually contain the code.
> 
> I'm not sure how you checked, but it picked up false positives, 
> setroubleshoot was flagged but it has no references to ssl, tls, or 
> crypto in its sources.
It calls MD5 from python although as already discussed this should have
been filed only against python anyway.

> But this still begs the question, was a consensus reached this activity 
> represents a good use of maintainers time before a mass filing of bug 
> reports?
> 
> Note, that question is far different than "We recommend NSS for new 
> development", which I do think there is justifiable consensus on.
These bugs were filled for tracking purposes I fully understand that
some overworked maintainers will skip over them. But I think we'd like
to eventually port everything security relevant if at all possible.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From caillon at redhat.com  Tue Oct 23 15:34:54 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 23 Oct 2007 11:34:54 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193152862.6746.26.camel@vespa.kabelta.loc>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com>	<ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>	<20071023143827.GA2960@redhat.com>	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<471E0F17.50405@redhat.com>
	<1193152862.6746.26.camel@vespa.kabelta.loc>
Message-ID: <471E149E.2090705@redhat.com>

Tomas Mraz wrote:
> These bugs were filled for tracking purposes I fully understand that
> some overworked maintainers will skip over them. But I think we'd like
> to eventually port everything security relevant if at all possible.

This sounds like something that FESCo should get involved with, as it's 
a rather large, sweeping engineering effort.  Can someone summarize the 
points for why this should happen and place it as a feature proposal on 
the wiki?  Maybe we can discuss it during this week's meeting if the 
timing works out...



From mmcgrath at redhat.com  Tue Oct 23 15:31:51 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 23 Oct 2007 10:31:51 -0500
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471DB48D.6080106@kanarip.com>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>
	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>
	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>
	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>
	<471A7162.4080004@fedoraproject.org>	<471B2444.8030901@kanarip.com>	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>	<p04330102c342779f6e55@[192.168.123.162]>
	<471DB48D.6080106@kanarip.com>
Message-ID: <471E13E7.9050009@redhat.com>

Jeroen van Meeuwen wrote:
> Tony Nelson wrote:
>> At 7:55 AM -0500 10/22/07, Jon Ciesla wrote:
>>>> Rahul Sundaram wrote:
>>>>> Jeroen van Meeuwen wrote:
>>>>>
>>>>>
>>>>>> Upgrades from F7 to F8 using LiveCD's. Not being able to upgrade 
>>>>>> to F8
>>>>>> using *just* CDs.
>>>>> Now we are talking about an actual problem which wasn't clear to me
>>>>> earlier. So if Fedora Project released regular CD's for this 
>>>>> release and
>>>>> makes live upgrades a supported option from Fedora 9 onwards, do 
>>>>> you see
>>>>> any need for a regular CD variant in the future?
>>>>>
>>>> Other then for it's sentimental value, the impressive number of discs
>>>> for the Everything spin or laptop-in-the-bush cases, there's no real
>>>> need for CD's. The few people that want a customized install with all
>>>> kinds of exotic partitioning schemes (or minimal installs) should 
>>>> either
>>>> be able to create CDs off the DVD iso or get the CDs from any third
>>>> party providing them.
>>> A: I have not DVD drives.
>>  ...
>>
>> It could be explained better, but "askmethod" allows installation of 
>> a DVD
>> image with only a (or even no) CD drive, as long as the DVD image is 
>> made
>> available during the install.  I keep mine on C: (sda1,/), but a USB 
>> key or
>> hard drive would also work.  (I have a DVD drive, and I boot the DVD, 
>> but
>> one can just burn the RescueCD image that comes with the DVD, at 
>> least with
>> the torrent).
>
> That's oh so true but askmethod is a long way from "Next, Next, 
> Finish" which is the way you'd want to able to tell anyone when they 
> ask "How to install Fedora".
>
One thing I'd thought about a couple of times is creating a 
"http://ks.fedoraproject.org/" site that includes a minimal ks config, 
like method=http://path/to/our/mirrors"  it'd work with our current 
setup pretty easy, could even create install medium that defaults to 
it.  The main blocker is I'm not sure how anaconda will deal with bad 
mirrors (they do happen) and being able to switch mirrors in the middle 
of an install would be nice.

    -Mike



From sundaram at fedoraproject.org  Tue Oct 23 14:56:19 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 20:26:19 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471E13E7.9050009@redhat.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>	<471A7162.4080004@fedoraproject.org>	<471B2444.8030901@kanarip.com>	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>	<p04330102c342779f6e55@[192.168.123.162]>	<471DB48D.6080106@kanarip.com>
	<471E13E7.9050009@redhat.com>
Message-ID: <471E0B93.6020305@fedoraproject.org>

Mike McGrath wrote:

> One thing I'd thought about a couple of times is creating a 
> "http://ks.fedoraproject.org/" site that includes a minimal ks config, 
> like method=http://path/to/our/mirrors"  it'd work with our current 
> setup pretty easy, could even create install medium that defaults to 
> it.  The main blocker is I'm not sure how anaconda will deal with bad 
> mirrors (they do happen) and being able to switch mirrors in the middle 
> of an install would be nice.

Take a look at

http://people.redhat.com/csnook/joy-of-kickstart/

Rahul



From mattdm at mattdm.org  Tue Oct 23 16:04:40 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 23 Oct 2007 12:04:40 -0400
Subject: Multiarch crazyiness
In-Reply-To: <544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
	<200710222254.35624@rineau.tsetse>
	<20071023123947.GA5231@jadzia.bu.edu>
	<544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>
Message-ID: <20071023160440.GA25063@jadzia.bu.edu>

On Tue, Oct 23, 2007 at 02:13:16PM +0100, Bill Crawford wrote:
> > On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > > > We prefer 32bit on those platforms.
> > > What if I have a x86_64 platform and nevertheless want only a 64-bits kernel
> > > and almost all 32-bits apps?
> > Given the architecture constraints, why do you want that? Is this a real use
> > case that should be given serious consideration?
> 32-bit code for most platforms is smaller *and* uses less memory
> (pointers at least being half the size). There is often a speed
> penalty too.

But we're not talking about "most platforms". We're talking about x86_64.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From nphilipp at redhat.com  Tue Oct 23 16:39:21 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Tue, 23 Oct 2007 18:39:21 +0200
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <20071022203716.GE8813@crow.myhome.westell.com>
References: <20071022203716.GE8813@crow.myhome.westell.com>
Message-ID: <1193157561.15078.19.camel@gibraltar.stuttgart.redhat.com>

On Mon, 2007-10-22 at 16:37 -0400, Luke Macken wrote:

>   ? Updates will automatically get unpushed once they reach a karma of -3

I find the current push to stable/unpush automatisms a bit inflexible
and have submitted a ticket for it:

https://hosted.fedoraproject.org/projects/bodhi/ticket/124

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase 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 rjones at redhat.com  Tue Oct 23 16:46:15 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 17:46:15 +0100
Subject: Multiarch crazyiness
In-Reply-To: <1193148639.20893.93.camel@pmac.infradead.org>
References: <471B9291.4060800@amiga-hardware.com>
	<471B9D11.7020504@hhs.nl>	<471BC22D.4000908@amiga-hardware.com>	<1193011897.5168.52.camel@perihelion>	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com>	<1193062185.32582.24.camel@perihelion>	<471CB10A.3070803@redhat.com>	<471CB7DC.60604@hhs.nl>	<20071022110424.3b2395e7@redhat.com>	<1193068985.11781.14.camel@vincent52.localdomain>	<20071022122029.2b39bbea@redhat.com>	<1193082998.17860.7.camel@vincent52.localdomain>	<20071022155624.39186440@redhat.com>
	<471DB92C.7060608@redhat.com>
	<1193148639.20893.93.camel@pmac.infradead.org>
Message-ID: <471E2557.4050406@redhat.com>

David Woodhouse wrote:
> On Tue, 2007-10-23 at 10:04 +0100, Richard W.M. Jones wrote:
>> That's wrong for OCaml programs, since strings in 32 bit OCaml programs 
>> are limited to 16 MB (but effectively unlimited on 64 bit platforms). 
> 
> That doesn't actually affect anything we ship or might _want_ to ship,
> though, does it? 

Probably not.

It mainly affects people who want to do large-scale number crunching (32 
bit arrays have a similar limit which also goes away on 64 bit).  For me 
it was loading large XML documents into memory.

> s/port/debug/
> 
> Most of the work is done -- it builds, the native compiler works, and
> the test cases I tried it with all work.... except for freetennis, which
> segfaults after bringing up the first window. I kind of got stuck there
> because it was all static libraries and the debug information was
> missing; I need to build it all manually to poke at it.

I'll raise this issue with upstream again.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/521445cd/attachment.bin>

From notting at redhat.com  Tue Oct 23 16:47:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 23 Oct 2007 12:47:15 -0400
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <471DD16A.4010500@redhat.com>
References: <471DBB18.4080607@redhat.com> <20071023101914.GE2675@free.fr>
	<471DD16A.4010500@redhat.com>
Message-ID: <20071023164715.GB17802@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
>> The ocamlrun scripts also look like binary (arch dependent?) stuff
>> so it is a logical that there is conflict. It certainly requires
>> something to be done at the rpm level, but I am far from being an expert
>> on those issues.
>
> The files which begin with #!/usr/bin/ocamlrun are bytecode files.  Even 
> though it's called "bytecode" it isn't portable between architectures. It's 
> not like Java bytecode.  So consider these to be like binaries too.

rpm only handles resolving conflicts between 32 and 64-bit ELF files - anything
else is displayed to the user as a conflict. These bytecode files would
fall into that category.

Bill



From jkeating at redhat.com  Tue Oct 23 16:52:39 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 12:52:39 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <p04330102c343ba524a9e@[192.168.123.162]>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
	<p04330102c342779f6e55@[192.168.123.162]>
	<471DB48D.6080106@kanarip.com>
	<p04330102c343ba524a9e@[192.168.123.162]>
Message-ID: <20071023125239.333371e9@redhat.com>

On Tue, 23 Oct 2007 11:13:22 -0400
Tony Nelson <tonynelson at georgeanelson.com> wrote:

> Yes.  I think "askmethod" should be a standard choice in the installer
> menus, not a secret command, and it should be explained various
> places, including the place that says there are no CDs, and the place
> that says there are DVDs.

'askmethod' is the default when you boot the boot.iso.  For F9 we'll
likely change it so that the image previously known as rescue.iso will
do the same (and be named something more clearly).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/da175ee0/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct 23 15:55:53 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 23 Oct 2007 21:25:53 +0530
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <20071023125239.333371e9@redhat.com>
References: <470D81BB.2070404@redhat.com>
	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>
	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>
	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>
	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>
	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>
	<471A7162.4080004@fedoraproject.org>	<471B2444.8030901@kanarip.com>	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>	<p04330102c342779f6e55@[192.168.123.162]>	<471DB48D.6080106@kanarip.com>	<p04330102c343ba524a9e@[192.168.123.162]>
	<20071023125239.333371e9@redhat.com>
Message-ID: <471E1989.1030006@fedoraproject.org>

Jesse Keating wrote:
> On Tue, 23 Oct 2007 11:13:22 -0400
> Tony Nelson <tonynelson at georgeanelson.com> wrote:
> 
>> Yes.  I think "askmethod" should be a standard choice in the installer
>> menus, not a secret command, and it should be explained various
>> places, including the place that says there are no CDs, and the place
>> that says there are DVDs.
> 
> 'askmethod' is the default when you boot the boot.iso.  For F9 we'll
> likely change it so that the image previously known as rescue.iso will
> do the same (and be named something more clearly).

It might be useful if askmethod was the default for the DVD image too to 
expose the functionality better. Would be even better if we provided a 
mirror list.

Rahul



From rjones at redhat.com  Tue Oct 23 16:56:18 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 23 Oct 2007 17:56:18 +0100
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <20071023164715.GB17802@nostromo.devel.redhat.com>
References: <471DBB18.4080607@redhat.com>
	<20071023101914.GE2675@free.fr>	<471DD16A.4010500@redhat.com>
	<20071023164715.GB17802@nostromo.devel.redhat.com>
Message-ID: <471E27B2.4000700@redhat.com>

Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
>>> The ocamlrun scripts also look like binary (arch dependent?) stuff
>>> so it is a logical that there is conflict. It certainly requires
>>> something to be done at the rpm level, but I am far from being an expert
>>> on those issues.
>> The files which begin with #!/usr/bin/ocamlrun are bytecode files.  Even 
>> though it's called "bytecode" it isn't portable between architectures. It's 
>> not like Java bytecode.  So consider these to be like binaries too.
> 
> rpm only handles resolving conflicts between 32 and 64-bit ELF files - anything
> else is displayed to the user as a conflict. These bytecode files would
> fall into that category.

Aha. Is there any flag or setting to change this?

Also it still seems to report conflicts with the ELF binaries.  If you 
want to take a look at some they are in the links below.  They look like 
perfectly ordinary ELF binaries to my untrained eye ...

http://annexia.org/tmp/camlp4oof.opt.i386
http://annexia.org/tmp/camlp4oof.opt.x86-64

$ file */usr/bin/camlp4oof.opt
i386/usr/bin/camlp4oof.opt:   ELF 32-bit LSB executable, Intel 80386, 
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 
2.6.9, stripped
x86_64/usr/bin/camlp4oof.opt: ELF 64-bit LSB executable, x86-64, version 
1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, 
stripped

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/ec9ddafe/attachment.bin>

From notting at redhat.com  Tue Oct 23 17:06:00 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 23 Oct 2007 13:06:00 -0400
Subject: "multiarch conflicts in ..." bugs
In-Reply-To: <471E27B2.4000700@redhat.com>
References: <471DBB18.4080607@redhat.com> <20071023101914.GE2675@free.fr>
	<471DD16A.4010500@redhat.com>
	<20071023164715.GB17802@nostromo.devel.redhat.com>
	<471E27B2.4000700@redhat.com>
Message-ID: <20071023170600.GD17802@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> Aha. Is there any flag or setting to change this?

No.

> Also it still seems to report conflicts with the ELF binaries.  If you want 
> to take a look at some they are in the links below.  They look like 
> perfectly ordinary ELF binaries to my untrained eye ...
>
> http://annexia.org/tmp/camlp4oof.opt.i386
> http://annexia.org/tmp/camlp4oof.opt.x86-64
>
> $ file */usr/bin/camlp4oof.opt
> i386/usr/bin/camlp4oof.opt:   ELF 32-bit LSB executable, Intel 80386, 
> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 
> 2.6.9, stripped
> x86_64/usr/bin/camlp4oof.opt: ELF 64-bit LSB executable, x86-64, version 1 
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, 
> stripped

Can you file a RPM bug on this?

Bill



From jkeating at redhat.com  Tue Oct 23 17:09:06 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 13:09:06 -0400
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471E1989.1030006@fedoraproject.org>
References: <470D81BB.2070404@redhat.com> <470D8ED8.9010509@BitWagon.com>
	<470D9C88.9050106@redhat.com> <1192075110.19308.21.camel@cutter>
	<471A5BCE.5060708@kanarip.com>
	<20071020200854.GA25455@angus.ind.WPI.EDU>
	<471A65B6.8010808@kanarip.com> <471A5929.10605@fedoraproject.org>
	<471A6A08.7070507@kanarip.com> <471A5E62.1050801@fedoraproject.org>
	<471A7076.5050404@kanarip.com> <471A637C.9090009@fedoraproject.org>
	<471A7D48.7070803@kanarip.com> <471A7162.4080004@fedoraproject.org>
	<471B2444.8030901@kanarip.com>
	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>
	<p04330102c342779f6e55@[192.168.123.162]>
	<471DB48D.6080106@kanarip.com>
	<p04330102c343ba524a9e@[192.168.123.162]>
	<20071023125239.333371e9@redhat.com>
	<471E1989.1030006@fedoraproject.org>
Message-ID: <20071023130906.41824f1a@redhat.com>

On Tue, 23 Oct 2007 21:25:53 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> It might be useful if askmethod was the default for the DVD image too
> to expose the functionality better. Would be even better if we
> provided a mirror list.


Problem is that askmethod is in loader, in text, and that cuts out
being able to display it in a number of languages.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/59946cf7/attachment.sig>

From rc040203 at freenet.de  Tue Oct 23 17:15:16 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 23 Oct 2007 19:15:16 +0200
Subject: Bodhi & Fedora 8 Updates
In-Reply-To: <20071022203716.GE8813@crow.myhome.westell.com>
References: <20071022203716.GE8813@crow.myhome.westell.com>
Message-ID: <1193159716.9342.65.camel@mccallum.corsepiu.local>

On Mon, 2007-10-22 at 16:37 -0400, Luke Macken wrote:
> I just upgraded our Bodhi production instance, which will now allow you
> to enqueue your Fedora 8 Updates.
> 
>     http://bodhi.fedoraproject.org
> 
> Some notable changes since the last update:

To me this bodhi is not usable:

This morning, bodhi's spinner didn't react
https://hosted.fedoraproject.org/projects/bodhi/ticket/119

Now, bodhi in firefox permanently greats me with 
"Warning: nonresponsive script" and behaves VERY jerky.


Ralf
 



From rrelyea at redhat.com  Tue Oct 23 17:22:06 2007
From: rrelyea at redhat.com (Robert Relyea)
Date: Tue, 23 Oct 2007 10:22:06 -0700
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193146511.2944.5.camel@localhost.localdomain>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>
	<1193146511.2944.5.camel@localhost.localdomain>
Message-ID: <471E2DBE.6090200@REDHAT.COM>

Jeremy Katz wrote:
>
> Adding more compile time options isn't necessarily the answer, though.
> It makes maintenance a bit of a pain (now I have to maintain two
> versions of the same code, oh goodie!) and also ends up making things a
> little bit less obvious.  Maybe some projects will be willing to go this
> route, but I suspect it's not going to be a slam dunk, especially given
> the breadth of software being impacted.  Some of which probably doesn't
> even have a real maintained upstream anymore
>   
I really depends on the extent of the compile time options.
The conversions that have already been done were either very small 
changes, or larger changes that abstract the crypto usage a little 
better with very small diffs between the various crypto packages.

So far there hasn't been a huge problem getting upstream to accept the 
ability to use another crypto package.
> The idea of getting to where we can just have a fully drop-in
> replacement for all of openssl and gnutls that backend to NSS is going
> to end up being far more palatable for many packages.  It's not going to
> be as easy for those working on said drop-in replacements, though.
>   
A fully drop-in replacement with the existing API's isn't possible. Part 
of the reason we have to do this conversion is the API's are not 
conducive to proper validation (or proper crypto hygeine). Fortunately 
most applications do not need those API's, so our 90% replacements 
should work. Applications that are using the lower-level raw crypto need 
to be refactored to allow them to work with not only properly validated 
crypto, but also other hardware crypto engines which for security 
reasons do not release key material.

Another area that's a real problem is certificate validation. gnutls 
itself doe not do certificate validation (that's left to other 
packages), openssl provided helper functions and pushes everything else 
on the client. That means support for Crl's, OCSP, and PKIX would need 
to be added to each an every application. With NSS, there is a single 
call to validate certificates, and support for OCSP and CRL's come 
automatically. Most of the conversions have simplified cert processing 
in the NSS side.

At this point we need to start converting packages to see where the 
deficiencies in our helper conversion packages are. As packages fail we 
need to evaluate whether the conversion failure was a true deficiency in 
the conversion package, or is this an area that we need to move the 
application to a more generic interface anyway.

bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/155867ee/attachment.bin>

From berrange at redhat.com  Tue Oct 23 17:25:02 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 23 Oct 2007 18:25:02 +0100
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E2DBE.6090200@REDHAT.COM>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<1193146511.2944.5.camel@localhost.localdomain>
	<471E2DBE.6090200@REDHAT.COM>
Message-ID: <20071023172502.GE2960@redhat.com>

On Tue, Oct 23, 2007 at 10:22:06AM -0700, Robert Relyea wrote:
> Another area that's a real problem is certificate validation. gnutls 
> itself doe not do certificate validation (that's left to other 
> packages), openssl provided helper functions and pushes everything else 
> on the client. That means support for Crl's, OCSP, and PKIX would need 
> to be added to each an every application. With NSS, there is a single 
> call to validate certificates, and support for OCSP and CRL's come 
> automatically. Most of the conversions have simplified cert processing 
> in the NSS side.

That's rather misleading. I've implemented SSL support in 3 apps using GNU 
TLS and all of them had certificate validation done using the GNU TLS APIs,
including support for CRLs. Maybe NSS has more 'convenience' APIs for doing
cert validation in fewer API calls, but to claim GNU TLS  doesn't do any 
validation is just FUD.

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From rrelyea at redhat.com  Tue Oct 23 17:29:17 2007
From: rrelyea at redhat.com (Robert Relyea)
Date: Tue, 23 Oct 2007 10:29:17 -0700
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193152772.23200.14.camel@localhost.localdomain>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com>	<ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>	<20071023143827.GA2960@redhat.com>	<1193150534.6746.8.camel@vespa.kabelta.loc>	<1193151905.25405.77.camel@cookie.hadess.net>	<20071023151135.GD2960@redhat.com>
	<1193152772.23200.14.camel@localhost.localdomain>
Message-ID: <471E2F6D.7070202@REDHAT.COM>

Simo Sorce wrote:
> On Tue, 2007-10-23 at 16:11 +0100, Daniel P. Berrange wrote:
>   
>> Well for that matter GLibC itself has MD5 in it....
>>     
>
> Quick! Make it depend on NSS! :-)
>   
in progress.;).
> /simo with 3 packages with the same bug filed I can't possibly fix as
> NSS simply do not have the relevant algorithms ...
>   
Which algorithms are missing?

If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
fundamentally broken, has been for 10 years. There is only one 
legitimate use of MD4 that I know of and that is support NTLM 
(Microsoft's old NT authentication mechanism). In this case we need a 
common NTLM library that all NTLM users call. Any other use of MD4 needs 
to be identified and potentially squashed. Blind use of MD4 is 
detrimental to the security of our products.

If your product used MD4 for NTLM, we need a bug to create our common 
NTLM library (probably means take and existing library and make it the 
standard), and make your conversion depended on that library. If your 
package used MD4 for something other than NTLM, we need to look at that 
usage specifically to see if it's a security issue.

bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/cc5f60d9/attachment.bin>

From rrelyea at redhat.com  Tue Oct 23 17:32:27 2007
From: rrelyea at redhat.com (Robert Relyea)
Date: Tue, 23 Oct 2007 10:32:27 -0700
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023172502.GE2960@redhat.com>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>	<1193146511.2944.5.camel@localhost.localdomain>	<471E2DBE.6090200@REDHAT.COM>
	<20071023172502.GE2960@redhat.com>
Message-ID: <471E302B.1010402@REDHAT.COM>

Daniel P. Berrange wrote:
> On Tue, Oct 23, 2007 at 10:22:06AM -0700, Robert Relyea wrote:
>   
>> Another area that's a real problem is certificate validation. gnutls 
>> itself doe not do certificate validation (that's left to other 
>> packages), openssl provided helper functions and pushes everything else 
>> on the client. That means support for Crl's, OCSP, and PKIX would need 
>> to be added to each an every application. With NSS, there is a single 
>> call to validate certificates, and support for OCSP and CRL's come 
>> automatically. Most of the conversions have simplified cert processing 
>> in the NSS side.
>>     
>
> That's rather misleading. I've implemented SSL support in 3 apps using GNU 
> TLS and all of them had certificate validation done using the GNU TLS APIs,
> including support for CRLs. Maybe NSS has more 'convenience' APIs for doing
> cert validation in fewer API calls, but to claim GNU TLS  doesn't do any 
> validation is just FUD.
>   
My understanding was there was another package for certificate and der 
processing. If gnu tls uses single api (or a small set of API's) for 
certificate processing, then it will make the conversion tools for gnu 
tls much easier.

In general gnu tls does have better api separate than openssl. The issue 
gnu tls applications would have is if the call into libgcrypt directly.

bob
> Dan
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/80e4de9f/attachment.bin>

From pertusus at free.fr  Tue Oct 23 17:30:46 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 19:30:46 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E2F6D.7070202@REDHAT.COM>
References: <200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
	<20071023151135.GD2960@redhat.com>
	<1193152772.23200.14.camel@localhost.localdomain>
	<471E2F6D.7070202@REDHAT.COM>
Message-ID: <20071023173046.GC2680@free.fr>

On Tue, Oct 23, 2007 at 10:29:17AM -0700, Robert Relyea wrote:
>
> If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
> fundamentally broken, has been for 10 years. There is only one legitimate 
> use of MD4 that I know of and that is support NTLM (Microsoft's old NT 
> authentication mechanism). In this case we need a common NTLM library that 
> all NTLM users call. Any other use of MD4 needs to be identified and 

There is libntlm existing:
http://josefsson.org/libntlm/

--
Pat



From rrelyea at redhat.com  Tue Oct 23 17:38:52 2007
From: rrelyea at redhat.com (Robert Relyea)
Date: Tue, 23 Oct 2007 10:38:52 -0700
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023173046.GC2680@free.fr>
References: <200710230846.25736.sgrubb@redhat.com>	<471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org>	<1193148798.8542.285.camel@cutter>	<20071023143827.GA2960@redhat.com>	<1193150534.6746.8.camel@vespa.kabelta.loc>	<1193151905.25405.77.camel@cookie.hadess.net>	<20071023151135.GD2960@redhat.com>	<1193152772.23200.14.camel@localhost.localdomain>	<471E2F6D.7070202@REDHAT.COM>
	<20071023173046.GC2680@free.fr>
Message-ID: <471E31AC.8060803@REDHAT.COM>

Patrice Dumas wrote:
> On Tue, Oct 23, 2007 at 10:29:17AM -0700, Robert Relyea wrote:
>   
>> If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
>> fundamentally broken, has been for 10 years. There is only one legitimate 
>> use of MD4 that I know of and that is support NTLM (Microsoft's old NT 
>> authentication mechanism). In this case we need a common NTLM library that 
>> all NTLM users call. Any other use of MD4 needs to be identified and 
>>     
>
> There is libntlm existing:
> http://josefsson.org/libntlm/
>   
Thanks, We should take a look at it. At this point there are a number of 
ntlm libraries, mostly imbedded in various applications (mozilla, samba, 
etc.). This does have the advantage of being a separate package, though.

bob
> --
> Pat
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/b18c2ae4/attachment.bin>

From ssorce at redhat.com  Tue Oct 23 17:38:11 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 23 Oct 2007 13:38:11 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E2F6D.7070202@REDHAT.COM>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
	<20071023151135.GD2960@redhat.com>
	<1193152772.23200.14.camel@localhost.localdomain>
	<471E2F6D.7070202@REDHAT.COM>
Message-ID: <1193161091.23200.28.camel@localhost.localdomain>

On Tue, 2007-10-23 at 10:29 -0700, Robert Relyea wrote:
> Simo Sorce wrote:
> > On Tue, 2007-10-23 at 16:11 +0100, Daniel P. Berrange wrote:
> >   
> >> Well for that matter GLibC itself has MD5 in it....
> >>     
> >
> > Quick! Make it depend on NSS! :-)
> >   
> in progress.;).
> > /simo with 3 packages with the same bug filed I can't possibly fix as
> > NSS simply do not have the relevant algorithms ...
> >   
> Which algorithms are missing?
> 
> If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
> fundamentally broken, has been for 10 years. There is only one 
> legitimate use of MD4 that I know of and that is support NTLM 
> (Microsoft's old NT authentication mechanism). In this case we need a 
> common NTLM library that all NTLM users call. Any other use of MD4 needs 
> to be identified and potentially squashed. Blind use of MD4 is 
> detrimental to the security of our products.
> 
> If your product used MD4 for NTLM, we need a bug to create our common 
> NTLM library (probably means take and existing library and make it the 
> standard), and make your conversion depended on that library. If your 
> package used MD4 for something other than NTLM, we need to look at that 
> usage specifically to see if it's a security issue.

FYI I am the maintainer of samba and pam_smb ...

Simo.



From myfedora at richip.dhs.org  Tue Oct 23 17:38:25 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 23 Oct 2007 11:38:25 -0600
Subject: fontsize in 7.92
In-Reply-To: <1193091883.4605.13.camel@rousalka.dyndns.org>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
Message-ID: <1193161105.9545.12.camel@localhost6.localdomain6>

On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
> 
> > is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> > Display to see more information on my screen simultaneously 
> 
> If you want small fonts just lower the size in points of your fonts in
> your app preferences. Gnome font preferences use pt as unit. Till now
> the GNOME pt unit had no relation with the pt unit the rest of the world
> uses. Now it's the same, so if you want small fonts you need to actually
> configure small fonts and not change the unit meaning on your system
> (and likewise if you want big fonts).
> 
> That also means BTW that when you change laptop again your text will
> stay the same size regardless of the screen resolution, so you can
> invest the time to find good settings you'll keep them a long time.

I, for one, am glad that there's a move to make font sizes be based on
length rather than point sizes.

The selection of a default font size is still crap-shoot, at best.
Having the monitor DPI as a dependency now allows people to say "I want
fonts that are so-and-so millimeters in height", unfortunately, 1) we
still lack information like distance of the viewer from the screen and
the height of the screen relative to the viewer, and 2) we've no way to
guess what the user would want, anyway. There are a couple of
discussions on the most ergonomic distance between monitor and viewer,
but font size preference is pretty varied. The only way to find out is
to let the gnome desktop provide feedback (a'la Smolt) after the user
has customized the desktop to his/her preference. Perhaps than a norm
can be established.

Personally, I would like to set my font size preference in some length
unit of measure so that I can bump up the resolution and not have the
fonts and icons shrink to sizes I can hardly read. It's important for me
to see a lot more information on the screen, but not to the point where
it becomes useless because they're too small that I keep having to
squint. Believe me, straining ones eyesight like that will eventually
take its toll.
--

Richi Plana



From darrellpf at gmail.com  Tue Oct 23 18:08:33 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Tue, 23 Oct 2007 11:08:33 -0700
Subject: rawhide report: 20071023 changes
In-Reply-To: <200710231144.l9NBiQ6A022040@porkchop.devel.redhat.com>
References: <200710231144.l9NBiQ6A022040@porkchop.devel.redhat.com>
Message-ID: <f6e5806f0710231108v4e30cbf6j5759cadc4def66c3@mail.gmail.com>

After this morning's rawhide update I have two different machines that
both have had nautilus looping and totally unresponsive. A third
system that I updated didn't have the problem. All the machines were
basically in the same state, totally up to date from rawhide except
for last night's update. If it had only been one machine I would have
blamed cosmic rays.

The looping continued after a reboot.

On both the looping machines I had a file browser window open to my
home directory.

strace shows a lot of

read(3, 0x9823ba0, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x9823ba0, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x9823ba0, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x9823ba0, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)

I don't see anything obvious in the updates that would have caused
this. Killing nautilus so that it restarts seems to fix the problem.



From jonathan at jonmasters.org  Tue Oct 23 18:14:17 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Tue, 23 Oct 2007 14:14:17 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193082998.17860.7.camel@vincent52.localdomain>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion> <471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl> <20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
Message-ID: <1193163257.18025.12.camel@perihelion>


On Mon, 2007-10-22 at 15:56 -0400, Matthew Saltzman wrote:
> On Mon, 2007-10-22 at 12:20 -0400, Jesse Keating wrote:
> > On Mon, 22 Oct 2007 12:03:05 -0400
> > Matthew Saltzman <mjs at CLEMSON.EDU> wrote:
> > 
> > > 32-bit runtime in general?  Why?  (Not a critical "why", a genuinely
> > > curious "why"...)
> > 
> > On those arches, running 64bit code comes at a penalty.  In fact, even
> > on x86_64 there is a penalty.  Larger memory overhead.  However on
> > x86_64 the extra CPU registers gained by running in x86_64 mode
> > outweigh the memory overhead.  Not the case on ppc/sparc where there
> > are no 'extra registers' to gain.  Very little software in very few
> > situations need 64bit.
> 
> So on those archs one would want a 64-bit kernel and 32-bit apps, except
> for large-memory programs or those needing 64/128-bit numerical types
> (self-developed code, for example)?

My reservation about this kind of talk is that no assumption as to which
32/64-bit userland exists should be made anywhere but perhaps in the
default package set installed by anaconda - it is wrong to assume that
all spins of Fedora will always have a 32-bit userland on 64-bit
architectures or any such generalization ;-)

Jon.




From jonathan at jonmasters.org  Tue Oct 23 18:16:44 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Tue, 23 Oct 2007 14:16:44 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022155624.39186440@redhat.com>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion> <471CB10A.3070803@redhat.com>
	<471CB7DC.60604@hhs.nl> <20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
Message-ID: <1193163405.18025.16.camel@perihelion>


On Mon, 2007-10-22 at 15:56 -0400, Jesse Keating wrote:
> On Mon, 22 Oct 2007 15:56:38 -0400
> Matthew Saltzman <mjs at CLEMSON.EDU> wrote:
> 
> > So on those archs one would want a 64-bit kernel and 32-bit apps,
> > except for large-memory programs or those needing 64/128-bit
> > numerical types (self-developed code, for example)?
> 
> Yes.
> 
> > Is that how it's actually handled by the installer?
> 
> We prefer 32bit on those platforms.

Isn't this codified though, rather than through a package list
containing fully qualified packages with arches? IMO it'd be best in the
longer term if the only thing Anaconda needed to have were a list of
packages with arches rather than assuming any such logic. I see why it's
not that easy today, but if it didn't need to handle ordering of install
for multilib implementation, then I think it could be a lot simpler.

Jon.




From jkeating at redhat.com  Tue Oct 23 18:24:49 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 14:24:49 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193163405.18025.16.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com>
	<1193163405.18025.16.camel@perihelion>
Message-ID: <20071023142449.747d4722@redhat.com>

On Tue, 23 Oct 2007 14:16:44 -0400
Jon Masters <jonathan at jonmasters.org> wrote:

> Isn't this codified though, rather than through a package list
> containing fully qualified packages with arches?

It's in RPM to prefer the 32bit elf file over the 64bit elf file.  And
at compose time we treat ppc64 as the "secondary arch" so there are
less ppc64 packages than ppc32.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/2d0b4915/attachment.sig>

From jkeating at redhat.com  Tue Oct 23 18:25:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 14:25:34 -0400
Subject: Multiarch crazyiness
In-Reply-To: <1193163257.18025.12.camel@perihelion>
References: <471B9291.4060800@amiga-hardware.com> <471B9D11.7020504@hhs.nl>
	<471BC22D.4000908@amiga-hardware.com>
	<1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<1193062185.32582.24.camel@perihelion>
	<471CB10A.3070803@redhat.com> <471CB7DC.60604@hhs.nl>
	<20071022110424.3b2395e7@redhat.com>
	<1193068985.11781.14.camel@vincent52.localdomain>
	<20071022122029.2b39bbea@redhat.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<1193163257.18025.12.camel@perihelion>
Message-ID: <20071023142534.7969319c@redhat.com>

On Tue, 23 Oct 2007 14:14:17 -0400
Jon Masters <jonathan at jonmasters.org> wrote:

> My reservation about this kind of talk is that no assumption as to
> which 32/64-bit userland exists should be made anywhere but perhaps
> in the default package set installed by anaconda - it is wrong to
> assume that all spins of Fedora will always have a 32-bit userland on
> 64-bit architectures or any such generalization ;-)


Which is why I want to see multilib decided on the system in question
following locally configured policy rather than at repo compose time.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/51850e62/attachment.sig>

From matt at truch.net  Tue Oct 23 18:40:52 2007
From: matt at truch.net (Matthew D Truch)
Date: Tue, 23 Oct 2007 14:40:52 -0400
Subject: gpsd
Message-ID: <20071023184052.GH26291@truch.net>

Greetings,

I'm the current maintainer of gpsd, but I no longer use it very often
(if at all) and I'm finding less and less time and motivation to
maintain it.  I'm wondering if anyone out there is interested in
co-maintaining it and/or taking it over fully from me.  It has a couple
of open bugs, which shouldn't be that hard if you're familiar with gpsd
and/or have appropriate hardware to play with:

https://bugzilla.redhat.com/show_bug.cgi?id=219750
https://bugzilla.redhat.com/show_bug.cgi?id=243026
https://bugzilla.redhat.com/show_bug.cgi?id=233436
https://bugzilla.redhat.com/show_bug.cgi?id=341361

-- 
"One in every seven days is a Thursday."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.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/20071023/23ecc796/attachment.sig>

From valent.turkovic at gmail.com  Tue Oct 23 18:41:35 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 23 Oct 2007 20:41:35 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <loom.20071022T170516-150@post.gmane.org>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<loom.20071022T170516-150@post.gmane.org>
Message-ID: <64b14b300710231141m5273c5a5mc72306b76ccce986@mail.gmail.com>

On 10/22/07, Mike C <mike.cohler at gmail.com> wrote:
> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
>
> >
> >
> > Le Lun 22 octobre 2007 11:36, Valent Turkovic a ?crit :
> >
> > > Please make it on by default also for DVD install images.
> >
> > Till it works for all the systems Fedora targets (including those with
> > no permanent GUI session that also need network/wifi connexion) the
> > answer is no.
>
> Having recently got wpa_supplicant working in F7 with ipw2200 and another
> machine with iwl3945, I am now definitely a fan of wpa_supplicant as opposed to
> NM. I can configure a machine to bring up a wireless connection at boot now and
> it will connect either at home or at work - and that is ideal for a user that
> wants to boot and then load a browser and work with the web or then do office
> stuff. The many people who have made the in-kernel drivers, wpa_supplicant and
> NM as well ought to be congratulated on getting this into a working state.
> However there are further developments yet to be done - getting rt2x00 and ath5k
> working would be another huge step forward.

Can you give a little how-to or a link to resources you used to setup
wpa_supplicant to work at home and office?

>
> Yes, I can configure the necessary admin side in the background but the
> non-technical user sometimes would prefer not even to have to select a wireless
> AP from the NM menu.

My my family members I can see that choosing a network via some menue
(winxp or NM) is something they can handle but setting up a new
network connection for each one and then switching from one to other
is not in their domain...

> I have several family members who are F7 fans now but are definitely not
> technical when it comes to installing or setting up the system.

Great!

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From dcbw at redhat.com  Tue Oct 23 18:44:09 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 23 Oct 2007 14:44:09 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710231141m5273c5a5mc72306b76ccce986@mail.gmail.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<loom.20071022T170516-150@post.gmane.org>
	<64b14b300710231141m5273c5a5mc72306b76ccce986@mail.gmail.com>
Message-ID: <1193165049.26768.3.camel@localhost.localdomain>

On Tue, 2007-10-23 at 20:41 +0200, Valent Turkovic wrote:
> On 10/22/07, Mike C <mike.cohler at gmail.com> wrote:
> > Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> >
> > >
> > >
> > > Le Lun 22 octobre 2007 11:36, Valent Turkovic a ?crit :
> > >
> > > > Please make it on by default also for DVD install images.
> > >
> > > Till it works for all the systems Fedora targets (including those with
> > > no permanent GUI session that also need network/wifi connexion) the
> > > answer is no.
> >
> > Having recently got wpa_supplicant working in F7 with ipw2200 and another
> > machine with iwl3945, I am now definitely a fan of wpa_supplicant as opposed to
> > NM. I can configure a machine to bring up a wireless connection at boot now and
> > it will connect either at home or at work - and that is ideal for a user that
> > wants to boot and then load a browser and work with the web or then do office
> > stuff. The many people who have made the in-kernel drivers, wpa_supplicant and
> > NM as well ought to be congratulated on getting this into a working state.
> > However there are further developments yet to be done - getting rt2x00 and ath5k
> > working would be another huge step forward.
> 
> Can you give a little how-to or a link to resources you used to setup
> wpa_supplicant to work at home and office?

Usually you specify multiple network blocks in the conf file and as long
as ap_scan=1 wpa_supplicant will pick the first one that it can match to
some scan results.

Dan

> 
> >
> > Yes, I can configure the necessary admin side in the background but the
> > non-technical user sometimes would prefer not even to have to select a wireless
> > AP from the NM menu.
> 
> My my family members I can see that choosing a network via some menue
> (winxp or NM) is something they can handle but setting up a new
> network connection for each one and then switching from one to other
> is not in their domain...
> 
> > I have several family members who are F7 fans now but are definitely not
> > technical when it comes to installing or setting up the system.
> 
> Great!
> 
> -- 
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
> 



From mmcgrath at redhat.com  Tue Oct 23 19:00:53 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 23 Oct 2007 14:00:53 -0500
Subject: Smolts.org wiki
Message-ID: <471E44E5.8060902@redhat.com>

Smolt now has an integrated wiki (http://smolts.org/wiki/) and ratings 
system.  Submit your profile with smoltSendProfile then follow the URL 
it provides.  This will allow you to rate your hardware and click over 
to the wiki for your hardware.  If you have hardware with issues and can 
fix it, please fill in the relevant wiki page.  Soon there will be a 
scanner for users to run to see if pages exist for their hardware, if a 
page exists users will be directed their so they can get the most 
up-to-date information on making it work.

There's many more changes to come, stop by #smolt on irc.freenode.net if 
you're interested in more.

    -Mike



From jcm at redhat.com  Tue Oct 23 19:23:35 2007
From: jcm at redhat.com (Jon Masters)
Date: Tue, 23 Oct 2007 15:23:35 -0400
Subject: Multiarch crazyiness
In-Reply-To: <544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>
References: <471B9291.4060800@amiga-hardware.com>
	<1193082998.17860.7.camel@vincent52.localdomain>
	<20071022155624.39186440@redhat.com> <200710222254.35624@rineau.tsetse>
	<20071023123947.GA5231@jadzia.bu.edu>
	<544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>
Message-ID: <1193167416.22758.1.camel@perihelion>


On Tue, 2007-10-23 at 14:13 +0100, Bill Crawford wrote:
> On 23/10/2007, Matthew Miller <mattdm at mattdm.org> wrote:
> > On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > > > We prefer 32bit on those platforms.
> > > What if I have a x86_64 platform and nevertheless want only a 64-bits kernel
> > > and almost all 32-bits apps?
> >
> > Given the architecture constraints, why do you want that? Is this a real use
> > case that should be given serious consideration?
> 
> 32-bit code for most platforms is smaller *and* uses less memory
> (pointers at least being half the size). There is often a speed
> penalty too.

Right, and fewer instructions (for example, 5 instructions for a load
literal) but that doesn't mean there should be a codified rule - it
should be possible to have sensible enough packages that there is no
need for the installer or RPM to be too heavily hacked.

Jon.




From jcm at redhat.com  Tue Oct 23 19:31:00 2007
From: jcm at redhat.com (Jon Masters)
Date: Tue, 23 Oct 2007 15:31:00 -0400
Subject: Smolts.org wiki
In-Reply-To: <471E44E5.8060902@redhat.com>
References: <471E44E5.8060902@redhat.com>
Message-ID: <1193167860.22758.9.camel@perihelion>


On Tue, 2007-10-23 at 14:00 -0500, Mike McGrath wrote:
> Smolt now has an integrated wiki (http://smolts.org/wiki/) and ratings 
> system.  Submit your profile with smoltSendProfile then follow the URL 
> it provides.  This will allow you to rate your hardware and click over 
> to the wiki for your hardware.  If you have hardware with issues and can 
> fix it, please fill in the relevant wiki page.  Soon there will be a 
> scanner for users to run to see if pages exist for their hardware, if a 
> page exists users will be directed their so they can get the most 
> up-to-date information on making it work.
> 
> There's many more changes to come, stop by #smolt on irc.freenode.net if 
> you're interested in more.

I'm really enthused to see this happening. I actually planned to put
something like this together, then saw the announcement on FWN.

Anyway. I'd like to see this go beyond just hardware - I'd like to take
the user of a newly installed system immediately to a page identifying
their specific system, any known errata, and the like. It'll take some
work to go from a list of devices to inversely mapping that to the
machine in use, which vendor, where to get the errata information from
the vendor, and all of that. I'll share some of my ideas with you.

Jon.




From jon at fedoraunity.org  Tue Oct 23 19:54:19 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Tue, 23 Oct 2007 13:54:19 -0600
Subject: CDs DVDs or netboot.  Oh my!
In-Reply-To: <471E13E7.9050009@redhat.com>
References: <470D81BB.2070404@redhat.com>	<470D8ED8.9010509@BitWagon.com>	<470D9C88.9050106@redhat.com>	<1192075110.19308.21.camel@cutter>	<471A5BCE.5060708@kanarip.com>	<20071020200854.GA25455@angus.ind.WPI.EDU>	<471A65B6.8010808@kanarip.com>	<471A5929.10605@fedoraproject.org>	<471A6A08.7070507@kanarip.com>	<471A5E62.1050801@fedoraproject.org>	<471A7076.5050404@kanarip.com>	<471A637C.9090009@fedoraproject.org>	<471A7D48.7070803@kanarip.com>	<471A7162.4080004@fedoraproject.org>	<471B2444.8030901@kanarip.com>	<53266.63.85.68.164.1193057703.squirrel@mail.jcomserv.net>	<p04330102c342779f6e55@[192.168.123.162]>	<471DB48D.6080106@kanarip.com>
	<471E13E7.9050009@redhat.com>
Message-ID: <471E516B.6010106@fedoraunity.org>

Mike McGrath wrote:
> One thing I'd thought about a couple of times is creating a
> "http://ks.fedoraproject.org/" site that includes a minimal ks config,
> like method=http://path/to/our/mirrors"  it'd work with our current
> setup pretty easy, could even create install medium that defaults to
> it.  The main blocker is I'm not sure how anaconda will deal with bad
> mirrors (they do happen) and being able to switch mirrors in the middle
> of an install would be nice.

Having access to the mirror list at install time would be very nice
(automagically of course...) This would require anaconda to be able to
fail back mirrors, among other things. Right now, anaconda dies when a
package fails to download... there is no "oops, try again" and "hmm,
well look here instead" and we really need these features. I'm not sure
how much work it would be, but maybe I'll poke anaconda again, last time
it beat me.

-- 
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59



From tibbs at math.uh.edu  Tue Oct 23 19:59:27 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 23 Oct 2007 14:59:27 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <3835.192.54.193.51.1193136285.squirrel@rousalka.dyndns.org>
References: <3835.192.54.193.51.1193136285.squirrel@rousalka.dyndns.org>
Message-ID: <ufalk9t1u1s.fsf@epithumia.math.uh.edu>

>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

NM> Then that's not true free software, and has no place in
NM> Fedora.

I'm glad you've appointed yourself the sole arbiter of "true free
software" for all of us.

 - J<



From pertusus at free.fr  Tue Oct 23 20:00:44 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 22:00:44 +0200
Subject: script to get multiarch rpms on single arch
Message-ID: <20071023200044.GA2643@free.fr>

Hello,

Here is a quick and dirty script that allows to test multiarch conflicts
on non multiarch platforms by doing a koji scratch build, getting the
results, running multilib-cmp.py available at
http://katzj.fedorapeople.org/multilib-cmp.py
and then unpacking the rpms for manual diffs.

--
Pat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get_scratch_packages.sh
Type: application/x-sh
Size: 738 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/359f6635/attachment.sh>

From jspaleta at gmail.com  Tue Oct 23 20:06:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Oct 2007 12:06:58 -0800
Subject: script to get multiarch rpms on single arch
In-Reply-To: <20071023200044.GA2643@free.fr>
References: <20071023200044.GA2643@free.fr>
Message-ID: <604aa7910710231306t7deeb9b5v707becb6f22cd557@mail.gmail.com>

On 10/23/07, Patrice Dumas <pertusus at free.fr> wrote:
> Hello,
>
> Here is a quick and dirty script that allows to test multiarch conflicts
> on non multiarch platforms by doing a koji scratch build, getting the
> results, running multilib-cmp.py available at
> http://katzj.fedorapeople.org/multilib-cmp.py
> and then unpacking the rpms for manual diffs.

This is going to be quite handy for those of us stuck in the 20th
century and only have 32bit hardware locally.

-jef



From pertusus at free.fr  Tue Oct 23 20:10:01 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 23 Oct 2007 22:10:01 +0200
Subject: script to get multiarch rpms on single arch
In-Reply-To: <604aa7910710231306t7deeb9b5v707becb6f22cd557@mail.gmail.com>
References: <20071023200044.GA2643@free.fr>
	<604aa7910710231306t7deeb9b5v707becb6f22cd557@mail.gmail.com>
Message-ID: <20071023201000.GB2643@free.fr>

On Tue, Oct 23, 2007 at 12:06:58PM -0800, Jeff Spaleta wrote:
> On 10/23/07, Patrice Dumas <pertusus at free.fr> wrote:
> > Hello,
> >
> > Here is a quick and dirty script that allows to test multiarch conflicts
> > on non multiarch platforms by doing a koji scratch build, getting the
> > results, running multilib-cmp.py available at
> > http://katzj.fedorapeople.org/multilib-cmp.py
> > and then unpacking the rpms for manual diffs.
> 
> This is going to be quite handy for those of us stuck in the 20th
> century and only have 32bit hardware locally.

That's my case too, I wouldn't have done it otherwise ;-).

--
Pat



From nicolas.mailhot at laposte.net  Tue Oct 23 20:30:24 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 22:30:24 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <ufalk9t1u1s.fsf@epithumia.math.uh.edu>
References: <3835.192.54.193.51.1193136285.squirrel@rousalka.dyndns.org>
	<ufalk9t1u1s.fsf@epithumia.math.uh.edu>
Message-ID: <1193171424.5002.45.camel@rousalka.dyndns.org>


Le mardi 23 octobre 2007 ? 14:59 -0500, Jason L Tibbitts III a ?crit :
> >>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:
> 
> NM> Then that's not true free software, and has no place in
> NM> Fedora.
> 
> I'm glad you've appointed yourself the sole arbiter of "true free
> software" for all of us.

I did it the hard way for Java apps for years and I don't see why others
should have dispensations no one would have given me for my stuff then
or now just because figuring how to rebuild stuff is hard.

We should declare ELF a firmware format too, it's executed in a "KVM",
that should solve 99% of our rebuilding problems

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

From valent.turkovic at gmail.com  Tue Oct 23 20:30:52 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 23 Oct 2007 22:30:52 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
Message-ID: <64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>

On 10/22/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Lun 22 octobre 2007 11:36, Valent Turkovic a ?crit :
>
> > Please make it on by default also for DVD install images.
>
> Till it works for all the systems Fedora targets (including those with
> no permanent GUI session that also need network/wifi connexion) the
> answer is no.
>
> Right now NetworkManager is targetting a very small user niche, so
> it's only usable as default in the spin dedicated to this niche (and
> one could argue the spin desktop target audience is wider than the
> laptop-only no-daemon dumbed-down desktop NetworkManager supports)

Ok, I trust you have much more expertise with this topic.

Can I ask you (and all other fedora devels) one general question that
regards usability, desktop users and wireless...?

How do you expect average users who are new to linux and install
fedora from DVD to use wireless?

Is the NetworkManager only option (if they find it and start it in the
first place)? Are you making some fedora specific tool for easy
connectivity based on system-config-network?

Is using system-config-network only way of setting up and using
wireless network via gui in fedora?

Thank you for all of your comments,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From ml at deadbabylon.de  Tue Oct 23 20:34:56 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 23 Oct 2007 22:34:56 +0200
Subject: KDE-SIG weekly report (43/2007)
Message-ID: <200710232235.01457.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the topics 
that were discussed.
If you want to add a comment please reply to this email or add it to the 
related meeting page.

-----------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 43/2007

Time: 2007-10-23 17:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-23

Meeting Log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-23?action=AttachFile&do=get&target=fedora-kde-sig-2007-10-23.txt

-----------------------------------------------------------------------------

= Participants = 

RexDieter 
KevinKofler 
SebastianVahl 
AdelGadllah (drago01) 
DennisGilmore 

= Agenda =

* Pulseaudio in KDE (Setup [1], Thread on fedora-devel-ml [2]) 
* Infinity Splash Screen for KDE (#336301, Thread on fedora-art-list [3], 
initial version [4]) 
* beryl is dead. Is compiz-kde usable? 
* How well does nm-applet work as a replacement for knetworkmanager? 
* Defining a Top-5-List of the "most-needed-next-topics" to work on (to give 
new SIG-Members an advice where we need the most work) 
* Adjust the color scheme to match the default wallpaper (#295631) 
* Usage of fedora-bookmarks also in konqueror (#344711) 
* KDE 3.94.0 (development platform) for Fedora 7 and 8

= Summary =

o Pulseaudio: 
- We will use pulseaudio by default in Fedora 8 
- A script in /etc/kde/env/ will start pulseaudio for KDE (because there seems 
to be no interest in system-wide usage of pulseaudio) 
- With pulseaudio only started in a full session of KDE audio support won't be 
available in apps that are started outside a full session and if pulseaudio 
isn't running 
- RexDieter will find out where the best place is to put this in 

o Infinity Splash Screen: 
- artwork people offered help but at time of the meeting there was no existing 
splash 
- we will use kde's default (splash if no splash occurs later the day) 

o compiz/beryl: 
- compiz is obsoleting beryl now so that upgrade path will work 
- we have a quick hack for switching compiz<->kwin based on compiz-manager 
(which isn't submitted for review yet) 
- getting a package in fedora for f8-final would be difficult 
- SebastianVahl will submit compiz-manager for review 

o knetworkmanager: 
- /etc/skel/.kde/{env,shutdown} will be moved to /etc/kde/{env,shutdown} to 
not only affect newly created user accounts 
- RexDieter will also add some minor modifications to knetworkmanager 
- SebastianVahl re-included knetworkmanager on the live images again 

o adjust color scheme: 
- the adjusted color scheme will be included as default 
- later adjustements could be done then 

o use fedora-bookmarks: 
- it is unclear for the moment how to use fedora-bookmarks directly in 
konqueror and if this is possible 
- Plan: inlcude a snapshot now and try to figure out how to use 
fedora-bookmarks directly later 

o KDE 3.94.0 for F7, F8: 
- KDE 3.94 is built for devel (rawhide for f9) 
- kdebase-workspace isn't existing yet 
- KDE 3.94 will be prepared for integration into f8-updates-testing and 
f7-updates-testing 

o Top-5-List of the "most-needed-next-topics" to work on (for new SIG 
members...): 
- Such a list could help new contributors to give an advice where their help 
is most needed 
- But this list will change often and also become outdated quickly 
- A new wiki page will be prepared for the next meeting 

o Open discussion: 
- SebastianVahl has written to all the listed "participants" in the KDE-SIG 
for their opinion about culling down the list of participants (see last 
meeting). No response yet. 
- If more duplicated entries in kmenu are known which hasn't a bug yet they 
should be inserted in bugzilla

= Links =

[1] http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
[2] 
https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01442.html
[3]  
https://www.redhat.com/archives/fedora-art-list/2007-October/msg00149.html
[4] http://www.math.unl.edu/~rdieter1/Infinity/


-----------------------------------------------------------------------------

Next meeting:
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-30

-------------- 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/20071023/6a4d081a/attachment.sig>

From valent.turkovic at gmail.com  Tue Oct 23 20:43:01 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 23 Oct 2007 22:43:01 +0200
Subject: how to enable forbidden multimedia in Rawhide?
Message-ID: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>

Is there a drop-in way of enabling multimedia in fedora 8 devel
version (rawhide)?

I wanted to pay for fluendo codec pack but they don't accept AmEx :(

I don't wan't to recompile anything.

AFAIK there are no 3rd party rpm repos that have multimedia rpms but
that would work for me great if there are any.

Any ideas how to enable multimedia in rawhide?

ps. I live in Europe so it is legal for me to enable multimedia.

Thank you in advance,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From dominik at greysector.net  Tue Oct 23 20:49:08 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 23 Oct 2007 22:49:08 +0200
Subject: how to enable forbidden multimedia in Rawhide?
In-Reply-To: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>
References: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>
Message-ID: <20071023204908.GB14804@ryvius.pekin.waw.pl>

On Tuesday, 23 October 2007 at 22:43, Valent Turkovic wrote:
> Is there a drop-in way of enabling multimedia in fedora 8 devel
> version (rawhide)?
> 
> I wanted to pay for fluendo codec pack but they don't accept AmEx :(
> 
> I don't wan't to recompile anything.
> 
> AFAIK there are no 3rd party rpm repos that have multimedia rpms but
> that would work for me great if there are any.
> 
> Any ideas how to enable multimedia in rawhide?
> 
> ps. I live in Europe so it is legal for me to enable multimedia.

livna has a development repo. Just install the livna-release rpm for F-7
and use --disablerepo=livna --enablerepo=livna-development (or set things
in /etc/yum.repos.d/livna.repo by hand)

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From nicolas.mailhot at laposte.net  Tue Oct 23 20:49:50 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 23 Oct 2007 22:49:50 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
Message-ID: <1193172590.5002.57.camel@rousalka.dyndns.org>


Le mardi 23 octobre 2007 ? 22:30 +0200, Valent Turkovic a ?crit :

> Ok, I trust you have much more expertise with this topic.

I don't have more expertise than being told time after time by the
NetworkManager guys that their stuff depended on a GNOME applet and that
it was not intended to work for systems that ran network-dependant
daemons or did network-dependant stuff outside the GUI session.

So it's not a general networking solution. Therefore it's not a suitable
default for the Fedora DVD version, which is supposed to be
general-purpose.

And that sucks for you and Fedora in general but I didn't dig this
particular hole. I'd be the first delighted person if the NetworkManager
team told us "we want to be the general Fedora networking solution, and
be enabled by default on more than the desktop spin".

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

From jkeating at redhat.com  Tue Oct 23 20:54:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 16:54:41 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <1193172590.5002.57.camel@rousalka.dyndns.org>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
Message-ID: <20071023165441.4c996843@redhat.com>

On Tue, 23 Oct 2007 22:49:50 +0200
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> And that sucks for you and Fedora in general but I didn't dig this
> particular hole. I'd be the first delighted person if the
> NetworkManager team told us "we want to be the general Fedora
> networking solution, and be enabled by default on more than the
> desktop spin".


That's the plan for F9, and why NM got a rewrite in F8.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/a9aef6c6/attachment.sig>

From dcbw at redhat.com  Tue Oct 23 21:23:32 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 23 Oct 2007 17:23:32 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071023165441.4c996843@redhat.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
Message-ID: <1193174612.7110.11.camel@localhost.localdomain>

On Tue, 2007-10-23 at 16:54 -0400, Jesse Keating wrote:
> On Tue, 23 Oct 2007 22:49:50 +0200
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> > And that sucks for you and Fedora in general but I didn't dig this
> > particular hole. I'd be the first delighted person if the
> > NetworkManager team told us "we want to be the general Fedora
> > networking solution, and be enabled by default on more than the
> > desktop spin".
> 
> 
> That's the plan for F9, and why NM got a rewrite in F8.

Right; NM 0.7 and later is definitely _not_ targetted at a "very narrow
niche".  It's targeted at hopefully >= 75% of the use-cases of Fedora.

Perhaps this weekend (unless I'm still fixing bugs with NM in general)
I'll integrate the work Soren did for a system config service which will
allow connections to be brought up before you log in.  That's the only
real blocker to using NM in a GUI-less server-type environment if you
like.  Other than that, most of the bits for static IP support are in
(applet bits to follow), the options to lock things like 802.3 duplex,
speed, and other stuff are in-progress by Tambet, and most of the
wireless options work.  

By the holidays, I expect we can flip NM on by default in Rawhide, even
if it's not default in F8.

Dan




From choeger at cs.tu-berlin.de  Tue Oct 23 19:31:54 2007
From: choeger at cs.tu-berlin.de (=?UTF-8?B?Q2hyaXN0b3BoIEjDtmdlcg==?=)
Date: Tue, 23 Oct 2007 21:31:54 +0200
Subject: fontsize in 7.92
In-Reply-To: <1193161105.9545.12.camel@localhost6.localdomain6>
References: <1193093017.3574.3.camel@localhost.localdomain>	<1193073308.28655.5.camel@rousalka.dyndns.org>	<1193112112.3773.4.camel@localhost.localdomain>	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193161105.9545.12.camel@localhost6.localdomain6>
Message-ID: <471E4C2A.4020103@cs.tu-berlin.de>

Richi Plana schrieb:
> On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
>   
>> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
>>
>>     
>>> is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
>>> Display to see more information on my screen simultaneously 
>>>       
>> If you want small fonts just lower the size in points of your fonts in
>> your app preferences. Gnome font preferences use pt as unit. Till now
>> the GNOME pt unit had no relation with the pt unit the rest of the world
>> uses. Now it's the same, so if you want small fonts you need to actually
>> configure small fonts and not change the unit meaning on your system
>> (and likewise if you want big fonts).
>>
>> That also means BTW that when you change laptop again your text will
>> stay the same size regardless of the screen resolution, so you can
>> invest the time to find good settings you'll keep them a long time.
>>     
>
> I, for one, am glad that there's a move to make font sizes be based on
> length rather than point sizes.
>
> The selection of a default font size is still crap-shoot, at best.
> Having the monitor DPI as a dependency now allows people to say "I want
> fonts that are so-and-so millimeters in height", unfortunately, 1) we
> still lack information like distance of the viewer from the screen and
> the height of the screen relative to the viewer, and 2) we've no way to
> guess what the user would want, anyway. There are a couple of
> discussions on the most ergonomic distance between monitor and viewer,
> but font size preference is pretty varied. The only way to find out is
> to let the gnome desktop provide feedback (a'la Smolt) after the user
> has customized the desktop to his/her preference. Perhaps than a norm
> can be established.
>
> Personally, I would like to set my font size preference in some length
> unit of measure so that I can bump up the resolution and not have the
> fonts and icons shrink to sizes I can hardly read. It's important for me
> to see a lot more information on the screen, but not to the point where
> it becomes useless because they're too small that I keep having to
> squint. Believe me, straining ones eyesight like that will eventually
> take its toll.
> --
>
> Richi Plana
>
>   
I totally agree with your point.
But in my case that would mean to have one choice to use "small fonts" 
instead of "normal fonts". I think that choosing (and testing) every 
font size until it fits your needs is a little too much work for a 
normal user to have a comfortable desktop. So could we provide a 
"small/normal/large font" switch or even theme?

christoph



From bruno at wolff.to  Tue Oct 23 21:31:48 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 23 Oct 2007 16:31:48 -0500
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071023165441.4c996843@redhat.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
Message-ID: <20071023213148.GA17864@wolff.to>

On Tue, Oct 23, 2007 at 16:54:41 -0400,
  Jesse Keating <jkeating at redhat.com> wrote:
> On Tue, 23 Oct 2007 22:49:50 +0200
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> > And that sucks for you and Fedora in general but I didn't dig this
> > particular hole. I'd be the first delighted person if the
> > NetworkManager team told us "we want to be the general Fedora
> > networking solution, and be enabled by default on more than the
> > desktop spin".
> 
> 
> That's the plan for F9, and why NM got a rewrite in F8.

I was looking for information on NM yesterday and the information I saw
suggested that it was not intended to be a general network configuration
tool. But in fact seemed to be mostly suited for people who want to connect
to wireless networks opportunisticly and who use DHCP to get their wired
IP addresses. There was a statement that for static IP addresses it was
going to get that data from the network config scripts data.

Is there some roadmap documentation somewhere that suggests a more
ambitious plan?



From jkeating at redhat.com  Tue Oct 23 21:45:21 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 17:45:21 -0400
Subject: cvs-import.sh change (import to branch in cwd)
Message-ID: <20071023174521.17cc6fef@redhat.com>

I've made a small change to cvs-import.sh to keep it more in line with
the internal Red Hat version.  When importing packages it will use the
existence of a 'branch' file in your cwd to determine what branch to
import to by default.  This can still be overridden by -b.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/2dbf29fa/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From 777tahder at schlaegel.com  Tue Oct 23 22:03:35 2007
From: 777tahder at schlaegel.com (Schlaegel)
Date: Tue, 23 Oct 2007 15:03:35 -0700
Subject: Smolts.org wiki
In-Reply-To: <471E44E5.8060902@redhat.com>
References: <471E44E5.8060902@redhat.com>
Message-ID: <4e1f5c1a0710231503m737e0e73t4d0ee081e22601bd@mail.gmail.com>

On 10/23/07, Mike McGrath <mmcgrath at redhat.com> wrote:
> Smolt now has an integrated wiki (http://smolts.org/wiki/) and ratings
> system.  Submit your profile with smoltSendProfile then follow the URL
> it provides.  This will allow you to rate your hardware and click over
> to the wiki for your hardware.  If you have hardware with issues and can
> fix it, please fill in the relevant wiki page.  Soon there will be a
> scanner for users to run to see if pages exist for their hardware, if a
> page exists users will be directed their so they can get the most
> up-to-date information on making it work.

Please only allow the user who submitted the profile to rate the
profile. Currently, it seems that I can rate anyone's profile and
anyone can rate my profile.



From nicolas.mailhot at laposte.net  Tue Oct 23 22:32:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 24 Oct 2007 00:32:07 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071023165441.4c996843@redhat.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
Message-ID: <1193178727.29253.3.camel@rousalka.dyndns.org>


Le mardi 23 octobre 2007 ? 16:54 -0400, Jesse Keating a ?crit :
> On Tue, 23 Oct 2007 22:49:50 +0200
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> > And that sucks for you and Fedora in general but I didn't dig this
> > particular hole. I'd be the first delighted person if the
> > NetworkManager team told us "we want to be the general Fedora
> > networking solution, and be enabled by default on more than the
> > desktop spin".
> 
> 
> That's the plan for F9, and why NM got a rewrite in F8.

That's a very nice announce and hopefully will put an end to the
confusing networking state of Fedora. Many thanks to the NetworkManager
team! I hope we manage to get F9 out with a single unified networking
system shared by every Fedora spin.

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

From bloch at verdurin.com  Tue Oct 23 22:32:22 2007
From: bloch at verdurin.com (Adam Huffman)
Date: Tue, 23 Oct 2007 23:32:22 +0100
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <1193174612.7110.11.camel@localhost.localdomain>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
Message-ID: <20071023223222.GA26820@asus.config>

On Tue, 23 Oct 2007, Dan Williams wrote:

> Right; NM 0.7 and later is definitely _not_ targetted at a "very narrow
> niche".  It's targeted at hopefully >= 75% of the use-cases of Fedora.
> 
> Perhaps this weekend (unless I'm still fixing bugs with NM in general)
> I'll integrate the work Soren did for a system config service which will
> allow connections to be brought up before you log in.  That's the only
> real blocker to using NM in a GUI-less server-type environment if you
> like.  Other than that, most of the bits for static IP support are in
> (applet bits to follow), the options to lock things like 802.3 duplex,
> speed, and other stuff are in-progress by Tambet, and most of the
> wireless options work.  
> 
> By the holidays, I expect we can flip NM on by default in Rawhide, even
> if it's not default in F8.
> 

A general comment re. NM.  It did seem odd the way such a large change
was made so late in the F8 development cycle, with no real discussion I
could see (please do point me to such a discussion if there was one).

For quite a long time it was unusable for lots of people and still seems
a little flaky.

Was it a case of the rewrite taking longer than planned?



From fedora at camperquake.de  Tue Oct 23 22:34:37 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 24 Oct 2007 00:34:37 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <471DDD42.3030403@hhs.nl>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl> <471CC6B6.8090503@gmail.com>
	<1193085056.22958.23.camel@localhost.localdomain>
	<ufa640yah7q.fsf@epithumia.math.uh.edu>
	<20071023111449.GA12433@devserv.devel.redhat.com>
	<471DDD42.3030403@hhs.nl>
Message-ID: <20071024003437.00754034@lain.camperquake.de>

Hi.

On Tue, 23 Oct 2007 13:38:42 +0200, Hans de Goede wrote

> Probably not, as it uses a pretty advanced basic dialect, but it
> might be worth a shot. Anyone got a list of those free basics handy?

Somehow the phrase "pretty advanced basic" gets my brain into a knot.



From jspaleta at gmail.com  Tue Oct 23 22:36:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 23 Oct 2007 14:36:58 -0800
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <20071024003437.00754034@lain.camperquake.de>
References: <15145.192.54.193.51.1193042393.squirrel@rousalka.dyndns.org>
	<471C64E5.4070908@hhs.nl>
	<adf480660710220158t701e9608le46415d8e1382902@mail.gmail.com>
	<471C6810.5070200@hhs.nl> <471CC6B6.8090503@gmail.com>
	<1193085056.22958.23.camel@localhost.localdomain>
	<ufa640yah7q.fsf@epithumia.math.uh.edu>
	<20071023111449.GA12433@devserv.devel.redhat.com>
	<471DDD42.3030403@hhs.nl>
	<20071024003437.00754034@lain.camperquake.de>
Message-ID: <604aa7910710231536s3cceb734xace0a8022c25974d@mail.gmail.com>

On 10/23/07, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Somehow the phrase "pretty advanced basic" gets my brain into a knot.

yeah the word pretty just doesn't really work in that sentence.
s/pretty/grotesque  and you should feel better reading it.

-jef



From bnocera at redhat.com  Tue Oct 23 22:42:01 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 23 Oct 2007 23:42:01 +0100
Subject: how to enable forbidden multimedia in Rawhide?
In-Reply-To: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>
References: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>
Message-ID: <1193179321.25405.107.camel@cookie.hadess.net>


On Tue, 2007-10-23 at 22:43 +0200, Valent Turkovic wrote:
> Is there a drop-in way of enabling multimedia in fedora 8 devel
> version (rawhide)?

http://www.gnome.org/projects/totem/

Follow the links. Livna does a devel branch as well, which is what I use
for testing.



From fedora at camperquake.de  Tue Oct 23 22:53:54 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 24 Oct 2007 00:53:54 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
Message-ID: <20071024005354.2f2cc521@lain.camperquake.de>

Hi.

On Tue, 23 Oct 2007 15:25:26 +0400, Peter Lemenkov wrote

> We need to distinguish between *real* code which natively executes on
> CPU and any other binary content which not executes natively. Win32
> executables, ROMs, JARs are IMHO definitely falls into this category
> (content). As pictures, music and text-files they do not runs on CPU
> directly.

Win32 binaries (when run on x86, unless you found an old Alpha binary
somewhere) _do_ run natively on the host CPU. Wine does not emulate the
CPU, it 'just' provides the execution environment (libraries, kernel calls)
a Windows binary expects. Program code that is not spent in libraries or
in the kernel is executed natively on the CPU.



From david at lovesunix.net  Tue Oct 23 22:58:51 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 24 Oct 2007 00:58:51 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <1193174612.7110.11.camel@localhost.localdomain>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
Message-ID: <1193180331.3062.4.camel@dawkins>


tir, 23 10 2007 kl. 17:23 -0400, skrev Dan Williams:
> On Tue, 2007-10-23 at 16:54 -0400, Jesse Keating wrote:
> > On Tue, 23 Oct 2007 22:49:50 +0200
> > Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> > 
> > > And that sucks for you and Fedora in general but I didn't dig this
> > > particular hole. I'd be the first delighted person if the
> > > NetworkManager team told us "we want to be the general Fedora
> > > networking solution, and be enabled by default on more than the
> > > desktop spin".
> > 
> > 
> > That's the plan for F9, and why NM got a rewrite in F8.
> 
> Right; NM 0.7 and later is definitely _not_ targetted at a "very narrow
> niche".  It's targeted at hopefully >= 75% of the use-cases of Fedora.
> 
> Perhaps this weekend (unless I'm still fixing bugs with NM in general)
> I'll integrate the work Soren did for a system config service which will
> allow connections to be brought up before you log in.  That's the only
> real blocker to using NM in a GUI-less server-type environment if you
> like.  Other than that, most of the bits for static IP support are in
> (applet bits to follow), the options to lock things like 802.3 duplex,
> speed, and other stuff are in-progress by Tambet, and most of the
> wireless options work.  

Excellent to hear, I'm looking forward to deploying this on my home
server. NM has gotten really stable for me over the past few days, so
I'm overall very pleased with things given that a solution for headless
setups is being worked on.

(un)related question, one problem I'm currently experiencing on all my
boxes that run NM is that ntp starts up before a network connection is
available. It's not a huge issue but it would be a nice thing to fix
down the line.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/2981eddc/attachment.sig>

From mmcgrath at redhat.com  Tue Oct 23 23:20:31 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 23 Oct 2007 18:20:31 -0500
Subject: Smolts.org wiki
In-Reply-To: <4e1f5c1a0710231503m737e0e73t4d0ee081e22601bd@mail.gmail.com>
References: <471E44E5.8060902@redhat.com>
	<4e1f5c1a0710231503m737e0e73t4d0ee081e22601bd@mail.gmail.com>
Message-ID: <471E81BF.1060600@redhat.com>

Schlaegel wrote:
> On 10/23/07, Mike McGrath <mmcgrath at redhat.com> wrote:
>   
>> Smolt now has an integrated wiki (http://smolts.org/wiki/) and ratings
>> system.  Submit your profile with smoltSendProfile then follow the URL
>> it provides.  This will allow you to rate your hardware and click over
>> to the wiki for your hardware.  If you have hardware with issues and can
>> fix it, please fill in the relevant wiki page.  Soon there will be a
>> scanner for users to run to see if pages exist for their hardware, if a
>> page exists users will be directed their so they can get the most
>> up-to-date information on making it work.
>>     
>
> Please only allow the user who submitted the profile to rate the
> profile. Currently, it seems that I can rate anyone's profile and
> anyone can rate my profile.
>   

We're working on that.  For now, don't give out your UUID :)

    -Mike



From ndbecker2 at gmail.com  Tue Oct 23 23:29:39 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 23 Oct 2007 19:29:39 -0400
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
Message-ID: <ffm054$orp$1@ger.gmane.org>

Rex Dieter wrote:

> Neal Becker wrote:
> 
>> Rex Dieter wrote:
>> 
>>> Rex Dieter wrote:
>>> 
>>>> Here's some notes on making PulseAudio work with KDE,
>>>> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
>>>> which turned out to be painfully easy.
>>> 
>>> Really, to make this work, all we needed was pulseaudio getting
>>> autostarted
>>> with the session.  After chatting on fedora-desktop, we tried the
>>> /etc/X11/xinit.d/pulseaudio.sh containing
>>> pulseaudio -D
>>> solution (I initially had tried an over-complicated xdg/autostart
>>> setup).
>>> 
>>> Could this (or something like it) be considered for inclusion in F8's
>>> pulseaudio pkg?
> 
>> Did you mean /etc/X11/xinitrc.d ?
> 
> Yes.
> 
> -- Rex
> 
> 

I tried this with amarok.  I see that after starting pulseaudio, and
selecting pulseaudio as output in amarok, seems to work.  But, now I have
instead of 2 volume controls to play with, 3 of them.  One in amarok, one
in kmix, and 1 in  'pulse audio volume control'.  Not really user friendly.  



From rdieter at math.unl.edu  Tue Oct 23 23:41:09 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Oct 2007 18:41:09 -0500
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
	<ffm054$orp$1@ger.gmane.org>
Message-ID: <ffm0ql$q43$1@ger.gmane.org>

Neal Becker wrote:

> Rex Dieter wrote:
> 
>> Neal Becker wrote:
>> 
>>> Rex Dieter wrote:
>>> 
>>>> Rex Dieter wrote:
>>>> 
>>>>> Here's some notes on making PulseAudio work with KDE,
>>>>> http://fedoraproject.org/wiki/RexDieter/PulseAudioKDE
>>>>> which turned out to be painfully easy.
>>>> 
>>>> Really, to make this work, all we needed was pulseaudio getting
>>>> autostarted
>>>> with the session.  After chatting on fedora-desktop, we tried the
>>>> /etc/X11/xinit.d/pulseaudio.sh containing
>>>> pulseaudio -D
>>>> solution (I initially had tried an over-complicated xdg/autostart
>>>> setup).
>>>> 
>>>> Could this (or something like it) be considered for inclusion in F8's
>>>> pulseaudio pkg?
>> 
>>> Did you mean /etc/X11/xinitrc.d ?
>> 
>> Yes.
>> 
>> -- Rex
>> 
>> 
> 
> I tried this with amarok.  I see that after starting pulseaudio, and
> selecting pulseaudio as output in amarok, seems to work.  But, now I have
> instead of 2 volume controls to play with, 3 of them.  One in amarok, one
> in kmix, and 1 in  'pulse audio volume control'.  Not really user
> friendly.
> 

Well, take either kmix(arts) or pa volume out, and you're back to 2.

fyi, just comitted a kde-settings-pulseaudio subpkg implementing the ideas
from the aforementioned PulseAudioKDE page, so now you're just a
yum install kde-settings-pulseaudio
away from trying it out.  This is/will-be part of the default kde-desktop
install for f8.  

Thanks all for the feedback.

-- Rex



From sandeen at redhat.com  Tue Oct 23 23:45:37 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 23 Oct 2007 18:45:37 -0500
Subject: Smolts.org wiki
In-Reply-To: <471E81BF.1060600@redhat.com>
References: <471E44E5.8060902@redhat.com>	<4e1f5c1a0710231503m737e0e73t4d0ee081e22601bd@mail.gmail.com>
	<471E81BF.1060600@redhat.com>
Message-ID: <471E87A1.3040203@redhat.com>

Mike McGrath wrote:
> Schlaegel wrote:
>> On 10/23/07, Mike McGrath <mmcgrath at redhat.com> wrote:
>>   
>>> Smolt now has an integrated wiki (http://smolts.org/wiki/) and ratings
>>> system.  Submit your profile with smoltSendProfile then follow the URL
>>> it provides.  This will allow you to rate your hardware and click over
>>> to the wiki for your hardware.  If you have hardware with issues and can
>>> fix it, please fill in the relevant wiki page.  Soon there will be a
>>> scanner for users to run to see if pages exist for their hardware, if a
>>> page exists users will be directed their so they can get the most
>>> up-to-date information on making it work.
>>>     
>> Please only allow the user who submitted the profile to rate the
>> profile. Currently, it seems that I can rate anyone's profile and
>> anyone can rate my profile.
>>   
> 
> We're working on that.  For now, don't give out your UUID :)
> 
>     -Mike
> 

FWIW there's a wishlist page at
http://smolt.fedoraproject.org/wiki/Smolt_Wishlist :)

-Eric



From bnocera at redhat.com  Tue Oct 23 23:47:57 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 24 Oct 2007 00:47:57 +0100
Subject: F8+KDE+PulseAudio
In-Reply-To: <ffm054$orp$1@ger.gmane.org>
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
	<ffm054$orp$1@ger.gmane.org>
Message-ID: <1193183277.25405.111.camel@cookie.hadess.net>


On Tue, 2007-10-23 at 19:29 -0400, Neal Becker wrote:
<snip>
> I tried this with amarok.  I see that after starting pulseaudio, and
> selecting pulseaudio as output in amarok, seems to work.  But, now I have
> instead of 2 volume controls to play with, 3 of them.  One in amarok, one
> in kmix, and 1 in  'pulse audio volume control'.  Not really user friendly.  

The exact same problem exists for GNOME apps, and that's something
Lennart will be working on fixing in the future, with help from the ALSA
maitainers.



From jkeating at redhat.com  Wed Oct 24 00:06:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 20:06:37 -0400
Subject: F8+KDE+PulseAudio
In-Reply-To: <ffm054$orp$1@ger.gmane.org>
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
	<ffm054$orp$1@ger.gmane.org>
Message-ID: <20071023200637.33a398f3@redhat.com>

On Tue, 23 Oct 2007 19:29:39 -0400
Neal Becker <ndbecker2 at gmail.com> wrote:

> I tried this with amarok.  I see that after starting pulseaudio, and
> selecting pulseaudio as output in amarok, seems to work.  But, now I
> have instead of 2 volume controls to play with, 3 of them.  One in
> amarok, one in kmix, and 1 in  'pulse audio volume control'.  Not
> really user friendly.  


IMHO the PA mixer should always just be maxed.  Then you can use the
app mixer and/or the system (kmix) mixer to adjust stuff.  In gnome it
works that way, the panel volume control deals directly with alsa, the
app deals with the app and I just leave PA alone.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/429b3cd4/attachment.sig>

From jkeating at redhat.com  Wed Oct 24 00:07:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 23 Oct 2007 20:07:41 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071023223222.GA26820@asus.config>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
	<20071023223222.GA26820@asus.config>
Message-ID: <20071023200741.262e5835@redhat.com>

On Tue, 23 Oct 2007 23:32:22 +0100
Adam Huffman <bloch at verdurin.com> wrote:

> A general comment re. NM.  It did seem odd the way such a large change
> was made so late in the F8 development cycle, with no real discussion
> I could see (please do point me to such a discussion if there was
> one).
> 
> For quite a long time it was unusable for lots of people and still
> seems a little flaky.
> 
> Was it a case of the rewrite taking longer than planned?

This was discussed and tracked many times in FESCo meetings.  It was
deemed important enough to work through the delays and have the rewrite
for F8, leading to a on by default in F9.  Not the least of which if we
didn't use it, and say Ubuntu did before us, there is more thunder
stolen (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/287fd145/attachment.sig>

From abartlet at samba.org  Wed Oct 24 00:24:06 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 24 Oct 2007 10:24:06 +1000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E31AC.8060803@REDHAT.COM>
References: <200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
	<20071023151135.GD2960@redhat.com>
	<1193152772.23200.14.camel@localhost.localdomain>
	<471E2F6D.7070202@REDHAT.COM> <20071023173046.GC2680@free.fr>
	<471E31AC.8060803@REDHAT.COM>
Message-ID: <1193185446.3196.10.camel@naomi>


On Tue, 2007-10-23 at 10:38 -0700, Robert Relyea wrote:
> Patrice Dumas wrote:
> > On Tue, Oct 23, 2007 at 10:29:17AM -0700, Robert Relyea wrote:
> >   
> >> If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
> >> fundamentally broken, has been for 10 years. There is only one legitimate 
> >> use of MD4 that I know of and that is support NTLM (Microsoft's old NT 
> >> authentication mechanism). In this case we need a common NTLM library that 
> >> all NTLM users call. Any other use of MD4 needs to be identified and 
> >>     
> >
> > There is libntlm existing:
> > http://josefsson.org/libntlm/
> >   
> Thanks, We should take a look at it. At this point there are a number of 
> ntlm libraries, mostly imbedded in various applications (mozilla, samba, 
> etc.). This does have the advantage of being a separate package, though.

I just looked, and this was still a very poor implemention.  Unicode is
not achieved by:

static unsigned char *
strToUnicode (const char *p, size_t l, unsigned char *buf)
{
  int i = 0;

  if (l > (NTLM_BUFSIZE / 2))
    l = (NTLM_BUFSIZE / 2);

  while (l--)
    {
      buf[i++] = *p++;
      buf[i++] = 0;
    }

  return buf;
}

My strong recommendation is to use Samba's ntlm_auth and winbind (as a
client and server) to handle seamless ntlm authentication, particularly
in single-sign-on situations.

Andrew Bartlett 

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071024/5b151f09/attachment.sig>

From abartlet at samba.org  Wed Oct 24 00:26:28 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 24 Oct 2007 10:26:28 +1000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471E2F6D.7070202@REDHAT.COM>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
	<20071023151135.GD2960@redhat.com>
	<1193152772.23200.14.camel@localhost.localdomain>
	<471E2F6D.7070202@REDHAT.COM>
Message-ID: <1193185588.3196.12.camel@naomi>


On Tue, 2007-10-23 at 10:29 -0700, Robert Relyea wrote:
> Simo Sorce wrote:
> > On Tue, 2007-10-23 at 16:11 +0100, Daniel P. Berrange wrote:
> >   
> >> Well for that matter GLibC itself has MD5 in it....
> >>     
> >
> > Quick! Make it depend on NSS! :-)
> >   
> in progress.;).
> > /simo with 3 packages with the same bug filed I can't possibly fix as
> > NSS simply do not have the relevant algorithms ...
> >   
> Which algorithms are missing?
> 
> If MD4 is one of the algorithms,  We have a plan for that. MD4 is 
> fundamentally broken, has been for 10 years. There is only one 
> legitimate use of MD4 that I know of and that is support NTLM 
> (Microsoft's old NT authentication mechanism). In this case we need a 
> common NTLM library that all NTLM users call. Any other use of MD4 needs 
> to be identified and potentially squashed. Blind use of MD4 is 
> detrimental to the security of our products.

I presume you are going to rework the rsync protocol too?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071024/e68b823a/attachment.sig>

From abartlet at samba.org  Wed Oct 24 01:13:49 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 24 Oct 2007 11:13:49 +1000
Subject: Should we settle on one SSL implementation?
In-Reply-To: <1193151905.25405.77.camel@cookie.hadess.net>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023143827.GA2960@redhat.com>
	<1193150534.6746.8.camel@vespa.kabelta.loc>
	<1193151905.25405.77.camel@cookie.hadess.net>
Message-ID: <1193188429.3196.27.camel@naomi>


On Tue, 2007-10-23 at 16:05 +0100, Bastien Nocera wrote:
> On Tue, 2007-10-23 at 16:42 +0200, Tomas Mraz wrote:
> > On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > > 
> > > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > > John Dennis wrote:
> > > > > 
> > > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > > ago all with the summary:
> > > > > > 
> > > > > > "Port XXX to use NSS library for cryptography"
> > > > > > 
> > > > > > I haven't seen a consensus this how package maintainers should be
> > > > > > spending their time.
> > > > > 
> > > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > > 
> > > > 
> > > > and a lot of them are wrong.
> > > 
> > > Yep, this is just creating yet bug triage work for maintainers. When entering
> > > tickets one could at least check the app in question to see if it actually
> > > uses the crypto libraries we're being told to remove. Not useful.
> > Not only crypto libraries but built-in code as well. I have checked that
> > the packages actually contain the code. I hardly could in reasonable
> > time check whether the code is always used and so on. I'd expect some
> > help from maintainers in these corner cases.
> 
> The problem I have with the bugs is the description. Most of my packages
> don't use "security" or encryption libraries. But they will have md5 or
> sha1 implementations. Do we really expect libraries with barely any
> dependencies to drag in NSS to do md5 or sha1?

It does seem that we should look at and solve the SSL part of this
problem first, even to the detriment of leaving part of a package's
migration to NSS incomplete, before going after each and every call of
md5().  

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- 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/20071024/f4601a16/attachment.sig>

From mjs at CLEMSON.EDU  Wed Oct 24 01:38:22 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Tue, 23 Oct 2007 21:38:22 -0400
Subject: fontsize in 7.92
In-Reply-To: <471E4C2A.4020103@cs.tu-berlin.de>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193161105.9545.12.camel@localhost6.localdomain6>
	<471E4C2A.4020103@cs.tu-berlin.de>
Message-ID: <1193189902.5103.4.camel@vincent52.localdomain>

On Tue, 2007-10-23 at 21:31 +0200, Christoph H?ger wrote:
> Richi Plana schrieb:
> > On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
> >   
> >> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
> >>
> >>     
> >>> is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> >>> Display to see more information on my screen simultaneously 
> >>>       
> >> If you want small fonts just lower the size in points of your fonts in
> >> your app preferences. Gnome font preferences use pt as unit. Till now
> >> the GNOME pt unit had no relation with the pt unit the rest of the world
> >> uses. Now it's the same, so if you want small fonts you need to actually
> >> configure small fonts and not change the unit meaning on your system
> >> (and likewise if you want big fonts).
> >>
> >> That also means BTW that when you change laptop again your text will
> >> stay the same size regardless of the screen resolution, so you can
> >> invest the time to find good settings you'll keep them a long time.
> >>     
> >
> > I, for one, am glad that there's a move to make font sizes be based on
> > length rather than point sizes.
> >
> > The selection of a default font size is still crap-shoot, at best.
> > Having the monitor DPI as a dependency now allows people to say "I want
> > fonts that are so-and-so millimeters in height", unfortunately, 1) we
> > still lack information like distance of the viewer from the screen and
> > the height of the screen relative to the viewer, and 2) we've no way to
> > guess what the user would want, anyway. There are a couple of
> > discussions on the most ergonomic distance between monitor and viewer,
> > but font size preference is pretty varied. The only way to find out is
> > to let the gnome desktop provide feedback (a'la Smolt) after the user
> > has customized the desktop to his/her preference. Perhaps than a norm
> > can be established.
> >
> > Personally, I would like to set my font size preference in some length
> > unit of measure so that I can bump up the resolution and not have the
> > fonts and icons shrink to sizes I can hardly read. It's important for me
> > to see a lot more information on the screen, but not to the point where
> > it becomes useless because they're too small that I keep having to
> > squint. Believe me, straining ones eyesight like that will eventually
> > take its toll.
> > --
> >
> > Richi Plana
> >
> >   
> I totally agree with your point.
> But in my case that would mean to have one choice to use "small fonts" 
> instead of "normal fonts". I think that choosing (and testing) every 
> font size until it fits your needs is a little too much work for a 
> normal user to have a comfortable desktop. 

Really?  How incompetent do we think "normal users" are?

Users that don't want to take the trouble and are willing to live with
the consequences will behave accordingly anyway.  For those of us that
tune our desktops to within an inch of their lives, leave us the option,
please?

> So could we provide a 
> "small/normal/large font" switch or even theme?

If this is the direction you want to go, could you at least leave the
full selection available as "advanced"?

> 
> christoph
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From buytenh at wantstofly.org  Wed Oct 24 02:10:40 2007
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Wed, 24 Oct 2007 04:10:40 +0200
Subject: multiarch header file wrappers and ARM
Message-ID: <20071024021040.GA30880@xi.wantstofly.org>

Hi,

A number of packages have multilib header file wrappers such as
this one (blkid_types.h from e2fsprogs):

	/* This file is here to prevent a file conflict on multiarch systems. A
	 * conflict will occur because blkid_types.h has arch-specific definitions.
	 *
	 * DO NOT INCLUDE THE NEW FILE DIRECTLY -- ALWAYS INCLUDE THIS ONE INSTEAD. */

	#if defined(__i386__)
	#include "blkid_types-i386.h"
	#elif defined(__ia64__)
	#include "blkid_types-ia64.h"
	#elif defined(__powerpc64__)
	#include "blkid_types-ppc64.h"
	#elif defined(__powerpc__)
	#include "blkid_types-ppc.h"
	#elif defined(__s390x__)
	#include "blkid_types-s390x.h"
	#elif defined(__s390__)
	#include "blkid_types-s390.h"
	#elif defined(__x86_64__)
	#include "blkid_types-x86_64.h"
	#elif defined(__alpha__)
	#include "blkid_types-alpha.h"
	#else
	#error "This e2fsprogs-devel package does not work your architecture?"
	#endif

It seems that most of such header files are (directly or indirectly)
copied from some original example that didn't test for ARM, and so,
a couple of examples in the distro right now lack the proper definitions
for ARM, causing ARM to end up with unusable -devel packages.

On ARM, the preprocessor symbol __arm__ is defined, and %{_arch} is
set to 'arm', so something like this will work:

	 #if defined(__i386__)
	 #include "blkid_types-i386.h"
	+#elif defined(__arm__)
	+#include "blkid_types-arm.h"
	 #elif defined(__ia64__)
	 #include "blkid_types-ia64.h"
	 #elif defined(__powerpc64__)

If you have such a construct in your package, please consider adding
the relevant __arm__ bits.


thanks,
Lennert



From rdieter at math.unl.edu  Wed Oct 24 03:46:13 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 23 Oct 2007 22:46:13 -0500
Subject: multiarch header file wrappers and ARM
References: <20071024021040.GA30880@xi.wantstofly.org>
Message-ID: <ffmf65$re6$1@ger.gmane.org>

Lennert Buytenhek wrote:

> On ARM, the preprocessor symbol __arm__ is defined, and %{_arch} is
> set to 'arm', so something like this will work:
> 
> #if defined(__i386__)
> #include "blkid_types-i386.h"
> +#elif defined(__arm__)
> +#include "blkid_types-arm.h"
> #elif defined(__ia64__)
> #include "blkid_types-ia64.h"
> #elif defined(__powerpc64__)
> 
> If you have such a construct in your package, please consider adding
> the relevant __arm__ bits.

Is arm even capable of multilib'ing?  If not, why even bother with hacks
like this?

-- Rex



From sandeen at redhat.com  Wed Oct 24 03:51:34 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 23 Oct 2007 22:51:34 -0500
Subject: multiarch header file wrappers and ARM
In-Reply-To: <ffmf65$re6$1@ger.gmane.org>
References: <20071024021040.GA30880@xi.wantstofly.org>
	<ffmf65$re6$1@ger.gmane.org>
Message-ID: <471EC146.3020600@redhat.com>

Rex Dieter wrote:
> Lennert Buytenhek wrote:
> 
>> On ARM, the preprocessor symbol __arm__ is defined, and %{_arch} is
>> set to 'arm', so something like this will work:
>>
>> #if defined(__i386__)
>> #include "blkid_types-i386.h"
>> +#elif defined(__arm__)
>> +#include "blkid_types-arm.h"
>> #elif defined(__ia64__)
>> #include "blkid_types-ia64.h"
>> #elif defined(__powerpc64__)
>>
>> If you have such a construct in your package, please consider adding
>> the relevant __arm__ bits.
> 
> Is arm even capable of multilib'ing?  If not, why even bother with hacks
> like this?

Maybe consistency so the specfile doesn't have to differentiate?  I dunno.

It seems like if this is the preferred way to handle this, something like

%multilib_wrap(headerfile)

would be handy in the rpm macros somewhere, if possible, and it could do
the right things for the right arches...

-Eric



From loganjerry at gmail.com  Wed Oct 24 04:05:24 2007
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 23 Oct 2007 22:05:24 -0600
Subject: Intel compiler helper package with an SELinux problem
Message-ID: <870180fe0710232105p28f6628cl97fee2c377db0dcd@mail.gmail.com>

I have a little helper package for use with Intel's C and C++
compilers (icc and icpc), and debugger (idb).  You can see what I have
here:

  http://jjames.fedorapeople.org/icc-extras/

It works okay, but I have two problems with it that I hope someone on
this list has the expertise to help me solve.  I'd like to eventually
contribute this package to Fedora if I can get the problems ironed
out.

First, Intel's package names change with every release because the
version number is embedded.  For example, the version I am using now
is:

  intel-icc100026-10.0.026-1

The previous version had a package name of intel-icc100025.  The files
install into directories containing the version number, for example
/opt/intel/cc/10.0.26.  This means that it is easy to install multiple
versions in parallel.  Unfortunately, it makes my life difficult.  My
package doesn't need to change anything but the Intel version number
as Intel releases new versions.  There are reasons for not wanting to
release a new version of my package every time Intel makes a release
(for example, different versions are available to paying customers and
cheapskates like me).  So I made my package put symbolic links named
"current" into Intel's directories, so that I can refer to
/opt/intel/cc/current.  The scripts try to detect when the symbolic
links break and take appropriate action.  This would be a lot easier
if I could use an rpm trigger, but as I mentioned above, the package
names change with each Intel release.  Does anyone have a better
approach to suggest?

Second, the "current" symbolic links cause an SELinux problem.  When I
ran ldconfig, I got this:

:avc: denied { read } for comm="ldconfig" dev=dm-0 egid=0 euid=0
exe="/sbin/ldconfig" exit=0 fsgid=0 fsuid=0 gid=0 items=0
name="current" pid=4734 scontext=user_u:system_r:ldconfig_t:s0 sgid=0
subj=user_u:system_r:ldconfig_t:s0 suid=0 tclass=lnk_file
tcontext=user_u:object_r:usr_t:s0 tty=pts2 uid=0

So, while thinking of a better approach to suggest, think of how I
might avoid this problem too, please. :-)

Thanks in advance for any help.
-- 
Jerry James
http://loganjerry.googlepages.com/



From lmacken at redhat.com  Wed Oct 24 05:53:51 2007
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 24 Oct 2007 01:53:51 -0400
Subject: Koji/Bodhi noise
Message-ID: <20071024055024.GA5021@crow.myhome.westell.com>

Apologies to those who got spammed tonight by koji notices due to
builds moving back and forth.  We have been having some occasional
issues composing our updates repositories, which are usually "resolved"
by the OOM killer.  When mash fails, bodhi rolls back all of it's
actions back to its previously stable state, thus generating lots of
koji spam (we're thinking of ways to mitigate this in the future).

No worries though; your updates will make it to the right place, and you can
safely ignore those messages.  It's much better to explode before things
hit the mirrors :)

luke



From choeger at cs.tu-berlin.de  Wed Oct 24 07:22:36 2007
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 24 Oct 2007 09:22:36 +0200
Subject: fontsize in 7.92
In-Reply-To: <1193189902.5103.4.camel@vincent52.localdomain>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193161105.9545.12.camel@localhost6.localdomain6>
	<471E4C2A.4020103@cs.tu-berlin.de>
	<1193189902.5103.4.camel@vincent52.localdomain>
Message-ID: <1193210556.22907.4.camel@s5.math.tu-berlin.de>

Please don't misunderstand me, I did not mean "too hard to do ist for
"normal users". I just meant that it is not comfortable to change each
font one by one if the target is to "just get the desktop fonts smaller
(and keep the current ratio)", not that it should not be possible to
change each font size individually.

Am Dienstag, den 23.10.2007, 21:38 -0400 schrieb Matthew Saltzman:
> On Tue, 2007-10-23 at 21:31 +0200, Christoph H?ger wrote:
> > Richi Plana schrieb:
> > > On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
> > >   
> > >> Le mardi 23 octobre 2007 ? 00:01 -0400, Christoph Hoeger a ?crit :
> > >>
> > >>     
> > >>> is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> > >>> Display to see more information on my screen simultaneously 
> > >>>       
> > >> If you want small fonts just lower the size in points of your fonts in
> > >> your app preferences. Gnome font preferences use pt as unit. Till now
> > >> the GNOME pt unit had no relation with the pt unit the rest of the world
> > >> uses. Now it's the same, so if you want small fonts you need to actually
> > >> configure small fonts and not change the unit meaning on your system
> > >> (and likewise if you want big fonts).
> > >>
> > >> That also means BTW that when you change laptop again your text will
> > >> stay the same size regardless of the screen resolution, so you can
> > >> invest the time to find good settings you'll keep them a long time.
> > >>     
> > >
> > > I, for one, am glad that there's a move to make font sizes be based on
> > > length rather than point sizes.
> > >
> > > The selection of a default font size is still crap-shoot, at best.
> > > Having the monitor DPI as a dependency now allows people to say "I want
> > > fonts that are so-and-so millimeters in height", unfortunately, 1) we
> > > still lack information like distance of the viewer from the screen and
> > > the height of the screen relative to the viewer, and 2) we've no way to
> > > guess what the user would want, anyway. There are a couple of
> > > discussions on the most ergonomic distance between monitor and viewer,
> > > but font size preference is pretty varied. The only way to find out is
> > > to let the gnome desktop provide feedback (a'la Smolt) after the user
> > > has customized the desktop to his/her preference. Perhaps than a norm
> > > can be established.
> > >
> > > Personally, I would like to set my font size preference in some length
> > > unit of measure so that I can bump up the resolution and not have the
> > > fonts and icons shrink to sizes I can hardly read. It's important for me
> > > to see a lot more information on the screen, but not to the point where
> > > it becomes useless because they're too small that I keep having to
> > > squint. Believe me, straining ones eyesight like that will eventually
> > > take its toll.
> > > --
> > >
> > > Richi Plana
> > >
> > >   
> > I totally agree with your point.
> > But in my case that would mean to have one choice to use "small fonts" 
> > instead of "normal fonts". I think that choosing (and testing) every 
> > font size until it fits your needs is a little too much work for a 
> > normal user to have a comfortable desktop. 
> 
> Really?  How incompetent do we think "normal users" are?
> 
> Users that don't want to take the trouble and are willing to live with
> the consequences will behave accordingly anyway.  For those of us that
> tune our desktops to within an inch of their lives, leave us the option,
> please?
> 
> > So could we provide a 
> > "small/normal/large font" switch or even theme?
> 
> If this is the direction you want to go, could you at least leave the
> full selection available as "advanced"?
> 
> > 
> > christoph
> > 
> > 
> -- 
>                 Matthew Saltzman
> 
> Clemson University Math Sciences
> mjs AT clemson DOT edu
> http://www.math.clemson.edu/~mjs
> 



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 24 08:20:11 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 24 Oct 2007 10:20:11 +0200
Subject: rpms/xpa/FC-6 xpa.spec,1.7,1.8
In-Reply-To: <200710232137.l9NLbuFP031094@cvs-int.fedora.redhat.com>
References: <200710232137.l9NLbuFP031094@cvs-int.fedora.redhat.com>
Message-ID: <20071024102011.57759411.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 23 Oct 2007 17:37:56 -0400, Sergio Pascual (sergiopr) wrote:

> Author: sergiopr
> 
> Update of /cvs/pkgs/rpms/xpa/FC-6
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31069
> 
> Modified Files:
> 	xpa.spec 
> Log Message:
> * Sat Oct 13 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 2.1.7-0.3.b2
> - Splitted libraries in a new package
> * Mon Aug 27 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.7-0.2.b2.1
> - Added /bin/awk to BuildReq
> * Mon Aug 27 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.7-0.2.b2
> - Rebuild for Fedora 8 to get the build-id
> * Wed Mar 21 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.7-0.1.b2
> - New upstream version 2.1.7b2
> * Mon Feb 26 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-9
> - Back to tcl 8.4 due to stability problems
> * Thu Feb 01 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-8
> - Rebuilt for devel (out of sync with tcl).
> * Tue Sep 12 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-7
> - Rebuilt for FC6 (tag problem).
> * Tue Sep 12 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-6
> - Rebuilt for FC6 (mass rebuild).
> * Thu Jul 18 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-5
> - Changed BuildRequires to make common spec for FC-4 and up
> * Thu Jun 22 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-4
> - Patch0 is modified so Makefile installs in $(libdir) instead of $(prefix)/lib
> * Mon Jun 19 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-3
> - Added some space between package devel and description devel and
>   between install and clean to improve the flow and readability of the file.
> * Tue Jun 13 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-2
> - Specfile polished, minor fixes.
> * Wed Feb 22 2006 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.6-1
> - Initial spec file.

Since I've been unable to contact you before, and since you still
create overly huge commit messages like quoted above, this is another
attempt at giving advice:

Those cvs commit messages are stored in CVS, too. They turn the "cvs
log" of your packages into an unreadable mess.

Put _empty lines_ between your %changelog entries. Then in Fedora CVS
you can use "make clog" to store only the latest changelog entry in
the "clog" file. Short and to the point. "cvs commit -F clog" takes
that file as the commit message.

Perhaps you already use "make clog", but due to the missing blank
lines, you defeat the purpose of that Makefile method.

-- 
Michael Schwendt <mschwendt at fedoraproject.org>
Fedora release 7.92 (Rawhide) - Linux 2.6.23.1-23.fc8
loadavg: 1.54 1.38 1.08



From pertusus at free.fr  Wed Oct 24 09:38:28 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 24 Oct 2007 11:38:28 +0200
Subject: rpms/ssmtp/devel ssmtp.spec,1.10,1.11
In-Reply-To: <200710240934.l9O9Yqeu029962@cvs-int.fedora.redhat.com>
References: <200710240934.l9O9Yqeu029962@cvs-int.fedora.redhat.com>
Message-ID: <20071024093828.GB2668@free.fr>

On Wed, Oct 24, 2007 at 05:34:52AM -0400, Manuel Wolfshant wrote:
> Author: wolfy
> 
>  BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> -Provides:	MTA smtpdaemon %{_sbindir}/sendmail 
>  Requires(post):	%{_sbindir}/alternatives

Looks like %{_sbindir}/sendmail has been removed too. I think this one
should stay...

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct 24 09:59:57 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 24 Oct 2007 11:59:57 +0200
Subject: Request permission to break always use system
	libs	rule	for	asc-2.0
In-Reply-To: <471D5AC2.3000906@gmail.com>
References: <471CB6AF.3060905@hhs.nl>
	<471CC274.9080002@gmail.com>	<471CF051.7010705@hhs.nl>
	<471D5AC2.3000906@gmail.com>
Message-ID: <471F179D.1060609@hhs.nl>

Toshio Kuratomi wrote:
> Hans de Goede wrote:
>>> 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages from 
>>> the asc source tarball.
>>
>> To what purpose? There are no other users, if you can name one package 
>> out there which could be packaged for Fedora which uses either of them 
>> I would fully agree, which is why I created a seperate package for 
>> SDLmm in the first place. But there are _no_ other users. Try googling 
>> for paragui, the first 2 links are dead upstream websites then a 
>> domain squater, then some old mailinglist posts and then we go into 
>> rpmsearch hits.
>>
>> SDLmm, the same the last mailinglist post is from dec 2005!
>>
>> So I challenge you, give my another (potential) package that needs 
>> them and I agree.
>>
>>
> That's not great reasoning.  If asc maintained those libraries out of 
> tree and made releases as separate tarballs, you'd continue to make 
> separate packages, right?  It's not a question of how many consumers 
> there are but of how useful the library is outside of the program.
> 

Thats not great reasoning either, if we follow that reasoning then all pieces 
of code in applications which may be useful outside of an application should be 
converted into libraries before those programs may pass review. See, this kind 
of "reasoning" is what you get if you insist on stubbornly and blindly 
following the theory of the rules without looking at the practical situation at 
hand.

> Since these libraries were released outside of the program before and 
> you haven't said anything about the build scripts being changed just 
> bugfixes and code-formatting I have the impression that they would be 
> useful outside of asc.

I didn't say anything about buildscript changes because that seemed irrelvant, 
to be honest I didn't expect anyone to object. But no that you ask, the SDLmm 
and paragui configure scripts and config.h have been removed and now the asc 
scripts and config.h get used.

> You could correct me on that by letting me know 
> that the asc fixes have made the two code bases dependent on each other 
> or some other technical reason that they aren't two separate codebases 
> that happen to be maintained in the same tree.
>

I keep repeating myself, what is the practical use of splitting them? upstream 
is maintaining them as if they are one code base, there are no known other 
applications which them, not in Fedora, nor outside. All you are doing is 
bringing theoretical arguments, not practical ones.

Why should I have to find out what changed, generate patches, maintain seperate 
buildscripts, etc. For 2 additional packages, each time asc does a new release? 
Where is the sense in that? What is the added value for fellow Fedora 
developers or Fedora users? And since there is no added value I would much 
rather spend my time in some other more usefull way.

>>> 3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.
>>>
>>
>> Which would be the least work, not deviating from what upstream does 
>> (wasn't our mantra upstream upstream upstream?) and has no downsides.
>>
> If a problem is serious enough we do deviate from upstream.  For 
> instance, changing a package to build against system libraries is 
> certainly something that we do whether or not upstream.  We also will 
> take the time to help upstream do the right thing rather than blindly 
> packaging what they hand us.  In this case, it sure looks best to me to 
> build those libraries from upstream's tarball as system libraries and 
> then have the asc programs use those.
> 
> The downsides:
> * if you make these private libraries of asc you then have all the 
> problems of static libraries should another program be created in the 
> future that makes use of their own copy of those libraries.
> 

Notice the ".. if .. in the future" in your reasoning, still theoretical. I 
would like to be given some more credit here, I have no problem with splitting 
out the libraries again once another using app turns up. But lets wait till then.

I'm very much in favor of the use system libs rule. For example AFAIK Fedora is 
the only distro that has quake3 and tremulous use the system libjpeg use the 
system libjpeg instead of a ptivate copy. Also I'm trying to find the time to 
work on ripping all patent encumbered stuff out of SDL_sound so that can move 
to Fedora, as the new asc release can use a system SDL_sound if present (and 
will use a stripped down, patent free included copy if not present). But 
unfortunately as my time gets sunk into useless discussions like these, sofar I 
haven't found the time to work on SDL-sound.

> * There's no attempt to coordinate work on the libraries.  Should 
> another developer decide they want to build something that uses 
> functionality that could be provided by SDl-mm or paragui they'll be 
> unaware that there is active maintenance of these libraries occurring 
> and will either fork their own copy or reinvent the wheel.
> 

And since when is it my task as maintainer to take care of coordination of dead 
upstream packages? If FESco / the FPC start demanding that I'm going to have to 
drop a whole shitload of packages, as quite a few of my packages have a dead 
upstream.

Anyways I'm totally fed up with having discussions like this with the 
bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either 
the powers that be give me permission to use SDLmm and paragui as included and 
maintained within upstream asc release, or I'll just orphan all 3 of them. I 
refuse to become upstream for 2 libraries backporting fixes from asc each 
release just because some people want to follow the rules as if they are 
something holy. orphaning asc would be a shame as its a great and quite popular 
game, but if that is want the powers that be want, then that is what they will get.

Regards,

Hans



From caillon at redhat.com  Wed Oct 24 10:08:22 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 24 Oct 2007 06:08:22 -0400
Subject: rpms/xpa/FC-6 xpa.spec,1.7,1.8
In-Reply-To: <20071024102011.57759411.mschwendt.tmp0701.nospam@arcor.de>
References: <200710232137.l9NLbuFP031094@cvs-int.fedora.redhat.com>
	<20071024102011.57759411.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <471F1996.8060100@redhat.com>

Michael Schwendt wrote:
  > Perhaps you already use "make clog", but due to the missing blank
> lines, you defeat the purpose of that Makefile method.

Which is something that we *could* theoretically fix in Makefile.common 
if we wanted to...



From wolfy at nobugconsulting.ro  Wed Oct 24 10:24:51 2007
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Wed, 24 Oct 2007 13:24:51 +0300
Subject: rpms/ssmtp/devel ssmtp.spec,1.10,1.11
In-Reply-To: <20071024093828.GB2668@free.fr>
References: <200710240934.l9O9Yqeu029962@cvs-int.fedora.redhat.com>
	<20071024093828.GB2668@free.fr>
Message-ID: <471F1D73.1040406@nobugconsulting.ro>

Patrice Dumas wrote:
> On Wed, Oct 24, 2007 at 05:34:52AM -0400, Manuel Wolfshant wrote:
>   
>> Author: wolfy
>>
>>  BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>> -Provides:	MTA smtpdaemon %{_sbindir}/sendmail 
>>  Requires(post):	%{_sbindir}/alternatives
>>     
>
> Looks like %{_sbindir}/sendmail has been removed too. I think this one
> should stay...
>   
Indeed. I was counting on rpmbuild to pick the sendmail provides.
The package is already rebuilding in koji (after I've done a couple of 
local tests, so hopefully this time I won't break anything else).



From buytenh at wantstofly.org  Wed Oct 24 10:43:24 2007
From: buytenh at wantstofly.org (Lennert Buytenhek)
Date: Wed, 24 Oct 2007 12:43:24 +0200
Subject: multiarch header file wrappers and ARM
In-Reply-To: <ffmf65$re6$1@ger.gmane.org>
References: <20071024021040.GA30880@xi.wantstofly.org>
	<ffmf65$re6$1@ger.gmane.org>
Message-ID: <20071024104324.GE31651@xi.wantstofly.org>

On Tue, Oct 23, 2007 at 10:46:13PM -0500, Rex Dieter wrote:

> > On ARM, the preprocessor symbol __arm__ is defined, and %{_arch} is
> > set to 'arm', so something like this will work:
> > 
> > #if defined(__i386__)
> > #include "blkid_types-i386.h"
> > +#elif defined(__arm__)
> > +#include "blkid_types-arm.h"
> > #elif defined(__ia64__)
> > #include "blkid_types-ia64.h"
> > #elif defined(__powerpc64__)
> > 
> > If you have such a construct in your package, please consider adding
> > the relevant __arm__ bits.
> 
> Is arm even capable of multilib'ing?

Nope.


> If not, why even bother with hacks like this?

Some packages, like apr, only substitute a wrapper header when the
package is built for a multilib arch, but other packages, like gmp,
substitute this header all the time.

So, yes, another solution would be to do it like apr and only
substitute on a multilib arch.  That would solve it as well.



From kevin.kofler at chello.at  Wed Oct 24 10:49:51 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 24 Oct 2007 10:49:51 +0000 (UTC)
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
	<ffm054$orp$1@ger.gmane.org> <ffm0ql$q43$1@ger.gmane.org>
Message-ID: <loom.20071024T104922-132@post.gmane.org>

Rex Dieter <rdieter <at> math.unl.edu> writes:
> Well, take either kmix(arts) or pa volume out, and you're back to 2.

The KMix volume settings are actually for ALSA, not aRts.

        Kevin Kofler



From buildsys at redhat.com  Wed Oct 24 10:59:19 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 24 Oct 2007 06:59:19 -0400
Subject: rawhide report: 20071024 changes
Message-ID: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-1:0.7.0-0.3.svn3014.fc8
--------------------------------------
* Tue Oct 23 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn3014
- Suppress excessive GConf updates which sometimes caused secrets to be cleared
    at the wrong times, causing connections to fail
- Various EAP and LEAP related fixes

* Tue Oct 23 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn3008
- Make WPA-EAP and Dynamic WEP options connect successfully
- Static IPs are now handled correctly in NM itself

* Mon Oct 22 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2995
- Add Dynamic WEP as a supported authentication/security option

NetworkManager-vpnc-1:0.7.0-0.3.svn3014.fc8
-------------------------------------------
* Tue Oct 23 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn3014
- Rebuild

acpid-1.0.6-3.fc8
-----------------
* Tue Oct 23 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-3.fc8
- Silent initscript
- Resolves: #345611

anaconda-11.3.0.45-1
--------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.45-1
- A few liveinst cleanups
- Fix writing out of ipv6 network config (dcantrell, #328931)
- Disable betanag
- Don't traceback when offering the chance to retry a 
  failed mirror (clumens, #349371)

bind-32:9.5.0-16.a6.fc8
-----------------------
* Tue Oct 23 2007 Adam Tkac <atkac redhat com> 32:9.5.0-16.a6
- disabled DBUS (dhcdbd doesn't exist & #339191)

* Thu Oct 18 2007 Adam Tkac <atkac redhat com> 32:9.5.0-15.1.a6
- fixed missing va_end () functions (#336601)
- fixed memory leak when dbus initialization fails

blam-1.8.3-9.fc8
----------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 1.8.3-9
- Rebuild against new firefox

compiz-0.6.2-2.fc8
------------------
* Tue Oct 23 2007 Adel Gadllah <adel.gadllah at gmail.com> - 0.6.2-2
- Obsolete berly-core

* Mon Oct 22 2007 Warren Togami <wtogami at redhat.com> - 0.6.2-1
- 0.6.2

compiz-bcop-0.6.0-1.fc8
-----------------------

compiz-fusion-0.6.0-2.fc8
-------------------------
* Mon Oct 22 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-2
- Obsolete beryl-plugins

* Mon Oct 22 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-1
- Update to 0.6.0

* Fri Oct 12 2007 Adel Gadllah <adel.gadllag at gmail.com> 0.5.2-10.09b700
- Fix BuildRequries to build missing plugins (RH #327411)
- Mock isn't broken but the Buildrequires ... remove hack

compiz-fusion-extras-0.6.0-1.fc8
--------------------------------
* Mon Oct 22 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-1
- Update to 0.6.0

devhelp-0.16.1-2.fc8
--------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 0.16.1-2.fc8
- rebuild against new firefox

e2fsprogs-1.40.2-10.fc8
-----------------------
* Tue Oct 23 2007 Eric Sandeen <esandeen at redhat.com> 1.40.2-10
- Add arm to multilib header wrapper

empathy-0.14-4.fc8
------------------
* Fri Oct 19 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-4
- Backport upstream patch to fixes crashes when using drag-and-drop of a
  contact from the buddy list to the current conversation window to initiate a
  conversation:
    + svn380-fix-contact-DnD.patch 
- Resolves: GNOME bug 483168 (crash in Empathy Instant Messenger: I had
  dragged a contact ...)

epiphany-2.20.1-3.fc8
---------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 2.20.1-3
- Rebuild against new firefox

* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Add patch to allow epiphany to use the plugins wrapped by
  nspluginwrapper (#334751)

* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1

fedorainfinity-kdm-theme-1.0.1-1.fc8
------------------------------------
* Tue Oct 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 1.0.1-1
- [RFE] Adjust the standard colour scheme to match to default wallpaper (#295631)
firefox-2.0.0.8-1.fc8
---------------------
* Tue Oct 23 2007 Martin Stransky <stransky at redhat.com> 2.0.0.8-1
- updated to the latest upstream
- moved preference updates to build section

galeon-2.0.3-13.fc8
-------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 2.0.3-13
- Rebuild against new firefox

ghostscript-8.60-5.fc8
----------------------
* Tue Oct 23 2007 Tim Waugh <twaugh at redhat.com> 8.60-5
- Applied patch from upstream to fix CVE-2007-2721 (bug #346511).

* Tue Oct 09 2007 Tim Waugh <twaugh at redhat.com> 8.60-4
- Marked localized man pages as %lang (bug #322321).

* Thu Sep 27 2007 Tim Waugh <twaugh at redhat.com> 8.60-3
- Back-ported mkstemp64 patch (bug #308211).

gtkmozembedmm-1.4.2.cvs20060817-15.fc8
--------------------------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 1.4.2.cvs20060817-15
- Rebuild against new firefox

kazehakase-0.4.9-2.fc8.1
------------------------
* Tue Oct 23 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2.dist.1
- Rebuild against new gecko engine.

kde-settings-3.5-33.fc8.1
-------------------------
* Tue Oct 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5-33.1
- -pulseaudio: new subpkg, to enable pulseaudio support

* Tue Oct 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5-33
- kdmrc: ColorScheme=FedoraInfinityKDM
- ksplashrc: drop Theme=Echo (ie, revert to Default)
- kdeglobals: colorScheme=FedoraInfinity.kcsrc

kernel-2.6.23.1-31.fc8
----------------------
* Tue Oct 23 2007 John W. Linville <linville at redhat.com>
- remove problematic hunk from ath5k fixes patch

* Mon Oct 22 2007 Adam Jackson <ajax at redhat.com>
- Add e1000.eeprom_bad_csum_allow

* Sun Oct 21 2007 Jarod Wilson <jwilson at redhat.com>
- Log warning about unimplemented isochronous I/O on
  firewire ohci 1.0 controllers (bz #344851)

kernel-xen-2.6-2.6.21-2950.fc8
------------------------------
* Tue Oct 23 2007 Eduardo Habkost <ehabkost at redhat.com>
- Fix for 'virt-install --nographics --paravirt' (bug #348931)

knetworkmanager-0.2-0.6.fc8
---------------------------
* Tue Oct 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 0.2-0.6
- %_sysconfdir/skel/.kde/ -> %_sysconfdir/kde/
- cleanup start/stop scripts
- omit %svn from Release
- Requires: kde-filesystem

liferea-1.2.23-3.fc8
--------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 1.2.23-3
- Don't build against NetworkManager as the nm-glib api seems to have changed

* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 1.2.23-2
- Rebuild against new firefox

nspluginwrapper-0.9.91.5-8.fc8
------------------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> 0.9.91.5-8
- Rebuild against new firefox

pm-utils-0.99.4-6.fc8
---------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 0.99.4-6
- Set suspend to not supported by default on machines with nVidia graphics 
  using the nv driver based on testing results.  Can be overriden if you 
  know your machine works by setting ALLOW_NV_SUSPEND="yes" in a file 
  in /etc/pm/config.d/

* Wed Oct 10 2007 Till Maas <opensource till name> - 0.99.4-5
- Require vbetool only for x86 archs (RH #325741)
- add missing BR for docbook-utils

* Thu Sep 20 2007 Till Maas <opensource till name> - 0.99.4-4
- fix manpage cut and paste mistake (RH #286201)

ppc64-utils-0.12-3.fc8
----------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 0.12-3
- and one more file is needed

pykickstart-1.18-1.fc8
----------------------
* Thu Oct 18 2007 Chris Lumens <clumens at redhat.com> 1.18-1
- Don't write out %end to packages and scripts if the syntax version doesn't
  support it.
- Remove obsolete translation (#332221).

python-2.5.1-13.fc8
-------------------
* Mon Oct 22 2007 James Antill <jantill at redhat.com> - 2.5.1-13
- Add tix buildprereq
- Add tkinter patch
- Resolves: #281751
- Fix ctypes loading of libraries, add requires on binutils
- Resolves: #307221
- Possible fix for CVE-2007-4965 possible exploitable integer overflow
- Resolves: #295971

* Tue Oct 16 2007 Mike Bonnet <mikeb at redhat.com> - 2.5.1-12
- fix marshalling of objects in xmlrpclib (python bug #1739842)

* Fri Sep 14 2007 Jeremy Katz <katzj at redhat.com> - 2.5.1-11
- fix encoding of sqlite .py files to work around weird encoding problem 
  in Turkish (#283331)

system-config-date-1.9.15-1.fc8
-------------------------------
* Tue Oct 23 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.15-1
- cope with comments in /etc/ntp/step-tickers (#333881)

vnc-4.1.2-23.fc8
----------------
* Tue Oct 23 2007 Adam Tkac <atkac redhat com> 4.1.2-23
- disabled Composite extension (#242280, #339811)

xfsprogs-2.9.4-4.fc8
--------------------
* Tue Oct 23 2007 Eric Sandeen <sandeen at redhat.com> 2.9.4-4
- Add arm to multilib header wrapper

yelp-2.20.0-2.fc8
-----------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com> - 2.20.0-2
- Rebuild against new firefox

Broken deps for i386
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.i386 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.i386 requires firefox = 0:2.0.0.6
	epiphany-extensions - 2.20.1-1.fc8.i386 requires gecko-libs = 0:1.8.1.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.i386 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	libcompizconfig-devel - 0.6.0-0.3.20071011git5615ca.fc8.i386 requires compiz-devel = 0:0.6.0
	openvrml - 0.16.6-4.fc8.i386 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.i386 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	ruby-gtkmozembed - 0.16.0-12.fc8.i386 requires firefox = 0:2.0.0.6



Broken deps for x86_64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.x86_64 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.x86_64 requires firefox = 0:2.0.0.6
	epiphany-extensions - 2.20.1-1.fc8.x86_64 requires gecko-libs = 0:1.8.1.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.x86_64 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	libcompizconfig-devel - 0.6.0-0.3.20071011git5615ca.fc8.x86_64 requires compiz-devel = 0:0.6.0
	libcompizconfig-devel - 0.6.0-0.3.20071011git5615ca.fc8.i386 requires compiz-devel = 0:0.6.0
	openvrml - 0.16.6-4.fc8.i386 requires firefox = 0:2.0.0.6
	openvrml - 0.16.6-4.fc8.x86_64 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.x86_64 requires firefox-devel = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.i386 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	ruby-gtkmozembed - 0.16.0-12.fc8.x86_64 requires firefox = 0:2.0.0.6



Broken deps for ppc
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.ppc requires firefox = 0:2.0.0.6
	epiphany-extensions - 2.20.1-1.fc8.ppc requires gecko-libs = 0:1.8.1.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.ppc requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	libcompizconfig-devel - 0.6.0-0.3.20071011git5615ca.fc8.ppc requires compiz-devel = 0:0.6.0
	openvrml - 0.16.6-4.fc8.ppc64 requires firefox = 0:2.0.0.6
	openvrml - 0.16.6-4.fc8.ppc requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc requires firefox-devel = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc64 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	ruby-gtkmozembed - 0.16.0-12.fc8.ppc requires firefox = 0:2.0.0.6



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc64 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.ppc64 requires firefox = 0:2.0.0.6
	epiphany-extensions - 2.20.1-1.fc8.ppc64 requires gecko-libs = 0:1.8.1.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.ppc64 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	openvrml - 0.16.6-4.fc8.ppc64 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc64 requires firefox-devel = 0:2.0.0.6
	ruby-gtkmozembed - 0.16.0-12.fc8.ppc64 requires firefox = 0:2.0.0.6





From ndbecker2 at gmail.com  Wed Oct 24 11:19:31 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 24 Oct 2007 07:19:31 -0400
Subject: rawhide report: 20071024 changes
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
Message-ID: <ffn9o3$83l$1@ger.gmane.org>

Unable to update for several days now, on x86_64 I still get:

ERROR with rpm_check_debug vs depsolve:
Package kdegraphics needs libIlmImf.so.4, this is not available.
Package kdebase needs libIlmImf.so.4, this is not available.




From ndbecker2 at gmail.com  Wed Oct 24 11:22:57 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 24 Oct 2007 07:22:57 -0400
Subject: F8+KDE+PulseAudio
References: <ff8coq$57c$2@ger.gmane.org> <ff8ddv$7rn$1@ger.gmane.org>
	<ffkpqo$cub$1@ger.gmane.org> <ffkrk0$juh$1@ger.gmane.org>
	<ffm054$orp$1@ger.gmane.org> <ffm0ql$q43$1@ger.gmane.org>
Message-ID: <ffn9uh$83l$2@ger.gmane.org>

[...]
>> 
>> I tried this with amarok.  I see that after starting pulseaudio, and
>> selecting pulseaudio as output in amarok, seems to work.  But, now I have
>> instead of 2 volume controls to play with, 3 of them.  One in amarok, one
>> in kmix, and 1 in  'pulse audio volume control'.  Not really user
>> friendly.
>> 
> 

Actually, make that 4 volume controls - there is one built into my notebook
(a soft slider control) that seems to affect only the headphone volume for
some reason.



From pertusus at free.fr  Wed Oct 24 11:45:52 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 24 Oct 2007 13:45:52 +0200
Subject: Request permission to break always use system libs rule for
	asc-2.0
In-Reply-To: <471F179D.1060609@hhs.nl>
References: <471CB6AF.3060905@hhs.nl> <471CC274.9080002@gmail.com>
	<471CF051.7010705@hhs.nl> <471D5AC2.3000906@gmail.com>
	<471F179D.1060609@hhs.nl>
Message-ID: <20071024114552.GA22623@free.fr>

On Wed, Oct 24, 2007 at 11:59:57AM +0200, Hans de Goede wrote:
>
> Anyways I'm totally fed up with having discussions like this with the 
> bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) 
> either the powers that be give me permission to use SDLmm and paragui as 
> included and maintained within upstream asc release, or I'll just orphan 
> all 3 of them. I refuse to become upstream for 2 libraries backporting 

Why do you need a permission? There is a controversy here, so just use
the internal libs, and wait for somebody to report the issue to turn to
FESCO ruling, and in the mean time just do what you think is best.
If FESCO disagree with you then orphan them, but wait for that to
happen. I can't find on the wiki, but there was some guidance on how to
cope with disagreement like this one, and basically it is bring the
issue on the mailing list (you've done it without success in getting an
agreement), and otherwise wait for somebody to report to FESCO for FESCO
ruling. It should be in
http://fedoraproject.org/wiki/PackageMaintainers/Policy
but I can't find it.

--
Pat



From rdieter at math.unl.edu  Wed Oct 24 11:49:23 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 24 Oct 2007 06:49:23 -0500
Subject: rawhide report: 20071024 changes
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<ffn9o3$83l$1@ger.gmane.org>
Message-ID: <ffnbg4$ear$1@ger.gmane.org>

Neal Becker wrote:

> Unable to update for several days now, on x86_64 I still get:
> 
> ERROR with rpm_check_debug vs depsolve:
> Package kdegraphics needs libIlmImf.so.4, this is not available.
> Package kdebase needs libIlmImf.so.4, this is not available.

These pkgs went away multilib-wise, so
rpm -e kdegraphics.i386 kdebase.i386
and try again.

-- Rex



From caillon at redhat.com  Wed Oct 24 11:58:54 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 24 Oct 2007 07:58:54 -0400
Subject: Request permission to break always use system libs rule for
	asc-2.0
In-Reply-To: <471CB6AF.3060905@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>
Message-ID: <471F337E.3020208@redhat.com>

Hans de Goede wrote:
> Hi All,
> 
> I'm currently working on upgrading asc (Advanced Strategic Command) to 
> 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and 
> paragui-1.0.4.
> 
> While packaging SDLmm I had to backport several fixes from a copy 
> included in asc to the package, as SDLmm is very much dead upstream.
> 
> With 1.16.4.0, paragui was not included so the packaging of it was 
> needed, and I packaged the then already old version 1.0.4, as that is 
> what asc 1.16.4.0 wanted.
> 
> Now with asc-2.0 there are yet again bugfixes to the included 
> SDLmm-0.1.8, now I can port these to the external SDLmm package, and 
> patch asc to use the external SDLmm. But since SDLmm upstream has been 
> dead for a long time, and asc is the only user of SDLmm, this feels 
> rather silly. So I would like to declare SDLmm dead for current devel 
> (F-9 and later) and just use the included copy.
> 
> asc-2.0 now uses paragui-1.1.8, which is the latest release from 2004 
> (again very dead upstream, website is down, etc.) and again has it 
> heavily patched. Unfortunately some idiot ran indent on there copy, so 
> doing a diff results in 30000 changed lines. I could go through these 
> manually and port any fixes to the official paragui, and patch asc to 
> use the system version. But again asc is the only user, so doing this 
> feels really silly (going through a 30000 lines diff is no fun). So I 
> would like to declare paragui dead for current devel (F-9 and later) 
> also, and just use the included copy.
> 
> Are there any objections against this?
> 

If upstream is dead, we should call it dead.  Trying to port patches 
sort of makes us upstream and if we don't have anyone willing to be 
upstream, is not an option.  Your plan seems OK to me.



From limb at jcomserv.net  Wed Oct 24 12:08:03 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 24 Oct 2007 07:08:03 -0500 (CDT)
Subject: Request permission to break always use system libs rule for 
 asc-2.0
In-Reply-To: <471F337E.3020208@redhat.com>
References: <471CB6AF.3060905@hhs.nl> <471F337E.3020208@redhat.com>
Message-ID: <32597.63.85.68.164.1193227683.squirrel@mail.jcomserv.net>


> Hans de Goede wrote:
>> Hi All,
>>
>> I'm currently working on upgrading asc (Advanced Strategic Command) to
>> 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and
>> paragui-1.0.4.
>>
>> While packaging SDLmm I had to backport several fixes from a copy
>> included in asc to the package, as SDLmm is very much dead upstream.
>>
>> With 1.16.4.0, paragui was not included so the packaging of it was
>> needed, and I packaged the then already old version 1.0.4, as that is
>> what asc 1.16.4.0 wanted.
>>
>> Now with asc-2.0 there are yet again bugfixes to the included
>> SDLmm-0.1.8, now I can port these to the external SDLmm package, and
>> patch asc to use the external SDLmm. But since SDLmm upstream has been
>> dead for a long time, and asc is the only user of SDLmm, this feels
>> rather silly. So I would like to declare SDLmm dead for current devel
>> (F-9 and later) and just use the included copy.
>>
>> asc-2.0 now uses paragui-1.1.8, which is the latest release from 2004
>> (again very dead upstream, website is down, etc.) and again has it
>> heavily patched. Unfortunately some idiot ran indent on there copy, so
>> doing a diff results in 30000 changed lines. I could go through these
>> manually and port any fixes to the official paragui, and patch asc to
>> use the system version. But again asc is the only user, so doing this
>> feels really silly (going through a 30000 lines diff is no fun). So I
>> would like to declare paragui dead for current devel (F-9 and later)
>> also, and just use the included copy.
>>
>> Are there any objections against this?
>>
>
> If upstream is dead, we should call it dead.  Trying to port patches
> sort of makes us upstream and if we don't have anyone willing to be
> upstream, is not an option.  Your plan seems OK to me.

+1

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From Christian.Iseli at licr.org  Wed Oct 24 12:42:01 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Wed, 24 Oct 2007 14:42:01 +0200
Subject: Request permission to break always use system libs	rule	for
 asc-2.0
In-Reply-To: <471F179D.1060609@hhs.nl>
References: <471CB6AF.3060905@hhs.nl> <471CC274.9080002@gmail.com>
	<471CF051.7010705@hhs.nl> <471D5AC2.3000906@gmail.com>
	<471F179D.1060609@hhs.nl>
Message-ID: <20071024144201.2997ccf2@ludwig-alpha.unil.ch>

Hey Hans,

On Wed, 24 Oct 2007 11:59:57 +0200, Hans de Goede wrote:
> Anyways I'm totally fed up with having discussions like this with the 
> bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either 
> the powers that be give me permission to use SDLmm and paragui as included and 
> maintained within upstream asc release, or I'll just orphan all 3 of them. I 
> refuse to become upstream for 2 libraries backporting fixes from asc each 
> release just because some people want to follow the rules as if they are 
> something holy. orphaning asc would be a shame as its a great and quite popular 
> game, but if that is want the powers that be want, then that is what they will get.

I'd say: just relax and follow your original idea.  It makes sense and
your reasons make sense to me too.

Worse comes to worst, someone will file a BZ ticket and/or ask FESCO
for a decision.

So far, from FESCO, I've only seen caillon comment and also agree that
you should follow your plan.

I don't think FESCO should be seen as wanting to police each and every
of your decisions.  I think we trust the maintainers to make the
right decisions.  I think FESCO should only step in when there is a
disagreement between different maintainers that they are unable to
resolve between themselves.  In this case, different opinions have been
expressed but I didn't see someone violently oppose your plan.  Of
course, given an infinite amount of free time we could make many
wonderful things, but we must be content with what reality has to
offer...

Kind regards,
					Christian



From jonathan.underwood at gmail.com  Wed Oct 24 12:45:26 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 24 Oct 2007 13:45:26 +0100
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20071023083834.GA4704@wolff.to>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20071023083834.GA4704@wolff.to>
Message-ID: <645d17210710240545u7047fcb1n807f1c5c97576fd7@mail.gmail.com>

On 23/10/2007, Bruno Wolff III <bruno at wolff.to> wrote:
> NetworkManager doesn't seem to be evolving toward providing full use of
> the network tools (e.g. multiple networks on an interface, bridging, routing,
> QoS). It seems to be very oriented toward convenient use in simple cases.
>
> If it is not going to ever give access to the more advanced networking
> features, I think there is a reason to replace the current network
> configuration scripts with something like etcnet.
>
> Sure you can add commands in rc.local to set up the network properly, but
> then ifup and ifdown don't work correctly (in the general case) and neither
> does changing between run levels where the network gets turned off or on.
>
> etcnet does seem to be continuing to be developed, but it looks like they
> aren't continuing to provide Fedora specific installations.

As mentioned in the thread back in 2005, the first step would be
submitting etcnet to for inclusion as a Fedora package. That can
happen independently of whether or not discussions of replacing
network-scripts happens, and what the outcome of them are.

FWIW, I'd quite like to see etcnet in the repo as an alternative, so
if you want some help packaging it, drop me a line. That said, the
thing that is very unappealing to me about its design is the multitude
of configuration files distributed over several subdirectories. That's
subjective though.

Jonathan.



From pertusus at free.fr  Wed Oct 24 12:51:04 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 24 Oct 2007 14:51:04 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <645d17210710240545u7047fcb1n807f1c5c97576fd7@mail.gmail.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20071023083834.GA4704@wolff.to>
	<645d17210710240545u7047fcb1n807f1c5c97576fd7@mail.gmail.com>
Message-ID: <20071024125104.GD22623@free.fr>

On Wed, Oct 24, 2007 at 01:45:26PM +0100, Jonathan Underwood wrote:
> 
> As mentioned in the thread back in 2005, the first step would be
> submitting etcnet to for inclusion as a Fedora package. That can

Right.
There has been a submission
https://bugzilla.redhat.com/show_bug.cgi?id=195365
It has been closed, but I think it is worth pursuing.

> happen independently of whether or not discussions of replacing
> network-scripts happens, and what the outcome of them are.
> 
> FWIW, I'd quite like to see etcnet in the repo as an alternative, so
> if you want some help packaging it, drop me a line. That said, the

I'd happily review it.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct 24 12:51:18 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 24 Oct 2007 14:51:18 +0200
Subject: Request permission to break always use system libs	rule	for
	asc-2.0
In-Reply-To: <20071024144201.2997ccf2@ludwig-alpha.unil.ch>
References: <471CB6AF.3060905@hhs.nl>
	<471CC274.9080002@gmail.com>	<471CF051.7010705@hhs.nl>
	<471D5AC2.3000906@gmail.com>	<471F179D.1060609@hhs.nl>
	<20071024144201.2997ccf2@ludwig-alpha.unil.ch>
Message-ID: <471F3FC6.8010603@hhs.nl>

Christian Iseli wrote:
> Hey Hans,
> 
> On Wed, 24 Oct 2007 11:59:57 +0200, Hans de Goede wrote:
>> Anyways I'm totally fed up with having discussions like this with the 
>> bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either 
>> the powers that be give me permission to use SDLmm and paragui as included and 
>> maintained within upstream asc release, or I'll just orphan all 3 of them. I 
>> refuse to become upstream for 2 libraries backporting fixes from asc each 
>> release just because some people want to follow the rules as if they are 
>> something holy. orphaning asc would be a shame as its a great and quite popular 
>> game, but if that is want the powers that be want, then that is what they will get.
> 
> I'd say: just relax and follow your original idea.  It makes sense and
> your reasons make sense to me too.
> 
> Worse comes to worst, someone will file a BZ ticket and/or ask FESCO
> for a decision.
> 

Thanks for the good advice. I'll follow it and just move along as planned.

> So far, from FESCO, I've only seen caillon comment and also agree that
> you should follow your plan.
> 

I was under the mistaken impression that Toshia is (was?) part of FESco.

Regards,

Hans



From mike at miketc.com  Wed Oct 24 12:54:43 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 24 Oct 2007 07:54:43 -0500
Subject: Development to Official
Message-ID: <1193230483.4821.2.camel@scrappy.miketc.com>

Don't know if I worded the subject correctly, but wanted to know when
will rawhide not be geared towards F8 any longer and start towards F9
development?  I know the freeze is on, but wanted to find out when even
bugs and such would stop.

Guess I am asking to know when to stop playing with beta and gear
towards final/official updates for a while until am ready to begin F9
testing (In other words, time to change repo files to official
update/testing, instead of rawhide).

<Note> I thought I sent this last night, but didn't see it in the
archives, although in my sent folder.  So I apologize if I sent it
twice.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From pertusus at free.fr  Wed Oct 24 13:04:31 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 24 Oct 2007 15:04:31 +0200
Subject: rpms/chmsee/devel chmsee.spec,1.10,1.11
In-Reply-To: <200710241258.l9OCwUis029063@cvs-int.fedora.redhat.com>
References: <200710241258.l9OCwUis029063@cvs-int.fedora.redhat.com>
Message-ID: <20071024130431.GE22623@free.fr>

On Wed, Oct 24, 2007 at 08:58:30AM -0400, Yuan Yijun wrote:
> Author: bbbush
> 
>  %changelog
> -* Thu Aug 23 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.24
> -- rebuild
> +* Wed Oct 24 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.26
> +- build for firefox-2.0.0.8

You should not remove changelog entries, except in very specific case
(and sometimes, old entries).

--
Pat



From opensource at till.name  Wed Oct 24 13:11:28 2007
From: opensource at till.name (Till Maas)
Date: Wed, 24 Oct 2007 15:11:28 +0200
Subject: Development to Official
In-Reply-To: <1193230483.4821.2.camel@scrappy.miketc.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
Message-ID: <200710241511.35633.opensource@till.name>

On Mi Oktober 24 2007, Mike Chambers wrote:
> Don't know if I worded the subject correctly, but wanted to know when
> will rawhide not be geared towards F8 any longer and start towards F9
> development?  I know the freeze is on, but wanted to find out when even
> bugs and such would stop.

F-8 has its own branch in CVS, since then every change to the devel branch aka 
rawhide is done for F-9.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/c5f9ae16/attachment.sig>

From giallu at gmail.com  Wed Oct 24 13:13:50 2007
From: giallu at gmail.com (Gianluca Sforna)
Date: Wed, 24 Oct 2007 15:13:50 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <1193174612.7110.11.camel@localhost.localdomain>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
Message-ID: <d5ad21470710240613i1b534b6bv662f666f21e77389@mail.gmail.com>

On 10/23/07, Dan Williams <dcbw at redhat.com> wrote:
> Perhaps this weekend (unless I'm still fixing bugs with NM in general)
> I'll integrate the work Soren did for a system config service which will
> allow connections to be brought up before you log in.

OT: is this Soren Sandmann?
If so, I'm pretty sure now I understand why I had no replies on a mail
I sent him lately...



From opensource at till.name  Wed Oct 24 13:29:03 2007
From: opensource at till.name (Till Maas)
Date: Wed, 24 Oct 2007 15:29:03 +0200
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <47190B89.1030506@BitWagon.com>
References: <47190B89.1030506@BitWagon.com>
Message-ID: <200710241529.09209.opensource@till.name>

On Fr Oktober 19 2007, John Reiser wrote:
> Is there a preference to limit the drive speed when playing
> compact disc digital audio?  I find that "eject -x 8 /dev/cdrom"
> is much quieter than the full speed (such as 48x) that appears to be
> the default.  Would it be a preference of hal, nautilus, each player
> application, gnome-desktop, or what?

1x is enough for playing. Imho it should be a preference of the player 
applications, because the speed should not be limited, when one wants to rip 
the cd.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/f99b8bce/attachment.sig>

From andy at smile.org.ua  Wed Oct 24 13:49:51 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Wed, 24 Oct 2007 16:49:51 +0300
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <200710241529.09209.opensource@till.name>
References: <47190B89.1030506@BitWagon.com>
	<200710241529.09209.opensource@till.name>
Message-ID: <20071024134951.GE1156@serv.smile.org.ua>

Hi Till Maas!

 On Wed, Oct 24, 2007 at 03:29:03PM +0200, Till Maas wrote next:

> 1x is enough for playing. Imho it should be a preference of the player 
> applications, because the speed should not be limited, when one wants to rip 
> the cd.
However higher riping speed provides some crackling of the sound (like a
peak noise).

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From bnocera at redhat.com  Wed Oct 24 13:55:11 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 24 Oct 2007 14:55:11 +0100
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <200710241529.09209.opensource@till.name>
References: <47190B89.1030506@BitWagon.com>
	<200710241529.09209.opensource@till.name>
Message-ID: <1193234112.25405.124.camel@cookie.hadess.net>


On Wed, 2007-10-24 at 15:29 +0200, Till Maas wrote:
> On Fr Oktober 19 2007, John Reiser wrote:
> > Is there a preference to limit the drive speed when playing
> > compact disc digital audio?  I find that "eject -x 8 /dev/cdrom"
> > is much quieter than the full speed (such as 48x) that appears to be
> > the default.  Would it be a preference of hal, nautilus, each player
> > application, gnome-desktop, or what?
> 
> 1x is enough for playing. Imho it should be a preference of the player 
> applications, because the speed should not be limited, when one wants to rip 
> the cd.

It's enough to play back in audio mode, not in CDDA mode. When there's
scratches, you'll want to re-read the part of the disc that had
problems...



From jwboyer at jdub.homelinux.org  Wed Oct 24 14:00:14 2007
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Wed, 24 Oct 2007 09:00:14 -0500
Subject: Development to Official
In-Reply-To: <200710241511.35633.opensource@till.name>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
Message-ID: <20071024090014.1737f6b8@weaponx.rchland.ibm.com>

On Wed, 24 Oct 2007 15:11:28 +0200
Till Maas <opensource at till.name> wrote:

> On Mi Oktober 24 2007, Mike Chambers wrote:
> > Don't know if I worded the subject correctly, but wanted to know when
> > will rawhide not be geared towards F8 any longer and start towards F9
> > development?  I know the freeze is on, but wanted to find out when even
> > bugs and such would stop.
> 
> F-8 has its own branch in CVS, since then every change to the devel branch aka 
> rawhide is done for F-9.

Not quite.  CVS and rawhide the repo are two different things.

CVS is branched.  Changes to the devel branch in CVS will be for F-9.

Rawhide is still composing from f8-final, so it doesn't pick up any of
the changes in the devel branch of CVS.

josh



From 777tahder at schlaegel.com  Wed Oct 24 14:09:40 2007
From: 777tahder at schlaegel.com (Schlaegel)
Date: Wed, 24 Oct 2007 07:09:40 -0700
Subject: Smolts.org wiki
In-Reply-To: <471E87A1.3040203@redhat.com>
References: <471E44E5.8060902@redhat.com>
	<4e1f5c1a0710231503m737e0e73t4d0ee081e22601bd@mail.gmail.com>
	<471E81BF.1060600@redhat.com> <471E87A1.3040203@redhat.com>
Message-ID: <4e1f5c1a0710240709o2a107facy32b4946139e62fab@mail.gmail.com>

On 10/23/07, Eric Sandeen <sandeen at redhat.com> wrote:
> FWIW there's a wishlist page at
> http://smolt.fedoraproject.org/wiki/Smolt_Wishlist :)

Yes; I added the wish: "Only allow system owner to rate system
components and update configuration," just before I sent the original
email to the list.



From lemenkov at gmail.com  Wed Oct 24 14:14:27 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 24 Oct 2007 18:14:27 +0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <47190B89.1030506@BitWagon.com>
References: <47190B89.1030506@BitWagon.com>
Message-ID: <adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>

2007/10/19, John Reiser <jreiser at bitwagon.com>:
> Is there a preference to limit the drive speed when playing
> compact disc digital audio?  I find that "eject -x 8 /dev/cdrom"

OMG!
Someone still playing (and buying) AudioCDs!

-- 
With best regards!



From lemenkov at gmail.com  Wed Oct 24 14:15:35 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 24 Oct 2007 18:15:35 +0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <20071024134951.GE1156@serv.smile.org.ua>
References: <47190B89.1030506@BitWagon.com>
	<200710241529.09209.opensource@till.name>
	<20071024134951.GE1156@serv.smile.org.ua>
Message-ID: <adf480660710240715h50704230l4c87ab3bfc940d5a@mail.gmail.com>

2007/10/24, Andy Shevchenko <andy at smile.org.ua>:

> However higher riping speed provides some crackling of the sound (like a
> peak noise).

Replace your drive ASAP - it's definitely his fault.


-- 
With best regards!



From lkundrak at redhat.com  Wed Oct 24 14:22:23 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 24 Oct 2007 16:22:23 +0200
Subject: cvs-import.sh change (import to branch in cwd)
In-Reply-To: <20071023174521.17cc6fef@redhat.com>
References: <20071023174521.17cc6fef@redhat.com>
Message-ID: <1193235743.13152.47.camel@localhost.localdomain>


On Tue, 2007-10-23 at 17:45 -0400, Jesse Keating wrote:
> I've made a small change to cvs-import.sh to keep it more in line with
> the internal Red Hat version.  When importing packages it will use the
> existence of a 'branch' file in your cwd to determine what branch to
> import to by default.  This can still be overridden by -b.

Much thanks for this. It happened multiple times to me that I imported
stuff to the wrong branch not thinking about -b flag.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From mjs at CLEMSON.EDU  Wed Oct 24 14:27:16 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Wed, 24 Oct 2007 10:27:16 -0400
Subject: fontsize in 7.92
In-Reply-To: <1193210556.22907.4.camel@s5.math.tu-berlin.de>
References: <1193093017.3574.3.camel@localhost.localdomain>
	<1193073308.28655.5.camel@rousalka.dyndns.org>
	<1193112112.3773.4.camel@localhost.localdomain>
	<1193091883.4605.13.camel@rousalka.dyndns.org>
	<1193161105.9545.12.camel@localhost6.localdomain6>
	<471E4C2A.4020103@cs.tu-berlin.de>
	<1193189902.5103.4.camel@vincent52.localdomain>
	<1193210556.22907.4.camel@s5.math.tu-berlin.de>
Message-ID: <1193236037.5103.25.camel@vincent52.localdomain>

On Wed, 2007-10-24 at 09:22 +0200, Christoph H?ger wrote:
> Please don't misunderstand me, I did not mean "too hard to do ist for
> "normal users". I just meant that it is not comfortable to change each
> font one by one if the target is to "just get the desktop fonts smaller
> (and keep the current ratio)", not that it should not be possible to
> change each font size individually.

Ah, OK.  I apologize for speaking sharply.

But still, small/normal or small/medium/large is too limiting.  I still
want the range of point sizes (and I want them to mean real points!).  I
usually do set all my fonts to one size, but I would still advocate an
advanced setting that allows hard-core customizers to change sizes for
individual fonts if they want.

> 
> Am Dienstag, den 23.10.2007, 21:38 -0400 schrieb Matthew Saltzman:
> > On Tue, 2007-10-23 at 21:31 +0200, Christoph Hger wrote:
> > > Richi Plana schrieb:
> > > > On Tue, 2007-10-23 at 00:24 +0200, Nicolas Mailhot wrote:
> > > >   
> > > >> Le mardi 23 octobre 2007  00:01 -0400, Christoph Hoeger a crit :
> > > >>
> > > >>     
> > > >>> is that sense-full? I mean, I've bought a Thinkpad R60 with a 1440x900
> > > >>> Display to see more information on my screen simultaneously 
> > > >>>       
> > > >> If you want small fonts just lower the size in points of your fonts in
> > > >> your app preferences. Gnome font preferences use pt as unit. Till now
> > > >> the GNOME pt unit had no relation with the pt unit the rest of the world
> > > >> uses. Now it's the same, so if you want small fonts you need to actually
> > > >> configure small fonts and not change the unit meaning on your system
> > > >> (and likewise if you want big fonts).
> > > >>
> > > >> That also means BTW that when you change laptop again your text will
> > > >> stay the same size regardless of the screen resolution, so you can
> > > >> invest the time to find good settings you'll keep them a long time.
> > > >>     
> > > >
> > > > I, for one, am glad that there's a move to make font sizes be based on
> > > > length rather than point sizes.
> > > >
> > > > The selection of a default font size is still crap-shoot, at best.
> > > > Having the monitor DPI as a dependency now allows people to say "I want
> > > > fonts that are so-and-so millimeters in height", unfortunately, 1) we
> > > > still lack information like distance of the viewer from the screen and
> > > > the height of the screen relative to the viewer, and 2) we've no way to
> > > > guess what the user would want, anyway. There are a couple of
> > > > discussions on the most ergonomic distance between monitor and viewer,
> > > > but font size preference is pretty varied. The only way to find out is
> > > > to let the gnome desktop provide feedback (a'la Smolt) after the user
> > > > has customized the desktop to his/her preference. Perhaps than a norm
> > > > can be established.
> > > >
> > > > Personally, I would like to set my font size preference in some length
> > > > unit of measure so that I can bump up the resolution and not have the
> > > > fonts and icons shrink to sizes I can hardly read. It's important for me
> > > > to see a lot more information on the screen, but not to the point where
> > > > it becomes useless because they're too small that I keep having to
> > > > squint. Believe me, straining ones eyesight like that will eventually
> > > > take its toll.
> > > > --
> > > >
> > > > Richi Plana
> > > >
> > > >   
> > > I totally agree with your point.
> > > But in my case that would mean to have one choice to use "small fonts" 
> > > instead of "normal fonts". I think that choosing (and testing) every 
> > > font size until it fits your needs is a little too much work for a 
> > > normal user to have a comfortable desktop. 
> > 
> > Really?  How incompetent do we think "normal users" are?
> > 
> > Users that don't want to take the trouble and are willing to live with
> > the consequences will behave accordingly anyway.  For those of us that
> > tune our desktops to within an inch of their lives, leave us the option,
> > please?
> > 
> > > So could we provide a 
> > > "small/normal/large font" switch or even theme?
> > 
> > If this is the direction you want to go, could you at least leave the
> > full selection available as "advanced"?
> > 
> > > 
> > > christoph
> > > 
> > > 
> > -- 
> >                 Matthew Saltzman
> > 
> > Clemson University Math Sciences
> > mjs AT clemson DOT edu
> > http://www.math.clemson.edu/~mjs
> > 
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From dcbw at redhat.com  Wed Oct 24 14:34:08 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 24 Oct 2007 10:34:08 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <d5ad21470710240613i1b534b6bv662f666f21e77389@mail.gmail.com>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
	<d5ad21470710240613i1b534b6bv662f666f21e77389@mail.gmail.com>
Message-ID: <1193236448.2557.15.camel@localhost.localdomain>

On Wed, 2007-10-24 at 15:13 +0200, Gianluca Sforna wrote:
> On 10/23/07, Dan Williams <dcbw at redhat.com> wrote:
> > Perhaps this weekend (unless I'm still fixing bugs with NM in general)
> > I'll integrate the work Soren did for a system config service which will
> > allow connections to be brought up before you log in.
> 
> OT: is this Soren Sandmann?
> If so, I'm pretty sure now I understand why I had no replies on a mail
> I sent him lately...

Correct :)

Dan




From alan at redhat.com  Wed Oct 24 14:38:38 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 24 Oct 2007 10:38:38 -0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
Message-ID: <20071024143838.GB8263@devserv.devel.redhat.com>

On Wed, Oct 24, 2007 at 06:14:27PM +0400, Peter Lemenkov wrote:
> OMG!
> Someone still playing (and buying) AudioCDs!

They make a good archive format, and as the are uncompressed are also
rather higher quality data sources. Plus they don't mysteriously vanish
when your pet DRM crippled music store vanishes 8)



From j.w.r.degoede at hhs.nl  Wed Oct 24 14:38:46 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 24 Oct 2007 16:38:46 +0200
Subject: Heads-up: lm_sensors will go to 3.0.0 for F-9, all users will need
 patching for new API
Message-ID: <471F58F6.6070808@hhs.nl>

Hi all,

In upstream lm_sensors I've been contributing to a major new release 
lm_sensors-3.0.0 . The major new item here is that the new libsensors4, which 
is part of this release, no longer contains a database with all the properties 
of the supported chips, instead it uses the new 2.6 sysfs interface to 
dynmically query an hwmon driver how many inputs there are and which types 
these inputs have (it drops 2.4 support removing lots of cruft).

This means that if a new kernel gets installed which supports new hwmon chips, 
these new chips will be recognized immediately instead of that one first needs 
to install a new lm_sensors release (if available at all) to get things to work.

The new libsensors also features a new cleaned up API (one can now ask 
libsensors what the type (volt / temp / fan) of an input is, amongst other 
cleanups).

Well enough propaganda, since lm_sensors-3.x.x is a major leap forward we 
(mostly me and Phil Knirsch the lm_sensors maintainer) are going to introduce 
lm_sensor-3.0.0 into F-9.

The plan is to introduce it at the very beginning of the F-9 cycle so that 
there will be plenty of time to fix all using packages. A compat package for 
the old version is possible, but not desirable, so we will go for a hard break.

I will be working on an lm_sensors-3.0.0 package based on rc2 + a few small svn 
fixes the next few days and I'll post koji package URL's here as soon as that 
is done, so that owners of involved packages have something to test with and 
prepare there packages for this.

Here is the list of packages that uses lm_sensors on my system:
gkrellm *
ksensors **
gnome-sensors-applet **
kdebase
net-snmp
net-snmp-libs

*  Patch to convert to new API is ready (written by me)
** I will take care of these as they are mine

As for those not taken care of, I'm always willing to help, please let me know 
if you encounter any problems adjusting your packages to the new API.

Regards,

Hans



From dcbw at redhat.com  Wed Oct 24 14:42:38 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 24 Oct 2007 10:42:38 -0400
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <20071023223222.GA26820@asus.config>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
	<20071023223222.GA26820@asus.config>
Message-ID: <1193236958.2557.24.camel@localhost.localdomain>

On Tue, 2007-10-23 at 23:32 +0100, Adam Huffman wrote:
> On Tue, 23 Oct 2007, Dan Williams wrote:
> 
> > Right; NM 0.7 and later is definitely _not_ targetted at a "very narrow
> > niche".  It's targeted at hopefully >= 75% of the use-cases of Fedora.
> > 
> > Perhaps this weekend (unless I'm still fixing bugs with NM in general)
> > I'll integrate the work Soren did for a system config service which will
> > allow connections to be brought up before you log in.  That's the only
> > real blocker to using NM in a GUI-less server-type environment if you
> > like.  Other than that, most of the bits for static IP support are in
> > (applet bits to follow), the options to lock things like 802.3 duplex,
> > speed, and other stuff are in-progress by Tambet, and most of the
> > wireless options work.  
> > 
> > By the holidays, I expect we can flip NM on by default in Rawhide, even
> > if it's not default in F8.
> > 
> 
> A general comment re. NM.  It did seem odd the way such a large change
> was made so late in the F8 development cycle, with no real discussion I
> could see (please do point me to such a discussion if there was one).

It's mostly about the D-Bus interface.  Since the D-Bus interface is no
longer insane, but quite clear and usable, switching to 0.7 as an F8
update is completely out of the question.  With the new architecture,
it's possible to add the following things as follow-on updates to F8
that would be impossible using 0.6.x branch:

1) multiple active devices
2) good static IP support
3) PPP and Bluetooth support
4) Broadband card support (GPRS/UMTS/EVDO/etc)
5) internet connection sharing
6) better handling of similar APs with different security or on
different radio bands

These are all things people want and all are only possible building on
the architecture that 0.7 provides.

Yes, it's a gamble, and it'll be a bit rocky.  But that's _also_
compounded by landing the mac80211 stack and it's 8 or so new drivers in
F8 as well (p54, iwl3945, iwl4965, b43legacy, b43, rt2x00, ath5k,
zd1211).  So many bugs people might encounter with wireless in F8 will
be of kernel driver origin, not necessarily due to NetworkManager.  We
just have to sort out the bugs wherever they may be.

Dan

> For quite a long time it was unusable for lots of people and still seems
> a little flaky.
> 
> Was it a case of the rewrite taking longer than planned?




From jreiser at BitWagon.com  Wed Oct 24 15:04:27 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Wed, 24 Oct 2007 08:04:27 -0700
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
Message-ID: <471F5EFB.9000407@BitWagon.com>

Peter Lemenkov wrote:
> 2007/10/19, John Reiser <jreiser at bitwagon.com>:
> 
>>Is there a preference to limit the drive speed when playing
>>compact disc digital audio?  I find that "eject -x 8 /dev/cdrom"
> 
> 
> OMG!
> Someone still playing (and buying) AudioCDs!

I object to the low fidelity of the usual .ogg, .mp3, etc.
I can recognize the difference within a few measures of music,
and I prefer to listen to CD-DA.

-- 



From varekova at redhat.com  Wed Oct 24 15:08:59 2007
From: varekova at redhat.com (Ivana Varekova)
Date: Wed, 24 Oct 2007 17:08:59 +0200
Subject: gsl-devel package is split
Message-ID: <471F600B.3000404@redhat.com>

Hello,
gsl-devel package was just split into gsl-devel and gsl-static in devel 
branch.
If there is any problem/comment, please write me a mail.
Ivana Varekova



From jreiser at BitWagon.com  Wed Oct 24 15:09:16 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Wed, 24 Oct 2007 08:09:16 -0700
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <200710241529.09209.opensource@till.name>
References: <47190B89.1030506@BitWagon.com>
	<200710241529.09209.opensource@till.name>
Message-ID: <471F601C.9050504@BitWagon.com>

Till Maas wrote:
> On Fr Oktober 19 2007, John Reiser wrote:
> 
>>Is there a preference to limit the drive speed when playing
>>compact disc digital audio?  I find that "eject -x 8 /dev/cdrom" ...

> 1x is enough for playing. ...

Even if the disc and drive are error-free, then something like
4x or 8x still is worthwhile as a buffer against the possiblity
that the OS might not provide isochronous service for CD-DA.

-- 



From lightsolphoenix at gmail.com  Wed Oct 24 15:09:14 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 11:09:14 -0400
Subject: Current problems with Rawhide
Message-ID: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>

Um, I meant to report these yesterday, but I was tired and decided to wait
until now.  I noticed some problems with the packages currently in Rawhide.
I know Rawhide is supposed to be unstable (it's the development branch,
after all), but I figured I'd better report these, since the new version of
Fedora is only a few days away.

1)  PulseAudio is horribly, horribly flaky.  I dunno if it's because it's
the SVN version or what, but it crashed more times last night than it has in
the 5 months I used it before that.  Is it normal for PulseAudio to consume
50%+ of the system memory?

2)  knetworkmanager isn't working at all.  NetworkManager works, but it
refuses to use the static IP address I told it to, instead choosing one one
point higher.  Since my system requires a static IP to function, this is not
good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/01f9cd6a/attachment.htm>

From debarshi.ray at gmail.com  Wed Oct 24 15:18:12 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 24 Oct 2007 20:48:12 +0530
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
Message-ID: <3170f42f0710240818u28ee2ac8tb09f0d99d17ade73@mail.gmail.com>

> 2)  knetworkmanager isn't working at all.  NetworkManager works, but it
> refuses to use the static IP address I told it to, instead choosing one one
> point higher.  Since my system requires a static IP to function, this is not
> good.

As far as I know knetworkmanager does not work with latest
NetworkManager. Thus, KDE uses nm-applet, which works.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lemenkov at gmail.com  Wed Oct 24 15:21:46 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 24 Oct 2007 19:21:46 +0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <471F5EFB.9000407@BitWagon.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
Message-ID: <adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>

2007/10/24, John Reiser <jreiser at bitwagon.com>:
> Peter Lemenkov wrote:

> > OMG!
> > Someone still playing (and buying) AudioCDs!

> I object to the low fidelity of the usual .ogg, .mp3, etc.
> I can recognize the difference within a few measures of music,
> and I prefer to listen to CD-DA.

I'll tell you only two words  - FLAC and WavPack.

And another one - RockBox! :)

BTW if you purchased an AudioCD you helped media-monsters to punish
and torture innocent people (so-called "pirates"), so its up to you -
continue using old and inconvenient thing which capable to handle only
70+ minutes or using progressive lossless audio formats with plenty of
media players already present in Fedora of with RockBox-enabled
hardware media player.

I also heard about FLAC-support in modern media-centers (even in
AppleTV and Playstation3, using plugins of course)...
-- 
With best regards!



From caillon at redhat.com  Wed Oct 24 15:25:06 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 24 Oct 2007 11:25:06 -0400
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
Message-ID: <471F63D2.1090300@redhat.com>

Kelly Miller wrote:

> 2)  knetworkmanager isn't working at all.  NetworkManager works, but it
> refuses to use the static IP address I told it to, instead choosing one one
> point higher.  Since my system requires a static IP to function, this is not
> good.
> 
>
We're "fixing" this by making the knetworkmanager package load up the 
GNOME applet for F8 final.  When the K version is fixed, we'll remove 
the hack and the GNOME dependencies in an F8 update.



From sandeen at redhat.com  Wed Oct 24 15:37:24 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 24 Oct 2007 10:37:24 -0500
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
Message-ID: <471F66B4.7070405@redhat.com>

Peter Lemenkov wrote:
> 2007/10/24, John Reiser <jreiser at bitwagon.com>:
>> Peter Lemenkov wrote:
> 
>>> OMG!
>>> Someone still playing (and buying) AudioCDs!
> 
>> I object to the low fidelity of the usual .ogg, .mp3, etc.
>> I can recognize the difference within a few measures of music,
>> and I prefer to listen to CD-DA.
> 
> I'll tell you only two words  - FLAC and WavPack.
> 
> And another one - RockBox! :)
> 
> BTW if you purchased an AudioCD you helped media-monsters to punish
> and torture innocent people (so-called "pirates"), so its up to you -
> continue using old and inconvenient thing which capable to handle only
> 70+ minutes or using progressive lossless audio formats with plenty of
> media players already present in Fedora of with RockBox-enabled
> hardware media player.

Well, I use those old inconvenient things exactly once each, to rip &
encode to a progressive lossless audio format.  So maybe I straddle that
line.  I figure if you buy the CDs used you're not doing too much
damage.  ;)

-Eric

> I also heard about FLAC-support in modern media-centers (even in
> AppleTV and Playstation3, using plugins of course)...



From nicolas.mailhot at laposte.net  Wed Oct 24 15:37:35 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 24 Oct 2007 17:37:35 +0200 (CEST)
Subject: Current problems with Rawhide
Message-ID: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>


Le Mer 24 octobre 2007 17:09, Kelly Miller a ?crit :
> I noticed some problems with the packages currently in
> Rawhide.

Rawhide is not targeting F8 any longer but F9, so every unstable
change that had to be postponed to stabilize F8 is hitting it right
now. The start of a cycle is its lowest stability point.

Regards,

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Wed Oct 24 15:41:13 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 24 Oct 2007 17:41:13 +0200 (CEST)
Subject: fontsize in 7.92
Message-ID: <29252.192.54.193.51.1193240473.squirrel@rousalka.dyndns.org>


Le Mer 24 octobre 2007 16:27, Matthew Saltzman a ?crit :
> On Wed, 2007-10-24 at 09:22 +0200, Christoph H?ger wrote:
>> Please don't misunderstand me, I did not mean "too hard to do ist
>> for
>> "normal users". I just meant that it is not comfortable to change
>> each
>> font one by one if the target is to "just get the desktop fonts
>> smaller
>> (and keep the current ratio)", not that it should not be possible to
>> change each font size individually.
>
> Ah, OK.  I apologize for speaking sharply.
>
> But still, small/normal or small/medium/large is too limiting.  I
> still
> want the range of point sizes (and I want them to mean real points!).
> I
> usually do set all my fonts to one size, but I would still advocate an
> advanced setting that allows hard-core customizers to change sizes for
> individual fonts if they want.

If you want your opinion to be heard by GNOME developers, you have to
comment on aforementioned GNOME bug

If you want to discuss font or text rendering choices in Fedora,
please use the fonts list

Regards,

-- 
Nicolas Mailhot



From bnocera at redhat.com  Wed Oct 24 15:43:15 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 24 Oct 2007 16:43:15 +0100
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
Message-ID: <1193240595.25405.126.camel@cookie.hadess.net>


On Wed, 2007-10-24 at 11:09 -0400, Kelly Miller wrote:
> Um, I meant to report these yesterday, but I was tired and decided to
> wait until now.  I noticed some problems with the packages currently
> in Rawhide.  I know Rawhide is supposed to be unstable (it's the
> development branch, after all), but I figured I'd better report these,
> since the new version of Fedora is only a few days away. 
> 
> 1)  PulseAudio is horribly, horribly flaky.  I dunno if it's because
> it's the SVN version or what, but it crashed more times last night
> than it has in the 5 months I used it before that.  Is it normal for
> PulseAudio to consume 50%+ of the system memory? 

Works fine here. File bugs!



From lightsolphoenix at gmail.com  Wed Oct 24 15:43:33 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 11:43:33 -0400
Subject: Current problems with Rawhide
In-Reply-To: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
Message-ID: <a785db460710240843s545a1ea5vd7d23ac8a36831bc@mail.gmail.com>

On 10/24/07, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> Rawhide is not targeting F8 any longer but F9, so every unstable
> change that had to be postponed to stabilize F8 is hitting it right
> now. The start of a cycle is its lowest stability point.



So F8's going to be using PulseAudio 0.9.6?  There's a stable Flash plugin
for PulseAudio, but it requires 0.9.7... which is currently in Rawhide
only...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/ba1ad3a4/attachment.htm>

From jkeating at redhat.com  Wed Oct 24 15:43:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 11:43:45 -0400
Subject: Current problems with Rawhide
In-Reply-To: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
Message-ID: <20071024114345.020843f4@redhat.com>

On Wed, 24 Oct 2007 17:37:35 +0200 (CEST)
"Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:

> Rawhide is not targeting F8 any longer but F9, so every unstable
> change that had to be postponed to stabilize F8 is hitting it right
> now.

Wrong.  the rawhide trees are still composing from the f8-final koji
tag.  This tag is only getting new builds as requested through rel-eng.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/f41ba7bc/attachment.sig>

From kevin.kofler at chello.at  Wed Oct 24 15:46:56 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 24 Oct 2007 15:46:56 +0000 (UTC)
Subject: Current problems with Rawhide
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
Message-ID: <loom.20071024T154300-923@post.gmane.org>

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> Rawhide is not targeting F8 any longer but F9, so every unstable
> change that had to be postponed to stabilize F8 is hitting it right
> now. The start of a cycle is its lowest stability point.

Actually no, no .fc9 builds have hit Rawhide yet. But you're right to warn 
about this. Rawhide is probably going to switch to tracking F9 at some point 
BEFORE the F8 release (at least that's how it was for the previous releases), 
so if you intend to move to the stable version, you have to watch carefully for 
when to stop pulling from Rawhide or you'll end up with a mess of F9 packages 
which is essentially impossible to untangle.

        Kevin Kofler



From lightsolphoenix at gmail.com  Wed Oct 24 15:48:51 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 11:48:51 -0400
Subject: Current problems with Rawhide
In-Reply-To: <1193240595.25405.126.camel@cookie.hadess.net>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
Message-ID: <a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>

On 10/24/07, Bastien Nocera <bnocera at redhat.com> wrote:
>
>
> Works fine here. File bugs!



I'm not getting any feedback from the system on it.  It just dies, so I'm
not sure where to look for logs related to it.  I can't even get it to
happen consistently; sometimes it'll run fine for half an hour and then
suddenly die, and sometimes it'll die two seconds in.  I know it's being
shut down because of the 50%+ system check, but I'm not sure why it keeps
running like that...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/21fd8dc0/attachment.htm>

From mjs at CLEMSON.EDU  Wed Oct 24 15:52:06 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Wed, 24 Oct 2007 11:52:06 -0400
Subject: rawhide report: 20071024 changes
In-Reply-To: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
Message-ID: <1193241126.5103.50.camel@vincent52.localdomain>

On Wed, 2007-10-24 at 06:59 -0400, Build System wrote:
> 
> 
> Updated Packages:
> ...

When I try to update, yum reports that all of these are unsigned!

> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From mike at miketc.com  Wed Oct 24 15:52:30 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 24 Oct 2007 10:52:30 -0500
Subject: Development to Official
In-Reply-To: <20071024090014.1737f6b8@weaponx.rchland.ibm.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
Message-ID: <1193241150.2109.2.camel@scrappy.miketc.com>

On Wed, 2007-10-24 at 09:00 -0500, Josh Boyer wrote:

> Rawhide is still composing from f8-final, so it doesn't pick up any of
> the changes in the devel branch of CVS.

This is what I figured.  When does rawhide start picking up the devel
cvs branch?  Right up until the release goes gold and spins are created
and such?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jkeating at redhat.com  Wed Oct 24 15:54:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 11:54:15 -0400
Subject: Development to Official
In-Reply-To: <1193241150.2109.2.camel@scrappy.miketc.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
Message-ID: <20071024115415.1195fdc5@redhat.com>

On Wed, 24 Oct 2007 10:52:30 -0500
Mike Chambers <mike at miketc.com> wrote:

> This is what I figured.  When does rawhide start picking up the devel
> cvs branch?  Right up until the release goes gold and spins are
> created and such?

Once the GOLD release has been spun, we redirect rawhide to pull from
the next target.  Announcements will be made.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/c432f119/attachment.sig>

From lightsolphoenix at gmail.com  Wed Oct 24 15:58:33 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 11:58:33 -0400
Subject: Current problems with Rawhide
In-Reply-To: <471F63D2.1090300@redhat.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<471F63D2.1090300@redhat.com>
Message-ID: <a785db460710240858h78eb7147xddbb8963ef1ca226@mail.gmail.com>

> We're "fixing" this by making the knetworkmanager package load up the
> GNOME applet for F8 final.  When the K version is fixed, we'll remove
> the hack and the GNOME dependencies in an F8 update.


Yeah, I didn't think anyone would miss that problem.  I still don't entirely
understand why NetworkManager itself (nm-applet) is screwing up my IP,
though.

I set it to give me a standard IP of 192.168.2.4 on my network all the time,
because my computer acts as an LDAP/NFS server for the rest of the computers
on the network.  However, when I activate NetworkManager, my IP becomes
192.168.2.5.  When I turn it off and use the old networking system, I get
the IP I asked for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/62c54ad8/attachment.htm>

From mike at miketc.com  Wed Oct 24 16:09:06 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 24 Oct 2007 11:09:06 -0500
Subject: Development to Official
In-Reply-To: <20071024115415.1195fdc5@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
Message-ID: <1193242146.2109.5.camel@scrappy.miketc.com>

On Wed, 2007-10-24 at 11:54 -0400, Jesse Keating wrote:

> Once the GOLD release has been spun, we redirect rawhide to pull from
> the next target.  Announcements will be made.

Ok, that is the answer I was looking for. Then we can change repo files
to updates and testing, obviously once they are available and exist.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From bernie at codewiz.org  Wed Oct 24 16:14:04 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Wed, 24 Oct 2007 12:14:04 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071023103410.46acd566@redhat.com>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>	<471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org>	<1193148798.8542.285.camel@cutter>	<20071023101828.28ab1670@redhat.com>	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com>
Message-ID: <471F6F4C.6040307@codewiz.org>

On 10/23/07 10:34, Jesse Keating wrote:
> On Tue, 23 Oct 2007 16:23:24 +0200
> Tomas Mraz <tmraz at redhat.com> wrote:
> 
>> Why remove? Just not use a built-in code but call NSS instead.
> 
> Call NSS, to make a sha1sum?

Please, let's not add an external dependency for something
as trivial as a SHA1.

See this thread on xorg-devel@ .

-------- Original Message --------
Subject: Re: glyph-pixmaps merged
Date: Sun, 21 Oct 2007 05:11:40 +0200
From: Edgar Toernig <froese at gmx.de>
To: xorg at freedesktop.org

Keith Packard wrote:
>
> We need a strong hash function as this replaces the previous weak hash +
> memcmp when checking incoming glyphs for matches with the existing set
> of server-resident glyphs. One could argue that this must be
> cryptographically secure to avoid applications uploading misleading
> glyph images.
> 
> Patches to use alternate SHA1 implementation would also be welcome, if
> anyone has reason to choose other bits.

Below is a modified sha1 routine.  The algorithm has been kept
but support for byte streams and byte-order independence has
been dropped.  That simplifies the code and makes it faster.

Compiles to about 700 bytes on x86 and is public domain.

Ciao, ET.

----8<----
#include <sys/types.h>
#include <string.h>

typedef unsigned int u32;

#define f1(x,y,z)   (z ^ (x & (y ^ z)))		/* x ? y : z */
#define f2(x,y,z)   (x ^ y ^ z)			/* xor */
#define f3(x,y,z)   ((x & y) + (z & (x ^ y)))	/* majority */

#define K1  0x5A827999L	/* Rounds  0-19: sqrt(2) * 2^30 */
#define K2  0x6ED9EBA1L	/* Rounds 20-39: sqrt(3) * 2^30 */
#define K3  0x8F1BBCDCL	/* Rounds 40-59: sqrt(5) * 2^30 */
#define K4  0xCA62C1D6L	/* Rounds 60-79: sqrt(10) * 2^30 */

static inline u32
rol32(u32 val, int n)
{
    return (val << n) | (val >> (32 - n));
}

static void
sha1(u32 digest[5], u32 *W)
{
    u32 a, b, c, d, e, t;
    int i;

    for (i = 0; i < 64; i++)
	W[i+16] = rol32(W[i+13] ^ W[i+8] ^ W[i+2] ^ W[i], 1);

    a = digest[0];
    b = digest[1];
    c = digest[2];
    d = digest[3];
    e = digest[4];

    for (i = 0; i < 20; i++)
    {
	t = f1(b, c, d) + K1 + rol32(a, 5) + e + W[i];
	e = d; d = c; c = rol32(b, 30); b = a; a = t;
    }

    for (; i < 40; i++)
    {
	t = f2(b, c, d) + K2 + rol32(a, 5) + e + W[i];
	e = d; d = c; c = rol32(b, 30); b = a; a = t;
    }

    for (; i < 60; i++)
    {
	t = f3(b, c, d) + K3 + rol32(a, 5) + e + W[i];
	e = d; d = c; c = rol32(b, 30); b = a; a = t;
    }

    for (; i < 80; i++)
    {
	t = f2(b, c, d) + K4 + rol32(a, 5) + e + W[i];
	e = d; d = c; c = rol32(b, 30); b = a; a = t;
    }

    digest[0] += a;
    digest[1] += b;
    digest[2] += c;
    digest[3] += d;
    digest[4] += e;
}

void
hash_buffer(u32 digest[5], char *buf, size_t n)
{
    u32 W[80];
    u32 size = n;

    digest[0] = 0x67452301;
    digest[1] = 0xefcdab89;
    digest[2] = 0x98badcfe;
    digest[3] = 0x10325476;
    digest[4] = 0xc3d2e1f0;

    if (n < 64)
	memset((char *)W + n, 0, 64 - n);
    while (n >= 64)
    {
	memcpy((char *)W, buf, 64);
	sha1(digest, W);
	buf += 64;
	n -= 64;
    }
    if (n > 0)
	memcpy((char *)W, buf, n);
    if (n > 60)
	sha1(digest, W);
    W[15] = size;
    sha1(digest, W);
}

_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg



-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From kevin.kofler at chello.at  Wed Oct 24 16:21:18 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 24 Oct 2007 16:21:18 +0000 (UTC)
Subject: Development to Official
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
Message-ID: <loom.20071024T161727-347@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> Once the GOLD release has been spun, we redirect rawhide to pull from
> the next target.  Announcements will be made.

WARNING: spun != officially released. This is something you and I (and whoever 
else works on Fedora packaging or watches it closely) know, but at every 
release some users wanting to switch from Rawhide to final get burned by this, 
so here's my warning:
The release is spun some days BEFORE it is officially released, because mirrors 
need time to download it from the master server. Therefore, Rawhide normally 
switches to tracking the next release a few days BEFORE the official release. 
So make sure you check the latest announcements before updating from Rawhide if 
you intend to switch to the stable release.

        Kevin Kofler






From ssorce at redhat.com  Wed Oct 24 16:23:53 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Wed, 24 Oct 2007 12:23:53 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471F6F4C.6040307@codewiz.org>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>	<471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org>	<1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com>  <471F6F4C.6040307@codewiz.org>
Message-ID: <1193243033.24962.56.camel@localhost.localdomain>

On Wed, 2007-10-24 at 12:14 -0400, Bernardo Innocenti wrote:
> On 10/23/07 10:34, Jesse Keating wrote:
> > On Tue, 23 Oct 2007 16:23:24 +0200
> > Tomas Mraz <tmraz at redhat.com> wrote:
> > 
> >> Why remove? Just not use a built-in code but call NSS instead.
> > 
> > Call NSS, to make a sha1sum?
> 
> Please, let's not add an external dependency for something
> as trivial as a SHA1.

Just make it easy to compile with NSS or use your own if NSS is not
available.
I don't like the work I need to do to make this happen in my packages
either, but if you use a generic crypto lib it will make your life
easier in the long run (esp. if you make it possible to change algos
easily maybe even with just a configuration option)

> See this thread on xorg-devel@ .

The world is full of people reinventing the wheel :) why is that thread
relevant ?

Simo.




From kagesenshi.87 at gmail.com  Wed Oct 24 16:26:40 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Thu, 25 Oct 2007 00:26:40 +0800
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
Message-ID: <c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>

On 10/24/07, Kelly Miller <lightsolphoenix at gmail.com> wrote:
> On 10/24/07, Bastien Nocera <bnocera at redhat.com> wrote:
> >
> > Works fine here. File bugs!
>
>
> I'm not getting any feedback from the system on it.  It just dies, so I'm
> not sure where to look for logs related to it.  I can't even get it to
> happen consistently; sometimes it'll run fine for half an hour and then
> suddenly die, and sometimes it'll die two seconds in.  I know it's being
> shut down because of the 50%+ system check, but I'm not sure why it keeps
> running like that...
>

by default F-8 pulseaudio logs into syslog ..

cat /var/log/messages|grep -i pulse



-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From opensource at till.name  Wed Oct 24 16:38:15 2007
From: opensource at till.name (Till Maas)
Date: Wed, 24 Oct 2007 18:38:15 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071023123947.GA5231@jadzia.bu.edu>
References: <471B9291.4060800@amiga-hardware.com>
	<200710222254.35624@rineau.tsetse>
	<20071023123947.GA5231@jadzia.bu.edu>
Message-ID: <200710241838.20472.opensource@till.name>

On Di Oktober 23 2007, Matthew Miller wrote:
> On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > > We prefer 32bit on those platforms.
> >
> > What if I have a x86_64 platform and nevertheless want only a 64-bits
> > kernel and almost all 32-bits apps??
>
> Given the architecture constraints, why do you want that? Is this a real
> use case that should be given serious consideration?

This sounds interesting for me. I manage a system that runs from a compact 
flash card and runs a i686 kernel. Is it possible to just install a x86_64 
kernel there? It's a 64bit capable CPU. The advantage is that the traffic 
counters for the network interfaces are then 64bit counters (the machine has 
5 GBit Ports). So when the traffic is at full GBit speed, there is an integer 
overflow around every 20 seconds with 32Bit counters. And this is the only 
part, where I would need 64bit on this machine.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/94615232/attachment.sig>

From myfedora at richip.dhs.org  Wed Oct 24 16:52:54 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 24 Oct 2007 10:52:54 -0600
Subject: firefox-2.0.0.8 Upgrade Problems in F7
Message-ID: <1193244774.19243.9.camel@localhost6.localdomain6>

Hi,

It looks like firefox-2.0.0.8 finally made it to F7 updates.
Unfortunately, this breaks a couple of dependencies (for me, Miro,
gnome-gtk2-gtkmozembed, yelp and devhelp).

I understand that Miro is still heavily under development and might need
to hard-require a specific version of firefox (2.0.0.5).
gnome-gtk2-gtkmozembed might also be just as sensitive to changes. My
question, though, is what functionalities are in place to catch
dependency breakages when packages are uploaded to the repository? Does
the system inform the breaking package maintainer that his check-in will
break other packages? Does it inform the broken package maintainers that
they need to update their packages? Is there an easy way to allow
multiple installations to support both versions? Most importantly, is
there a way that such check-ins can be postponed in a containment unit
pending check-ins of packages which resolve the breakage in that
specific repository (by this, I mean fedora-updates, but do third-party
repos have a system for resolving their own problems)?
--

Richi Plana



From myfedora at richip.dhs.org  Wed Oct 24 16:57:39 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 24 Oct 2007 10:57:39 -0600
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193244774.19243.9.camel@localhost6.localdomain6>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
Message-ID: <1193245059.19243.14.camel@localhost6.localdomain6>

I guess I should have added that the reason the update broke yelp and
devhelp is that they both require a specific version of the virtual
provides gecko-libs which firefox-2.0.0.8 updates. The questions still
apply, though.

On Wed, 2007-10-24 at 10:52 -0600, Richi Plana wrote:
> Hi,
> 
> It looks like firefox-2.0.0.8 finally made it to F7 updates.
> Unfortunately, this breaks a couple of dependencies (for me, Miro,
> gnome-gtk2-gtkmozembed, yelp and devhelp).
> 
> I understand that Miro is still heavily under development and might need
> to hard-require a specific version of firefox (2.0.0.5).
> gnome-gtk2-gtkmozembed might also be just as sensitive to changes. My
> question, though, is what functionalities are in place to catch
> dependency breakages when packages are uploaded to the repository? Does
> the system inform the breaking package maintainer that his check-in will
> break other packages? Does it inform the broken package maintainers that
> they need to update their packages? Is there an easy way to allow
> multiple installations to support both versions? Most importantly, is
> there a way that such check-ins can be postponed in a containment unit
> pending check-ins of packages which resolve the breakage in that
> specific repository (by this, I mean fedora-updates, but do third-party
> repos have a system for resolving their own problems)?
> --
> 
> Richi Plana
> 



From alan at redhat.com  Wed Oct 24 17:04:38 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 24 Oct 2007 13:04:38 -0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
Message-ID: <20071024170438.GA12628@devserv.devel.redhat.com>

On Wed, Oct 24, 2007 at 07:21:46PM +0400, Peter Lemenkov wrote:
> BTW if you purchased an AudioCD you helped media-monsters to punish
> and torture innocent people (so-called "pirates"), so its up to you -

Nope.. there are lots of audio CDs available from non major media companies
who are not evil.

Alan



From alan at redhat.com  Wed Oct 24 17:09:13 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 24 Oct 2007 13:09:13 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471F6F4C.6040307@codewiz.org>
References: <471C94BD.6080801@codewiz.org> <ffja8k$dj7$1@ger.gmane.org>
	<200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
Message-ID: <20071024170913.GC12628@devserv.devel.redhat.com>

On Wed, Oct 24, 2007 at 12:14:04PM -0400, Bernardo Innocenti wrote:
> Please, let's not add an external dependency for something
> as trivial as a SHA1.

The positives to adding an external dependancy are you only have
to worry about bugs in one implementation.

I also note:

> >We need a strong hash function as this replaces the previous weak hash +
> >memcmp when checking incoming glyphs for matches with the existing set
> >of server-resident glyphs. One could argue that this must be
> >cryptographically secure to avoid applications uploading misleading
> >glyph images.

Which presumably means they'll not be using SHA1 much longer - right ?



From lightsolphoenix at gmail.com  Wed Oct 24 17:11:29 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 13:11:29 -0400
Subject: Current problems with Rawhide
In-Reply-To: <c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
Message-ID: <a785db460710241011t3419b999vfe52626850b3ca96@mail.gmail.com>

On 10/24/07, Hikaru Amano <kagesenshi.87 at gmail.com> wrote:.

> by default F-8 pulseaudio logs into syslog ..
>
> cat /var/log/messages|grep -i pulse



Okay, when I get home I'll check the messages log for anything.  I'm just
not sure if it's an error with PulseAudio or with Fedora's implementation of
it (though I think I'm leaning towards the latter, since I haven't noticed
this on any other Linux distro.  But then, I don't think I've used the
0.9.7SVN sources on any other distro, either).

I'm also going to note that despite claims, I pulled the source for the
libflashsupport plugin for pulse and compiled it into an RPM, changing the
minimum version number, and it appears that it DOES work with 0.9.6 as
well.  So if anyone's interested, I'll submit it as an official package
request, since it'd be handy for people to get Flash sound out of the box
(even though they can't get Flash itself out of the box).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/b2a90d17/attachment.htm>

From howard at cohtech.com  Wed Oct 24 17:14:36 2007
From: howard at cohtech.com (Howard Wilkinson)
Date: Wed, 24 Oct 2007 18:14:36 +0100
Subject: kernel-2.6.23.1-30.fc8 problem with symbios scsi controllers.
Message-ID: <471F7D7C.2070003@cohtech.com>

I have today tried out the latest development kernel on an Intel SC450NX 
- this is a 7+ year old machine running a 4 way Intel Xeon Pentium III 
55 Mhz CPU environment. The machine has 3 in-built SCSI bus controllers 
- all Symbios.

Chip sym53c896, device id 0xb, revision id 0x1
At PCI address 0000:01:03.0, IRQ 17
Min. period factor 10, Wide SCSI BUS
Max. started commands 448, max. commands per LUN 64

Chip sym53c896, device id 0xb, revision id 0x1
At PCI address 0000:01:03.1, IRQ 18
Min. period factor 10, Wide SCSI BUS
Max. started commands 448, max. commands per LUN 64

Chip sym53c810a, device id 0x1, revision id 0x23
At PCI address 0000:00:08.0, IRQ 19
Min. period factor 25, Narrow SCSI BUS
Max. started commands 448, max. commands per LUN 64


The box currently has 2 * 73GB drives on SCSI Channel 1.

Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: ESG-SHV  Model: SCA HSBP M6      Rev: 0.63
  Type:   Processor                        ANSI  SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST373307LC       Rev: DS09
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: SEAGATE  Model: ST373405LC       Rev: 2203
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: CREATIVE Model: CD5233E          Rev: 1.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05

The system has been running the latest fedora kernels from FC7 as they 
have been released. The current one is 2.6.22.9-91.fc7. However with the 
FC8 candidate kernel (and the corresponding FC7 one in the testing 
updates) the Symbios buses fail to initialise properly.

Booting'Fedora(2.6.23.1-30.fc8)'                                                 
root(hd0,0)Filesystem type is ext2fs, partition type 
0xfd                             kernel /vmlinuz-2.6.23.1-30.fc8 ro 
root=/dev/md0 console=tty0 console=ttyS0,19200n8 audit=0                 
[Linux-bzImage, 
setup=0x2e00,size=0x1dfcc0]                                               
Linux version 2.6.23.1-30.fc8 (kojibuilder at hammer2.fedora.redhat.com) 
(gcc version 4.1.2 20070925 (Red Hat 4.1.2-32)) #1 SMP Mon Oct 22 
18:46:28 EDT 2007
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d800 (usable)
 BIOS-e820: 000000000009d800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0400 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000f9ffa800 (usable)
 BIOS-e820: 00000000f9ffa800 - 00000000f9fffc00 (ACPI data)
 BIOS-e820: 00000000f9fffc00 - 00000000fa000000 (ACPI NVS)
 BIOS-e820: 00000000fe900000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000106000000 (usable)
Warning only 4GB will be used.
Use a HIGHMEM64G enabled kernel.
3200MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f6b70
Using x86 segment limits to approximate NX protection
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->  1048576
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->  1048576
DMI 2.1 present.
Using APIC driver default
ACPI: RSDP 000F6B50, 0014 (r0 PTLTD )
ACPI: RSDT F9FFABDF, 002C (r1 INTEL  S450NX01        0 INTL  1000000)
ACPI: FACP F9FFFAFE, 0074 (r1 Intel  S450NX          2 INT     F4240)
ACPI: DSDT F9FFAC0B, 4EF3 (r1  INTEL  S450NX1        1 MSFT  1000009)
ACPI: FACS F9FFFFC0, 0040
ACPI: APIC F9FFFB72, 008E (r1 Intel  Custom          1 INT  10000000)
ACPI: PM-Timer IO Port: 0xc08
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:7 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:7 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
Processor #2 6:7 APIC version 17
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
Processor #3 6:7 APIC version 17
ACPI: LAPIC_NMI (acpi_id[0x00] low level lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] low level lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] low level lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] low level lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 19, address 0xfec00000, GSI 0-63
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at fa800000 (gap: fa000000:04900000)
swsusp: Registered nosave memory region: 000000000009d000 - 000000000009e000
swsusp: Registered nosave memory region: 000000000009e000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f1000
swsusp: Registered nosave memory region: 00000000000f1000 - 0000000000100000
Built 1 zonelists in Zone order.  Total pages: 1040384
Kernel command line: ro root=/dev/md0 console=tty0 console=ttyS0,19200n8 
audit=0
audit: disabled (after initialization)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c07a7000 soft=c0787000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 550.197 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 4053376k/4194304k available (2183k kernel code, 41252k reserved, 
1113k data, 280k init, 3178472k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc53000 - 0xfffff000   (3760 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc073e000 - 0xc0784000   ( 280 kB)
      .data : 0xc0621e0d - 0xc0738544   (1113 kB)
      .text : 0xc0400000 - 0xc0621e0d   (2183 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=4, Nodes=1
Calibrating delay using timer specific routine.. 1101.19 BogoMIPS 
(lpj=550597)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
CPU0: Intel Pentium III (Katmai) stepping 03
SMP alternatives: switching to SMP code
Booting processor 1/0 eip 3000
CPU 1 irqstacks, hard=c07a8000 soft=c0788000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1100.13 BogoMIPS 
(lpj=550068)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Katmai) stepping 03
SMP alternatives: switching to SMP code
Booting processor 2/1 eip 3000
CPU 2 irqstacks, hard=c07a9000 soft=c0789000
Initializing CPU#2
Calibrating delay using timer specific routine.. 1100.17 BogoMIPS 
(lpj=550087)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#2.
CPU2: Intel Pentium III (Katmai) stepping 03
SMP alternatives: switching to SMP code
Booting processor 3/2 eip 3000
CPU 3 irqstacks, hard=c07aa000 soft=c078a000
Initializing CPU#3
Calibrating delay using timer specific routine.. 1100.17 BogoMIPS 
(lpj=550085)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#3.
CPU3: Intel Pentium III (Katmai) stepping 03
Total of 4 processors activated (4401.67 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
checking TSC synchronization [CPU#0 -> CPU#2]: passed.
checking TSC synchronization [CPU#0 -> CPU#3]: passed.
Brought up 4 CPUs
Booting paravirtualized kernel on bare hardware
Time: 17:00:44  Date: 10/24/07
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb33, last bus=3
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
PCI quirk: region 0c00-0c3f claimed by PIIX4 ACPI
PCI quirk: region 0cc0-0ccf claimed by PIIX4 SMB
PIIX4 devres B PIO at 0ca2-0ca3
PIIX4 devres C PIO at 0ca0-0ca1
PCI: Searching for i450NX host bridges on 0000:00:10.0
ACPI: PCI Root Bridge [PCI1] (0000:01)
ACPI: Bus 0000:01 not present in PCI namespace
ACPI: PCI Interrupt Link [IT00] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT01] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT02] (IRQs 3 4 5 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [IT10] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT11] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT12] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT20] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT21] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT22] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT30] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT31] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT32] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT42] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [IT38] (IRQs 3 4 5 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [IT39] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT03] (IRQs 3 4 *5 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [IT04] (IRQs 3 5 7 10 *11 15)
ACPI: PCI Interrupt Link [IT05] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT06] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT13] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [IT14] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [IT15] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT16] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT23] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT24] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT25] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT26] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT33] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT34] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT35] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT36] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [IT41] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [IT40] (IRQs 3 4 5 7 10 *11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a 
report
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Time: tsc clocksource has been installed.
pnp: 00:01: ioport range 0xc10-0xc3f has been reserved
pnp: 00:01: ioport range 0xca0-0xca7 has been reserved
pnp: 00:01: ioport range 0xcc0-0xccf has been reserved
pnp: 00:01: iomem range 0xffe00000-0xffffffff could not be reserved
pnp: 00:01: iomem range 0xfec00000-0xfec00fff could not be reserved
PCI: Bridge: 0000:01:01.0
  IO window: 4000-4fff
  MEM window: fe100000-fe2fffff
  PREFETCH window: fe700000-fe7fffff
PCI: Bridge: 0000:01:02.0
  IO window: 5000-5fff
  MEM window: fe300000-fe4fffff
  PREFETCH window: fe800000-fe8fffff
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1572864 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs...<6>Switched to high resolution mode on 
CPU 1
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 2
 it is
Freeing initrd memory: 3049k freed
apm: BIOS not found.
audit: initializing netlink socket (disabled)
audit(1193245243.347:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
ksign: Installing public key data
Loading keyring
- Added public key 559AEDE0E277CA54
- User ID: Red Hat, Inc. (Kernel Module GPG key)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: Firmware left 0000:02:04.0 e100 interrupts enabled, disabling
PCI: Firmware left 0000:02:05.0 e100 interrupts enabled, disabling
PCI: Firmware left 0000:03:04.0 e100 interrupts enabled, disabling
PCI: Firmware left 0000:03:05.0 e100 interrupts enabled, disabling
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
?serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:KBC,PNP0f03:MOUS] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
  Magic number: 11:592:37
Freeing unused kernel memory: 280k freed
Write protecting the kernel read-only data: 847k
Red Hat nash version 6.0.9 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:0c.2[D] -> GSI 54 (level, low) -> IRQ 16
uhci_hcd 0000:00:0c.2: UHCI Host Controller
uhci_hcd 0000:00:0c.2: new USB bus registered, assigned bus number 1
input: PS/2 Generic Mouse as /class/input/input2
uhci_hcd 0000:00:0c.2: irq 16, io base 0x00002440
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Loading ohci-hcd.ko module
Loading ehci-hcd.ko module
Loading mbcache.ko module
Loading jbd.ko module
Loading ext3.ko module
Loading raid1.ko module
md: raid1 personality registered for level 1
Loading xor.ko module
xor: automatically using best checksumming function: pIII_sse
   pIII_sse  :  1104.000 MB/sec
xor: using function: pIII_sse (1104.000 MB/sec)
Loading async_tx.ko module
async_tx: api initialized (async)
Loading async_memcpy.ko module
Loading async_xor.ko module
Loading raid456.ko module
raid6: int32x1    132 MB/s
raid6: int32x2    125 MB/s
raid6: int32x4    152 MB/s
raid6: int32x8    156 MB/s
raid6: mmxx1      367 MB/s
raid6: mmxx2      417 MB/s
raid6: sse1x1     296 MB/s
raid6: sse1x2     394 MB/s
raid6: using algorithm sse1x2 (394 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading scsi_transport_spi.ko module
Loading sym53c8xx.ko module
ACPI: Unable to derive IRQ for device 0000:01:03.0
ACPI: PCI Interrupt 0000:01:03.0[A]: no GSI - using IRQ 11
sym0: <896> rev 0x1 at pci 0000:01:03.0 irq 11
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
ACPI: Unable to derive IRQ for device 0000:01:03.1
ACPI: PCI Interrupt 0000:01:03.1[B]: no GSI - using IRQ 11
sym1: <896> rev 0x1 at pci 0000:01:03.1 irq 11
sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.3
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 58 (level, low) -> IRQ 17
sym2: <810a> rev 0x23 at pci 0000:00:08.0 irq 17
sym2: No NVRAM, ID 7, Fast-10, SE, parity checking
sym2: SCSI BUS has been reset.
scsi2 : sym-2.2.3
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: 
dm-devel at redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
scsi: waiting for bus probes to complete ...
scsi 0:0:0:0: ABORT operation started.
scsi 1:0:0:0: ABORT operation started.
scsi 0:0:0:0: ABORT operation timed-out.
scsi 0:0:0:0: DEVICE RESET operation started.
scsi 1:0:0:0: ABORT operation timed-out.
scsi 1:0:0:0: DEVICE RESET operation started.
scsi 0:0:0:0: DEVICE RESET operation timed-out.
scsi 0:0:0:0: BUS RESET operation started.
scsi 1:0:0:0: DEVICE RESET operation timed-out.
scsi 1:0:0:0: BUS RESET operation started.
scsi 0:0:0:0: BUS RESET operation timed-out.
scsi 0:0:0:0: HOST RESET operation started.
sym0: SCSI BUS has been reset.
scsi 1:0:0:0: BUS RESET operation timed-out.
scsi 1:0:0:0: HOST RESET operation started.
sym1: SCSI BUS has been reset.
scsi 0:0:0:0: HOST RESET operation timed-out.
scsi 0:0:0:0: scsi: Device offlined - not ready after error recovery
scsi 1:0:0:0: HOST RESET operation timed-out.
scsi 1:0:0:0: scsi: Device offlined - not ready after error recovery
scsi 0:0:1:0: ABORT operation started.
scsi 1:0:1:0: ABORT operation started.
scsi 0:0:1:0: ABORT operation timed-out.
scsi 0:0:1:0: DEVICE RESET operation started.
scsi 1:0:1:0: ABORT operation timed-out.
scsi 1:0:1:0: DEVICE RESET operation started.

and so on until all devices on all 3 buses have timed out!

Anybody got any suggestions? Ones that I may want to act on :-)

Apologies for the length of the Email but I am trying to provide 
sufficient information in the first shot this time.

Regards, Howard

-- 

Howard Wilkinson

	

Phone:

	

+44(20)76907075

Coherent Technology Limited

	

Fax:

	

 

23 Northampton Square,

	

Mobile:

	

+44(7980)639379

United Kingdom, EC1V 0HL

	

Email:

	

howard at cohtech.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/480d58a2/attachment.htm>

From jkeating at redhat.com  Wed Oct 24 17:30:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 13:30:43 -0400
Subject: Development to Official
In-Reply-To: <loom.20071024T161727-347@post.gmane.org>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
Message-ID: <20071024133043.3934b8e0@redhat.com>

On Wed, 24 Oct 2007 16:21:18 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> WARNING: spun != officially released. This is something you and I
> (and whoever else works on Fedora packaging or watches it closely)
> know, but at every release some users wanting to switch from Rawhide
> to final get burned by this, so here's my warning:
> The release is spun some days BEFORE it is officially released,
> because mirrors need time to download it from the master server.
> Therefore, Rawhide normally switches to tracking the next release a
> few days BEFORE the official release. So make sure you check the
> latest announcements before updating from Rawhide if you intend to
> switch to the stable release.

We can prevent this by just holding rawhide until the day of the
release.  Of course this tends to piss off developers who want their
new bits looked at.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/7a275bde/attachment.sig>

From laurent.rineau__fedora at normalesup.org  Wed Oct 24 17:35:26 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Wed, 24 Oct 2007 19:35:26 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071023160440.GA25063@jadzia.bu.edu>
References: <471B9291.4060800@amiga-hardware.com>
	<544eb990710230613m500cffe6y95edf93d66dfbbea@mail.gmail.com>
	<20071023160440.GA25063@jadzia.bu.edu>
Message-ID: <200710241935.26512@rineau.tsetse>

On Tuesday 23 October 2007 18:04:40 Matthew Miller wrote:
> On Tue, Oct 23, 2007 at 02:13:16PM +0100, Bill Crawford wrote:
> > > On Mon, Oct 22, 2007 at 10:54:35PM +0200, Laurent Rineau wrote:
> > > > > We prefer 32bit on those platforms.
> > > >
> > > > What if I have a x86_64 platform and nevertheless want only a 64-bits
> > > > kernel and almost all 32-bits apps?
> > >
> > > Given the architecture constraints, why do you want that? Is this a
> > > real use case that should be given serious consideration?
> >
> > 32-bit code for most platforms is smaller *and* uses less memory
> > (pointers at least being half the size). There is often a speed
> > penalty too.
>
> But we're not talking about "most platforms". We're talking about x86_64.

i386 applications use less memory that x86_64 ones. I would prefere to run 
under x86_64 only for applications that needs more that 2Go of memory.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From gemi at bluewin.ch  Wed Oct 24 17:30:53 2007
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Wed, 24 Oct 2007 19:30:53 +0200
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <20071024170438.GA12628@devserv.devel.redhat.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<20071024170438.GA12628@devserv.devel.redhat.com>
Message-ID: <1193247053.10653.3.camel@localhost.localdomain>

On Wed, 2007-10-24 at 13:04 -0400, Alan Cox wrote:
> Nope.. there are lots of audio CDs available from non major media
> companies
> who are not evil.
FWIW, I listen almost exclusively to classical music, and most releases
come from rather small companies. Furthermore, those releases are
produced in small numbers compared to popular music and are quite
expensive to produce. They mostly deliver good products, often with
excellent lines notes. Maybe I am just old school, but I like holding
something in my hands, same with books.
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From agk at redhat.com  Wed Oct 24 17:51:09 2007
From: agk at redhat.com (Alasdair G Kergon)
Date: Wed, 24 Oct 2007 18:51:09 +0100
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071020220439.5fa885a1@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
Message-ID: <20071024175109.GA20802@agk.fab.redhat.com>

On Sat, Oct 20, 2007 at 10:04:39PM -0400, Jesse Keating wrote:
> The branching is done.  CVS commits have been re-enabled.  If your
> package is missing an F-8 branch please mail rel-eng at fedoraproject.org
> and we'll look into it.

Well the pkgdb part of this seems to have gone wrong for *all* the
lvm-team-owned projects, unfortunately.

Specifically, the Fedora 7 permissions were not copied across to the
new Fedora 8 correctly:

  lvm2 and device-mapper: mostly cloned OK, but 2 users were not granted
  "commit" access for F8, although they have it for the other collections.
  When I try to grant this manually, I get the error "<number> is not in a
  group that is allowed to hold the commit acl".  Yet of course they hold
  the commit acl elsewhere.

  dmraid and device-mapper-multipath: only *one* user was given access to
  F8 (watchcommits and commit).  Nobody has "approveacls" so we cannot
  even attempt to fix this ourselves.
 
What quality assurance was performed on this data edit?  Why didn't the
scripts performing the change flag up any errors?  And what about
checking the results of a major data edit like this for inconsistencies
afterwards: Were any other packages affected similarly?

Alasdair
-- 
agk at redhat.com



From jkeating at redhat.com  Wed Oct 24 17:54:02 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 13:54:02 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071024175109.GA20802@agk.fab.redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
	<20071024175109.GA20802@agk.fab.redhat.com>
Message-ID: <20071024135402.7ceeb335@redhat.com>

On Wed, 24 Oct 2007 18:51:09 +0100
Alasdair G Kergon <agk at redhat.com> wrote:

> Well the pkgdb part of this seems to have gone wrong for *all* the
> lvm-team-owned projects, unfortunately.
> 
> Specifically, the Fedora 7 permissions were not copied across to the
> new Fedora 8 correctly:
> 
>   lvm2 and device-mapper: mostly cloned OK, but 2 users were not
> granted "commit" access for F8, although they have it for the other
> collections. When I try to grant this manually, I get the error
> "<number> is not in a group that is allowed to hold the commit acl".
> Yet of course they hold the commit acl elsewhere.
> 
>   dmraid and device-mapper-multipath: only *one* user was given
> access to F8 (watchcommits and commit).  Nobody has "approveacls" so
> we cannot even attempt to fix this ourselves.
>  
> What quality assurance was performed on this data edit?  Why didn't
> the scripts performing the change flag up any errors?  And what about
> checking the results of a major data edit like this for
> inconsistencies afterwards: Were any other packages affected
> similarly?


The script showed the errors for your packages and I passed those on to
Toshio for hand fixing.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/23e233ea/attachment.sig>

From agk at redhat.com  Wed Oct 24 18:02:05 2007
From: agk at redhat.com (Alasdair G Kergon)
Date: Wed, 24 Oct 2007 19:02:05 +0100
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071024135402.7ceeb335@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
	<20071024175109.GA20802@agk.fab.redhat.com>
	<20071024135402.7ceeb335@redhat.com>
Message-ID: <20071024180205.GB20802@agk.fab.redhat.com>

On Wed, Oct 24, 2007 at 01:54:02PM -0400, Jesse Keating wrote:
> The script showed the errors for your packages and I passed those on to
> Toshio for hand fixing.
 
When did you do that?

I noticed the problem yesterday, and mailed Toshio but got no reply.

Obviously, we can't be depending on one individual for a critical part
of the fedora infrastructure:  Who is looking after the system while
Toshio is unavailable?

Alasdair
-- 
agk at redhat.com



From mike at miketc.com  Wed Oct 24 18:04:27 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 24 Oct 2007 13:04:27 -0500
Subject: Development to Official
In-Reply-To: <20071024133043.3934b8e0@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
Message-ID: <1193249067.2109.9.camel@scrappy.miketc.com>

On Wed, 2007-10-24 at 13:30 -0400, Jesse Keating wrote:

> We can prevent this by just holding rawhide until the day of the
> release.  Of course this tends to piss off developers who want their
> new bits looked at.

Then again, what is a few days of waiting?  Or even that, maybe we
should worry about bugs up until, and even right after the release (few
days anyway) to make sure no major bugs are ran into before worry about
the next release?

Just making some points, no worries either way with me.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jkeating at redhat.com  Wed Oct 24 18:04:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 14:04:43 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071024180205.GB20802@agk.fab.redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
	<20071024175109.GA20802@agk.fab.redhat.com>
	<20071024135402.7ceeb335@redhat.com>
	<20071024180205.GB20802@agk.fab.redhat.com>
Message-ID: <20071024140443.47052be5@redhat.com>

On Wed, 24 Oct 2007 19:02:05 +0100
Alasdair G Kergon <agk at redhat.com> wrote:

> When did you do that?
> 
> I noticed the problem yesterday, and mailed Toshio but got no reply.
> 
> Obviously, we can't be depending on one individual for a critical part
> of the fedora infrastructure:  Who is looking after the system while
> Toshio is unavailable?

I informed him when I was doing the branches, a couple of days ago.
It's entirely possible that he either overlooked it or thought he had
fixed it and something reverted it.  Toshio is around, we'll make sure
this gets done.  Spare your lectures.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/16ab7242/attachment.sig>

From sl at killefiz.de  Wed Oct 24 18:04:08 2007
From: sl at killefiz.de (Sven Lankes)
Date: Wed, 24 Oct 2007 18:04:08 +0000 (UTC)
Subject: Current problems with Rawhide
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
	<20071024114345.020843f4@redhat.com>
Message-ID: <slrnfhv28o.j74.sven@mail.yuio.de>

Jesse Keating <jkeating at redhat.com> schrieb:

>> Rawhide is not targeting F8 any longer but F9, so every unstable
>> change that had to be postponed to stabilize F8 is hitting it right
>> now.

> Wrong.  the rawhide trees are still composing from the f8-final koji
> tag.  This tag is only getting new builds as requested through rel-eng.

Is there a repository I can configure in my yum.repos.d instead of
development that will track what will becom "f8"?

I'm used to the debian way where I just use the codename (e.g. lenny) in
my repository-config and will end up with that even after the release.

-- 
sven === jabber/xmpp: sven at lankes.net



From jspaleta at gmail.com  Wed Oct 24 18:20:01 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 10:20:01 -0800
Subject: Development to Official
In-Reply-To: <20071024133043.3934b8e0@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
Message-ID: <604aa7910710241120p1220c5f1t270e610624c87655@mail.gmail.com>

On 10/24/07, Jesse Keating <jkeating at redhat.com> wrote:
> We can prevent this by just holding rawhide until the day of the
> release.

If you were going to do this...I think you'd want to hold off to the
day after release and have one cross over day.  And even though I'm
not a big fan of making rawhide baby friendly.. I think if there is a
consensus that a smoother upgrade path from rawhide to release is
desirable then you'll need to do this sort of hold-off.

-jef"get in my belly!"spaleta



From robert at marcanoonline.com  Wed Oct 24 18:19:31 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Wed, 24 Oct 2007 14:19:31 -0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <1193247053.10653.3.camel@localhost.localdomain>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<20071024170438.GA12628@devserv.devel.redhat.com>
	<1193247053.10653.3.camel@localhost.localdomain>
Message-ID: <1193249971.9044.2.camel@localhost.localdomain>

On Wed, 2007-10-24 at 19:30 +0200, G?rard Milmeister wrote:
> On Wed, 2007-10-24 at 13:04 -0400, Alan Cox wrote:
> > Nope.. there are lots of audio CDs available from non major media
> > companies
> > who are not evil.
> FWIW, I listen almost exclusively to classical music, and most releases
> come from rather small companies. Furthermore, those releases are
> produced in small numbers compared to popular music and are quite
> expensive to produce. They mostly deliver good products, often with
> excellent lines notes. Maybe I am just old school, but I like holding
> something in my hands, same with books.

Just to expand a little this discussion, NOT everyone lives in USA or UK
or another country with a good online store. And by the way I love to
have something physical I can sell if I want too

> -- 
> G?rard Milmeister
> Langackerstrasse 49
> CH-8057 Z?rich
> 



From jkeating at redhat.com  Wed Oct 24 18:17:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 14:17:41 -0400
Subject: Current problems with Rawhide
In-Reply-To: <slrnfhv28o.j74.sven@mail.yuio.de>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
	<20071024114345.020843f4@redhat.com>
	<slrnfhv28o.j74.sven@mail.yuio.de>
Message-ID: <20071024141741.77290bd1@redhat.com>

On Wed, 24 Oct 2007 18:04:08 +0000 (UTC)
Sven Lankes <sl at killefiz.de> wrote:

> Is there a repository I can configure in my yum.repos.d instead of
> development that will track what will becom "f8"?

Well you can enable the fedora and updates-released repos so long as
you're using mirror list.  Right now mirrormanager will redirect you to
rawhide which is still F8 bits.  Once we go GOLD it'll send you to the
final locations.  The only gotcha is that you have to turn off GPG
checking for now until we get everything signed.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/13f2d67b/attachment.sig>

From mike at miketc.com  Wed Oct 24 18:20:29 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 24 Oct 2007 13:20:29 -0500
Subject: Current problems with Rawhide
In-Reply-To: <slrnfhv28o.j74.sven@mail.yuio.de>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
	<20071024114345.020843f4@redhat.com> <slrnfhv28o.j74.sven@mail.yuio.de>
Message-ID: <1193250029.2109.13.camel@scrappy.miketc.com>

On Wed, 2007-10-24 at 18:04 +0000, Sven Lankes wrote:

> Is there a repository I can configure in my yum.repos.d instead of
> development that will track what will becom "f8"?

Look in /etc/yum.repos/ dir for your config files.  Turn on fedora-core,
fedora-updates, and fedora-updates-testing (this one being optional if
you want to test updates before they are official) and turn off
fedora-development.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From poelstra at redhat.com  Wed Oct 24 18:20:37 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 24 Oct 2007 11:20:37 -0700
Subject: Fedora Rel-Eng Meeting Recap 2007-oct-22
Message-ID: <471F8CF5.4060505@redhat.com>

Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-oct-22

Please make corrections and clarifications to the wiki page.

== Overall Discussion About F8 Readiness & Plans ==
 * Have a Gold tree by Nov 1, maybe the 2nd if it's early in the day--this week to really pound out bugs and validate install paths
 * slight issue with disk space in the colo and getting signed packages written out.  We need to do some garbage collection first
 * dropping fedora-release in today provided that mdomsch hooked up the mirrorlist cgi to return f8 requests to rawhide for now.
 * blocker list is still at 51 bugs, but quite a few of those are questionable
 * need to add link to https://fedoraproject.org/wiki/KernelCommonProblems in the release notes
 * kde libs problem https://bugzilla.redhat.com/show_bug.cgi?id=339981
 * list of known good/bad the wireless drivers--http://fedoraproject.org/wiki/JeremyKatz/Laptops
 * tomorrow's rawhide should be installable--today's needs an updates.img, but works otherwise
    * http://people.redhat.com/clumens/updates.img 

== IRC Transcript ==



From jspaleta at gmail.com  Wed Oct 24 18:26:57 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 10:26:57 -0800
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
Message-ID: <604aa7910710241126u7a2d27b3ocb525eb1ee4024df@mail.gmail.com>

On 10/24/07, Peter Lemenkov <lemenkov at gmail.com> wrote:
> BTW if you purchased an AudioCD you helped media-monsters to punish
> and torture innocent people (so-called "pirates"), so its up to you -

If you can give me proof that signaturesounds 'tortures' people. I'll
stop buying the cds from that label.

-jef"as soon as its medically possible for me to give birth to Peter
Mulvey's baby.. I will"spaleta



From jkeating at redhat.com  Wed Oct 24 18:24:30 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 14:24:30 -0400
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071024135402.7ceeb335@redhat.com>
References: <20071019231326.607bf89d@redhat.com>
	<20071020095212.402c5849@redhat.com>
	<20071020220439.5fa885a1@redhat.com>
	<20071024175109.GA20802@agk.fab.redhat.com>
	<20071024135402.7ceeb335@redhat.com>
Message-ID: <20071024142430.6e7e5de8@redhat.com>

On Wed, 24 Oct 2007 13:54:02 -0400
Jesse Keating <jkeating at redhat.com> wrote:

> The script showed the errors for your packages and I passed those on
> to Toshio for hand fixing.

Looks like I've inappropriately thrown Toshio under the bus on this
one.  I could have sworn I passed those along, but it turns out I can't
find them in my logs at all.  They are being fixed.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/958f594b/attachment.sig>

From lemenkov at gmail.com  Wed Oct 24 18:29:52 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 24 Oct 2007 22:29:52 +0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <1193249971.9044.2.camel@localhost.localdomain>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<20071024170438.GA12628@devserv.devel.redhat.com>
	<1193247053.10653.3.camel@localhost.localdomain>
	<1193249971.9044.2.camel@localhost.localdomain>
Message-ID: <adf480660710241129y79723b72ra2728be7789b745e@mail.gmail.com>

2007/10/24, Robert Marcano <robert at marcanoonline.com>:

> Just to expand a little this discussion, NOT everyone lives in USA or UK
> or another country with a good online store.

You should explore and open for yourself wonderful world of p2p-networks.

-- 
With best regards!



From sundaram at fedoraproject.org  Wed Oct 24 17:28:58 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 24 Oct 2007 22:58:58 +0530
Subject: Fedora Rel-Eng Meeting Recap 2007-oct-22
In-Reply-To: <471F8CF5.4060505@redhat.com>
References: <471F8CF5.4060505@redhat.com>
Message-ID: <471F80DA.80300@fedoraproject.org>

John Poelstra wrote:
> Recap and full IRC transcript found here:
> http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-oct-22
> 
> Please make corrections and clarifications to the wiki page.
> 
> == Overall Discussion About F8 Readiness & Plans ==
> * Have a Gold tree by Nov 1, maybe the 2nd if it's early in the 
> day--this week to really pound out bugs and validate install paths
> * slight issue with disk space in the colo and getting signed packages 
> written out.  We need to do some garbage collection first
> * dropping fedora-release in today provided that mdomsch hooked up the 
> mirrorlist cgi to return f8 requests to rawhide for now.
> * blocker list is still at 51 bugs, but quite a few of those are 
> questionable

We had a QA meeting an hour or so back where we spend sometime reviewing 
and triaging the bugs and this list is just 16 actual bugs.

https://bugzilla.redhat.com/showdependencytree.cgi?id=235703&hide_resolved=1

Some of them are already fixed but need folks to verify this. Please 
look at this list and help out.

Rahul



From tbrinkman at sbcglobal.net  Wed Oct 24 17:30:51 2007
From: tbrinkman at sbcglobal.net (Tom Brinkman)
Date: Wed, 24 Oct 2007 12:30:51 -0500
Subject: Current problems with Rawhide
In-Reply-To: <loom.20071024T154300-923@post.gmane.org>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
	<loom.20071024T154300-923@post.gmane.org>
Message-ID: <200710241230.51596.tbrinkman@sbcglobal.net>

On Wednesday 24 October 2007 10:46:56 am Kevin Kofler wrote:
> Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> > Rawhide is not targeting F8 any longer but F9, so every
> > unstable change that had to be postponed to stabilize F8 is
> > hitting it right now. The start of a cycle is its lowest
> > stability point.
>
> Actually no, no .fc9 builds have hit Rawhide yet. But you're
> right to warn about this. Rawhide is probably going to switch to
> tracking F9 at some point BEFORE the F8 release (at least that's
> how it was for the previous releases), so if you intend to move
> to the stable version, you have to watch carefully for when to
> stop pulling from Rawhide or you'll end up with a mess of F9
> packages which is essentially impossible to untangle.
>
>         Kevin Kofler

   ??  Yesterday's (23) updates included,
fedora-release-notes-8.0.0-1
fedora-release-8-2       and it was noted in 'rawhide report'  that 
this update would disable -development an enable -updates. Which it 
did.    $ cat /etc/fedora-release  Fedora release 8 (Werewolf)

   So I disabled fedora.repo an -updates, an reenabled -development.  
This mornin (24) I was able to update about 30 packages.  So are 
these fc8's going to be in F8 next week, or the beginning of F9  ?
-- 
    Tom Brinkman                       Corpus Christi, Texas



From bernie at codewiz.org  Wed Oct 24 18:32:59 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Wed, 24 Oct 2007 14:32:59 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <20071024170913.GC12628@devserv.devel.redhat.com>
References: <471C94BD.6080801@codewiz.org>
	<ffja8k$dj7$1@ger.gmane.org>	<200710230846.25736.sgrubb@redhat.com>	<471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org>	<1193148798.8542.285.camel@cutter>	<20071023101828.28ab1670@redhat.com>	<1193149404.6746.5.camel@vespa.kabelta.loc>	<20071023103410.46acd566@redhat.com>
	<471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
Message-ID: <471F8FDB.8070405@codewiz.org>

On 10/24/07 13:09, Alan Cox wrote:
> On Wed, Oct 24, 2007 at 12:14:04PM -0400, Bernardo Innocenti wrote:
>> Please, let's not add an external dependency for something
>> as trivial as a SHA1.
> 
> The positives to adding an external dependancy are you only have
> to worry about bugs in one implementation.

That's right, in general.

But in this specific case, we're talking about adding a bulky
library and all of its dependencies to Python just to save 25
lines of duplicated code.

By doing so too carelessly, we easily create runtime or
build-time dependency loops that are hard to solve.

Surely, there must be a better way, such as creating
simpler libraries containing basic crypto algorithms.

>>> We need a strong hash function as this replaces the previous weak hash +
>>> memcmp when checking incoming glyphs for matches with the existing set
>>> of server-resident glyphs. One could argue that this must be
>>> cryptographically secure to avoid applications uploading misleading
>>> glyph images.
> 
> Which presumably means they'll not be using SHA1 much longer - right ?

Uh?  I wasn't aware SHA1 has been broken (at least, not in
a practically exploitable way).

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From jkeating at redhat.com  Wed Oct 24 18:37:05 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 14:37:05 -0400
Subject: Current problems with Rawhide
In-Reply-To: <200710241230.51596.tbrinkman@sbcglobal.net>
References: <14464.192.54.193.51.1193240255.squirrel@rousalka.dyndns.org>
	<loom.20071024T154300-923@post.gmane.org>
	<200710241230.51596.tbrinkman@sbcglobal.net>
Message-ID: <20071024143705.1911e889@redhat.com>

On Wed, 24 Oct 2007 12:30:51 -0500
Tom Brinkman <tbrinkman at sbcglobal.net> wrote:

>    So I disabled fedora.repo an -updates, an reenabled -development.  
> This mornin (24) I was able to update about 30 packages.  So are 
> these fc8's going to be in F8 next week, or the beginning of F9 

F8.  Rawhide is still F8 content, I was just trying to get the final
fedora-release out there early.  Just hit a small snag with signed
copies of packages.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/cadeeafc/attachment.sig>

From lemenkov at gmail.com  Wed Oct 24 18:45:39 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 24 Oct 2007 22:45:39 +0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <604aa7910710241126u7a2d27b3ocb525eb1ee4024df@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<604aa7910710241126u7a2d27b3ocb525eb1ee4024df@mail.gmail.com>
Message-ID: <adf480660710241145x352cdd98nc135f6f7f3d09e8f@mail.gmail.com>

2007/10/24, Jeff Spaleta <jspaleta at gmail.com>:

> If you can give me proof that signaturesounds 'tortures' people. I'll
> stop buying the cds from that label.

"Kill them all. God will know his own."

I personally stopped buying CDs completely 5-7 years ago. Actually
there is no way to play these funny pieces of plastic in my home :).
Downloading music is better, easy and handy. Also its more easy to
share with friends by sending them torrent-link or opening ftp-access.

I wonder why torrent- and ftp-software still not prohibited by US laws :)

-- 
With best regards!



From galibert at pobox.com  Wed Oct 24 18:49:28 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 24 Oct 2007 20:49:28 +0200
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <1193249971.9044.2.camel@localhost.localdomain>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<20071024170438.GA12628@devserv.devel.redhat.com>
	<1193247053.10653.3.camel@localhost.localdomain>
	<1193249971.9044.2.camel@localhost.localdomain>
Message-ID: <20071024184928.GA24537@dspnet.fr.eu.org>

On Wed, Oct 24, 2007 at 02:19:31PM -0400, Robert Marcano wrote:
> Just to expand a little this discussion, NOT everyone lives in USA or UK
> or another country with a good online store. And by the way I love to
> have something physical I can sell if I want too

Funny, I haven't listened to an audio CD directly on a computer in
years, while I did buy a bunch of CDs in the interval.

The original "people still do that?" remark was about CD playback, not
about archival/trade media, as Alan Cox seems to have been the only
one to notice.  Reading speed is not an issue for CD dumping, since
the paranoia stuff/dumping application manages it.

  OG.



From bpepple at fedoraproject.org  Wed Oct 24 18:49:39 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 24 Oct 2007 14:49:39 -0400
Subject: Plan for tomorrows (20071025) FESCO meeting
Message-ID: <1193251779.7673.1.camel@kennedy>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic FESCo meeting -- Free discussion around Fedora

There's nothing on the schedule for tomorrow so if you want something
to be discussed, send a note to the list in reply to this mail and I'll
add it to the schedule.  You can also propose topics in the meeting
while it is in the "Free discussion around Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071024/a3da99bd/attachment.sig>

From ville.skytta at iki.fi  Wed Oct 24 19:04:08 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 24 Oct 2007 22:04:08 +0300
Subject: Heads-up: lm_sensors will go to 3.0.0 for F-9,
	all users will need patching for new API
In-Reply-To: <471F58F6.6070808@hhs.nl>
References: <471F58F6.6070808@hhs.nl>
Message-ID: <200710242204.08734.ville.skytta@iki.fi>

On Wednesday 24 October 2007, Hans de Goede wrote:
>
> Here is the list of packages that uses lm_sensors on my system:
> gkrellm *
> ksensors **
> gnome-sensors-applet **
> kdebase
> net-snmp
> net-snmp-libs

repoquery additionally reveals:

nagios-plugins
xfce4-sensors-plugin



From a.badger at gmail.com  Wed Oct 24 19:15:02 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 24 Oct 2007 12:15:02 -0700
Subject: Mass Branching for F-8 (round 2)
In-Reply-To: <20071024175109.GA20802@agk.fab.redhat.com>
References: <20071019231326.607bf89d@redhat.com>	<20071020095212.402c5849@redhat.com>	<20071020220439.5fa885a1@redhat.com>
	<20071024175109.GA20802@agk.fab.redhat.com>
Message-ID: <471F99B6.3000004@gmail.com>

Alasdair G Kergon wrote:
> On Sat, Oct 20, 2007 at 10:04:39PM -0400, Jesse Keating wrote:
>> The branching is done.  CVS commits have been re-enabled.  If your
>> package is missing an F-8 branch please mail rel-eng at fedoraproject.org
>> and we'll look into it.
> 
> Well the pkgdb part of this seems to have gone wrong for *all* the
> lvm-team-owned projects, unfortunately.
> 
> Specifically, the Fedora 7 permissions were not copied across to the
> new Fedora 8 correctly:
>
Yep.  This is because when the ownership data was imported there were 
people who still hadn't signed up for cvsextras like they were supposed 
to.  Since then, I've plugged holes in the pkgdb checks that keep people 
who haven't signed up for cvsextras from getting acls where they aren't 
supposed to which led to some packages having errors in this round of 
mass branching.  My apologies, I should have stripped those people out 
of the data on initial import instead of assuming they were just being 
slow to finish the merge process.

To fix your particular problem, you need to decide what to do about the 
following lvm team members:

mauelsha Heinz Mauelshagen -- !!Very important!! Needs to have cla_done 
and cvsextras before he can be allowed to commit.

These people only need cvsextras
sct Stephen Tweedie
dwysocha Dave Wysochanski

Once you get these people sign up for the right accounts I can rebranch 
lvm2, device-mapper, device-mapper-multipath, and dmraid in the pkgdb 
and the acls will duplicate what's in devel.

Alternately, you can have me remove those people from the acls for these 
packages and I can then rebranch the permissions at that point.

-Toshio



From robert at marcanoonline.com  Wed Oct 24 19:18:37 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Wed, 24 Oct 2007 15:18:37 -0400
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <20071024184928.GA24537@dspnet.fr.eu.org>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<20071024170438.GA12628@devserv.devel.redhat.com>
	<1193247053.10653.3.camel@localhost.localdomain>
	<1193249971.9044.2.camel@localhost.localdomain>
	<20071024184928.GA24537@dspnet.fr.eu.org>
Message-ID: <1193253517.9044.13.camel@localhost.localdomain>

On Wed, 2007-10-24 at 20:49 +0200, Olivier Galibert wrote:
> On Wed, Oct 24, 2007 at 02:19:31PM -0400, Robert Marcano wrote:
> > Just to expand a little this discussion, NOT everyone lives in USA or UK
> > or another country with a good online store. And by the way I love to
> > have something physical I can sell if I want too
> 
> Funny, I haven't listened to an audio CD directly on a computer in
> years, while I did buy a bunch of CDs in the interval.
> 
> The original "people still do that?" remark was about CD playback, not
> about archival/trade media, as Alan Cox seems to have been the only
> one to notice.  Reading speed is not an issue for CD dumping, since
> the paranoia stuff/dumping application manages it.

Well I got the idea, but I was replying to the person trying to change
the preferred way to buy/listen music of people, with a little limited
view of what other people options are, legal options, for some of us
downloading music from P2P networks is not one of those like Peter try
to recommend me on a later reply

> 
>   OG.
> 



From jcm at redhat.com  Wed Oct 24 19:42:10 2007
From: jcm at redhat.com (Jon Masters)
Date: Wed, 24 Oct 2007 15:42:10 -0400
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
Message-ID: <1193254930.3393.19.camel@perihelion>


On Wed, 2007-10-24 at 11:48 -0400, Kelly Miller wrote:
> On 10/24/07, Bastien Nocera <bnocera at redhat.com> wrote:
>         
>         Works fine here. File bugs!
> 
> 
> I'm not getting any feedback from the system on it.  It just dies, so
> I'm not sure where to look for logs related to it.  I can't even get
> it to happen consistently; sometimes it'll run fine for half an hour
> and then suddenly die, and sometimes it'll die two seconds in.  I know
> it's being shut down because of the 50%+ system check, but I'm not
> sure why it keeps running like that... 

Yesterday, I had pulseaudio and my dbus system bus die at the same time
- then this morning, the box locked hard playing audio[0]. Lovely ;-)

Jon.

[0] Admittedly, I didn't have it logging remotely so I'm not certain
what caused that kernel panic yet.



From dcbw at redhat.com  Wed Oct 24 19:41:52 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 24 Oct 2007 15:41:52 -0400
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710240858h78eb7147xddbb8963ef1ca226@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<471F63D2.1090300@redhat.com>
	<a785db460710240858h78eb7147xddbb8963ef1ca226@mail.gmail.com>
Message-ID: <1193254912.22161.2.camel@localhost.localdomain>

On Wed, 2007-10-24 at 11:58 -0400, Kelly Miller wrote:
> 
>         We're "fixing" this by making the knetworkmanager package load
>         up the
>         GNOME applet for F8 final.  When the K version is fixed, we'll
>         remove
>         the hack and the GNOME dependencies in an F8 update.
> 
> Yeah, I didn't think anyone would miss that problem.  I still don't
> entirely understand why NetworkManager itself (nm-applet) is screwing
> up my IP, though. 
> 
> I set it to give me a standard IP of 192.168.2.4 on my network all the
> time, because my computer acts as an LDAP/NFS server for the rest of
> the computers on the network.  However, when I activate
> NetworkManager, my IP becomes 192.168.2.5.  When I turn it off and use
> the old networking system, I get the IP I asked for.

How are you telling NM to do this?

Dan




From jspaleta at gmail.com  Wed Oct 24 19:56:50 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 11:56:50 -0800
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193245059.19243.14.camel@localhost6.localdomain6>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
Message-ID: <604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>

On 10/24/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> I guess I should have added that the reason the update broke yelp and
> devhelp is that they both require a specific version of the virtual
> provides gecko-libs which firefox-2.0.0.8 updates.

These are well understood problems with how firefox is packaged. These
problems are
some of the reasons why we wanted to get xulrunner packaged so that
the libraries that are being asked for can be packaged seperately from
the firefox application in a reasonable way.  This is further
complicated by the fact that pretty much every firefox update is a
security update and as a result is not going to see staging in
updates-testing.

You are absolutely NOT going to see security updates postponed for
deps to catch up.

Until we are able to get xulrunner in place, any package which
> The questions still
> apply, though.

I believe that we do in fact have dependancy chain breakage scripts
running and those scripts do email maintainers which depchains break.
But again because this is a security update I'm not sure those scripts
will fire in a reasonable time to prevent seeing end-user breakage.

We've been fighting the firefox dependancy chain problem for a long
while now, and its not going to get any better until we get xulrunner
in distro. As a user of packages which dep on firefox or gecko-libs,
you best course of action is to be as proactive as possible at filing
and re-opening bugreports to make sure the maintainers who need to
rebuild packages..do so as quickly as possible after a firefox
security update.

And on a side-note applications sure as hell have a good reason to dep
on firefox over gecko-libs.  Anything that's using the libraries needs
to be depping on gecko-libs so when the xulrunner conversion happens
they are prepared for it.

-jef



From louisg00 at bellsouth.net  Wed Oct 24 20:03:19 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Wed, 24 Oct 2007 16:03:19 -0400
Subject: NetworkManager-0.7.0-0.3.svn3016.fc8 selinux problem
Message-ID: <1193256199.5029.3.camel@tiger>

NetworkManager can't connect to wireless and quits because:

SELinux is preventing NetworkManager (NetworkManager_t) "execute" to
(nscd_exec_t).



From valent.turkovic at gmail.com  Wed Oct 24 20:06:10 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 24 Oct 2007 22:06:10 +0200
Subject: Fluendo codecs in Fedora 8?
Message-ID: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>

I followed instructions for installing fluendo mega codec pack and
copied all files to
/usr/lib/gstreamer-0.10/ under Fedora 8 test 3 (with latest updates)
but whenever I try to open different video files I still get message
from Totem that I need to go to fluendo site and get codecs...

I then copied files also to ~/.gstreamer-0.10/plugins directory but
that doesn't help either...

Any ideas? Should I file a bug? Am I doing something wrong?

Thank you in advance.

Valent.
-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Wed Oct 24 20:07:24 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 24 Oct 2007 22:07:24 +0200
Subject: how to enable forbidden multimedia in Rawhide?
In-Reply-To: <1193179321.25405.107.camel@cookie.hadess.net>
References: <64b14b300710231343w44d9c945r7ece8e4df8119d52@mail.gmail.com>
	<1193179321.25405.107.camel@cookie.hadess.net>
Message-ID: <64b14b300710241307t11e50fd9kd04978be5bb5c70e@mail.gmail.com>

Thank you all for your replies.

On 10/24/07, Bastien Nocera <bnocera at redhat.com> wrote:
>
> On Tue, 2007-10-23 at 22:43 +0200, Valent Turkovic wrote:
> > Is there a drop-in way of enabling multimedia in fedora 8 devel
> > version (rawhide)?
>
> http://www.gnome.org/projects/totem/
>
> Follow the links. Livna does a devel branch as well, which is what I use
> for testing.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From lightsolphoenix at gmail.com  Wed Oct 24 20:27:55 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 24 Oct 2007 16:27:55 -0400
Subject: Current problems with Rawhide
In-Reply-To: <1193254912.22161.2.camel@localhost.localdomain>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<471F63D2.1090300@redhat.com>	<a785db460710240858h78eb7147xddbb8963ef1ca226@mail.gmail.com>
	<1193254912.22161.2.camel@localhost.localdomain>
Message-ID: <471FAACB.5030708@gmail.com>

Dan Williams wrote:
>
> How are you telling NM to do this?
>
> Dan
>   
system-control-network.  It's always worked with NetworkManager before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/28028436/attachment.htm>

From valent.turkovic at gmail.com  Wed Oct 24 20:35:33 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 24 Oct 2007 22:35:33 +0200
Subject: any plans to make wireless more user-friendly in Fedora 9?
In-Reply-To: <1193236958.2557.24.camel@localhost.localdomain>
References: <52651.192.54.193.51.1193046493.squirrel@rousalka.dyndns.org>
	<64b14b300710231330h22dfe0a8i45bde6b86bce2308@mail.gmail.com>
	<1193172590.5002.57.camel@rousalka.dyndns.org>
	<20071023165441.4c996843@redhat.com>
	<1193174612.7110.11.camel@localhost.localdomain>
	<20071023223222.GA26820@asus.config>
	<1193236958.2557.24.camel@localhost.localdomain>
Message-ID: <64b14b300710241335y7c3c9f55l36a7fd989670e8e4@mail.gmail.com>

Whoow this was an insightful thread into Fedora networking... thank you all.

Valent.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jkeating at redhat.com  Wed Oct 24 20:41:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 16:41:11 -0400
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
Message-ID: <20071024164111.6fee94f6@redhat.com>

On Wed, 24 Oct 2007 22:06:10 +0200
"Valent Turkovic" <valent.turkovic at gmail.com> wrote:

> Any ideas? Should I file a bug? Am I doing something wrong?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/7ba6af32/attachment.sig>

From jkeating at redhat.com  Wed Oct 24 20:41:36 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 16:41:36 -0400
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
Message-ID: <20071024164136.50130513@redhat.com>

On Wed, 24 Oct 2007 22:06:10 +0200
"Valent Turkovic" <valent.turkovic at gmail.com> wrote:

> Any ideas? Should I file a bug? Am I doing something wrong?

I would suggest you contact your vendor (Fluendo) for support on the
proprietary software you've installed from them.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/c2ddcd75/attachment.sig>

From valent.turkovic at gmail.com  Wed Oct 24 20:57:20 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 24 Oct 2007 22:57:20 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <20071024164136.50130513@redhat.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<20071024164136.50130513@redhat.com>
Message-ID: <64b14b300710241357k3d0b6adbje8b6c269cd8331df@mail.gmail.com>

On 10/24/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 24 Oct 2007 22:06:10 +0200
> "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
>
> > Any ideas? Should I file a bug? Am I doing something wrong?
>
> I would suggest you contact your vendor (Fluendo) for support on the
> proprietary software you've installed from them.
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?

Sure, of course I will but I need to know it the OSS bits or
proprietary bits are "broken". I can equally assume that totem it to
blame or CodecBuddy or some other OSS and also proprietary fluendo
part...

That was the intention of my question.

I posted them a inquiery but I want to see if somebody already knows
what might be the issue and with which component in the chain is the
issue.

Thank you,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From myfedora at richip.dhs.org  Wed Oct 24 21:05:52 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 24 Oct 2007 15:05:52 -0600
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
Message-ID: <1193259952.23316.12.camel@localhost6.localdomain6>

On Wed, 2007-10-24 at 11:56 -0800, Jeff Spaleta wrote:
> On 10/24/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> > I guess I should have added that the reason the update broke yelp and
> > devhelp is that they both require a specific version of the virtual
> > provides gecko-libs which firefox-2.0.0.8 updates.
> 
> These are well understood problems with how firefox is packaged. These
> problems are
> some of the reasons why we wanted to get xulrunner packaged so that
> the libraries that are being asked for can be packaged seperately from
> the firefox application in a reasonable way.  This is further
> complicated by the fact that pretty much every firefox update is a
> security update and as a result is not going to see staging in
> updates-testing.
> 
> You are absolutely NOT going to see security updates postponed for
> deps to catch up.

I can understand and agree that certain updates (Security, mostly)
should not be delayed. But 1) how does one do a "yum update" in such a
case? and 2) How about a delay system for non-essential updates which
break dependencies?

The first question is the more important one. If a normal "yum update"
won't apply the security update because of dependency issues and the
user isn't made readily aware of how to apply the patch anyway given
that there are dependency issues, then forcing the patch out only serves
a percentage of the population (those who know how to somehow do a
"--nodeps" check). If security updates are going to be released without
consideration for breakage, doesn't it stand to reason that yum should
apply them, breakage notwithstanding?

As for the second issue (delaying non-essential updates which break), if
we look at the most common use-case, we have the ff. actors: the package
maintainer for the package that breaks (A), the package maintainer/s for
the package that depend on the breaking one (B), and the users who do
"yum update"s (C). It's my contention that (A)'s update should be
delayed pending the resolution of (B)'s packages or a certain amount of
time has passed. I won't even begin to argue who is responsible for
coordinating with who ((A) or (B)). I just believe that (C) shouldn't
have to be involved.

And yes, I can't wait till xulrunner is its own separate package.
--

Richi Plana



From jspaleta at gmail.com  Wed Oct 24 21:08:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 13:08:58 -0800
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193259952.23316.12.camel@localhost6.localdomain6>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
Message-ID: <604aa7910710241408m5f1e2b50saaa296cd865ae0bb@mail.gmail.com>

On 10/24/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> As for the second issue (delaying non-essential updates which break), if
> we look at the most common use-case, we have the ff. actors: the package
> maintainer for the package that breaks (A), the package maintainer/s for
> the package that depend on the breaking one (B), and the users who do
> "yum update"s (C). It's my contention that (A)'s update should be
> delayed pending the resolution of (B)'s packages or a certain amount of
> time has passed. I won't even begin to argue who is responsible for
> coordinating with who ((A) or (B)). I just believe that (C) shouldn't
> have to be involved.
>
> And yes, I can't wait till xulrunner is its own separate package.
> --
>
> Richi Plana
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jkeating at redhat.com  Wed Oct 24 21:09:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 17:09:53 -0400
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710241357k3d0b6adbje8b6c269cd8331df@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<20071024164136.50130513@redhat.com>
	<64b14b300710241357k3d0b6adbje8b6c269cd8331df@mail.gmail.com>
Message-ID: <20071024170953.5b58b525@redhat.com>

On Wed, 24 Oct 2007 22:57:20 +0200
"Valent Turkovic" <valent.turkovic at gmail.com> wrote:

> Sure, of course I will but I need to know it the OSS bits or
> proprietary bits are "broken". I can equally assume that totem it to
> blame or CodecBuddy or some other OSS and also proprietary fluendo
> part...
> 
> That was the intention of my question.
> 
> I posted them a inquiery but I want to see if somebody already knows
> what might be the issue and with which component in the chain is the
> issue.

If you followed your vendor's instructions and it's not working,
you need to follow that up with your vendor.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/0e8e0701/attachment.sig>

From wwoods at redhat.com  Wed Oct 24 21:19:00 2007
From: wwoods at redhat.com (Will Woods)
Date: Wed, 24 Oct 2007 17:19:00 -0400
Subject: F8 blocker bug status report - testers needed!
Message-ID: <1193260740.9430.35.camel@metroid.rdu.redhat.com>

Hi folks,

The QA team went through the F8Blocker bug list today. The good news is
that a lot of the things that would have blocked the release are fixed -
we're down under 20 blocker bugs (not including trackers). 

The current blocker list can be found here: 
https://bugzilla.redhat.com/showdependencytree.cgi?id=235703&hide_resolved=1

We need help testing and evaluating some of these bugs - some of them
only affect certain hardware or less-common software configurations. We
need to know how widespread the problems are in order to decide whether
a given problem is actually worth delaying the release to fix.

Please look through this list and see if there's anything you could help
to test. 

In order by bug ID, here's a look at our current blocker bugs, with
commentary:

* Bug 208607: ASSIGNED - kernel-maint at redhat.com
- mkinitrd: iSCSI root requires crc32c module

iSCSI is a tricky beast. This didn't work right in F7 either, so it's
not a new problem, just something we were planning to have fixed
properly for F8. Instead we will probably end up building crc32c into
the kernel so that iSCSI-root works properly.

If you've got iSCSI hardware, it would be excellent if you could help us
test installation (after we get this change in..). Adding yourself to
the CC list for the bug would be a great idea.


* Bug 242536: ASSIGNED - alan at redhat.com
- [pata_via] Anaconda failed after formatting the / partition
* Bug 242766: ASSIGNED - alan at redhat.com
- [pata_via via82c596a] hard drive not found during install attempt

If anyone has pata_via hardware, please speak up! We need to know how
much impact these bugs will have, testing help, etc.


* Bug 253892: ASSIGNED - vcrhonek at redhat.com
- There is no usable romanian keymap for the linux console

An earlier fix didn't work. It's unclear whether this actually prevents
Romanian users from using their systems (which would make it a blocker)
but the fix should be simple, so it stays for now.


* Bug 264901: NEW - notting at redhat.com
- oops, we have multiple sources of persistent network names active at
the same time

notting says that this is (more or less) fixed for things in the default
install. We're trying to work out ways to test it. This may get dropped
from the blocker list and fully fixed in F9-rawhide.

* Bug 311511: NEEDINFO - dcbw at redhat.com
- x86_64 iwl3945 NM crash after Keyring loop Deny

A fix for this has been committed, we're waiting for the reporter to
confirm. If you can confirm this fix, that would help.


* Bug 323371: ASSIGNED - dcbw at redhat.com
- NM 0.7 doesn't support WPA/WPA2 Enterprise (certificate-based
authentication)

This is also fixed, in theory, but the original reporter is having
problems beyond WPA/WPA2 Enterprise. If you can confirm WPA or WPA2
Enterprise is working with current NetworkManager 
(NetworkManager-0.7.0-0.3.svn3016.fc8, in koji or tomorrow's rawhide)
please comment on the bug.


* Bug 330931: NEEDINFO - katzj at redhat.com
- liveinst fails - sg devices confuse anaconda?

This involves some interesting hardware - Dell PowerEdge 2650 - so if
you have some of this hardware and can help test / debug, please grab a
copy of the LiveCD and give it a shot.


* Bug 335161: MODIFIED - triad at df.lth.se
- multilib file conflicts in gnokii

A fix for this has been committed and should show up in rawhide
tomorrow. 


* Bug 338551: NEW - davej at redhat.com
- kernel 2.6.23.1-23.fc8 does not boot anymore on SK8V

Again, this is a bug with specific hardware - if you have an SK8V
motherboard, we could use testing help. 


* Bug 345841: MODIFIED - dwalsh at redhat.com
- SELinux denial from cron

This should be fixed in today's rawhide, hopefully the reporter will
retest and close the bug (COUGH COUGH JESSE COUGH SLACKER COUGH)


* Bug 346471: NEW - lvm-team at redhat.com
- F8T3 Live CD detects LVM groups inside RAID1, without using RAID1

This one is kind of nasty - LVM startup problems on the LiveCD can cause
it to mess around with one mirror of a RAID1 set, which could lead to
desynched mirrors and other badness. It's being investigated.

* Bug 348931: MODIFIED - ehabkost at redhat.com
- virt-install --nographics --paravirt is broken

There's a fix for this in the kernel-xen-2.6 package in today's rawhide.
If you're a xen user, testing and commenting on this bug would be much
appreciated.

A few more bugs have been added since the QA meeting - I'll comment
about them in a status report later this week.

Thanks for any help, and keep on testin', rawhiders!

-w
-------------- 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/20071024/9b250a11/attachment.sig>

From jspaleta at gmail.com  Wed Oct 24 21:25:34 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 13:25:34 -0800
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193259952.23316.12.camel@localhost6.localdomain6>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
Message-ID: <604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>

On 10/24/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> As for the second issue (delaying non-essential updates which break), if
> we look at the most common use-case, we have the ff. actors: the package
> maintainer for the package that breaks (A), the package maintainer/s for
> the package that depend on the breaking one (B), and the users who do
> "yum update"s (C). It's my contention that (A)'s update should be
> delayed pending the resolution of (B)'s packages or a certain amount of
> time has passed. I won't even begin to argue who is responsible for
> coordinating with who ((A) or (B)). I just believe that (C) shouldn't
> have to be involved.

Point of fact... is there anything which depends on firefox that is
currently experience a depchain problem that is considered a mandatory
application?
Crap like yelp and devhelp and Miro are fundamentally optional
components. And you absolutely are not going to be able to make a
strong enough argument that firefox security updates should be delay
one milliseconds to keep optional packages from breaking. It just isnt
going to fly.  People who do not have these optional components
installed will suffer lapses in security unnecessarily.

Yes it absolutely sucks for the user who has these optional components
installed. Because that user is now required to make a choice.  You
can choose to uninstall the packages which have a dep problem or you
can choose to ignore that update because it causes dep problems.
Something like the yum-skip-broken  plugin package helps users make a
choice, by choosing to not install the update because of the dep
problems.  I'm not aware of a similar yum plugin which forces the
install of security updates, but perhaps such a plugin should exist to
round out the policy choices for end-users.

There's no getting around it. The fact that these application have
choosen to require libraries from firefox, when said libraries are
known to be unstable and non-conformant to established generally
accepted soname rules is the fundamental problem.  Until xulrunner
finds its way in, its absolutely up to the maintainers of packages
which depend on firefox to  know exactly the sort of problems thier
packages cause on every single firefox update since the dawn of time.
Honestly if I could do it I would forbid any package from depping
against firefox until xulrunner lands in Fedora to avoid this entirely
than to continue to work under the farce that the gecko libraries that
applications are depending are appropriate to rely on as a development
framework.

-jef"lost count of the number of times he's re-opened bugs about ff
deps since fc1 was released"spaleta



From j.w.r.degoede at hhs.nl  Wed Oct 24 21:27:13 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 24 Oct 2007 23:27:13 +0200
Subject: F8 blocker bug status report - testers needed!
In-Reply-To: <1193260740.9430.35.camel@metroid.rdu.redhat.com>
References: <1193260740.9430.35.camel@metroid.rdu.redhat.com>
Message-ID: <471FB8B1.1070101@hhs.nl>

Will Woods wrote:
> Hi folks,
> 
> The QA team went through the F8Blocker bug list today. The good news is
> that a lot of the things that would have blocked the release are fixed -
> we're down under 20 blocker bugs (not including trackers). 
> 
> The current blocker list can be found here: 
> https://bugzilla.redhat.com/showdependencytree.cgi?id=235703&hide_resolved=1
> 
> We need help testing and evaluating some of these bugs - some of them
> only affect certain hardware or less-common software configurations. We
> need to know how widespread the problems are in order to decide whether
> a given problem is actually worth delaying the release to fix.
> 
> Please look through this list and see if there's anything you could help
> to test. 
> 
> In order by bug ID, here's a look at our current blocker bugs, with
> commentary:
> 

<snip>

Very useful report, thanks Will! Unfortunately no issues there I can help with.

Regards,

Hans



From bloch at verdurin.com  Wed Oct 24 22:05:00 2007
From: bloch at verdurin.com (Adam Huffman)
Date: Wed, 24 Oct 2007 23:05:00 +0100
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
Message-ID: <20071024220500.GD2698@asus.config>

On Wed, 24 Oct 2007, Jeff Spaleta wrote:

> Yes it absolutely sucks for the user who has these optional components
> installed. Because that user is now required to make a choice.  You
> can choose to uninstall the packages which have a dep problem or you
> can choose to ignore that update because it causes dep problems.
> Something like the yum-skip-broken  plugin package helps users make a
> choice, by choosing to not install the update because of the dep
> problems.  I'm not aware of a similar yum plugin which forces the
> install of security updates, but perhaps such a plugin should exist to
> round out the policy choices for end-users.
> 

I tried the skip-broken plugin to resolve this problem but it failed to,
um, skip the broken packages.  Can't find it as a component in bugzilla.



From ngompa13 at gmail.com  Wed Oct 24 22:06:52 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Wed, 24 Oct 2007 17:06:52 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <20071024005354.2f2cc521@lain.camperquake.de>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
Message-ID: <8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>

Isn't that basically what all binaries do? Use libraries and execute the
code natively on the CPU?

On 10/23/07, Ralf Ertzinger <fedora at camperquake.de> wrote:
>
> Hi.
>
> On Tue, 23 Oct 2007 15:25:26 +0400, Peter Lemenkov wrote
>
> > We need to distinguish between *real* code which natively executes on
> > CPU and any other binary content which not executes natively. Win32
> > executables, ROMs, JARs are IMHO definitely falls into this category
> > (content). As pictures, music and text-files they do not runs on CPU
> > directly.
>
> Win32 binaries (when run on x86, unless you found an old Alpha binary
> somewhere) _do_ run natively on the host CPU. Wine does not emulate the
> CPU, it 'just' provides the execution environment (libraries, kernel
> calls)
> a Windows binary expects. Program code that is not spent in libraries or
> in the kernel is executed natively on the CPU.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/4b36a0b9/attachment.htm>

From david at lovesunix.net  Wed Oct 24 22:17:25 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 25 Oct 2007 00:17:25 +0200
Subject: F8 blocker bug status report - testers needed!
In-Reply-To: <1193260740.9430.35.camel@metroid.rdu.redhat.com>
References: <1193260740.9430.35.camel@metroid.rdu.redhat.com>
Message-ID: <1193264245.3639.9.camel@dawkins>


ons, 24 10 2007 kl. 17:19 -0400, skrev Will Woods:

> * Bug 311511: NEEDINFO - dcbw at redhat.com
> - x86_64 iwl3945 NM crash after Keyring loop Deny
> 
> A fix for this has been committed, we're waiting for the reporter to
> confirm. If you can confirm this fix, that would help.

I'll give that one a bit of abuse tomorrow, also sorry about sleeping
through the meeting, I swear I had a legimate excuse, I spend all night
closing old bugs.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/e3fc87de/attachment.sig>

From bnocera at redhat.com  Wed Oct 24 22:20:29 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 24 Oct 2007 23:20:29 +0100
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
Message-ID: <1193264429.25405.134.camel@cookie.hadess.net>


On Wed, 2007-10-24 at 22:06 +0200, Valent Turkovic wrote:
> I followed instructions for installing fluendo mega codec pack and
> copied all files to
> /usr/lib/gstreamer-0.10/ under Fedora 8 test 3 (with latest updates)
> but whenever I try to open different video files I still get message
> from Totem that I need to go to fluendo site and get codecs...

1) Check that the video you're trying to play is supposed to be playing
(ie. which video and audio codecs does it complain about when you exit
Codeina?)

2) Check that the plugins are correctly installed ("gst-inspect-0.10 |
grep flu" will list the Fluendo plugins.

3) File bugs with Fluendo if they're supposed to be playing and aren't:
https://core.fluendo.com/gstreamer/trac

Cheers



From myfedora at richip.dhs.org  Wed Oct 24 22:23:58 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 24 Oct 2007 16:23:58 -0600
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
Message-ID: <1193264638.23316.40.camel@localhost6.localdomain6>

On Wed, 2007-10-24 at 13:25 -0800, Jeff Spaleta wrote:
> Point of fact... is there anything which depends on firefox that is
> currently experience a depchain problem that is considered a mandatory
> application?
> Crap like yelp and devhelp and Miro are fundamentally optional
> components. And you absolutely are not going to be able to make a
> strong enough argument that firefox security updates should be delay
> one milliseconds to keep optional packages from breaking. It just isnt
> going to fly.  People who do not have these optional components
> installed will suffer lapses in security unnecessarily.

Well, whether yelp and devhelp are "crap" is debatable (I'm a software
developer as well as a user and I've yet to find use for either. Don't
get me wrong, though. I agree that security updates SHOULD NOT be
delayed. But if they can't be applied, then they're effectively delayed.
I'm just saying that for certain updates, the user should be given the
choice to either force the update and allow it to break the dependency
or do an automatic dependency resolution by REMOVING packages (as
opposed to adding). I know it's complicated, but if it's worth it, then
at least it can go on the table.

I've gone ahead and removed "yelp" and "devhelp", but removing dependent
packages isn't always a choice.

> Something like the yum-skip-broken  plugin package helps users make a
> choice, by choosing to not install the update because of the dep
> problems.  I'm not aware of a similar yum plugin which forces the
> install of security updates, but perhaps such a plugin should exist to
> round out the policy choices for end-users.

yum-skip-broken was the answer to my first question earlier, but it's
not obvious to everyone. If there really is a move to make Fedora
user-friendly (and even as a seasoned admin, I have to say "Anything to
make things easier would be appreciated"), then security updates like
this should be made easier to work with.

But again, even though this example may or may not be the result of a
bad choice of app developers in choosing what they depend on, it won't
always be the case.
--

Richi Plana



From mjs at CLEMSON.EDU  Wed Oct 24 22:49:01 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Wed, 24 Oct 2007 18:49:01 -0400
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <1193241126.5103.50.camel@vincent52.localdomain>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
Message-ID: <1193266141.5354.10.camel@valkyrie.localdomain>


On Wed, 2007-10-24 at 11:52 -0400, Matthew Saltzman wrote:
> On Wed, 2007-10-24 at 06:59 -0400, Build System wrote:
> > 
> > 
> > Updated Packages:
> > ...
> 
> When I try to update, yum reports that all of these are unsigned!

Seriously, suddenly I can't apply updates, because yum reports all RPMs
are unsigned.

I had installed livna-release for F7 as suggested by somebody else to
get Livna updates.  When I tried "rpm -qi gpg-pubkey", only Livna and
Adobe (Flash) keys were listed.  I ran "rpm --import" on all the keys
in /etc/pki/gpg-keys/ and I even re-installed fedora-release-8-2, but I
still can't install today's updates.

I guess I can run yum with --nogpgcheck, but surely that shouldn't be
necessary--it hasn't been in the past.

Help!

$ rpm -q gpg-pubkey
gpg-pubkey-f6777c67-45e5b1b9.(none)
gpg-pubkey-a109b1ec-3f6e28d5.(none)
gpg-pubkey-db42a60e-37ea5438.(none)
gpg-pubkey-4f2a6fd2-3f9d9d3b.(none)
gpg-pubkey-e418e3aa-3f439953.(none)
gpg-pubkey-1cddbca9-3f9da14c.(none)
gpg-pubkey-897da07a-3c979a7f.(none)
gpg-pubkey-30c9ecf8-3f9da3f7.(none)


TIA.

-- 
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://math.clemson.edu/~mjs



From bruno at wolff.to  Wed Oct 24 22:50:08 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 24 Oct 2007 17:50:08 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <645d17210710240545u7047fcb1n807f1c5c97576fd7@mail.gmail.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20071023083834.GA4704@wolff.to>
	<645d17210710240545u7047fcb1n807f1c5c97576fd7@mail.gmail.com>
Message-ID: <20071024225008.GA29385@wolff.to>

On Wed, Oct 24, 2007 at 13:45:26 +0100,
  Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> 
> As mentioned in the thread back in 2005, the first step would be
> submitting etcnet to for inclusion as a Fedora package. That can
> happen independently of whether or not discussions of replacing
> network-scripts happens, and what the outcome of them are.
> 
> FWIW, I'd quite like to see etcnet in the repo as an alternative, so
> if you want some help packaging it, drop me a line. That said, the
> thing that is very unappealing to me about its design is the multitude
> of configuration files distributed over several subdirectories. That's
> subjective though.

I think there are plusses and minuses to that. For scripting stuff, that can
be a plus. When editing by hand its a pain to have to go so many places.

When I switch to Fedora 8, I can look at trying to allow use of etcnet
by turning off the network service and turning on an etcnet service.
This would allow it to be installed without breaking other stuff. Once you
started actually using it instead of the standard network service that
would break the system-config-network tool, since it would be changing
files that aren't being used anymore. If I have success with that, I may
submit it as a package after running it for a while.



From davej at redhat.com  Wed Oct 24 23:11:18 2007
From: davej at redhat.com (Dave Jones)
Date: Wed, 24 Oct 2007 19:11:18 -0400
Subject: Koji Garbage Collection
In-Reply-To: <1193104148.10460.41.camel@localhost.localdomain>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<1193104148.10460.41.camel@localhost.localdomain>
Message-ID: <20071024231118.GA6298@redhat.com>

On Mon, Oct 22, 2007 at 09:49:08PM -0400, Jeremy Katz wrote:

 > > What I'd like to do, is still keep all these RPMs, but get them out
 > > of koji.  I'm even prepared to give up a few hundred GB of diskspace
 > > on my own machines to keep them.   The question I have though, is
 > > whats the easiest way to get them?  Clicking through the koji web interface
 > > will quickly drive me nuts.   Is there some place I can just scp them from?
 > 
 > You can get a list of builds with koji list-tagged or just by getting a
 > directory listing.  Then, there's koji download-build[1] which will
 > download all the packages for a specific build into the current
 > directory
 > 
 > Jeremy
 > 
 > [1] I just found this one a couple of months ago -- it's incredibly
 > handy for all kinds of things

Indeed. kudos to whoever wrote that. That's going to be really useful.

	Dave

-- 
http://www.codemonkey.org.uk



From mjs at exchange.clemson.edu  Wed Oct 24 23:35:22 2007
From: mjs at exchange.clemson.edu (Matthew Saltzman)
Date: Wed, 24 Oct 2007 19:35:22 -0400
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <1193266141.5354.10.camel@valkyrie.localdomain>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
	<1193266141.5354.10.camel@valkyrie.localdomain>
Message-ID: <1193268923.3553.1.camel@valkyrie.localdomain>

On Wed, 2007-10-24 at 18:49 -0400, Matthew Saltzman wrote:
> On Wed, 2007-10-24 at 11:52 -0400, Matthew Saltzman wrote:
> > On Wed, 2007-10-24 at 06:59 -0400, Build System wrote:
> > > 
> > > 
> > > Updated Packages:
> > > ...
> > 
> > When I try to update, yum reports that all of these are unsigned!
> 
> Seriously, suddenly I can't apply updates, because yum reports all RPMs
> are unsigned.
> 
> I had installed livna-release for F7 as suggested by somebody else to
> get Livna updates.  When I tried "rpm -qi gpg-pubkey", only Livna and
> Adobe (Flash) keys were listed.  I ran "rpm --import" on all the keys
> in /etc/pki/gpg-keys/ and I even re-installed fedora-release-8-2, but I
> still can't install today's updates.
> 
> I guess I can run yum with --nogpgcheck, but surely that shouldn't be
> necessary--it hasn't been in the past.

One more piece of information: Installing directly with rpm works with
no complaint (at least with all those keys installed).  So this is
apparently something to do with yum.

> 
> Help!
> 
> $ rpm -q gpg-pubkey
> gpg-pubkey-f6777c67-45e5b1b9.(none)
> gpg-pubkey-a109b1ec-3f6e28d5.(none)
> gpg-pubkey-db42a60e-37ea5438.(none)
> gpg-pubkey-4f2a6fd2-3f9d9d3b.(none)
> gpg-pubkey-e418e3aa-3f439953.(none)
> gpg-pubkey-1cddbca9-3f9da14c.(none)
> gpg-pubkey-897da07a-3c979a7f.(none)
> gpg-pubkey-30c9ecf8-3f9da3f7.(none)
> 
> 
> TIA.
> 



From jspaleta at gmail.com  Wed Oct 24 23:45:41 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 24 Oct 2007 15:45:41 -0800
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <1193268923.3553.1.camel@valkyrie.localdomain>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
	<1193266141.5354.10.camel@valkyrie.localdomain>
	<1193268923.3553.1.camel@valkyrie.localdomain>
Message-ID: <604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>

On 10/24/07, Matthew Saltzman <mjs at exchange.clemson.edu> wrote:
> One more piece of information: Installing directly with rpm works with
> no complaint (at least with all those keys installed).  So this is
> apparently something to do with yum.

known issue

fedore-release package was updated for F8 final which turns on sig checking.

development repo does not garuantee signed packages...so until all the
packages are signed in preparation for f8 going gold, gpg checking
will fail.

Sooooooo, what you can do is turn gpg checking off in the repo
configuration file until f8 goes gold.

-jef"I think its great that gpg checking was turned on before all the
packages were signed. It's a good test to make sure the gpg checking
is actually working."spaleta



From Matt_Domsch at dell.com  Thu Oct 25 00:56:32 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 24 Oct 2007 19:56:32 -0500
Subject: Plan for tomorrows (20071025) FESCO meeting
In-Reply-To: <1193251779.7673.1.camel@kennedy>
References: <1193251779.7673.1.camel@kennedy>
Message-ID: <20071025005632.GB10879@auslistsprd01.us.dell.com>

On Wed, Oct 24, 2007 at 02:49:39PM -0400, Brian Pepple wrote:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
> in #fedora-meeting on irc.freenode.org:

May I suggest, if it doesn't exist already, setting a policy for when
soon-to-be-end-of-life releases (such as Fedora 6 is now) stop getting
new package branches?  I think new packages branching and getting
pushed on December 6 would be poor given a December 7
end-of-updates. (dates pulled out of the air by me, but is pretty
close to being right...)

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From jkeating at redhat.com  Thu Oct 25 01:02:23 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 21:02:23 -0400
Subject: Plan for tomorrows (20071025) FESCO meeting
In-Reply-To: <20071025005632.GB10879@auslistsprd01.us.dell.com>
References: <1193251779.7673.1.camel@kennedy>
	<20071025005632.GB10879@auslistsprd01.us.dell.com>
Message-ID: <20071024210223.1c7337d2@redhat.com>

On Wed, 24 Oct 2007 19:56:32 -0500
Matt Domsch <Matt_Domsch at dell.com> wrote:

> May I suggest, if it doesn't exist already, setting a policy for when
> soon-to-be-end-of-life releases (such as Fedora 6 is now) stop getting
> new package branches?  I think new packages branching and getting
> pushed on December 6 would be poor given a December 7
> end-of-updates. (dates pulled out of the air by me, but is pretty
> close to being right...)

I'm almost certain we came up with a date, and that was the release
date of the N+2 release.  IE no new packages/branches a month before
the EOL (modulo any thing that has to be brought in for security or
upstream renaming)

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/02de687d/attachment.sig>

From braden at endoframe.com  Thu Oct 25 01:26:00 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Wed, 24 Oct 2007 21:26:00 -0400
Subject: No Package Found for curl-devel
Message-ID: <1193275560.3300.26.camel@hinge.endoframe.net>

My F9 build of openvrml failed apparently for this reason:

        No Package Found for curl-devel

Full log is here:

        <http://koji.fedoraproject.org/koji/getfile?taskID=212794&name=root.log>

Do I just try again later?

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From kevin.kofler at chello.at  Thu Oct 25 02:18:54 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 02:18:54 +0000 (UTC)
Subject: No Package Found for curl-devel
References: <1193275560.3300.26.camel@hinge.endoframe.net>
Message-ID: <loom.20071025T021802-754@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> My F9 build of openvrml failed apparently for this reason:
> 
>         No Package Found for curl-devel

It's called libcurl-devel now, however libcurl-devel has been fixed to Provide 
and Obsolete curl-devel, so this:

> Do I just try again later?

should work too.

        Kevin Kofler





From kevin.kofler at chello.at  Thu Oct 25 02:31:27 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 02:31:27 +0000 (UTC)
Subject: firefox-2.0.0.8 Upgrade Problems in F7
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
Message-ID: <loom.20071025T021930-666@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:
> You are absolutely NOT going to see security updates postponed for
> deps to catch up.

I don't think that's a good way to handle things. I think almost every user has 
at least one of the affected packages installed, so what will happen will be 
that best case they have something like yum-skip-broken, apt or smart which can 
skip the Firefox update automatically (so why is it being pushed then?), worst 
case they'll end with NO security updates applied at all. (OK, they could also 
be using something like apt-get dist-upgrade which will delete the packages 
depending on Firefox, but that's not really a solution either, and most likely 
they'll just choose to hold back Firefox instead, putting us back to square 
one.)

Now, I can understand breaking deps for a package with few users and/or no 
active maintainer (it's still a bad thing, but sometimes a tradeoff has to be 
made), but not for a dozen packages (some of them installed on a lot of 
machines) which weren't even given a chance to rebuild.

What my personal suggestion would be is to:
* have the dependent packages centrally rebuilt (by rel-eng?) as soon as 
Firefox is built,
* have the Firefox security update held off until the rebuilds are complete. 
That shouldn't amount to more than one day of delay, much less than the delay 
those updates go through for most users with the current system (due to broken 
deps). Of course, if a rebuild fails for whatever reason, pushing the new 
Firefox anyway, breaking the dep, is probably the best that can be done.

        Kevin Kofler



From jwilliam at xmission.com  Thu Oct 25 03:03:45 2007
From: jwilliam at xmission.com (Jerry Williams)
Date: Wed, 24 Oct 2007 21:03:45 -0600
Subject: ISO file size in bytes?
Message-ID: <008201c816b3$a8797bb0$020aa8c0@a18>

Would it be possible to list the iso file size in bytes in the SHA1SUM file?

The reason that I ask it is that I had a DVD with Fedora 7 on it and needed
a copy of the iso file.  So I did a dd on the DVD, but the file ended up
being bigger than the original iso file.  I had to know the size so I could
enter the number of blocks to copy.

It is much quicker to do an ls -l than it is to run sha1sum on a file.
If the size is right then run the sha1sum.

Or is the size listed on some web page some place?
Everywhere I have looked I end up with an estimate.

Thanks!
Jerry



From jkeating at redhat.com  Thu Oct 25 03:04:18 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 24 Oct 2007 23:04:18 -0400
Subject: comps-f9 open for commit
Message-ID: <20071024230418.4411609b@redhat.com>

We've created the f9 comps based on the current f8 comps.  This will be
used once we switch rawhide over to composing from dist-f9.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/4d749e02/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From loganjerry at gmail.com  Thu Oct 25 03:16:08 2007
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 24 Oct 2007 21:16:08 -0600
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <20071024220500.GD2698@asus.config>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
	<20071024220500.GD2698@asus.config>
Message-ID: <870180fe0710242016m217f7c3at1e34464612edd7b7@mail.gmail.com>

On 10/24/07, Adam Huffman <bloch at verdurin.com> wrote:
> I tried the skip-broken plugin to resolve this problem but it failed to,
> um, skip the broken packages.  Can't find it as a component in bugzilla.

That happened to me, too.  So I tried "yum upgrade yum rpm" first
(since both of them were in my pending updates list), then tried
again.  The second time, skip-broken worked.  This is on a 32-bit x86
box.
-- 
Jerry James
http://loganjerry.googlepages.com/



From Matt_Domsch at dell.com  Thu Oct 25 03:29:30 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 24 Oct 2007 22:29:30 -0500
Subject: ISO file size in bytes?
In-Reply-To: <008201c816b3$a8797bb0$020aa8c0@a18>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
Message-ID: <20071025032930.GA17151@auslistsprd01.us.dell.com>

On Wed, Oct 24, 2007 at 09:03:45PM -0600, Jerry Williams wrote:
> Would it be possible to list the iso file size in bytes in the SHA1SUM file?
> 
> The reason that I ask it is that I had a DVD with Fedora 7 on it and needed
> a copy of the iso file.  So I did a dd on the DVD, but the file ended up
> being bigger than the original iso file.  I had to know the size so I could
> enter the number of blocks to copy.
> 
> It is much quicker to do an ls -l than it is to run sha1sum on a file.
> If the size is right then run the sha1sum.
> 
> Or is the size listed on some web page some place?
> Everywhere I have looked I end up with an estimate.

When reading a the file itself with isoinfo, it'll tell you:

$ isoinfo -d -i F-7-x86_64-DVD.iso 
...
Logical block size is: 2048
Volume size is: 1683582
...


If you're reading a physical CD or DVD, you can do the same thing.
Here's a little script I use all the time for getting the size right.
It prompts you for the name of the ISO you want to create, then reads
the media using dd; repeat until Ctrl-C.

IIRC there was something about using -pad when writing media, but I
haven't had to do that for a while...

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux


#!/bin/bash

DEVICE=/dev/cdrom

let i=0

while [ 1 ]; do

echo "Please insert a disc.  What do you want it named?"
read FILENAME
BLOCKS=`isoinfo -d -i ${DEVICE} | grep "Volume size" | awk '{print $4}'`

dd if=${DEVICE} of=${FILENAME} bs=2k count=${BLOCKS}
md5sum ${FILENAME}
done



From jcm at redhat.com  Thu Oct 25 03:44:08 2007
From: jcm at redhat.com (Jon Masters)
Date: Wed, 24 Oct 2007 23:44:08 -0400
Subject: ISO file size in bytes?
In-Reply-To: <20071025032930.GA17151@auslistsprd01.us.dell.com>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
Message-ID: <1193283848.3393.44.camel@perihelion>


On Wed, 2007-10-24 at 22:29 -0500, Matt Domsch wrote:
> On Wed, Oct 24, 2007 at 09:03:45PM -0600, Jerry Williams wrote:
> > Would it be possible to list the iso file size in bytes in the SHA1SUM file?
> > 
> > The reason that I ask it is that I had a DVD with Fedora 7 on it and needed
> > a copy of the iso file.  So I did a dd on the DVD, but the file ended up
> > being bigger than the original iso file.  I had to know the size so I could
> > enter the number of blocks to copy.
> > 
> > It is much quicker to do an ls -l than it is to run sha1sum on a file.
> > If the size is right then run the sha1sum.
> > 
> > Or is the size listed on some web page some place?
> > Everywhere I have looked I end up with an estimate.
> 
> When reading a the file itself with isoinfo, it'll tell you:
> 
> $ isoinfo -d -i F-7-x86_64-DVD.iso 
> ...
> Logical block size is: 2048
> Volume size is: 1683582
> ...

Right, but I think what he's saying is that he *didn't* have the ISO
file to hand - but did have a DVD he could dd from - and he wanted a way
to find out how big the image should have been without downloading it.

Jon.




From tmz at pobox.com  Thu Oct 25 03:55:45 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 24 Oct 2007 23:55:45 -0400
Subject: ISO file size in bytes?
In-Reply-To: <1193283848.3393.44.camel@perihelion>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
	<1193283848.3393.44.camel@perihelion>
Message-ID: <20071025035545.GB4413@psilocybe.teonanacatl.org>

Jon Masters wrote:
> Right, but I think what he's saying is that he *didn't* have the ISO
> file to hand - but did have a DVD he could dd from - and he wanted a
> way to find out how big the image should have been without
> downloading it.

And the very next part of Matt's mail said:

> If you're reading a physical CD or DVD, you can do the same thing.
> Here's a little script I use all the time for getting the size
> right.  It prompts you for the name of the ISO you want to create,
> then reads the media using dd; repeat until Ctrl-C.

He even provided a short script to do the job.  You can't be much more
helpful than that. ;)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You're not drunk if you can lie on the floor without holding on.
    -- Dean Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071024/41ae1e86/attachment.sig>

From Matt_Domsch at dell.com  Thu Oct 25 03:56:00 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 24 Oct 2007 22:56:00 -0500
Subject: ISO file size in bytes?
In-Reply-To: <1193283848.3393.44.camel@perihelion>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
	<1193283848.3393.44.camel@perihelion>
Message-ID: <20071025035600.GB17151@auslistsprd01.us.dell.com>

On Wed, Oct 24, 2007 at 11:44:08PM -0400, Jon Masters wrote:
> 
> Right, but I think what he's saying is that he *didn't* have the ISO
> file to hand - but did have a DVD he could dd from - and he wanted a way
> to find out how big the image should have been without downloading it.

Go to bed Jon, you didn't read far enough. :-)  You would have seen
the appended script do:

BLOCKS=`isoinfo -d -i ${DEVICE} | grep "Volume size" | awk '{print $4}'`
dd if=${DEVICE} of=${FILENAME} bs=2k count=${BLOCKS}

where DEVICE=/dev/cdrom  or whatever device had the media.


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From wwoods at redhat.com  Thu Oct 25 04:31:52 2007
From: wwoods at redhat.com (Will Woods)
Date: Thu, 25 Oct 2007 00:31:52 -0400
Subject: NetworkManager-0.7.0-0.3.svn3016.fc8 selinux problem
In-Reply-To: <1193256199.5029.3.camel@tiger>
References: <1193256199.5029.3.camel@tiger>
Message-ID: <1193286713.6343.3.camel@zebes.localdomain>


On Wed, 2007-10-24 at 16:03 -0400, Louis E Garcia II wrote:
> NetworkManager can't connect to wireless and quits because:
> 
> SELinux is preventing NetworkManager (NetworkManager_t) "execute" to
> (nscd_exec_t).

Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=351671

I'm told selinux-policy-3.0.8-32.fc8 (which should be in tomorrow's
rawhide) fixes it, although the changelog doesn't mention it
specifically. It seems to work just fine in my testing, though.

-w



From lightsolphoenix at gmail.com  Thu Oct 25 04:51:07 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 25 Oct 2007 00:51:07 -0400
Subject: Feedback from PulseAudio 0.9.7 SVN (Was: Current problems with
	Rawhide)
In-Reply-To: <c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<1193240595.25405.126.camel@cookie.hadess.net>	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
Message-ID: <472020BB.9080804@gmail.com>

Okay, I'm attaching my logs related to PulseAudio to this email.  I hope 
someone can tell me the right place to go.

I guess it's important to describe the setup as well.  I'm using 
alsa-plugins-pulse to redirect ALSA sound to PulseAudio, so pcm.default! 
and ctl.default! are both set to module: pulse.  The actual hardware is 
aliased as hw:0 (I keep getting errors that it's busy, even though 
nothing is running that would use sound because I automatically kill 
aRts before I start PulseAudio, and none of the other sound daemons are 
running...)

BTW, for some odd reason, Thunderbird seems to pass between a phase of 
being fine and a phase where it takes up 90% of the system resources and 
grinds to a halt for a period of time.  I'm not sure what's up with 
that, either...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulse-log.log
Type: text/x-log
Size: 18593 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/be8ad842/attachment.bin>

From alexl at users.sourceforge.net  Thu Oct 25 04:53:34 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 24 Oct 2007 21:53:34 -0700
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193264638.23316.40.camel@localhost6.localdomain6> (Richi
	Plana's message of "Wed\, 24 Oct 2007 16\:23\:58 -0600")
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
	<1193264638.23316.40.camel@localhost6.localdomain6>
Message-ID: <0qd4v3iylt.fsf@allele2.eebweb.arizona.edu>

RP> On Wed, 2007-10-24 at 13:25 -0800, Jeff Spaleta wrote:
>> Point of fact... is there anything which depends on firefox that is
>> currently experience a depchain problem that is considered a
>> mandatory application?  Crap like yelp and devhelp and Miro are
>> fundamentally optional components. And you absolutely are not going
>> to be able to make a strong enough argument that firefox security
>> updates should be delay one milliseconds to keep optional packages
>> from breaking. It just isnt going to fly.  People who do not have
>> these optional components installed will suffer lapses in security
>> unnecessarily.

>>>>> "RP" == Richi Plana  writes:

RP> Well, whether yelp and devhelp are "crap" is debatable (I'm a
RP> software developer as well as a user and I've yet to find use for
RP> either. 

"yelp" is not a "crap application", and *is* a fundamental part of the
GNOME desktop, and it is "mandatory" for the "GNOME Desktop
Environment" group, see the comps-f7.xml file:

      <packagereq type="mandatory">yelp</packagereq>

This means that all Fedora users who install GNOME via pirut etc. or
in anaconda (which is probably the majority of users who leave
everything at the default in anaconda) *will* have yelp installed, so
this is not some obscure "leaf" application that the Firefox
maintainers should ignore.

RP> Don't get me wrong, though. I agree that security updates SHOULD
RP> NOT be delayed. But if they can't be applied, then they're
RP> effectively delayed.  I'm just saying that for certain updates,
RP> the user should be given the choice to either force the update and
RP> allow it to break the dependency or do an automatic dependency
RP> resolution by REMOVING packages (as opposed to adding). I know
RP> it's complicated, but if it's worth it, then at least it can go on
RP> the table.

That's the way "smart" and "apt" package managers work, but I believe
that it's been considered by the yum maintainers as not to be
desirable.

RP> I've gone ahead and removed "yelp" and "devhelp", but removing
RP> dependent packages isn't always a choice.

Until the xulrunner solution is in place there basically needs to be
better communication from the firefox maintainer to the downstream
maintainers.  At the very least an e-mail almost immediately after the
firefox update is pushed to each of the downstream dependent package
maintainers that the new firefox security update has been pushed and
please rebuild packages ASAP would be useful.  (Apparently
telegraphing the change in advance to maintainers in advance of the
update is considered a security risk, which is debatable, but anyway).
The firefox maintainer(s) can use repoquery to get a list of all such
packages and be ready to send it immediately.  (My apologies if this
was already done in this case.)

If the maintainer doesn't respond reasonably quickly, other
maintainers could be permitted to step up to the bat to rebuild
the broken apps against the new firefox themselves.

This would be preferable rather than let those maintainers (galeon,
Miro etc.) discover them through multiple bugs filed on bugzilla
and/or user forums or IRC several days later, dragging the updating
process on, and generating confusion) which seems to be what tends to
happen.  

Alex



From jcm at redhat.com  Thu Oct 25 05:08:24 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 01:08:24 -0400
Subject: ISO file size in bytes?
In-Reply-To: <20071025035600.GB17151@auslistsprd01.us.dell.com>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
	<1193283848.3393.44.camel@perihelion>
	<20071025035600.GB17151@auslistsprd01.us.dell.com>
Message-ID: <1193288904.3393.50.camel@perihelion>


On Wed, 2007-10-24 at 22:56 -0500, Matt Domsch wrote:
> On Wed, Oct 24, 2007 at 11:44:08PM -0400, Jon Masters wrote:
> > 
> > Right, but I think what he's saying is that he *didn't* have the ISO
> > file to hand - but did have a DVD he could dd from - and he wanted a way
> > to find out how big the image should have been without downloading it.
> 
> Go to bed Jon, you didn't read far enough. :-)  You would have seen
> the appended script do:
> 
> BLOCKS=`isoinfo -d -i ${DEVICE} | grep "Volume size" | awk '{print $4}'`
> dd if=${DEVICE} of=${FILENAME} bs=2k count=${BLOCKS}
> 
> where DEVICE=/dev/cdrom  or whatever device had the media.

Yeah. I suck. Too much Red Sox and coffee, not enough reading...sorry
Matt - sooner or later I'll learn :-)

Jon.




From jcm at redhat.com  Thu Oct 25 05:14:38 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 01:14:38 -0400
Subject: ISO file size in bytes?
In-Reply-To: <20071025032930.GA17151@auslistsprd01.us.dell.com>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
Message-ID: <1193289278.3393.57.camel@perihelion>

On Wed, 2007-10-24 at 22:29 -0500, Matt Domsch wrote:

> If you're reading a physical CD or DVD, you can do the same thing.
> Here's a little script I use all the time for getting the size right.
> It prompts you for the name of the ISO you want to create, then reads
> the media using dd; repeat until Ctrl-C.

Right. But if you end up reading more from the disk than you planned,
this will only flag that up (the MD5SUM generated) - it won't tell you
what it should be. So my point from before is somehow semi valid ;-)

> IIRC there was something about using -pad when writing media, but I
> haven't had to do that for a while...

It's down to the size of the ISO image. I haven't had to use pad in a
while, which suggests that most of the ISOs are created in the right
multiples of 2.whatever K or tools like growisofs are handling it.

CDs are fascinating little things. I've got a book on the multiple stage
error correction process somewhere here I used to use for bedtime
reading...these days, coffee is all that's required.

Jon.




From jcm at redhat.com  Thu Oct 25 05:19:08 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 01:19:08 -0400
Subject: ISO file size in bytes?
In-Reply-To: <1193289278.3393.57.camel@perihelion>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
	<1193289278.3393.57.camel@perihelion>
Message-ID: <1193289548.3393.63.camel@perihelion>


On Thu, 2007-10-25 at 01:14 -0400, Jon Masters wrote:
> On Wed, 2007-10-24 at 22:29 -0500, Matt Domsch wrote:
> 
> > If you're reading a physical CD or DVD, you can do the same thing.
> > Here's a little script I use all the time for getting the size right.
> > It prompts you for the name of the ISO you want to create, then reads
> > the media using dd; repeat until Ctrl-C.
> 
> Right. But if you end up reading more from the disk than you planned,
> this will only flag that up (the MD5SUM generated) - it won't tell you
> what it should be. So my point from before is somehow semi valid ;-)

No, I'm wrong, because isoinfo is going to get that from the TOC. So
clearly I'm way too Red Soxed for one evening and should just shut up.

Ignore me... :-)

Jon.




From jcm at redhat.com  Thu Oct 25 05:31:02 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 01:31:02 -0400
Subject: NSCD, Fedora, and busted DNS
In-Reply-To: <1193013005.5168.65.camel@perihelion>
References: <1193013005.5168.65.camel@perihelion>
Message-ID: <1193290263.3393.68.camel@perihelion>

On Sun, 2007-10-21 at 20:30 -0400, Jon Masters wrote:

> We have NSCD installed on my F8T3, why is it not running by default?

Anyone want to field an answer to this question?

I'd love to help solve some of the occasional slow bootup times by
fixing this kind of thing - I guess I'll also look at fixing vpnc so it
cleans up more gracefully on exit.

Jon.




From a.badger at gmail.com  Thu Oct 25 05:32:30 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 24 Oct 2007 22:32:30 -0700
Subject: Request permission to break always use
	system	libs	rule	for	asc-2.0
In-Reply-To: <471F179D.1060609@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>	<471CC274.9080002@gmail.com>	<471CF051.7010705@hhs.nl>	<471D5AC2.3000906@gmail.com>
	<471F179D.1060609@hhs.nl>
Message-ID: <47202A6E.1020108@gmail.com>

Hans de Goede wrote:
> Toshio Kuratomi wrote:
>> Hans de Goede wrote:
>>>> 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages 
>>>> from the asc source tarball.
>>>
>>> To what purpose? There are no other users, if you can name one 
>>> package out there which could be packaged for Fedora which uses 
>>> either of them I would fully agree, which is why I created a seperate 
>>> package for SDLmm in the first place. But there are _no_ other users. 
>>> Try googling for paragui, the first 2 links are dead upstream 
>>> websites then a domain squater, then some old mailinglist posts and 
>>> then we go into rpmsearch hits.
>>>
>>> SDLmm, the same the last mailinglist post is from dec 2005!
>>>
>>> So I challenge you, give my another (potential) package that needs 
>>> them and I agree.
>>>
>>>
>> That's not great reasoning.  If asc maintained those libraries out of 
>> tree and made releases as separate tarballs, you'd continue to make 
>> separate packages, right?  It's not a question of how many consumers 
>> there are but of how useful the library is outside of the program.
>>
> 
> Thats not great reasoning either, if we follow that reasoning then all 
> pieces of code in applications which may be useful outside of an 
> application should be converted into libraries before those programs may 
> pass review. See, this kind of "reasoning" is what you get if you insist 
> on stubbornly and blindly following the theory of the rules without 
> looking at the practical situation at hand.
> 
But I also say in the next few paragraphs that it depends on whether the 
codebases are separate or not.  Extracting a piece of code from a 
program is not a separate codebase.  Building a library from a library 
which is merely being distributed inside of another project's tarball is 
a different story.

>> Since these libraries were released outside of the program before and 
>> you haven't said anything about the build scripts being changed just 
>> bugfixes and code-formatting I have the impression that they would be 
>> useful outside of asc.
> 
> I didn't say anything about buildscript changes because that seemed 
> irrelvant, to be honest I didn't expect anyone to object. But no that 
> you ask, the SDLmm and paragui configure scripts and config.h have been 
> removed and now the asc scripts and config.h get used.
> 
Okay.  So that sounds un-promising.  Does this cripple the ability to 
build shared libraries?

>> You could correct me on that by letting me know that the asc fixes 
>> have made the two code bases dependent on each other or some other 
>> technical reason that they aren't two separate codebases that happen 
>> to be maintained in the same tree.
>>
> 
> I keep repeating myself, what is the practical use of splitting them? 

I keep telling you, being able to reuse the code.

> upstream is maintaining them as if they are one code base, there are no 
> known other applications which them, not in Fedora, nor outside. All you 
> are doing is bringing theoretical arguments, not practical ones.
> 

I took a highly superficial look at the layout of the source.  Upstream 
is not quite to the point where they are maintaining them as one 
codebase.  They have a libs directory in which they have all of these 
third party libraries tucked.  I didn't look at the separately packaged 
paragui or SDLmm so I don't know how crippled their buildsystems are; 
I'm depending on you as the maintainer to tell me that.

> Why should I have to find out what changed, generate patches, maintain 
> seperate buildscripts, etc. For 2 additional packages, each time asc 
> does a new release? Where is the sense in that? What is the added value 
> for fellow Fedora developers or Fedora users? And since there is no 
> added value I would much rather spend my time in some other more usefull 
> way.
>
Either you're misreading me or I'm misreading you.  I've never asked you 
to find out what changed or generate patches.  I've never asked you to 
maintain separate buildscripts although I have asked you whether the 
libraries were still buildable as separate entities.  I'm not asking you 
to continue maintaining three source packages for asc, paragui, and 
SDLmm.  I'm asking you to:

1) Ask the asc maintainers if they'd like to maintain paragui or SDLmm 
upstream.  This is a benefit to the opensource community as a whole if 
they want to do that since someone who needs that functionality won't 
come along later and find that it's no longer possible to separate asc 
from these libraries. This is not something that requires any long term 
effort on your part.  You ask, they refuse, you proceed to package 
everything from the asc tarball.

2) make a quick estimate of whether the paragui and SDLmm sources have 
been so integrated with the asc sources that it's not feasible to build 
multiple rpms from the asc srpm for those libraries.  If it is possible, 
you stop having to maintain three separate spec files.  You stop having 
to push three srpms through the buildsystem.  You stop having to 
generate diffs between the fixed source in the asc source tree and the 
old-never-to-be-updated tarballs from the "official" download 
repository.  These are the benefits of doing this over the state that 
you're in now.  You would still have three binary rpms and the separate 
%files section inside the [single] spec file to manage that so it's not 
as easy as your proposal but it removes the gripes you had with the 
status quo.

Further note that I am not demanding that you follow this plan.  I am 
asking you to tell me if you've considered it and whether it is 
workable.  If you say "the source is all thrown into one directory where 
it's impossible to separate" or "patching the buildscripts to cleanly 
build dynamic libraries will take as long as porting to separate specs 
would have" then I'll know that you had a look at this possibility and 
decided it wasn't worthwhile.

>>>> 3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.
>>>>
>>>
>>> Which would be the least work, not deviating from what upstream does 
>>> (wasn't our mantra upstream upstream upstream?) and has no downsides.
>>>
>> If a problem is serious enough we do deviate from upstream.  For 
>> instance, changing a package to build against system libraries is 
>> certainly something that we do whether or not upstream.  We also will 
>> take the time to help upstream do the right thing rather than blindly 
>> packaging what they hand us.  In this case, it sure looks best to me 
>> to build those libraries from upstream's tarball as system libraries 
>> and then have the asc programs use those.
>>
>> The downsides:
>> * if you make these private libraries of asc you then have all the 
>> problems of static libraries should another program be created in the 
>> future that makes use of their own copy of those libraries.
>>
> 
> Notice the ".. if .. in the future" in your reasoning, still 
> theoretical. I would like to be given some more credit here, I have no 
> problem with splitting out the libraries again once another using app 
> turns up. But lets wait till then.
> 
If it's hard to split out the libraries now because upstream decided 
that it was extraneous to have separate build scripts, how easy is it 
going to be to split them out three releases from now when the 
maintainers have decided they don't need two versions of a function to 
copy memory or two logging functions or two variables that turn on 
debugging?  If you ask upstream if they would like to maintain the 
packages separately and they say yes, you halt that process and keep 
these libraries alive.  If you don't and those libraries end up 
integrated into the main app then the community loses the ability to 
reuse the code.

And yes, in one respect you can't know what the future will bring but 
it's also not something that can "wait till then." to find out.  The act 
of asking upstream asc if they are willing to become the maintainers of 
the paraguia nad SDLmm libraries will let them know that the 
separability of the libraries is valuable even if they are unwilling to 
actually do the work of packaging them separately.

> I'm very much in favor of the use system libs rule. For example AFAIK 
> Fedora is the only distro that has quake3 and tremulous use the system 
> libjpeg use the system libjpeg instead of a ptivate copy. Also I'm 
> trying to find the time to work on ripping all patent encumbered stuff 
> out of SDL_sound so that can move to Fedora, as the new asc release can 
> use a system SDL_sound if present (and will use a stripped down, patent 
> free included copy if not present). But unfortunately as my time gets 
> sunk into useless discussions like these, sofar I haven't found the time 
> to work on SDL-sound.
> 
>> * There's no attempt to coordinate work on the libraries.  Should 
>> another developer decide they want to build something that uses 
>> functionality that could be provided by SDl-mm or paragui they'll be 
>> unaware that there is active maintenance of these libraries occurring 
>> and will either fork their own copy or reinvent the wheel.
>>
> 
> And since when is it my task as maintainer to take care of coordination 
> of dead upstream packages? If FESco / the FPC start demanding that I'm 
> going to have to drop a whole shitload of packages, as quite a few of my 
> packages have a dead upstream.
> 
It's not.  But it's within the realm of your responsibilities to try and 
shift the burden onto someone else :-).  asc is plainly maintaining the 
code.  Find out if they're willing to go one step further and maintain 
the code as libraries rather than just a piece of asc.

> Anyways I'm totally fed up with having discussions like this with the 
> bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) 
> either the powers that be give me permission to use SDLmm and paragui as 
> included and maintained within upstream asc release, or I'll just orphan 
> all 3 of them. I refuse to become upstream for 2 libraries backporting 
> fixes from asc each release just because some people want to follow the 
> rules as if they are something holy. orphaning asc would be a shame as 
> its a great and quite popular game, but if that is want the powers that 
> be want, then that is what they will get.

I'd be fed up too if I was standing in your shoes and saw things that 
way.  But the way I see it,  1) you gave an outline of a plan for 
dealing with a dead upstream, 2) I proposed two alternative plans that 
had most of the benefits of your plan, 3) you jump on my case and accuse 
me of forcing you to do something unreasonable.

Once again, I've made no requirements of you.  I've asked you to find 
out if upstream would be willing to do more work.  I've asked you to 
evaluate whether continuing to package the code as libraries but from 
within the asc srpm is feasible.

If you've done the first and the results of the second are that it's an 
unreasonable amount of work then I have no complaints.  If you refuse to 
do the first and don't look into the second I still won't have a 
bugzilla-worthy grievance with your plan (your first message was 
perfectly clear on how dead the upstreams were). I will just be slightly 
peeved that people request comments on their ideas without the 
expectation that they'll have to reevaluate their ideas rather than just 
blindly defending them.

Sincerely,
-Toshio



From jcm at redhat.com  Thu Oct 25 05:34:46 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 01:34:46 -0400
Subject: boot a live image from an ipod?
In-Reply-To: <1193095503.10460.27.camel@localhost.localdomain>
References: <471D275D.7040903@redhat.com>
	<1193095503.10460.27.camel@localhost.localdomain>
Message-ID: <1193290486.3393.71.camel@perihelion>


On Mon, 2007-10-22 at 19:25 -0400, Jeremy Katz wrote:
> On Mon, 2007-10-22 at 15:42 -0700, John Poelstra wrote:
> > Working from this page http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo 
> > 
> > I don't have a USB stick yet to try this so I'm wondering if anyone has successfully used their ipod as a USB boot device?  I am reluctant to change the partition flag on the ipod to be bootable because I don't have time right now to setting up my ipod again if it gets hosed.
> 
> Current ipods are set up with 2048 byte sectors which syslinux (and
> other bootloaders) don't support, so you can't actually boot from them.
> Fixing that requires a lot of really grotty work to clean out all of the
> "sector size == 512" assumptions through syslinux and even then, no
> guarantee that it doesn't brick the iPod

I guess that'll apply to any of the flash based NAND iPods out there -
but not the disk ones, I'd assume they're still standard 512 sectors.

So, your testing before was all on a disk based iPod?

Jon.




From alexl at users.sourceforge.net  Thu Oct 25 05:35:18 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 24 Oct 2007 22:35:18 -0700
Subject: rebuilding galeon and/or Miro (was Re: firefox-2.0.0.8 Upgrade
	Problems in F7)
In-Reply-To: <0qd4v3iylt.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's
	message of "Wed\, 24 Oct 2007 21\:53\:34 -0700")
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
	<1193264638.23316.40.camel@localhost6.localdomain6>
	<0qd4v3iylt.fsf@allele2.eebweb.arizona.edu>
Message-ID: <6p3avziwo9.fsf_-_@allele2.eebweb.arizona.edu>

>>>>> "AL" == Alex Lancaster  writes:

[...]

AL> If the maintainer doesn't respond reasonably quickly, other
AL> maintainers could be permitted to step up to the bat to rebuild
AL> the broken apps against the new firefox themselves.

AL> This would be preferable rather than let those maintainers
AL> (galeon, Miro etc.) discover them through multiple bugs filed on
AL> bugzilla and/or user forums or IRC several days later, dragging
AL> the updating process on, and generating confusion) which seems to
AL> be what tends to happen.

In the interests of getting these security updates up quickly, I'm
taking the liberty to rebuild galeon against the new firefox (I've had
a fair bit of experience rebuilding this application before) .  I'm
currently doing a scratch build in koji, let me know if this isn't OK
with anyone.

I'll also do Miro if nobody screams at me.

(PS.  I can't see any pending builds in koji and/or CVS action that
would imply that the current maintainers of these packages are aware
of the change firefox at the moment.)

Alex



From a.badger at gmail.com  Thu Oct 25 05:39:48 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 24 Oct 2007 22:39:48 -0700
Subject: Request permission to break always use
	system	libs	rule	for	asc-2.0
In-Reply-To: <471F179D.1060609@hhs.nl>
References: <471CB6AF.3060905@hhs.nl>	<471CC274.9080002@gmail.com>	<471CF051.7010705@hhs.nl>	<471D5AC2.3000906@gmail.com>
	<471F179D.1060609@hhs.nl>
Message-ID: <47202C24.2070105@gmail.com>

Looking back to my first message I see that I wrote:

 > 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel
 > packages from the asc source tarball.

I realize on reading this over that it's unclear whether I meant those 
to be separate packages in the srpm sense or in the rpm sense.  If 
that's the source of confusion (which may or may not be, I don't know.) 
then I apologize for causing confusion.  This would be clearer if stated as:

   2) Create paragui and SDL-mm binary rpms from the asc source rpm.

-Toshio



From valent.turkovic at gmail.com  Thu Oct 25 06:01:34 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 08:01:34 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <20071024170953.5b58b525@redhat.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<20071024164136.50130513@redhat.com>
	<64b14b300710241357k3d0b6adbje8b6c269cd8331df@mail.gmail.com>
	<20071024170953.5b58b525@redhat.com>
Message-ID: <64b14b300710242301h5a6068bdk2d24bef26096a9c7@mail.gmail.com>

On 10/24/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 24 Oct 2007 22:57:20 +0200
> "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
>
> > Sure, of course I will but I need to know it the OSS bits or
> > proprietary bits are "broken". I can equally assume that totem it to
> > blame or CodecBuddy or some other OSS and also proprietary fluendo
> > part...
> >
> > That was the intention of my question.
> >
> > I posted them a inquiery but I want to see if somebody already knows
> > what might be the issue and with which component in the chain is the
> > issue.
>
> If you followed your vendor's instructions and it's not working,
> you need to follow that up with your vendor.
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>

Ok, thanks.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Thu Oct 25 06:07:46 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 08:07:46 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <1193264429.25405.134.camel@cookie.hadess.net>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<1193264429.25405.134.camel@cookie.hadess.net>
Message-ID: <64b14b300710242307y4d868611qf08bcad128b32693@mail.gmail.com>

On 10/25/07, Bastien Nocera <bnocera at redhat.com> wrote:
>
> On Wed, 2007-10-24 at 22:06 +0200, Valent Turkovic wrote:
> > I followed instructions for installing fluendo mega codec pack and
> > copied all files to
> > /usr/lib/gstreamer-0.10/ under Fedora 8 test 3 (with latest updates)
> > but whenever I try to open different video files I still get message
> > from Totem that I need to go to fluendo site and get codecs...
>
> 1) Check that the video you're trying to play is supposed to be playing
> (ie. which video and audio codecs does it complain about when you exit
> Codeina?)
>
> 2) Check that the plugins are correctly installed ("gst-inspect-0.10 |
> grep flu" will list the Fluendo plugins.
>
> 3) File bugs with Fluendo if they're supposed to be playing and aren't:
> https://core.fluendo.com/gstreamer/trac
>
> Cheers

Thank you, I'll do that mediately...

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jnovy at redhat.com  Thu Oct 25 06:47:33 2007
From: jnovy at redhat.com (Jindrich Novy)
Date: Thu, 25 Oct 2007 08:47:33 +0200
Subject: No Package Found for curl-devel
In-Reply-To: <loom.20071025T021802-754@post.gmane.org>
References: <1193275560.3300.26.camel@hinge.endoframe.net>
	<loom.20071025T021802-754@post.gmane.org>
Message-ID: <20071025064732.GA2884@dhcp-lab-186.brq.redhat.com>

On Thu, Oct 25, 2007 at 02:18:54AM +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> >         No Package Found for curl-devel
> 
> > Do I just try again later?
>
It should work just fine now as the virtual provides curl-devel was
added to libcurl-devel & built yesterday.

Jindrich

--- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From j.w.r.degoede at hhs.nl  Thu Oct 25 07:14:59 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 09:14:59 +0200
Subject: Request permission to break always
	use	system	libs	rule	for	asc-2.0
In-Reply-To: <47202C24.2070105@gmail.com>
References: <471CB6AF.3060905@hhs.nl>	<471CC274.9080002@gmail.com>	<471CF051.7010705@hhs.nl>	<471D5AC2.3000906@gmail.com>	<471F179D.1060609@hhs.nl>
	<47202C24.2070105@gmail.com>
Message-ID: <47204273.3050802@hhs.nl>

Toshio Kuratomi wrote:
> Looking back to my first message I see that I wrote:
> 
>  > 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel
>  > packages from the asc source tarball.
> 
> I realize on reading this over that it's unclear whether I meant those 
> to be separate packages in the srpm sense or in the rpm sense.  If 
> that's the source of confusion (which may or may not be, I don't know.) 
> then I apologize for causing confusion.  This would be clearer if stated 
> as:
> 
>   2) Create paragui and SDL-mm binary rpms from the asc source rpm.
>

Yes, I'm afraid I misunderstood that, doing things that way sounds reasonable . 
If feasible, I still have to check that.

And thanks for the other long reply in this thread, I'm afraid we've mainly 
been misunderstanding each other.

Regards,

Hans



From jcm at redhat.com  Thu Oct 25 07:42:34 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 25 Oct 2007 03:42:34 -0400
Subject: nautilus/GNOME VFS ACL support capabilities?
Message-ID: <1193298155.3393.85.camel@perihelion>

Yo,

Rather than sleeping, I was just looking at a few capabilities currently
in F8 and thinking about what would be nice in the future.

Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
to understand ACLs. Am I missing something? Heck, I remember 5 or 6
years ago patching in the original ACL patches from bestbits and even
setting ACLs remotely from a Windows machine using Samba, by right
clicking on the export files. Does this not work in nautilus?

Jon.




From che666 at gmail.com  Thu Oct 25 08:07:06 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Thu, 25 Oct 2007 10:07:06 +0200
Subject: nautilus/GNOME VFS ACL support capabilities?
In-Reply-To: <1193298155.3393.85.camel@perihelion>
References: <1193298155.3393.85.camel@perihelion>
Message-ID: <e99d27470710250107v6ad2be18qbe840ee1d9354bcc@mail.gmail.com>

2007/10/25, Jon Masters <jcm at redhat.com>:
> Yo,
>
> Rather than sleeping, I was just looking at a few capabilities currently
> in F8 and thinking about what would be nice in the future.
>
> Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
> to understand ACLs. Am I missing something? Heck, I remember 5 or 6
> years ago patching in the original ACL patches from bestbits and even
> setting ACLs remotely from a Windows machine using Samba, by right
> clicking on the export files. Does this not work in nautilus?
>
> Jon.
>

With the current broken default permission tab you cant even set
standard permissions like sticky bit, sgid, suid. acls which is
clearly a regression, so why do you expect acls or even extended ext3
attributes would be shown or handled? ;)
There is a user unfriendly way of enabling the old permssion tab with
some magic gconf key... (very user friendly indeed).

regards,
Rudolf Kastl


>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From che666 at gmail.com  Thu Oct 25 08:08:22 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Thu, 25 Oct 2007 10:08:22 +0200
Subject: nautilus/GNOME VFS ACL support capabilities?
In-Reply-To: <e99d27470710250107v6ad2be18qbe840ee1d9354bcc@mail.gmail.com>
References: <1193298155.3393.85.camel@perihelion>
	<e99d27470710250107v6ad2be18qbe840ee1d9354bcc@mail.gmail.com>
Message-ID: <e99d27470710250108y5a7e9fafqe9b1299383ae7d09@mail.gmail.com>

2007/10/25, Rudolf Kastl <che666 at gmail.com>:
> 2007/10/25, Jon Masters <jcm at redhat.com>:
> > Yo,
> >
> > Rather than sleeping, I was just looking at a few capabilities currently
> > in F8 and thinking about what would be nice in the future.
> >
> > Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
> > to understand ACLs. Am I missing something? Heck, I remember 5 or 6
> > years ago patching in the original ACL patches from bestbits and even
> > setting ACLs remotely from a Windows machine using Samba, by right
> > clicking on the export files. Does this not work in nautilus?
> >
> > Jon.
> >
>
> With the current broken default permission tab you cant even set
> standard permissions like sticky bit, sgid, suid which is
> clearly a regression, so why do you expect acls or even extended ext3
> attributes would be shown or handled? ;)
> There is a user unfriendly way of enabling the old permssion tab with
> some magic gconf key... (very user friendly indeed).
>
> regards,
> Rudolf Kastl
>
>
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>

fixed a small confusing "typo" in the text above ;)

regards,
Rudolf Kastl



From jonathan at jonmasters.org  Thu Oct 25 08:18:35 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 25 Oct 2007 04:18:35 -0400
Subject: Fosscamp this weekend
Message-ID: <1193300315.3393.94.camel@perihelion>

Yo,

FYI there's a local hacker meet in Cambridge, MA this weekend:

http://www.fosscamp.org/

I'll be there...

Jon.




From caillon at redhat.com  Thu Oct 25 08:50:49 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 25 Oct 2007 04:50:49 -0400
Subject: Development to Official
In-Reply-To: <1193249067.2109.9.camel@scrappy.miketc.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
Message-ID: <472058E9.30704@redhat.com>

Mike Chambers wrote:
> On Wed, 2007-10-24 at 13:30 -0400, Jesse Keating wrote:
> 
>> We can prevent this by just holding rawhide until the day of the
>> release.  Of course this tends to piss off developers who want their
>> new bits looked at.
> 
> Then again, what is a few days of waiting?

What's a few days extra?  A few days of extra testing for F9 on the 
features that didn't quite make it into F8, such as intlclock.  Or a few 
days of testing some bugfixes, such as NetworkManager fixes, in F9 
packages before they make it in to F8-updates.  With all the "few days 
here" because of test freezes, we've maybe lost a month or so of testing 
in the F8 cycle -- out of 6 months.



From caillon at redhat.com  Thu Oct 25 08:57:24 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 25 Oct 2007 04:57:24 -0400
Subject: Current problems with Rawhide
In-Reply-To: <a785db460710241011t3419b999vfe52626850b3ca96@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<1193240595.25405.126.camel@cookie.hadess.net>	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
	<a785db460710241011t3419b999vfe52626850b3ca96@mail.gmail.com>
Message-ID: <47205A74.5020205@redhat.com>

Kelly Miller wrote:
> Okay, when I get home I'll check the messages log for anything.  I'm just
> not sure if it's an error with PulseAudio or with Fedora's implementation of
> it (though I think I'm leaning towards the latter, since I haven't noticed
> this on any other Linux distro.  But then, I don't think I've used the
> 0.9.7SVN sources on any other distro, either).

Red Hat employs Lennart Poeterring, who wrote PulseAudio.  And given 
that we're tracking the upstream SVN version, I'd say this is not 
Fedora-specific.  More likely is just that we're using a newer snapshot 
of sources to fix other bugs which has the unfortunate side effect of 
breaking you.  WFM, at least.



From caillon at redhat.com  Thu Oct 25 08:58:56 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 25 Oct 2007 04:58:56 -0400
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <1193244774.19243.9.camel@localhost6.localdomain6>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
Message-ID: <47205AD0.4030306@redhat.com>

Richi Plana wrote:
> Hi,
> 
> It looks like firefox-2.0.0.8 finally made it to F7 updates.
> Unfortunately, this breaks a couple of dependencies (for me, Miro,
> gnome-gtk2-gtkmozembed, yelp and devhelp).

I built some of these just forgot to push them.  Mea culpa.  I think 
they ought to be fixed by now.



From mschwendt.tmp0701.nospam at arcor.de  Thu Oct 25 08:17:17 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 25 Oct 2007 10:17:17 +0200
Subject: rebuilding galeon and/or Miro (was Re: firefox-2.0.0.8 Upgrade
 Problems in F7)
In-Reply-To: <6p3avziwo9.fsf_-_@allele2.eebweb.arizona.edu>
References: <1193244774.19243.9.camel@localhost6.localdomain6>
	<1193245059.19243.14.camel@localhost6.localdomain6>
	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>
	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
	<1193264638.23316.40.camel@localhost6.localdomain6>
	<0qd4v3iylt.fsf@allele2.eebweb.arizona.edu>
	<6p3avziwo9.fsf_-_@allele2.eebweb.arizona.edu>
Message-ID: <20071025101717.7adb3736.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 24 Oct 2007 22:35:18 -0700, Alex Lancaster wrote:

> In the interests of getting these security updates up quickly, I'm
> taking the liberty to rebuild galeon against the new firefox (I've had
> a fair bit of experience rebuilding this application before) .  I'm
> currently doing a scratch build in koji, let me know if this isn't OK
> with anyone.
> 
> I'll also do Miro if nobody screams at me.
> 
> (PS.  I can't see any pending builds in koji and/or CVS action that
> would imply that the current maintainers of these packages are aware
> of the change firefox at the moment.)

"Being aware of" and "working on it" are two different things.

Yesterday's list of firefox/gecko breakage is this, btw:

blam
chmsee
devhelp
epiphany-extensions
galeon
gnome-python2-gtkmozembed
gtkmozembedmm
lifera
Miro
openvrml
openvrml-devel
ruby-gtkmozembed
yelp



From braden at endoframe.com  Thu Oct 25 09:18:25 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Thu, 25 Oct 2007 05:18:25 -0400
Subject: No Package Found for curl-devel
In-Reply-To: <20071025064732.GA2884@dhcp-lab-186.brq.redhat.com>
References: <1193275560.3300.26.camel@hinge.endoframe.net>
	<loom.20071025T021802-754@post.gmane.org>
	<20071025064732.GA2884@dhcp-lab-186.brq.redhat.com>
Message-ID: <1193303905.3300.28.camel@hinge.endoframe.net>

On Thu, 2007-10-25 at 08:47 +0200, Jindrich Novy wrote:
> On Thu, Oct 25, 2007 at 02:18:54AM +0000, Kevin Kofler wrote:
> > Braden McDaniel <braden <at> endoframe.com> writes:
> > >         No Package Found for curl-devel
> > 
> > > Do I just try again later?
> >
> It should work just fine now as the virtual provides curl-devel was
> added to libcurl-devel & built yesterday.

And it did, thanks.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From buildsys at fedoraproject.org  Thu Oct 25 09:31:41 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 25 Oct 2007 05:31:41 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-25
Message-ID: <20071025093141.8E06815212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 9

NEW comgt-0.32-1.fc6 : Linux UMTS/GPRS command-line tool
NEW cpl-3.1-2.fc6 : ESO library for automated astronomical data-reduction tasks
    mirage-0.9-1.fc6
NEW perl-SQL-Translator-0.08001-2.fc6 : Manipulate structured data definitions (SQL and more)
NEW perl-Template-Alloy-1.007-3.fc6 : Templating tool supporting multiple markup formats
NEW qlandkarte-0.5.3-4.fc6 : A tool to visualize maps and other GPS information for Garmin devices
    smolt-0.9.9.1-4.fc6
NEW xgrav-1.2.0-4.fc6 : A simple physics simulation for a large number of particles
    xpa-2.1.7-0.3.b2.fc6


Changes in Fedora Extras 6: 


comgt-0.32-1.fc6
----------------
* Wed Jun 27 2007 Dominik Mierzejewski <rpm at greysector.net> 0.32-1
- initial build

cpl-3.1-2.fc6
-------------
* Tue Oct 09 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-2
- Updated qfits patch to build in 64 bits systems

* Tue Sep 25 2007 Sergio Pascual <sergiopr at fedoraproject.org> 3.1-1
- Minor changes

mirage-0.9-1.fc6
----------------
* Fri Oct 19 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.9-1
- 0.9

* Wed Aug 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.3-2.dist.2
- Mass rebuild (buildID or binutils issue)

* Fri Aug 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.3-2.dist.1
- License update

* Fri Jun 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.3-2
- Remove Version= entry (on F-8+)

perl-SQL-Translator-0.08001-2.fc6
---------------------------------
* Wed Oct 24 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.08001-2
- bump

* Sun Oct 14 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.08001-1
- updated to 0.08001
- update license tag
- nix errant perl(Producer::BaseTest) provides
- make description useful :)
- we now skip Template::Toolkit tests correctly, so stop disabling them

perl-Template-Alloy-1.007-3.fc6
-------------------------------
* Wed Oct 24 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.007-3
- bump

* Wed Oct 24 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.007-2
- update summary tag

* Mon Oct 15 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.007-1
- update to 1.007
- update license tag: GPL -> GPL+

qlandkarte-0.5.3-4.fc6
----------------------
* Mon Oct 22 2007 Douglas E. Warner <silfreed at silfreed.net> 0.5.3-4
- including icon for desktop file
- disabling parallel make flags

* Mon Oct 22 2007 Douglas E. Warner <silfreed at silfreed.net> 0.5.3-3
- spec file patches and desktop file by Dan Horak <dan at danny.cz>
  GPLv2+
  desktop file
  use sed to cleanup problems in makefile
  additional BuildRequires

* Sat Oct 20 2007 Douglas E. Warner <silfreed at silfreed.net> 0.5.3-2
- cleanup for inclusion in Fedora

smolt-0.9.9.1-4.fc6
-------------------
* Tue Oct 23 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9.1-4
- Upstream released new version

* Thu Oct 18 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9-2
- Fixed /etc/smolt/ ownership issue

xgrav-1.2.0-4.fc6
-----------------
* Wed Oct 17 2007 Jon Ciesla <limb at jcomserv.net> - 1.2.0-4
- Removed duplicate file listing.
- Re-added zlib-devel BR.

* Tue Oct 16 2007 Jon Ciesla <limb at jcomserv.net> - 1.2.0-3
- Fixed build.
- Preserved source timestamp.

* Tue Oct 16 2007 Jon Ciesla <limb at jcomserv.net> - 1.2.0-2
- Changing optflag method, dropped zlib-devel BR.
- Sited icon source, dropped .png from .desktop icon name.
- .desktop now honors macros.
- Preserved timestamps.
- Consistentified buildroot macro.

* Mon Oct 15 2007 Jon Ciesla <limb at jcomserv.net> - 1.2.0-1
- create.

xpa-2.1.7-0.3.b2.fc6
--------------------
* Sat Oct 13 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 2.1.7-0.3.b2
- Splitted libraries in a new package

* Mon Aug 27 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.7-0.2.b2.1
- Added /bin/awk to BuildReq

* Mon Aug 27 2007 Sergio Pascual <spr at astrax.fis.ucm.es> 2.1.7-0.2.b2
- Rebuild for Fedora 8 to get the build-id



From buildsys at redhat.com  Thu Oct 25 09:36:29 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 25 Oct 2007 05:36:29 -0400
Subject: rawhide report: 20071025 changes
Message-ID: <200710250936.l9P9aTit011970@porkchop.devel.redhat.com>

New package compizconfig-python
	Python bindings for the Compiz Configuration System

New package ql2100-firmware
	Firmware for qlogic 2100 devices

New package ql2200-firmware
	Firmware for qlogic 2200 devices

New package ql23xx-firmware
	Firmware for qlogic 23xx devices

New package ql2400-firmware
	Firmware for qlogic 2400 devices


 
Updated Packages:

NetworkManager-1:0.7.0-0.3.svn3020.fc8
--------------------------------------
* Wed Oct 24 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn3020
- Fix WPA Enterprise connections that use certificates
- Better display of SSIDs in the menu

* Wed Oct 24 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn3016
- Fix getting current access point
- Fix WPA Enterprise connections
- Wireless dialog now defaults to sensible choices based on the connection
- Tell nscd to restart if needed, don't silently kill it

control-center-1:2.20.1-5.fc8
-----------------------------
* Wed Oct 24 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-5
- Fix the orca command in the default applications capplet (#351471)

* Fri Oct 19 2007 - Ray Strode <rstrode at redhat.com> - 2.20.1-4
- Update libxklavier buildreq (bug 339731)

dhcp-12:3.0.6-10.fc8
--------------------
* Wed Oct 24 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-10
- Fix 'restart' mode in init script (#349341)
- Make sure restorecon is run on /var/lib/dhcpd/dhcpd.leases (#251688)

* Tue Oct 23 2007 David Cantrell <dcantrell at redhat.com> - 12:3.0.6-9
- Add missing /etc/openldap/dhcp.schema file (#330471)

emacs-22.1-6.fc8
----------------
* Wed Oct 24 2007 Jeremy Katz <katzj at redhat.com> - 22.1-6
- Update rpm-spec-mode to the current upstream (#306841)

* Wed Sep 12 2007 Chip Coldwell <coldwell at redhat.com> - 22.1-5
- require xorg-x11-fonts-ISO8859-1-100dpi instead of 75dpi (Resolves: bz281861)
- drop broken python mode (Resolves: bz262801)

* Mon Sep 10 2007 Chip Coldwell <coldwell at redhat.com> - 22.1-4
- fix pkgconfig path (from pkg-config to pkgconfig (Jonathan Underwood)
- use macro instead of variable style for buildroot.

epiphany-extensions-2.20.1-2.fc8
--------------------------------
* Tue Oct 23 2007 Jeremy Katz <katzj at redhat.com>- 2.20.1-2
- Rebuild for new firefox

fedora-release-notes-8.0.0-2
----------------------------
* Wed Oct 24 2007 Paul W. Frields <stickster at gmail.com> - 8.0.0-2
- Fix leftover draft notice on local startpage copy (#350801)

gnokii-0.6.18-2.fc8
-------------------
* Tue Oct 23 2007 - Jeremy Katz <katzj at redhat.com> - 0.6.18-2
- Quick fix to multilib conflict (#335161)

kdebase4-3.94.0-1.fc8
---------------------
* Fri Oct 19 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.94.0-1
- update to 3.94.0

* Thu Oct 04 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-5
- don't make this the default kdebase on F9 yet
- drop ExcludeArch: ppc64 (#300601)

* Fri Sep 21 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-4
- ExcludeArch: ppc64 (#300601)
- update description

kdelibs4-3.94.0-2.fc8
---------------------
* Thu Oct 18 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.94.0-2
- drop optional BR hspell-devel again due to broken x86_64 static library

* Thu Oct 18 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.94.0-1
- update to 3.94.0
- BR soprano-devel >= 1.95.0
- don't rename js to kjs after installation, fixed upstream
- update parallel-devel patch
- drop kde#149704 patch, fixed upstream
- drop colorscheme-hack patch
- backport upstream fix for unversioned kpty library (rev 724528)
- add new BRs hspell-devel and jasper-devel
- 3.94.0 generates some manpages, add them to the file list

* Thu Oct 04 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.93.0-11
- don't make this the default kdelibs on F9 yet
- retry ppc64 build (#300571)

kdepimlibs-3.94.0-1.fc8
-----------------------
* Thu Oct 18 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.94.0-1
- update to 3.94.0
- add new %{_kde4_libdir}/Gpgmepp directory to file list

libcompizconfig-0.6.0-3.fc8
---------------------------
* Wed Oct 24 2007 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.6.0-3
- -devel requires compiz-devel >= version

* Wed Oct 24 2007 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.6.0-2
- >= instead of = to allow compiz upgrade flexibility

* Tue Oct 23 2007 Mohd Izhar Firdaus Ismail <mohd.izhar.firdaus at gmail.com> 0.6.0-1
- official 0.6.0 release

libraw1394-1.3.0-3.fc8
----------------------
* Wed Oct 24 2007 Jarod Wilson <jwilson at redhat.com> - 1.3.0-3
- Update firewire-cdev.h to match kernel and eliminate
  bitfield usage, fixes capture on big-endian systems (#345221)

libtheora-0:1.0beta2-2.fc8
--------------------------
* Wed Oct 24 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0beta2-2
- Put Obsoletes/Provides theora-exp-devel in the -devel package instead of in
  the -tools package (oops)
- Install png2theora (bz 349951)

liferea-1.2.23-4.fc8
--------------------
* Wed Oct 24 2007 Jeremy Katz <katzj at redhat.com> - 1.2.23-4
- Fix build against new NetworkManager

memtest86+-1.70-4.fc8
---------------------
* Wed Oct 24 2007 Peter Jones <pjones at redhat.com> - 1.70-4
- Fix mactel support.

python-2.5.1-14.fc8
-------------------
* Wed Oct 24 2007 James Antill <jantill at redhat.com> - 2.5.1-14
- Remove bintuils dep. for live CD ... add work around for ctypes

* Mon Oct 22 2007 James Antill <jantill at redhat.com> - 2.5.1-13
- Add tix buildprereq
- Add tkinter patch
- Resolves: #281751
- Fix ctypes loading of libraries, add requires on binutils
- Resolves: #307221
- Possible fix for CVE-2007-4965 possible exploitable integer overflow
- Resolves: #295971

* Tue Oct 16 2007 Mike Bonnet <mikeb at redhat.com> - 2.5.1-12
- fix marshalling of objects in xmlrpclib (python bug #1739842)

selinux-policy-3.0.8-32.fc8
---------------------------
* Wed Oct 24 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-32
- Dontaudit mail programs looking at munin_var_lib

* Tue Oct 23 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-31
- Fixes for vmware
- Additional textrel_shlib_t for codecs

soprano-1.95.0-1.fc8
--------------------
* Tue Oct 16 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.95.0-1
- update to 1.95.0 (Soprano 2 beta 2)
- new BRs clucene-core-devel, raptor-devel >= 1.4.15
- now need redland-devel >= 1.0.6
- add patch to find CLucene (clucene-config.h is moved in the Fedora package)
- new Requires: pkg-config for -devel

wpa_supplicant-1:0.5.7-12.fc8
-----------------------------
* Wed Oct 24 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-12
- Fix conversion of byte arrays to strings by ensuring the buffer is NULL
    terminated after conversion

* Sat Oct 20 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-11
- Add BLOB support to the D-Bus interface
- Fix D-Bus interface permissions so that only root can use the wpa_supplicant
    D-Bus interface

Broken deps for i386
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.i386 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.i386 requires firefox = 0:2.0.0.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.i386 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	openvrml - 0.16.6-4.fc8.i386 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.i386 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10
	ruby-gtkmozembed - 0.16.0-12.fc8.i386 requires firefox = 0:2.0.0.6



Broken deps for x86_64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.x86_64 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.x86_64 requires firefox = 0:2.0.0.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.x86_64 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	openvrml - 0.16.6-4.fc8.i386 requires firefox = 0:2.0.0.6
	openvrml - 0.16.6-4.fc8.x86_64 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.x86_64 requires firefox-devel = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.i386 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)
	ruby-gtkmozembed - 0.16.0-12.fc8.x86_64 requires firefox = 0:2.0.0.6



Broken deps for ppc
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.ppc requires firefox = 0:2.0.0.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.ppc requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	openvrml - 0.16.6-4.fc8.ppc64 requires firefox = 0:2.0.0.6
	openvrml - 0.16.6-4.fc8.ppc requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc requires firefox-devel = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc64 requires firefox-devel = 0:2.0.0.6
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10
	ruby-gtkmozembed - 0.16.0-12.fc8.ppc requires firefox = 0:2.0.0.6



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.8.1-6.fc8.ppc64 requires firefox = 0:2.0.0.6
	chmsee - 1.0.0-1.24.fc8.ppc64 requires firefox = 0:2.0.0.6
	gnome-python2-gtkmozembed - 2.19.1-7.fc8.ppc64 requires firefox = 0:2.0.0.6
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump
	openvrml - 0.16.6-4.fc8.ppc64 requires firefox = 0:2.0.0.6
	openvrml-devel - 0.16.6-4.fc8.ppc64 requires firefox-devel = 0:2.0.0.6
	ruby-gtkmozembed - 0.16.0-12.fc8.ppc64 requires firefox = 0:2.0.0.6





From pbrobinson at gmail.com  Thu Oct 25 10:11:01 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 25 Oct 2007 11:11:01 +0100
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
Message-ID: <5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>

> I followed instructions for installing fluendo mega codec pack and
> copied all files to
> /usr/lib/gstreamer-0.10/ under Fedora 8 test 3 (with latest updates)
> but whenever I try to open different video files I still get message
> from Totem that I need to go to fluendo site and get codecs...
>
> I then copied files also to ~/.gstreamer-0.10/plugins directory but
> that doesn't help either...
>
> Any ideas? Should I file a bug? Am I doing something wrong?

Does gst-inspect report the codecs? what about if you put them in a
plugins directory in the .gstreamer (I think that's the one - not on
my linux box atm) in your home dir. This is what I've done and they
seem to work for me with basic testing.

Pete



From kevin.kofler at chello.at  Thu Oct 25 10:55:41 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 10:55:41 +0000 (UTC)
Subject: Development to Official
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
Message-ID: <loom.20071025T104150-827@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> What's a few days extra?  A few days of extra testing for F9 on the 
> features that didn't quite make it into F8, such as intlclock.  Or a few 
> days of testing some bugfixes, such as NetworkManager fixes, in F9 
> packages before they make it in to F8-updates.  With all the "few days 
> here" because of test freezes, we've maybe lost a month or so of testing 
> in the F8 cycle -- out of 6 months.

I have one possible suggestion (at least for F9+, it's probably too late for 
F8) for this problem (maybe worthy of its own thread? Anyway, here it is):
* make updates-testing available early, e.g. as soon as builds for the new 
release go to dist-f*-updates-candidate,
* if a direct push to stable was requested, but the stable updates haven't been 
opened yet, make the updates go through testing anyway, and automatically push 
them as 0-day stable updates unless they have been unpushed or the move request 
revoked. (Alternatively, the stable updates could be opened early too, but it 
just doesn't make sense to me to declare updates "stable" before the release.)
* Of course, start doing regular test update pushes for the new release as soon 
as updates-testing is opened.

The advantages and drawbacks of this approach as I see them:
+ 0-day updates would be able to get some testing.
+ Rawhide users would be able to reliably get security updates even during the 
freeze. (Right now, they only show up in Rawhide if tagged f8-final.)
- Less testing for the packages which show up in the frozen release (because 
testers will be split between f*-final and f*-final + updates-testing).

Any comments/feedback? (Feedback from all of: release engineering, packagers 
and Rawhide users is welcome!)

        Kevin Kofler



From dcbw at redhat.com  Thu Oct 25 11:31:29 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 25 Oct 2007 07:31:29 -0400
Subject: NetworkManager-0.7.0-0.3.svn3016.fc8 selinux problem
In-Reply-To: <1193286713.6343.3.camel@zebes.localdomain>
References: <1193256199.5029.3.camel@tiger>
	<1193286713.6343.3.camel@zebes.localdomain>
Message-ID: <1193311889.3972.0.camel@localhost.localdomain>

On Thu, 2007-10-25 at 00:31 -0400, Will Woods wrote:
> On Wed, 2007-10-24 at 16:03 -0400, Louis E Garcia II wrote:
> > NetworkManager can't connect to wireless and quits because:
> > 
> > SELinux is preventing NetworkManager (NetworkManager_t) "execute" to
> > (nscd_exec_t).
> 
> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=351671
> 
> I'm told selinux-policy-3.0.8-32.fc8 (which should be in tomorrow's
> rawhide) fixes it, although the changelog doesn't mention it
> specifically. It seems to work just fine in my testing, though.

You shouldn't notice any effects from this bug unless you run nscd.  It
should be fixed today in a policy update.

Dan



From pp at ee.oulu.fi  Thu Oct 25 11:34:11 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Thu, 25 Oct 2007 14:34:11 +0300
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471F8FDB.8070405@codewiz.org>
References: <200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
	<471F8FDB.8070405@codewiz.org>
Message-ID: <20071025113411.GA19744@ee.oulu.fi>

On Wed, Oct 24, 2007 at 02:32:59PM -0400, Bernardo Innocenti wrote:
> On 10/24/07 13:09, Alan Cox wrote:
> >On Wed, Oct 24, 2007 at 12:14:04PM -0400, Bernardo Innocenti wrote:
> >>Please, let's not add an external dependency for something
> >>as trivial as a SHA1.
> >
> >The positives to adding an external dependancy are you only have
> >to worry about bugs in one implementation.
> 
> That's right, in general.
> 
> But in this specific case, we're talking about adding a bulky
> library and all of its dependencies to Python just to save 25
> lines of duplicated code.
Well, the point isn't saving 25 lines of code, the point is also having 
something that is certified to do SHA1 correctly. The 25 line version
isn't, even though it very likely is just as good... 

Now, having NSS depend on something small & tiny & certified for sha1
(even if it's nss-hashes inside the same tarball that could be split up
with rpm) that other stuff could use as well might be useful.
No idea what chance of that happening ever there is...

-- 
Pekka Pietikainen



From jkeating at redhat.com  Thu Oct 25 12:07:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 08:07:15 -0400
Subject: Development to Official
In-Reply-To: <loom.20071025T104150-827@post.gmane.org>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
Message-ID: <20071025080715.5e0bdf1e@redhat.com>

On Thu, 25 Oct 2007 10:55:41 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> I have one possible suggestion (at least for F9+, it's probably too
> late for F8) for this problem (maybe worthy of its own thread?
> Anyway, here it is):
> * make updates-testing available early, e.g. as soon as builds for
> the new release go to dist-f*-updates-candidate,

This has a set of problems.

A) signing packages.  This can somewhat be mitigated by using a signing
server (which work is developing on), however for a while I'm not going
to feel comfortable hooking up some automated process to sign packages.

B) potential for broken deps.  As we see from rawhide, or even updates
today, deps can and will break often.  Doing a full proper depcheck of
all release + updates + potential testing updates takes a good long
time due to having to figure out the multilib set.  This can be made
better by stop pre-calculating multilib but that isn't here yet and may
not be for a while.

C) mirror churn.  It's hard enough to keep mirrors updated when we only
push a couple times a day.  If we were to churn the repo on demand we'd
likely never see up to date mirrors and mirrormanager would be
constantly dropping mirrors from the list.

> * if a direct push to stable was requested, but the stable updates
> haven't been opened yet, make the updates go through testing anyway,
> and automatically push them as 0-day stable updates unless they have
> been unpushed or the move request revoked. (Alternatively, the stable
> updates could be opened early too, but it just doesn't make sense to
> me to declare updates "stable" before the release.)
> * Of course, start doing regular test update pushes for the new
> release as soon as updates-testing is opened.

This is a bit more reasonable, and I actually planned to do an updates
push (both final and testing) prior to F8 going live.  This is to
pre-populate the mirrors with update content and give folks who do
network installs a chance to install directly to the 0day updates
rather than waiting a day.

I'm not sure if we want to force final updates into testing, nor how
early to do this.  If we do release too early, we get people testing
the release /plus/ the updates and missing glaring issues that may be
in the release itself.

> 
> The advantages and drawbacks of this approach as I see them:
> + 0-day updates would be able to get some testing.
> + Rawhide users would be able to reliably get security updates even
> during the freeze. (Right now, they only show up in Rawhide if tagged
> f8-final.)

Which every security update that has been requested for Fedora 8 has
been tagged.  We take these things seriously and tag them as soon as we
can.  Once we stop taking in builds for the release seems like a great
time to open up the update repos.

> - Less testing for the packages which show up in the frozen release
> (because testers will be split between f*-final and f*-final +
> updates-testing).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/62f379f4/attachment.sig>

From kevin.kofler at chello.at  Thu Oct 25 12:50:30 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 12:50:30 +0000 (UTC)
Subject: Development to Official
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
Message-ID: <loom.20071025T124330-888@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> > * make updates-testing available early, e.g. as soon as builds for
> > the new release go to dist-f*-updates-candidate,
> 
> This has a set of problems.
> 
> A) signing packages.  This can somewhat be mitigated by using a signing
> server (which work is developing on), however for a while I'm not going
> to feel comfortable hooking up some automated process to sign packages.
> 
> B) potential for broken deps.  As we see from rawhide, or even updates
> today, deps can and will break often.  Doing a full proper depcheck of
> all release + updates + potential testing updates takes a good long
> time due to having to figure out the multilib set.  This can be made
> better by stop pre-calculating multilib but that isn't here yet and may
> not be for a while.
> 
> C) mirror churn.  It's hard enough to keep mirrors updated when we only
> push a couple times a day.  If we were to churn the repo on demand we'd
> likely never see up to date mirrors and mirrormanager would be
> constantly dropping mirrors from the list.

My idea wasn't to handle updates-testing like Rawhide, but like updates-testing 
for a release.

> I'm not sure if we want to force final updates into testing, nor how
> early to do this.  If we do release too early, we get people testing
> the release /plus/ the updates and missing glaring issues that may be
> in the release itself.

Right, that's the main drawback.

> Which every security update that has been requested for Fedora 8 has
> been tagged.  We take these things seriously and tag them as soon as we
> can.  Once we stop taking in builds for the release seems like a great
> time to open up the update repos.

There are 4 security updates in the pending updates queue for F8, for example 
seamonkey-1.1.5-2.fc8 is sitting there (requested as a stable update, not 
tagged f8-final). The others are: python-2.5.1-13.fc8 (requested: stable), 
tar-1.17-4.fc8 (requested: stable) and openvrml-0.16.6-5.fc8 (requested: 
testing). So there might be some miscommunication there (maintainers not asking 
for f8-final tagging for security updates).

        Kevin Kofler



From jkeating at redhat.com  Thu Oct 25 12:54:13 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 08:54:13 -0400
Subject: Development to Official
In-Reply-To: <loom.20071025T124330-888@post.gmane.org>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<loom.20071025T124330-888@post.gmane.org>
Message-ID: <20071025085413.19dec15c@redhat.com>

On Thu, 25 Oct 2007 12:50:30 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

>  So there might be some miscommunication there (maintainers not
> asking for f8-final tagging for security updates).

That's most likely the case, or they are not remotely exploitable or
otherwise low impact "security" issues.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/5c64fe69/attachment.sig>

From ssorce at redhat.com  Thu Oct 25 13:15:01 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 25 Oct 2007 09:15:01 -0400
Subject: nautilus/GNOME VFS ACL support capabilities?
In-Reply-To: <1193298155.3393.85.camel@perihelion>
References: <1193298155.3393.85.camel@perihelion>
Message-ID: <1193318101.15848.0.camel@localhost.localdomain>

On Thu, 2007-10-25 at 03:42 -0400, Jon Masters wrote:
> Yo,
> 
> Rather than sleeping, I was just looking at a few capabilities currently
> in F8 and thinking about what would be nice in the future.
> 
> Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
> to understand ACLs. Am I missing something? Heck, I remember 5 or 6
> years ago patching in the original ACL patches from bestbits and even
> setting ACLs remotely from a Windows machine using Samba, by right
> clicking on the export files. Does this not work in nautilus?


yum install eiciel

(and it would be nice to have it installed by default now that we enable
xattrs/acls by default on file systems).

Simo.



From fedora at leemhuis.info  Thu Oct 25 13:19:15 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 25 Oct 2007 15:19:15 +0200
Subject: catching broken deps (was: Re: Development to Official)
In-Reply-To: <20071025080715.5e0bdf1e@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
Message-ID: <472097D3.8060604@leemhuis.info>

On 25.10.2007 14:07, Jesse Keating wrote:

> B) potential for broken deps.  As we see from rawhide, or even updates
> today, deps can and will break often.  Doing a full proper depcheck of
> all release + updates + potential testing updates takes a good long
> time due to having to figure out the multilib set. 

Just thinking aloud:

Depends on how you do it. The most usual case that introduces broken
deps is a update to libfoo, where the new packages ships libfoo.so.2
while the old shipped libfoo.so.1 That one can esily be catched within
seconds:

[thl at thl ~]$ rpm -qp libupnp-1.4.6-1.fc7.i386.rpm --requires > 1
[thl at thl ~]$ rpm -qp libupnp-1.6.0-1.fc7.i386.rpm --requires > 2
[thl at thl ~]$ grep -v -f 2 1
libupnp.so.2
[thl at thl ~]$ repoquery -q --whatrequires libupnp.so.2
[thl at thl ~]$ # here we would see packages that still need libupnp.so.2

Takes just a few seconds. Maybe we should tech bodhi should do such a
basic check? That would catch most errors.

Or even better would be to let the buildsys do this and similar checks
(rpmlint!) after each build and tell the maintainers if something
changed. I'd like that.

CU
knurd



From jkeating at redhat.com  Thu Oct 25 13:26:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 09:26:43 -0400
Subject: catching broken deps (was: Re: Development to Official)
In-Reply-To: <472097D3.8060604@leemhuis.info>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
Message-ID: <20071025092643.25f3349d@redhat.com>

On Thu, 25 Oct 2007 15:19:15 +0200
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Takes just a few seconds. Maybe we should tech bodhi should do such a
> basic check? That would catch most errors.
> 
> Or even better would be to let the buildsys do this and similar checks
> (rpmlint!) after each build and tell the maintainers if something
> changed. I'd like that.

Doesn't work when you have to take multilib into account, and you have
to use that new library to determine the multilib set.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/2f018bd2/attachment.sig>

From j.w.r.degoede at hhs.nl  Thu Oct 25 13:29:06 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 15:29:06 +0200
Subject: catching broken deps
In-Reply-To: <20071025092643.25f3349d@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>	<20071025080715.5e0bdf1e@redhat.com>	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com>
Message-ID: <47209A22.6080403@hhs.nl>

Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:19:15 +0200
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>> Takes just a few seconds. Maybe we should tech bodhi should do such a
>> basic check? That would catch most errors.
>>
>> Or even better would be to let the buildsys do this and similar checks
>> (rpmlint!) after each build and tell the maintainers if something
>> changed. I'd like that.
> 
> Doesn't work when you have to take multilib into account, and you have
> to use that new library to determine the multilib set.
> 

I'm much in favor of more automated checks like this too. I would even like to 
see them because build failures, were the packager gets some method to override 
them (for example a list of regular expressions of rpmlint messages which 
should be ignored by this check).

Jesse,

Could you explain why this won't work with mutlilib?

Regards,

Hans



From lightsolphoenix at gmail.com  Thu Oct 25 13:34:53 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 25 Oct 2007 09:34:53 -0400
Subject: Current problems with Rawhide
In-Reply-To: <47205A74.5020205@redhat.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
	<a785db460710241011t3419b999vfe52626850b3ca96@mail.gmail.com>
	<47205A74.5020205@redhat.com>
Message-ID: <a785db460710250634t8513784ia474b7158e8bc5b@mail.gmail.com>

On 10/25/07, Christopher Aillon <caillon at redhat.com> wrote:

> Red Hat employs Lennart Poeterring, who wrote PulseAudio.  And given
> that we're tracking the upstream SVN version, I'd say this is not
> Fedora-specific.  More likely is just that we're using a newer snapshot
> of sources to fix other bugs which has the unfortunate side effect of
> breaking you.  WFM, at least.



Yeah, possibly.  I'm starting to wonder if this is actually an ALSA error,
since that seems to be where the problem is originating; I only see it
through PulseAudio because PulseAudio is the only program that uses ALSA
directly...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/bc86618c/attachment.htm>

From dcbw at redhat.com  Thu Oct 25 13:35:30 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 25 Oct 2007 09:35:30 -0400
Subject: F8 blocker bug status report - testers needed!
In-Reply-To: <1193264245.3639.9.camel@dawkins>
References: <1193260740.9430.35.camel@metroid.rdu.redhat.com>
	<1193264245.3639.9.camel@dawkins>
Message-ID: <1193319330.5542.0.camel@localhost.localdomain>

On Thu, 2007-10-25 at 00:17 +0200, David Nielsen wrote:
> ons, 24 10 2007 kl. 17:19 -0400, skrev Will Woods:
> 
> > * Bug 311511: NEEDINFO - dcbw at redhat.com
> > - x86_64 iwl3945 NM crash after Keyring loop Deny
> > 
> > A fix for this has been committed, we're waiting for the reporter to
> > confirm. If you can confirm this fix, that would help.
> 
> I'll give that one a bit of abuse tomorrow, also sorry about sleeping
> through the meeting, I swear I had a legimate excuse, I spend all night
> closing old bugs.

Would be good to get visibility into the keyring interactions here,
especially between the login keyring and the default keyring, when NM
asks for the keyring password, and what happens when you deny NM.

Dan




From fedora at camperquake.de  Thu Oct 25 13:38:22 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 25 Oct 2007 15:38:22 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
Message-ID: <47209C4E.3000903@camperquake.de>

Hi.

King InuYasha schrieb:
> Isn't that basically what all binaries do? Use libraries and execute the
> code natively on the CPU?

Not if we are talking emulators.

The finer point of this thread is whether it is permissible to ship
binary only, executable content in Fedora, as long as these binaries
are not executed on the main CPU. There is precedent in the form of
firmware, which executes on some hardware subsystem (the WLAN card,
for example), which we allow.

Now someone threw Win32 binaries into the pool, which are, however,
not the same kind of beast, since they _do_ execute, natively, at least
in part, on the main CPU. That they require WINE to run at all does not
change that.

Then there is the third group of binaries for non host native binaries
(for example, arcade ROM files) which do not execute on the main CPU,
since they were written for a completely different hardware (again,
for example, Motorola 68xxx CPUs). Apart from copyright concerns,
would this be permissible? The binary would not run on the main CPU,
but on a virtual one, which is provided by an emulator (which, in turn,
does run on the main CPU).



From jkeating at redhat.com  Thu Oct 25 13:38:06 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 09:38:06 -0400
Subject: catching broken deps
In-Reply-To: <47209A22.6080403@hhs.nl>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com> <47209A22.6080403@hhs.nl>
Message-ID: <20071025093806.7fc68146@redhat.com>

On Thu, 25 Oct 2007 15:29:06 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> I'm much in favor of more automated checks like this too. I would
> even like to see them because build failures, were the packager gets
> some method to override them (for example a list of regular
> expressions of rpmlint messages which should be ignored by this
> check).
> 
> Jesse,
> 
> Could you explain why this won't work with mutlilib?

Because of the way we do multilib generation a very long process is
involved to re-determine with the new package set exactly what is
multilib and if this new determination would bring in anything new
and/or lead to broken deps.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/6757c99e/attachment.sig>

From jkeating at redhat.com  Thu Oct 25 13:40:10 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 09:40:10 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <47209C4E.3000903@camperquake.de>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
	<47209C4E.3000903@camperquake.de>
Message-ID: <20071025094010.2a7afb7e@redhat.com>

On Thu, 25 Oct 2007 15:38:22 +0200
Ralf Ertzinger <fedora at camperquake.de> wrote:

> Then there is the third group of binaries for non host native binaries
> (for example, arcade ROM files) which do not execute on the main CPU,
> since they were written for a completely different hardware (again,
> for example, Motorola 68xxx CPUs). Apart from copyright concerns,
> would this be permissible? The binary would not run on the main CPU,
> but on a virtual one, which is provided by an emulator (which, in
> turn, does run on the main CPU).

That's cheating IMHO.  That's like saying a .jar file doesn't execute
on the system CPU because the JVM executes it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/5b83eff1/attachment.sig>

From kevin.kofler at chello.at  Thu Oct 25 13:46:28 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 13:46:28 +0000 (UTC)
Subject: catching broken deps
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com> <47209A22.6080403@hhs.nl>
	<20071025093806.7fc68146@redhat.com>
Message-ID: <loom.20071025T134450-352@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> Because of the way we do multilib generation a very long process is
> involved to re-determine with the new package set exactly what is
> multilib and if this new determination would bring in anything new
> and/or lead to broken deps.

But wouldn't an approximation which ignores multilib, such as doing the checks 
only on non-multilib arches or even only on a single non-multilib arch (i.e. 
i386), be better than no checks at all?

        Kevin Kofler



From j.w.r.degoede at hhs.nl  Thu Oct 25 13:50:09 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 15:50:09 +0200
Subject: catching broken deps
In-Reply-To: <20071025093806.7fc68146@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>	<20071025080715.5e0bdf1e@redhat.com>	<472097D3.8060604@leemhuis.info>	<20071025092643.25f3349d@redhat.com>
	<47209A22.6080403@hhs.nl> <20071025093806.7fc68146@redhat.com>
Message-ID: <47209F11.4030205@hhs.nl>

Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:29:06 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> I'm much in favor of more automated checks like this too. I would
>> even like to see them because build failures, were the packager gets
>> some method to override them (for example a list of regular
>> expressions of rpmlint messages which should be ignored by this
>> check).
>>
>> Jesse,
>>
>> Could you explain why this won't work with mutlilib?
> 
> Because of the way we do multilib generation a very long process is
> involved to re-determine with the new package set exactly what is
> multilib and if this new determination would bring in anything new
> and/or lead to broken deps.
> 

Ah, but Thorsten (and I in the release-schedule discussion) are not talking 
about doing a full check, the idea is like this:
1) What does the version of package foo currently in the repo provide?
    Lets say it provides libbar.so.1 and libbaz.so.2
2) What does the just build version provide?
    Lets say it provides libbar.so.1 and libbaz.so.3
3) Is everything provided by the version of package foo currently in the repo
    provided by the newly build version of pakcage foo?
    In our example: no, libbaz.so.2 no longer gets provided
4) If the answer to 3 is no, flag this as a warning / error
    (suggestion make it a warning to the maintainer in devel (non RC freeze) and
    make it an error in stable / frozen branches *.

You see, we (Thorsten and me) do not want to make this 100% bullet proof, we 
just want to do some cheap (in computing time) checks which should catch a > 
50% percentage of all breakages.

* Packages with this error would get a special tag and rel-eng can override 
this for things like firefox updates, etc. But normally we do not want provides 
to go away with updates to a release.

Regards,

Hans



From jkeating at redhat.com  Thu Oct 25 13:55:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 09:55:35 -0400
Subject: catching broken deps
In-Reply-To: <loom.20071025T134450-352@post.gmane.org>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com> <47209A22.6080403@hhs.nl>
	<20071025093806.7fc68146@redhat.com>
	<loom.20071025T134450-352@post.gmane.org>
Message-ID: <20071025095535.0a30ac7a@redhat.com>

On Thu, 25 Oct 2007 13:46:28 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> But wouldn't an approximation which ignores multilib, such as doing
> the checks only on non-multilib arches or even only on a single
> non-multilib arch (i.e. i386), be better than no checks at all?

Yes, there is room for improvement.  Don't let me sound like it has to
be perfect.  All it takes is code, and time...

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/62f4c5a8/attachment.sig>

From jkeating at redhat.com  Thu Oct 25 13:56:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 09:56:11 -0400
Subject: catching broken deps
In-Reply-To: <47209F11.4030205@hhs.nl>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com> <47209A22.6080403@hhs.nl>
	<20071025093806.7fc68146@redhat.com> <47209F11.4030205@hhs.nl>
Message-ID: <20071025095611.26dcf17f@redhat.com>

On Thu, 25 Oct 2007 15:50:09 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> You see, we (Thorsten and me) do not want to make this 100% bullet
> proof, we just want to do some cheap (in computing time) checks which
> should catch a > 50% percentage of all breakages.
> 
> * Packages with this error would get a special tag and rel-eng can
> override this for things like firefox updates, etc. But normally we
> do not want provides to go away with updates to a release.


Do you have code to do this?  

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/f37bac00/attachment.sig>

From j.w.r.degoede at hhs.nl  Thu Oct 25 14:06:11 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 16:06:11 +0200
Subject: catching broken deps
In-Reply-To: <20071025095611.26dcf17f@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>	<20071025080715.5e0bdf1e@redhat.com>	<472097D3.8060604@leemhuis.info>	<20071025092643.25f3349d@redhat.com>
	<47209A22.6080403@hhs.nl>	<20071025093806.7fc68146@redhat.com>
	<47209F11.4030205@hhs.nl> <20071025095611.26dcf17f@redhat.com>
Message-ID: <4720A2D3.5080701@hhs.nl>

Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:50:09 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> You see, we (Thorsten and me) do not want to make this 100% bullet
>> proof, we just want to do some cheap (in computing time) checks which
>> should catch a > 50% percentage of all breakages.
>>
>> * Packages with this error would get a special tag and rel-eng can
>> override this for things like firefox updates, etc. But normally we
>> do not want provides to go away with updates to a release.
> 
> 
> Do you have code to do this?  
> 

Not at the moment, but before sinking time into this I would first like to see 
some commitment to / interest in checks like these.

If we are going to do this I have a few questions:
-What languages would be acceptable to write such checks in?
-What kind of access to the repository for which is being build is available on
  the buildsys. (mirror mounted as filesystem / yum only / ..)

Regards,

Hans



From opensource at till.name  Thu Oct 25 14:10:59 2007
From: opensource at till.name (Till Maas)
Date: Thu, 25 Oct 2007 16:10:59 +0200
Subject: Development to Official
In-Reply-To: <20071025080715.5e0bdf1e@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
Message-ID: <200710251611.07785.opensource@till.name>

On Do Oktober 25 2007, Jesse Keating wrote:

> A) signing packages.  This can somewhat be mitigated by using a signing
> server (which work is developing on), however for a while I'm not going
> to feel comfortable hooking up some automated process to sign packages.

What is the problem with an automated signing process?[1] It cannot be worse 
than the current situation where rawhide rpms are only available in unsecure 
ways for the common user. When the ssl certificate for koji is changed to one 
from a trusted ca, then at least they are available there, but it is still a 
lot more work than to just using a mirror. And I guess it is not intended to 
use koji as a repository.

Regards,
Till

[1] Of course one should not use the same key that is used for stable rpms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/c523a849/attachment.sig>

From denis at poolshark.org  Thu Oct 25 14:11:24 2007
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 25 Oct 2007 16:11:24 +0200
Subject: rebuilding galeon and/or Miro (was Re: firefox-2.0.0.8 Upgrade
 Problems in F7)
In-Reply-To: <6p3avziwo9.fsf_-_@allele2.eebweb.arizona.edu>
References: <1193244774.19243.9.camel@localhost6.localdomain6>	<1193245059.19243.14.camel@localhost6.localdomain6>	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>	<1193259952.23316.12.camel@localhost6.localdomain6>	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>	<1193264638.23316.40.camel@localhost6.localdomain6>	<0qd4v3iylt.fsf@allele2.eebweb.arizona.edu>
	<6p3avziwo9.fsf_-_@allele2.eebweb.arizona.edu>
Message-ID: <4720A40C.3050005@poolshark.org>

Alex Lancaster wrote:
>>>>>> "AL" == Alex Lancaster  writes:
> 
> [...]
> 
> AL> If the maintainer doesn't respond reasonably quickly, other
> AL> maintainers could be permitted to step up to the bat to rebuild
> AL> the broken apps against the new firefox themselves.
> 
> AL> This would be preferable rather than let those maintainers
> AL> (galeon, Miro etc.) discover them through multiple bugs filed on
> AL> bugzilla and/or user forums or IRC several days later, dragging
> AL> the updating process on, and generating confusion) which seems to
> AL> be what tends to happen.
> 
> In the interests of getting these security updates up quickly, I'm
> taking the liberty to rebuild galeon against the new firefox (I've had
> a fair bit of experience rebuilding this application before) .  I'm
> currently doing a scratch build in koji, let me know if this isn't OK
> with anyone.

Thanks Alex,



From kevin.kofler at chello.at  Thu Oct 25 14:16:28 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 14:16:28 +0000 (UTC)
Subject: catching broken deps
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>	<20071025080715.5e0bdf1e@redhat.com>	<472097D3.8060604@leemhuis.info>	<20071025092643.25f3349d@redhat.com>
	<47209A22.6080403@hhs.nl> <20071025093806.7fc68146@redhat.com>
	<47209F11.4030205@hhs.nl>
Message-ID: <loom.20071025T141215-528@post.gmane.org>

Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
> * Packages with this error would get a special tag and rel-eng can override 
> this for things like firefox updates, etc. But normally we do not want
> provides to go away with updates to a release.

I wouldn't say it like that. I'd say packages needing the changed provides 
should get rebuilt and be pushed at the same time, but saying no provides 
should ever change is going to be a problem for several libraries/packages 
(Firefox being only the most obvious example). For example, we need to allow 
for broken ABI compatibility for the KDE 4 development platform updates until 
the 4.0 release (or at least the 4.0 development platform release, which will 
be fairly soon). It's part of its nature as a tech preview.

        Kevin Kofler



From ajackson at redhat.com  Thu Oct 25 13:49:14 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 25 Oct 2007 09:49:14 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <47209C4E.3000903@camperquake.de>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
	<47209C4E.3000903@camperquake.de>
Message-ID: <1193320154.15341.27.camel@localhost.localdomain>

On Thu, 2007-10-25 at 15:38 +0200, Ralf Ertzinger wrote:

> The finer point of this thread is whether it is permissible to ship
> binary only, executable content in Fedora, as long as these binaries
> are not executed on the main CPU. There is precedent in the form of
> firmware, which executes on some hardware subsystem (the WLAN card,
> for example), which we allow.
> 
> Now someone threw Win32 binaries into the pool, which are, however,
> not the same kind of beast, since they _do_ execute, natively, at least
> in part, on the main CPU. That they require WINE to run at all does not
> change that.
> 
> Then there is the third group of binaries for non host native binaries
> (for example, arcade ROM files) which do not execute on the main CPU,
> since they were written for a completely different hardware (again,
> for example, Motorola 68xxx CPUs). Apart from copyright concerns,
> would this be permissible? The binary would not run on the main CPU,
> but on a virtual one, which is provided by an emulator (which, in turn,
> does run on the main CPU).

This is actually a subtle point.  The Debian criteria for this is
whether the distribution contains the preferred form of modification,
but they don't bother to define that, it's merely in the eye of the
original author.  As such, you could upload an ELF file you wrote by
hand in a hex editor and claim it's how you wanted to write it.

The Fedora Packaging Guidelines actually specifically prohibit this:
"All binaries or libraries included with Fedora packages must have been
built from sourcecode included in the source package."  So to address
the cases you just gave:

- Firmware (defined by not running on the host CPU) is permissible as
long as it's transitively freely distributable; see
http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware for
the details.

- win32 binaries (or Mach-O for OSX, or whatever else) that run on the
host CPU under a compatibility runtime like wine are permissible, as
long as they are built from source as part of the rpmbuild process, and
the source and binaries are under an acceptable free license.

- ROMs or other binary images that run under a CPU emulator are
permissible, as long as they are assembled from source as part of the
rpmbuild process, and the source and binaries are under an acceptable
free license.

There's another point in this spectrum that is instructive to compare
to: bytecode for various high-level languages.  We wouldn't allow a
python .pyc or .pyo without source, even though it's bytecode in the
"Python" instruction set.  Neither would we allow an Amiga ROM without
source, which is just a bytecode in the m68k instruction set.

I suppose, if I had to think about it, that the policy on game data sort
of contradicts this nice clean delineation, since game data files often
include a scripting language for in-game logic.  That's not necessarily
a problem, merely an exception.  Personally I'm fine with it, but it
seems difficult to construct a (non-emotional) justification for it that
doesn't expand to cover win32 binaries or ROMs without source.

- ajax



From jkeating at redhat.com  Thu Oct 25 14:18:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 10:18:32 -0400
Subject: catching broken deps
In-Reply-To: <4720A2D3.5080701@hhs.nl>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<200710241511.35633.opensource@till.name>
	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>
	<1193241150.2109.2.camel@scrappy.miketc.com>
	<20071024115415.1195fdc5@redhat.com>
	<loom.20071024T161727-347@post.gmane.org>
	<20071024133043.3934b8e0@redhat.com>
	<1193249067.2109.9.camel@scrappy.miketc.com>
	<472058E9.30704@redhat.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<472097D3.8060604@leemhuis.info>
	<20071025092643.25f3349d@redhat.com> <47209A22.6080403@hhs.nl>
	<20071025093806.7fc68146@redhat.com> <47209F11.4030205@hhs.nl>
	<20071025095611.26dcf17f@redhat.com> <4720A2D3.5080701@hhs.nl>
Message-ID: <20071025101832.0254b637@redhat.com>

On Thu, 25 Oct 2007 16:06:11 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Not at the moment, but before sinking time into this I would first
> like to see some commitment to / interest in checks like these.

I don't think anybody is going to say no to adding some checks in to at
least warn a maintainer that the build they submitted may cause
problems.  I don't think we want to fail any builds yet, especially
since we don't have an easy way to "unfail" the build.  So
informational only.

> 
> If we are going to do this I have a few questions:
> -What languages would be acceptable to write such checks in?

Python would be preferred.

> -What kind of access to the repository for which is being build is
> available on the buildsys. (mirror mounted as filesystem / yum
> only / ..)

Within the buildroot itself there should be access to the build
repository, but this doesn't necessarily match the released repos.  My
best recommendation would be to construct a yum object and point to a
known local repo (http) to gather repodata information.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/c40f9cb7/attachment.sig>

From jkeating at redhat.com  Thu Oct 25 14:20:51 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 10:20:51 -0400
Subject: Development to Official
In-Reply-To: <200710251611.07785.opensource@till.name>
References: <1193230483.4821.2.camel@scrappy.miketc.com>
	<loom.20071025T104150-827@post.gmane.org>
	<20071025080715.5e0bdf1e@redhat.com>
	<200710251611.07785.opensource@till.name>
Message-ID: <20071025102051.43e512da@redhat.com>

On Thu, 25 Oct 2007 16:10:59 +0200
Till Maas <opensource at till.name> wrote:

> What is the problem with an automated signing process?[1] It cannot
> be worse than the current situation where rawhide rpms are only
> available in unsecure ways for the common user. When the ssl
> certificate for koji is changed to one from a trusted ca, then at
> least they are available there, but it is still a lot more work than
> to just using a mirror. And I guess it is not intended to use koji as
> a repository.

Because it really doesn't offer much protection.  All it really says is
"this fell out of koji", which there is /some/ level of comfort about
that, but not much.

More scary to me is that with the signing server going to be so fresh I
just don't want to hook an automated process up to it, one that could
potentially be exploited to gain access to more important keys.
It's the paranoid in me.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/26ebf9a6/attachment.sig>

From j.w.r.degoede at hhs.nl  Thu Oct 25 14:39:33 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 16:39:33 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <20071025094010.2a7afb7e@redhat.com>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>	<20071024005354.2f2cc521@lain.camperquake.de>	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>	<47209C4E.3000903@camperquake.de>
	<20071025094010.2a7afb7e@redhat.com>
Message-ID: <4720AAA5.7090805@hhs.nl>

Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:38:22 +0200
> Ralf Ertzinger <fedora at camperquake.de> wrote:
> 
>> Then there is the third group of binaries for non host native binaries
>> (for example, arcade ROM files) which do not execute on the main CPU,
>> since they were written for a completely different hardware (again,
>> for example, Motorola 68xxx CPUs). Apart from copyright concerns,
>> would this be permissible? The binary would not run on the main CPU,
>> but on a virtual one, which is provided by an emulator (which, in
>> turn, does run on the main CPU).
> 
> That's cheating IMHO.  That's like saying a .jar file doesn't execute
> on the system CPU because the JVM executes it.
> 

Yes and No,

As said before I think the current guidelines work well, quoting some parts of 
them relevant to this discussion:

All from http://fedoraproject.org/wiki/Packaging/Guidelines # Legal:


"Shareware

Shareware applications are not Open Source code, and are not acceptable for Fedora.

However, it is worth noting that some non-executable content exists that is 
required to make Open Source applications functional. An example of this would 
be open sourced game engines, such as Doom, Heretic, and Descent. These game 
engines come with freely distributable shareware gamedata files.

In this case, the gamedata files can be packaged and included in Fedora, as 
long as the files meet the requirements for binary firmware."

Key here is not executable, which as this discussion turns out is a bit grey 
though, since game levels often contain a form of "instructions" to the game 
engine, so one could argue the game engine is a vm and the levels are executed 
on that vm.

Note that I'm not arguing in favor of this, I think the current interpretation 
that game engines are not vm's and thus game content is not executed but merely 
used as content is the correct interpretation, and that we should stick with 
this interpretation.


"Emulators

Most emulators (applications which emulate another platform) are not permitted 
for inclusion in Fedora. The rule of thumb to follow is: If it requires ROMs 
(or image files in any format) of copyrighted or patented material to be useful 
(and the owners of those copyrights and patents have not given their express 
written permission), then it's not permitted."

Notice how it says nowhere in the above that the ROMS themselves must be OSS, 
they merely must be freely distributable. We might want to clarify this by 
saying that emulator roms must meet the firmware guidelines.

Now here we hit some interesting ground which indeed needs more discussion. I'm 
in favor of treating BIOS(ish) roms of old computers, which are now freely 
redistributable like the amstrad ones, as content, if only because the sources 
are probably for ever lost.

However there are various freely redistributable dos games^H^H^H^H^Hprograms 
which run onder dosbox, and dosbox is clearly an emulator (it will run x86 
games hapily on powerpc). So do we allow packaging of these games, I say NO. 
Notice that this NO can be motived by the current rules as these programs are 
not required for the program (the emulator) to be usefull. Without _a_ dos 
program dosbox isn't very usefull, but not necessarily _this_ or _that_ 
program, much unlike a BIOS-ish rom where specifically that rom is required for 
the emulator to function.

So maybe for emulators we must make a distinction between wether or not some 
piece of data is required for it to function. If it is, we treat it as content 
(like the system and vga bios images for qemu). If it isn't, or iow if it 
merely is some software which can be run by the emulator we treat it as code. 
This is what we've been doing sofar, and I guess its time to codify this into 
some rules now.

---

Then another question is what do we do with free software which cannot be 
rebuilt from sources for whatever reason, here is what first popped up in ym mind:

1) If the software is native Linux software (iow elf-arch binaries) it _MUST_
    be rebuild from source, so that it is build against Fedora libs, using
    Fedora compilers and Fedora CFLAGS and normally will be available for all
    Fedora supported archs

2) If it is not native Linux software but rather runs under an emulator, for
    example old amstrad software, and it is opensource, then an srpm maybe used
    which contains both the sources and binaries from one and the same upstream.

On a second look I do not like 2 myself though, for one there seems little gain 
in rebuilding for example freedos from sources (see p.s.), actually in the 
ideal situation the resulting binaries would be identical to the ones 
distributed by freedos, as that is how most testing of this software is done, 
and thus we then don't loose a lot of QA. OTOH if our users cannot rebuild 
freedos (as example) from source under Fedora, then they loose some significant 
software freedoms, and the software effectively becomes non-free, and thus we 
do not want to distribute it.

Conclusion, free software which does not fall under the firmware exception may 
only be included in Fedore of build from source.

Regards,

Hans



p.s.

And in the past there have been discussions about freedos, and I was given 
permission (never got around to it) to package it using an srpm which included 
both the sources and the prebuild binaries from upstream. Instead of rebuilding 
from the freedos sources, as freedos cannot be compiled from sources under 
Fedora. This was not seen as a problem since the freedos binaries are not 
native Linux binaries, but are running under an emulator (they are running on 
the native CPU in v86 mode though). Freedos is a special case as it is freesoft 
ware, but cannot be built (it requires the free as in beer borland compiler, 
which in turn requires freedos + dosemu to run). I'm merely mentioning freedos 
to explain that there are many shades of gray here.



From j.w.r.degoede at hhs.nl  Thu Oct 25 14:43:59 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 16:43:59 +0200
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193320154.15341.27.camel@localhost.localdomain>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>	<20071024005354.2f2cc521@lain.camperquake.de>	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>	<47209C4E.3000903@camperquake.de>
	<1193320154.15341.27.camel@localhost.localdomain>
Message-ID: <4720ABAF.7090801@hhs.nl>

Adam Jackson wrote:
> On Thu, 2007-10-25 at 15:38 +0200, Ralf Ertzinger wrote:
> 
>> The finer point of this thread is whether it is permissible to ship
>> binary only, executable content in Fedora, as long as these binaries
>> are not executed on the main CPU. There is precedent in the form of
>> firmware, which executes on some hardware subsystem (the WLAN card,
>> for example), which we allow.
>>
>> Now someone threw Win32 binaries into the pool, which are, however,
>> not the same kind of beast, since they _do_ execute, natively, at least
>> in part, on the main CPU. That they require WINE to run at all does not
>> change that.
>>
>> Then there is the third group of binaries for non host native binaries
>> (for example, arcade ROM files) which do not execute on the main CPU,
>> since they were written for a completely different hardware (again,
>> for example, Motorola 68xxx CPUs). Apart from copyright concerns,
>> would this be permissible? The binary would not run on the main CPU,
>> but on a virtual one, which is provided by an emulator (which, in turn,
>> does run on the main CPU).
> 
> This is actually a subtle point.  The Debian criteria for this is
> whether the distribution contains the preferred form of modification,
> but they don't bother to define that, it's merely in the eye of the
> original author.  As such, you could upload an ELF file you wrote by
> hand in a hex editor and claim it's how you wanted to write it.
> 
> The Fedora Packaging Guidelines actually specifically prohibit this:
> "All binaries or libraries included with Fedora packages must have been
> built from sourcecode included in the source package."  So to address
> the cases you just gave:
> 
> - Firmware (defined by not running on the host CPU) is permissible as
> long as it's transitively freely distributable; see
> http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware for
> the details.
> 
> - win32 binaries (or Mach-O for OSX, or whatever else) that run on the
> host CPU under a compatibility runtime like wine are permissible, as
> long as they are built from source as part of the rpmbuild process, and
> the source and binaries are under an acceptable free license.
> 
> - ROMs or other binary images that run under a CPU emulator are
> permissible, as long as they are assembled from source as part of the
> rpmbuild process, and the source and binaries are under an acceptable
> free license.
> 
> There's another point in this spectrum that is instructive to compare
> to: bytecode for various high-level languages.  We wouldn't allow a
> python .pyc or .pyo without source, even though it's bytecode in the
> "Python" instruction set.  Neither would we allow an Amiga ROM without
> source, which is just a bytecode in the m68k instruction set.
> 
> I suppose, if I had to think about it, that the policy on game data sort
> of contradicts this nice clean delineation, since game data files often
> include a scripting language for in-game logic.  That's not necessarily
> a problem, merely an exception.  Personally I'm fine with it, but it
> seems difficult to construct a (non-emotional) justification for it that
> doesn't expand to cover win32 binaries or ROMs without source.
> 

Well written, and I fully agree, except that besides an exception for game 
data, I would also like to see an exception for system ROM's for old computers 
like the amstrad, where amstrad has been so kind to allow free redistribution 
of the roms. I'm not advocating to make the same exception for software that 
ran on these old computers, merely for the code that was in ROM's _inside_ the 
sytem and thus is needed for the emulator to function _at all_, to me this 
clearly is firmware.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Thu Oct 25 14:48:14 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 25 Oct 2007 16:48:14 +0200
Subject: catching broken deps
In-Reply-To: <20071025101832.0254b637@redhat.com>
References: <1193230483.4821.2.camel@scrappy.miketc.com>	<200710241511.35633.opensource@till.name>	<20071024090014.1737f6b8@weaponx.rchland.ibm.com>	<1193241150.2109.2.camel@scrappy.miketc.com>	<20071024115415.1195fdc5@redhat.com>	<loom.20071024T161727-347@post.gmane.org>	<20071024133043.3934b8e0@redhat.com>	<1193249067.2109.9.camel@scrappy.miketc.com>	<472058E9.30704@redhat.com>	<loom.20071025T104150-827@post.gmane.org>	<20071025080715.5e0bdf1e@redhat.com>	<472097D3.8060604@leemhuis.info>	<20071025092643.25f3349d@redhat.com>
	<47209A22.6080403@hhs.nl>	<20071025093806.7fc68146@redhat.com>
	<47209F11.4030205@hhs.nl>	<20071025095611.26dcf17f@redhat.com>
	<4720A2D3.5080701@hhs.nl> <20071025101832.0254b637@redhat.com>
Message-ID: <4720ACAE.2070309@hhs.nl>

Jesse Keating wrote:
> On Thu, 25 Oct 2007 16:06:11 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Not at the moment, but before sinking time into this I would first
>> like to see some commitment to / interest in checks like these.
> 
> I don't think anybody is going to say no to adding some checks in to at
> least warn a maintainer that the build they submitted may cause
> problems.  I don't think we want to fail any builds yet, especially
> since we don't have an easy way to "unfail" the build.  So
> informational only.
> 

Good I was expecting / hoping to hear something like that.

>> If we are going to do this I have a few questions:
>> -What languages would be acceptable to write such checks in?
> 
> Python would be preferred.
> 

Hmm, not my field of expertise I'm afraid.

>> -What kind of access to the repository for which is being build is
>> available on the buildsys. (mirror mounted as filesystem / yum
>> only / ..)
> 
> Within the buildroot itself there should be access to the build
> repository, but this doesn't necessarily match the released repos.  My
> best recommendation would be to construct a yum object and point to a
> known local repo (http) to gather repodata information.
> 

Hmm, even further away from my field of expertise I'm afraid, I was thinking 
about some ugly bash scripting using repoquery and who knows what other kind of 
ugliness. Any volunteers for writting somthing clean to run on the buildsys?

Maybe in the mean time its an idea to add an ugly version to the Makefile's 
make <arch> command's, then atleast those can warn the maintainer when he does 
a local test build, maybe we can even patch it into make mockbuild?

Regards,

Hans



From mjs at CLEMSON.EDU  Thu Oct 25 15:20:50 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Thu, 25 Oct 2007 11:20:50 -0400
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
	<1193266141.5354.10.camel@valkyrie.localdomain>
	<1193268923.3553.1.camel@valkyrie.localdomain>
	<604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>
Message-ID: <1193325650.20337.4.camel@vincent52.localdomain>

On Wed, 2007-10-24 at 15:45 -0800, Jeff Spaleta wrote:
> On 10/24/07, Matthew Saltzman <mjs at exchange.clemson.edu> wrote:
> > One more piece of information: Installing directly with rpm works with
> > no complaint (at least with all those keys installed).  So this is
> > apparently something to do with yum.
> 
> known issue
> 
> fedore-release package was updated for F8 final which turns on sig checking.
> 
> development repo does not garuantee signed packages...so until all the
> packages are signed in preparation for f8 going gold, gpg checking
> will fail.
> 
> Sooooooo, what you can do is turn gpg checking off in the repo
> configuration file until f8 goes gold.
> 
> -jef"I think its great that gpg checking was turned on before all the
> packages were signed. It's a good test to make sure the gpg checking
> is actually working."spaleta

OK That works.  Are we independent user-testers supposed to know that
from someplace?

> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From sundaram at fedoraproject.org  Thu Oct 25 14:22:09 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 25 Oct 2007 19:52:09 +0530
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <1193325650.20337.4.camel@vincent52.localdomain>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>	<1193241126.5103.50.camel@vincent52.localdomain>	<1193266141.5354.10.camel@valkyrie.localdomain>	<1193268923.3553.1.camel@valkyrie.localdomain>	<604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>
	<1193325650.20337.4.camel@vincent52.localdomain>
Message-ID: <4720A691.7010600@fedoraproject.org>

Matthew Saltzman wrote:

> OK That works.  Are we independent user-testers supposed to know that
> from someplace?

It has been discussed quite a few times in fedora-test list.

Rahul



From tibbs at math.uh.edu  Thu Oct 25 15:26:58 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 25 Oct 2007 10:26:58 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <4720ABAF.7090801@hhs.nl>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
	<47209C4E.3000903@camperquake.de>
	<1193320154.15341.27.camel@localhost.localdomain>
	<4720ABAF.7090801@hhs.nl>
Message-ID: <ufa8x5rz03h.fsf@epithumia.math.uh.edu>

>>>>> "HdG" == Hans de Goede <j.w.r.degoede at hhs.nl> writes:

HdG> for game data, I would also like to see an exception for system
HdG> ROM's for old computers like the amstrad, where amstrad has been
HdG> so kind to allow free redistribution of the roms.

Well, we have an Oric emulator in already.  With ROMs.

 - J<



From denis at poolshark.org  Thu Oct 25 15:58:23 2007
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 25 Oct 2007 17:58:23 +0200
Subject: firefox-2.0.0.8 Upgrade Problems in F7
In-Reply-To: <604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
References: <1193244774.19243.9.camel@localhost6.localdomain6>	<1193245059.19243.14.camel@localhost6.localdomain6>	<604aa7910710241256p95caedbl13b0dfd39b676ebf@mail.gmail.com>	<1193259952.23316.12.camel@localhost6.localdomain6>
	<604aa7910710241425je27ae3fuc6c3e4891d81bb1b@mail.gmail.com>
Message-ID: <4720BD1F.7070906@poolshark.org>

Jeff Spaleta wrote:
> Crap like yelp and devhelp

devhelp crap ?!? Come on.



From mjs at CLEMSON.EDU  Thu Oct 25 16:15:54 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Thu, 25 Oct 2007 12:15:54 -0400
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <4720A691.7010600@fedoraproject.org>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
	<1193266141.5354.10.camel@valkyrie.localdomain>
	<1193268923.3553.1.camel@valkyrie.localdomain>
	<604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>
	<1193325650.20337.4.camel@vincent52.localdomain>
	<4720A691.7010600@fedoraproject.org>
Message-ID: <1193328954.20337.11.camel@vincent52.localdomain>

On Thu, 2007-10-25 at 19:52 +0530, Rahul Sundaram wrote:
> Matthew Saltzman wrote:
> 
> > OK That works.  Are we independent user-testers supposed to know that
> > from someplace?
> 
> It has been discussed quite a few times in fedora-test list.

Oh, good, yet another mailing list to track...

OK thanks.

> 
> Rahul
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From poelstra at redhat.com  Thu Oct 25 16:45:20 2007
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 25 Oct 2007 09:45:20 -0700
Subject: Plan for tomorrows (20071025) FESCO meeting
In-Reply-To: <1193251779.7673.1.camel@kennedy>
References: <1193251779.7673.1.camel@kennedy>
Message-ID: <4720C820.5070402@redhat.com>

Brian Pepple said the following on 10/24/2007 11:49 AM Pacific Time:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
> in #fedora-meeting on irc.freenode.org:
> 
> /topic FESCo meeting -- Free discussion around Fedora
> 
> There's nothing on the schedule for tomorrow so if you want something
> to be discussed, send a note to the list in reply to this mail and I'll
> add it to the schedule.  You can also propose topics in the meeting
> while it is in the "Free discussion around Fedora" phase.
> 
> If your name/nick is on above list please update the status on the
> Extras schedule pages in the wiki ahead of the meeting. That way all the
> other FESCo members and interested contributors know what up ahead of
> the meeting. And we will avoid long delays in the meeting -- those often
> arise if someone describes the recent happenings on a topic directly in
> the meeting while all the others have to wait for his slow typing...
> 
> Thanks,
> /B
> 

We need a status and wiki update for: http://fedoraproject.org/wiki/Releases/FeatureNetworkManager

Direct requests for updates from the feature owners have gone unanswered.  

Considering some of the media attention we are getting it would be nice to have http://fedoraproject.org/wiki/Releases/8/FeatureList all at 100% :)

John



From jspaleta at gmail.com  Thu Oct 25 17:04:04 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 25 Oct 2007 09:04:04 -0800
Subject: Help! Can't update! (was Re: rawhide report: 20071024 changes)
In-Reply-To: <1193328954.20337.11.camel@vincent52.localdomain>
References: <200710241059.l9OAxJmh031471@porkchop.devel.redhat.com>
	<1193241126.5103.50.camel@vincent52.localdomain>
	<1193266141.5354.10.camel@valkyrie.localdomain>
	<1193268923.3553.1.camel@valkyrie.localdomain>
	<604aa7910710241645l671720c3x7eba8df2a45a953f@mail.gmail.com>
	<1193325650.20337.4.camel@vincent52.localdomain>
	<4720A691.7010600@fedoraproject.org>
	<1193328954.20337.11.camel@vincent52.localdomain>
Message-ID: <604aa7910710251004l737ed24bjde4c6b93e4f84ffc@mail.gmail.com>

On 10/25/07, Matthew Saltzman <mjs at clemson.edu> wrote:
> Oh, good, yet another mailing list to track...

I too find that tracking both test-list and devel-list to be quite
cumbersome. To offset that gmail cache test-list and search it for
posts about issues I'm seeing locally instead of practively reading
test-list.

Maybe there's some sort of aggressive knowledge base technology we can
implement as a Fedora service which does a better job than the
test-list for day to day issues, with a clientside tool working with a
fas account.

Honestly though, as a tester you have to make a certain level of
personal commitment to the process for it to work effectively.
Testing is very much about tracking nearly daily breakage and fixage.

But brainstorming a bit, I wonder can we tie F9 testing in with the
new smolt wiki somehow?  Perhaps by letting people group choose to
group smolt'd system together into a similar hardware group so they
can worth together to track some of the harder hardware specific
issues.  It would require testers to give up some of the privacy
protections that the uuid scheme provides.. but if testers choose to
form groups around similar hardware then it might make for more
effective testing.

-jef



From nando at ccrma.Stanford.EDU  Thu Oct 25 17:45:03 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Thu, 25 Oct 2007 10:45:03 -0700
Subject: repoview & templates in Fedora site
Message-ID: <1193334303.24482.2.camel@cmn18.stanford.edu>

Hi all, is there a place where the "modified" repoview used in the
Fedora site could be found? I really could use the layout (where package
pages do not include the version in their name). I'm trying to tweak the
original 0.5.2 to get the same result but it is not that easy...

Thanks...
-- Fernando




From notting at redhat.com  Thu Oct 25 17:45:07 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 13:45:07 -0400
Subject: Multiarch crazyiness
In-Reply-To: <20071022192036.GH9625@nostromo.devel.redhat.com>
References: <1193011897.5168.52.camel@perihelion>
	<1193048076.26495.5.camel@clockmaker.usersys.redhat.com>
	<1193013121.5168.68.camel@perihelion>
	<471C64C4.2090705@redhat.com> <20071022085313.GB2941@free.fr>
	<471CACBD.2080706@redhat.com> <20071022100132.76f33bbd@redhat.com>
	<20071022185644.GG9625@nostromo.devel.redhat.com>
	<1193080444.28655.8.camel@rousalka.dyndns.org>
	<20071022192036.GH9625@nostromo.devel.redhat.com>
Message-ID: <20071025174507.GA2549@nostromo.devel.redhat.com>

Bill Nottingham (notting at redhat.com) said: 
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
> > > will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
> > > foo.i386 will remain, often leading to conflicts.
> > 
> > Wouldn't an Obsoletes: foo < current_version fix this? Unless we want to
> > ship 32bit & 64bit versions of foo in the same repo
> 
> It *should*; need some more testing so this can be 100% codified.

Yes, obsoletes works here.

Bill



From mikeb at redhat.com  Thu Oct 25 17:48:19 2007
From: mikeb at redhat.com (Mike Bonnet)
Date: Thu, 25 Oct 2007 13:48:19 -0400
Subject: koji server installation
In-Reply-To: <1192719967.3358.6.camel@burren.boston.redhat.com>
References: <4717675F.6000608@codewiz.org>  <471768A7.3000800@codewiz.org>
	<1192719967.3358.6.camel@burren.boston.redhat.com>
Message-ID: <1193334499.21338.6.camel@localhost.localdomain>

On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
> In terms of your other problems, you need to to bootstrap Koji by
> importing a bunch of pre-built packages so Koji is able to populate a
> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
> guide, I'll point you at it when it's posted.

I've put up a setup/bootstrapping guide here:

https://fedoraproject.org/wiki/Koji/ServerBootstrap

and linked it from the bottom of the ServerHowTo.  Give it a try and let
me know if you run into problems or have suggestions on how to improve
the guide.

Thanks!




From skvidal at fedoraproject.org  Thu Oct 25 17:47:53 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 25 Oct 2007 13:47:53 -0400
Subject: repoview & templates in Fedora site
In-Reply-To: <1193334303.24482.2.camel@cmn18.stanford.edu>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
Message-ID: <1193334473.3517.39.camel@cutter>


On Thu, 2007-10-25 at 10:45 -0700, Fernando Lopez-Lezcano wrote:
> Hi all, is there a place where the "modified" repoview used in the
> Fedora site could be found? I really could use the layout (where package
> pages do not include the version in their name). I'm trying to tweak the
> original 0.5.2 to get the same result but it is not that easy...
> 

1. use repoview 0.6
2. I've got some fedora-specific ones, now that'll be in the repoview
pkg in f8 this afternoon.

-sv




From bernie at codewiz.org  Thu Oct 25 18:05:40 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Thu, 25 Oct 2007 14:05:40 -0400
Subject: koji server installation
In-Reply-To: <1193334499.21338.6.camel@localhost.localdomain>
References: <4717675F.6000608@codewiz.org> <471768A7.3000800@codewiz.org>	
	<1192719967.3358.6.camel@burren.boston.redhat.com>
	<1193334499.21338.6.camel@localhost.localdomain>
Message-ID: <4720DAF4.5050803@codewiz.org>

Mike Bonnet wrote:

> On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
>> In terms of your other problems, you need to to bootstrap Koji by
>> importing a bunch of pre-built packages so Koji is able to populate a
>> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
>> guide, I'll point you at it when it's posted.
> 
> I've put up a setup/bootstrapping guide here:
> 
> https://fedoraproject.org/wiki/Koji/ServerBootstrap
> 
> and linked it from the bottom of the ServerHowTo.  Give it a try and let
> me know if you run into problems or have suggestions on how to improve
> the guide.

Thank you very much!

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From nando at ccrma.Stanford.EDU  Thu Oct 25 18:05:39 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Thu, 25 Oct 2007 11:05:39 -0700
Subject: repoview & templates in Fedora site
In-Reply-To: <1193334473.3517.39.camel@cutter>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
	<1193334473.3517.39.camel@cutter>
Message-ID: <1193335539.24482.8.camel@cmn18.stanford.edu>

On Thu, 2007-10-25 at 13:47 -0400, seth vidal wrote:
> On Thu, 2007-10-25 at 10:45 -0700, Fernando Lopez-Lezcano wrote:
> > Hi all, is there a place where the "modified" repoview used in the
> > Fedora site could be found? I really could use the layout (where package
> > pages do not include the version in their name). I'm trying to tweak the
> > original 0.5.2 to get the same result but it is not that easy...
> 
> 1. use repoview 0.6

I tried 0.6.1... With that one I could not see immediately how to get
the (small) group list to appear on the left pane of the pages (and I
had to patch it to avoid problems with non ascii characters in, for
example, changelog entries). It looked like the required information was
not exported to the kid templates... (if I understand things correctly)
I probably should take another look at it. 

I was just trying again with 0.5.2 after not being very successfull with
0.6.1. 

> 2. I've got some fedora-specific ones, now that'll be in the repoview
> pkg in f8 this afternoon.

You mean templates? I'll take a look later. 
Thanks very much!
-- Fernando




From notting at redhat.com  Thu Oct 25 18:05:23 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 14:05:23 -0400
Subject: multlib and splitting packages
Message-ID: <20071025180523.GA15925@nostromo.devel.redhat.com>

Just to note, if you fix multiarch conflicts by moving libraries to
a -libs package, your new -libs package should obsolete the older
versions of the package where the libraries came from. This is so
that yum upgrades work properly.

For example, if you previously had:

foo-1.1-1.i386
foo-1.1-1.x86_64

that had libraries, and had other file conflicts, and you split them
into:

foo-1.1-2.x86_64
foo-libs-1.1-2.i386
foo-libs-1.1-2.x86_64

you should add:

Obsoletes: foo < 1.1-2

in the %package section for foo-libs.

Bill



From sundaram at fedoraproject.org  Thu Oct 25 17:06:25 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 25 Oct 2007 22:36:25 +0530
Subject: multlib and splitting packages
In-Reply-To: <20071025180523.GA15925@nostromo.devel.redhat.com>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
Message-ID: <4720CD11.5070807@fedoraproject.org>

Bill Nottingham wrote:
> Just to note, if you fix multiarch conflicts by moving libraries to
> a -libs package, your new -libs package should obsolete the older
> versions of the package where the libraries came from. This is so
> that yum upgrades work properly.

Please add this to the packaging guidelines.

Rahul



From notting at redhat.com  Thu Oct 25 18:09:59 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 14:09:59 -0400
Subject: multlib and splitting packages
In-Reply-To: <4720CD11.5070807@fedoraproject.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<4720CD11.5070807@fedoraproject.org>
Message-ID: <20071025180959.GB15925@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> Bill Nottingham wrote:
>> Just to note, if you fix multiarch conflicts by moving libraries to
>> a -libs package, your new -libs package should obsolete the older
>> versions of the package where the libraries came from. This is so
>> that yum upgrades work properly.
>
> Please add this to the packaging guidelines.

I'm not seeing an obvious place that this fits.

Bill



From tonynelson at georgeanelson.com  Thu Oct 25 18:13:46 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Thu, 25 Oct 2007 14:13:46 -0400
Subject: ISO file size in bytes?
In-Reply-To: <20071025032930.GA17151@auslistsprd01.us.dell.com>
References: <008201c816b3$a8797bb0$020aa8c0@a18>
	<20071025032930.GA17151@auslistsprd01.us.dell.com>
Message-ID: <p04330100c3467bad22b1@[192.168.123.162]>

At 10:29 PM -0500 10/24/07, Matt Domsch wrote:
>On Wed, Oct 24, 2007 at 09:03:45PM -0600, Jerry Williams wrote:
>> Would it be possible to list the iso file size in bytes in the SHA1SUM file?
>>
>> The reason that I ask it is that I had a DVD with Fedora 7 on it and needed
>> a copy of the iso file.  So I did a dd on the DVD, but the file ended up
>> being bigger than the original iso file.  I had to know the size so I could
>> enter the number of blocks to copy.
>>
>> It is much quicker to do an ls -l than it is to run sha1sum on a file.
>> If the size is right then run the sha1sum.
>>
>> Or is the size listed on some web page some place?
>> Everywhere I have looked I end up with an estimate.
>
>When reading a the file itself with isoinfo, it'll tell you:
>
>$ isoinfo -d -i F-7-x86_64-DVD.iso
>...
>Logical block size is: 2048
>Volume size is: 1683582
>...

I find isosize less AWKward, as it puts out the size directly and will also
do the math:

    $ isosize Fedora-7.92-i386-DVD.iso
    3000535040
    $ isosize -d 2048 Fedora-7.92-i386-DVD.iso
    1465105
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From sundaram at fedoraproject.org  Thu Oct 25 17:12:56 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 25 Oct 2007 22:42:56 +0530
Subject: multlib and splitting packages
In-Reply-To: <20071025180959.GB15925@nostromo.devel.redhat.com>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>	<4720CD11.5070807@fedoraproject.org>
	<20071025180959.GB15925@nostromo.devel.redhat.com>
Message-ID: <4720CE98.4040102@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Bill Nottingham wrote:
>>> Just to note, if you fix multiarch conflicts by moving libraries to
>>> a -libs package, your new -libs package should obsolete the older
>>> versions of the package where the libraries came from. This is so
>>> that yum upgrades work properly.
>> Please add this to the packaging guidelines.
> 
> I'm not seeing an obvious place that this fits.

Maybe add a new section that mentions what all packaging details to 
cover to avoid hacks in anaconda and get smooth upgrades.

Rahul



From jkeating at redhat.com  Thu Oct 25 18:19:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 14:19:26 -0400
Subject: multlib and splitting packages
In-Reply-To: <20071025180959.GB15925@nostromo.devel.redhat.com>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<4720CD11.5070807@fedoraproject.org>
	<20071025180959.GB15925@nostromo.devel.redhat.com>
Message-ID: <20071025141926.0f0a4d90@redhat.com>

On Thu, 25 Oct 2007 14:09:59 -0400
Bill Nottingham <notting at redhat.com> wrote:

> Rahul Sundaram (sundaram at fedoraproject.org) said: 
> > Bill Nottingham wrote:  
> >> Just to note, if you fix multiarch conflicts by moving libraries to
> >> a -libs package, your new -libs package should obsolete the older
> >> versions of the package where the libraries came from. This is so
> >> that yum upgrades work properly.  
> >
> > Please add this to the packaging guidelines.  
> 
> I'm not seeing an obvious place that this fits.

Probably best to add it to the 'dealing with multilib' page you
referenced in all your bugs.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/8b522397/attachment.sig>

From valent.turkovic at gmail.com  Thu Oct 25 18:37:26 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 20:37:26 +0200
Subject: Announcing rpmfusion
In-Reply-To: <46E6F59B.7010506@fedoraproject.org>
References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org>
	<loom.20070911T215813-142@post.gmane.org>
	<20070911160537.696c6a25@localhost.localdomain>
	<46E6F59B.7010506@fedoraproject.org>
Message-ID: <64b14b300710251137y591bcb44x9c762a5a306cda36@mail.gmail.com>

On 9/11/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Jesse Keating wrote:
> > On Tue, 11 Sep 2007 20:02:40 +0000 (UTC)
> > Kevin Kofler <kevin.kofler at chello.at> wrote:
> >
> >> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> >>> Thanks for this split. Hopefully we will able to link to the free
> >>> part from within Fedora.
> >> Unfortunately I don't think you will be able to. The stuff in the
> >> free part (or most of it, at least) is going to be exactly the stuff
> >> which Legal is most uncomfortable with: Free Software, but
> >> patent-encumbered in the US.
> >
> > And really, if we could reference it, then why the crap couldn't we
> > just package it in our repo?
>
> There is a lot of differences between pointing to the repository and
> including the packages directly as I already explained in Fedora
> Advisory Board list so I won't rehash all the arguments again now.
> Please read the releated threads if you missed it. In short, it is not
> possible to include patent-encumbered packages directly in the
> repository as long as it hosted in US. Pointing to it might very well be
> possible.
>
> Rahul

Yes! I cought a bit late on this thread but I can't be happier!
I started a threat that asked this exact question: why doesn't fedora
link to external repositories after users agreeing to some sort of
ULA.

What is the update on this topic? I really hope fedora goes ahead and
links to sites outside US that can legally host files.

It is a shame that worldwide users had to "suffer" because of US
legislative even if their countries (like mine) don't recognize
software patents.

Hope this changes in the future so please post a quick reply about
status of this issue.

Thank you in advance,
Valent.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From ajackson at redhat.com  Thu Oct 25 18:10:17 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 25 Oct 2007 14:10:17 -0400
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <4720ABAF.7090801@hhs.nl>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
	<47209C4E.3000903@camperquake.de>
	<1193320154.15341.27.camel@localhost.localdomain>
	<4720ABAF.7090801@hhs.nl>
Message-ID: <1193335817.15341.45.camel@localhost.localdomain>

On Thu, 2007-10-25 at 16:43 +0200, Hans de Goede wrote:
> Adam Jackson wrote:
> > I suppose, if I had to think about it, that the policy on game data sort
> > of contradicts this nice clean delineation, since game data files often
> > include a scripting language for in-game logic.  That's not necessarily
> > a problem, merely an exception.  Personally I'm fine with it, but it
> > seems difficult to construct a (non-emotional) justification for it that
> > doesn't expand to cover win32 binaries or ROMs without source.
> 
> Well written, and I fully agree, except that besides an exception for game 
> data, I would also like to see an exception for system ROM's for old computers 
> like the amstrad, where amstrad has been so kind to allow free redistribution 
> of the roms. I'm not advocating to make the same exception for software that 
> ran on these old computers, merely for the code that was in ROM's _inside_ the 
> sytem and thus is needed for the emulator to function _at all_, to me this 
> clearly is firmware.

Yeah, that's pretty clearly firmware to me too.

- ajax



From sundaram at fedoraproject.org  Thu Oct 25 18:37:30 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 26 Oct 2007 00:07:30 +0530
Subject: Announcing rpmfusion
In-Reply-To: <64b14b300710251137y591bcb44x9c762a5a306cda36@mail.gmail.com>
References: <46E637DB.6060102@hhs.nl>
	<46E63E21.8020305@fedoraproject.org>	<loom.20070911T215813-142@post.gmane.org>	<20070911160537.696c6a25@localhost.localdomain>	<46E6F59B.7010506@fedoraproject.org>
	<64b14b300710251137y591bcb44x9c762a5a306cda36@mail.gmail.com>
Message-ID: <4720E26A.4060804@fedoraproject.org>

Valent Turkovic wrote:
> On 9/11/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>> Jesse Keating wrote:
>>> On Tue, 11 Sep 2007 20:02:40 +0000 (UTC)
>>> Kevin Kofler <kevin.kofler at chello.at> wrote:
>>>
>>>> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>>>>> Thanks for this split. Hopefully we will able to link to the free
>>>>> part from within Fedora.
>>>> Unfortunately I don't think you will be able to. The stuff in the
>>>> free part (or most of it, at least) is going to be exactly the stuff
>>>> which Legal is most uncomfortable with: Free Software, but
>>>> patent-encumbered in the US.
>>> And really, if we could reference it, then why the crap couldn't we
>>> just package it in our repo?
>> There is a lot of differences between pointing to the repository and
>> including the packages directly as I already explained in Fedora
>> Advisory Board list so I won't rehash all the arguments again now.
>> Please read the releated threads if you missed it. In short, it is not
>> possible to include patent-encumbered packages directly in the
>> repository as long as it hosted in US. Pointing to it might very well be
>> possible.
>>
>> Rahul
> 
> Yes! I cought a bit late on this thread but I can't be happier!
> I started a threat that asked this exact question: why doesn't fedora
> link to external repositories after users agreeing to some sort of
> ULA.
> 
> What is the update on this topic? 

We are still waiting on legal input.

Rahul



From valent.turkovic at gmail.com  Thu Oct 25 18:40:34 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 20:40:34 +0200
Subject: Announcing rpmfusion
In-Reply-To: <46E6F512.1070403@ncsu.edu>
References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org>
	<loom.20070911T215813-142@post.gmane.org> <46E6F512.1070403@ncsu.edu>
Message-ID: <64b14b300710251140t7a392fe8kd0294b7e06169cae@mail.gmail.com>

On 9/11/07, Casey Dahlin <cjdahlin at ncsu.edu> wrote:
> Kevin Kofler wrote:
> > Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> >
> >> Thanks for this split. Hopefully we will able to link to the free part
> >> from within Fedora.
> >>
> >
> > Unfortunately I don't think you will be able to. The stuff in the free part (or
> > most of it, at least) is going to be exactly the stuff which Legal is most
> > uncomfortable with: Free Software, but patent-encumbered in the US.
> >
> >
> There's a wide spectrum between "right in Fedora" and "not acknowledging
> its existence."
>
> Whereas before Red Hat became subject to liability for merely saying the
> word "Livna" in public, we might be able to move to a tacit and
> well-disclaimed "suggestion" that users use the Free half of rpmfusion.
> So we could go from having to say "Never heard of it" to being able to
> say "Its over there, and I know about it, but I really can't recommend
> that you use it (by clicking this button right here)"

ha, ha :) great idea the "don't click this button" button :)

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From notting at redhat.com  Thu Oct 25 18:43:42 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 14:43:42 -0400
Subject: multlib and splitting packages
In-Reply-To: <20071025141926.0f0a4d90@redhat.com>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<4720CD11.5070807@fedoraproject.org>
	<20071025180959.GB15925@nostromo.devel.redhat.com>
	<20071025141926.0f0a4d90@redhat.com>
Message-ID: <20071025184342.GB17228@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Probably best to add it to the 'dealing with multilib' page you
> referenced in all your bugs.

Done.

Bill



From valent.turkovic at gmail.com  Thu Oct 25 19:02:11 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 21:02:11 +0200
Subject: Announcing rpmfusion
In-Reply-To: <1189565218.4727.16.camel@localhost.localdomain>
References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org>
	<loom.20070911T215813-142@post.gmane.org>
	<20070911160537.696c6a25@localhost.localdomain>
	<1189557606.4727.14.camel@localhost.localdomain>
	<604aa7910709111753u54fce8a1pfa3ce53f843f0c17@mail.gmail.com>
	<1189565218.4727.16.camel@localhost.localdomain>
Message-ID: <64b14b300710251202n6dca2fbem69636fb2dc5dcade@mail.gmail.com>

On 9/12/07, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote:
> > On 9/11/07, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> > > The installer asks you to locate your time-zone.  Couldn't you use this
> > > as a trigger for including the US patent encumbered stuff for non US
> > > citizens.
> >
> > I'm pretty sure it would be just as inappropriate for me, as a US
> > citizen, to be in a US embassy in Spain as it would be for me to be in
> > Seattle.
>
> Okay, well then include a question about citizenship in the installer
> and use that!
>
>
> R.

Yup, I support that. There a lot of us - non US fedora users and we
would really welcome these changes.

Valent from Croatia.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From rdieter at math.unl.edu  Thu Oct 25 19:03:01 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 25 Oct 2007 14:03:01 -0500
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
Message-ID: <ffqp95$7a1$1@ger.gmane.org>

Bill Nottingham wrote:

> Just to note, if you fix multiarch conflicts by moving libraries to
> a -libs package, your new -libs package should obsolete the older
> versions of the package where the libraries came from. This is so
> that yum upgrades work properly.
> 
> For example, if you previously had:
> 
> foo-1.1-1.i386
> foo-1.1-1.x86_64
> 
> that had libraries, and had other file conflicts, and you split them
> into:
> 
> foo-1.1-2.x86_64
> foo-libs-1.1-2.i386
> foo-libs-1.1-2.x86_64
> 
> you should add:
> 
> Obsoletes: foo < 1.1-2
> 
> in the %package section for foo-libs.

I tested this out the other day (on f7), and this only works right if:
-libs includes: 
Requires: %{name} ...

Else, yum removed (Obsoletes) *all* instances of foo.

-- Rex



From pemboa at gmail.com  Thu Oct 25 19:09:56 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 25 Oct 2007 14:09:56 -0500
Subject: Announcing rpmfusion
In-Reply-To: <64b14b300710251202n6dca2fbem69636fb2dc5dcade@mail.gmail.com>
References: <46E637DB.6060102@hhs.nl> <46E63E21.8020305@fedoraproject.org>
	<loom.20070911T215813-142@post.gmane.org>
	<20070911160537.696c6a25@localhost.localdomain>
	<1189557606.4727.14.camel@localhost.localdomain>
	<604aa7910709111753u54fce8a1pfa3ce53f843f0c17@mail.gmail.com>
	<1189565218.4727.16.camel@localhost.localdomain>
	<64b14b300710251202n6dca2fbem69636fb2dc5dcade@mail.gmail.com>
Message-ID: <16de708d0710251209k3452d844i89401c86a553d018@mail.gmail.com>

On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> On 9/12/07, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> > On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote:
> > > On 9/11/07, Rodd Clarkson <rodd at clarkson.id.au> wrote:
> > > > The installer asks you to locate your time-zone.  Couldn't you use this
> > > > as a trigger for including the US patent encumbered stuff for non US
> > > > citizens.
> > >
> > > I'm pretty sure it would be just as inappropriate for me, as a US
> > > citizen, to be in a US embassy in Spain as it would be for me to be in
> > > Seattle.
> >
> > Okay, well then include a question about citizenship in the installer
> > and use that!
> >
> >
> > R.
>
> Yup, I support that. There a lot of us - non US fedora users and we
> would really welcome these changes.
>
> Valent from Croatia.


I'm technically a non US fedora user. But you gentlemen have to
understand the situation - RedHat's base is registered in the USA. And
RedHat's legal team has enough work to do defending itself from patent
trolls, and possibly Judases to really attempt to fight for things
like "boxed" codecs, etc.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From valent.turkovic at gmail.com  Thu Oct 25 19:11:03 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 21:11:03 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
Message-ID: <64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>

On 10/25/07, Peter Robinson <pbrobinson at gmail.com> wrote:
> > I followed instructions for installing fluendo mega codec pack and
> > copied all files to
> > /usr/lib/gstreamer-0.10/ under Fedora 8 test 3 (with latest updates)
> > but whenever I try to open different video files I still get message
> > from Totem that I need to go to fluendo site and get codecs...
> >
> > I then copied files also to ~/.gstreamer-0.10/plugins directory but
> > that doesn't help either...
> >
> > Any ideas? Should I file a bug? Am I doing something wrong?
>
> Does gst-inspect report the codecs? what about if you put them in a
> plugins directory in the .gstreamer (I think that's the one - not on
> my linux box atm) in your home dir. This is what I've done and they
> seem to work for me with basic testing.
>
> Pete

I first tried coping them to /usr/lib/gstreamer-0.10 when that failed
I copied them to $HOME/.gstreamer-0.10/plugins. Now I have them on
both places.


$ gst-inspect-0.10 | grep flu
fluac3dec: audio/ac3: no extensions
fluac3dec:  fluac3dec: AC3 decoder
flumpeg4vdec:  flumpeg4vdec: Fluendo MPEG-4 ASP Video Decoder
flumpeg2vdec:  flumpeg2vdec: Fluendo MPEG-2 Video Decoder
fluwmvdec:  fluwmvdec: Fluendo WMV Decoder
fluisodemux:  fluisodemux: ISODemux Demuxer
flumpegdemux:  flupsdemux: MPEG Program Demuxer
flumpegdemux:  flutsdemux: MPEG Transport stream demuxer
fluasf:  fluasfdemux: Fluendo ASF Demuxer
fluasf:  fluasfcmdparse: Fluendo ASF Command Parser
flumms:  flummssrc: Fluendo MMS source
fluwmadec:  fluwmadec: Fluendo WMA Decoder
flump3dec:  flump3dec: Fluendo MP3 Decoder (IPP build)


I copied fluendo codec files to $HOME/.gstreamer-0.10/plugins in
openSuse 10.3 and it worked with some videos that previously it
didn't. Namely it worked with one mpeg1 file named bespring.mpg the
same file under same player on Fedora 8 test 3 gives this error:


$ totem /data/bedspring.mpg

(totem:3725): GStreamer-WARNING **: Failed to load plugin
'/home/fedora8test3/.gstreamer-0.10/plugins/libgstfluac3dec.so':
/home/fedora8test3/.gstreamer-0.10/plugins/libgstfluac3dec.so: cannot
restore segment prot after reloc: Permission denied

(totem:3725): GStreamer-WARNING **: Failed to load plugin
'/home/fedora8test3/.gstreamer-0.10/plugins/libgstflumpeg2vdec.so':
/home/fedora8test3/.gstreamer-0.10/plugins/libgstflumpeg2vdec.so:
cannot restore segment prot after reloc: Permission denied
** Message: don't know how to handle video/mpeg, mpegversion=(int)1,
systemstream=(boolean)false
** Message: Missing plugin: gstreamer|0.10|totem|MPEG-1 Video
decoder|decoder-video/mpeg, mpegversion=(int)1,
systemstream=(boolean)false (MPEG-1 Video decoder)
XID: 77594627


Any ideas?

Does this look to you like totem of fluendo bug?

Valent.
-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From fherrera at onirica.com  Thu Oct 25 19:15:50 2007
From: fherrera at onirica.com (Fernando Herrera)
Date: Thu, 25 Oct 2007 22:15:50 +0300
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
Message-ID: <121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>

On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> /home/fedora8test3/.gstreamer-0.10/plugins/libgstfluac3dec.so: cannot
> restore segment prot after reloc: Permission denied

Selinux :)

chcon -t texrel_shlib_t /home/fedora8test3l/.gstreamer-0.10/plugins/*.so

Salu2



From valent.turkovic at gmail.com  Thu Oct 25 19:32:46 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 21:32:46 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
Message-ID: <64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>

On 10/25/07, Fernando Herrera <fherrera at onirica.com> wrote:
> On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > /home/fedora8test3/.gstreamer-0.10/plugins/libgstfluac3dec.so: cannot
> > restore segment prot after reloc: Permission denied
>
> Selinux :)
>
> chcon -t texrel_shlib_t /home/fedora8test3l/.gstreamer-0.10/plugins/*.so
>
> Salu2
>

Thank you, thank you, thank you :)

chcon -t textrel_shlib_t ~/.gstreamer-0.10/plugins/*

this fixes the issue :)

where and to whom should I post bug in order for selinux not to stop
fluendo codecs from working?

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From sundaram at fedoraproject.org  Thu Oct 25 19:35:58 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 26 Oct 2007 01:05:58 +0530
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
Message-ID: <4720F01E.9030802@fedoraproject.org>

Valent Turkovic wrote:

> Thank you, thank you, thank you :)
> 
> chcon -t textrel_shlib_t ~/.gstreamer-0.10/plugins/*
> 
> this fixes the issue :)
> 
> where and to whom should I post bug in order for selinux not to stop
> fluendo codecs from working?

Ideally Fluendo should fix their code. Otherwise you can file a bug 
report against SELinux policy and see if they are agreeable to 
workaround this.

Rahul



From ville.skytta at iki.fi  Thu Oct 25 19:50:20 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 25 Oct 2007 22:50:20 +0300
Subject: multlib and splitting packages
In-Reply-To: <20071025180959.GB15925@nostromo.devel.redhat.com>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<4720CD11.5070807@fedoraproject.org>
	<20071025180959.GB15925@nostromo.devel.redhat.com>
Message-ID: <200710252250.20984.ville.skytta@iki.fi>

On Thursday 25 October 2007, Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said:
> > Bill Nottingham wrote:
> >> Just to note, if you fix multiarch conflicts by moving libraries to
> >> a -libs package, your new -libs package should obsolete the older
> >> versions of the package where the libraries came from. This is so
> >> that yum upgrades work properly.
> >
> > Please add this to the packaging guidelines.
>
> I'm not seeing an obvious place that this fits.

NamingGuidelines has a chapter that discusses renaming/replacing packages, I 
suppose this would fit pretty nicely there.  Or while at it the whole section 
perhaps moved from NamingGuidelines to somewhere else.

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d



From rdieter at math.unl.edu  Thu Oct 25 19:59:42 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 25 Oct 2007 14:59:42 -0500
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<ffqp95$7a1$1@ger.gmane.org>
Message-ID: <ffqsje$k71$1@ger.gmane.org>

Rex Dieter wrote:

> Bill Nottingham wrote:
> 
>> Just to note, if you fix multiarch conflicts by moving libraries to
>> a -libs package, your new -libs package should obsolete the older
>> versions of the package where the libraries came from. This is so
>> that yum upgrades work properly.
>> 
>> For example, if you previously had:
>> 
>> foo-1.1-1.i386
>> foo-1.1-1.x86_64
>> 
>> that had libraries, and had other file conflicts, and you split them
>> into:
>> 
>> foo-1.1-2.x86_64
>> foo-libs-1.1-2.i386
>> foo-libs-1.1-2.x86_64
>> 
>> you should add:
>> Obsoletes: foo < 1.1-2
>> in the %package section for foo-libs.
> 
> I tested this out the other day (on f7), and this only works right if:
> -libs includes:
> Requires: %{name} ...
> 
> Else, yum removed (Obsoletes) *all* instances of foo.

I take it back, with yum-3.2.7, it works beautifully.

-- Rex



From ajackson at redhat.com  Thu Oct 25 19:42:53 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 25 Oct 2007 15:42:53 -0400
Subject: BIG FAT WARNING: Breaking X in rawhide
Message-ID: <1193341373.15341.52.camel@localhost.localdomain>

Hopefully I have your attention.

We're working on a lot of stuff that's going into upstream X really
soon.  It's going to be quite disruptive, many drivers will fail to
launch, etc.  Good stuff, but disruptive.

I want to rebase rawhide to git xserver really soon, before November if
possible but definitely before December.  I'll work to make sure most
people can get _some_ X when that happens, but it's definitely going to
hurt for about a month.

I want to make sure everyone knows this is coming, and if anyone has
suggestions for how to time this best and communicate all the caveats
and workarounds, please, speak up now.

- ajax



From che666 at gmail.com  Thu Oct 25 20:18:28 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Thu, 25 Oct 2007 22:18:28 +0200
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193341373.15341.52.camel@localhost.localdomain>
References: <1193341373.15341.52.camel@localhost.localdomain>
Message-ID: <e99d27470710251318r2bfb0e2ei353b3bda97a1afaf@mail.gmail.com>

On 10/25/07, Adam Jackson <ajackson at redhat.com> wrote:
> Hopefully I have your attention.
>
> We're working on a lot of stuff that's going into upstream X really
> soon.  It's going to be quite disruptive, many drivers will fail to
> launch, etc.  Good stuff, but disruptive.
>
> I want to rebase rawhide to git xserver really soon, before November if
> possible but definitely before December.  I'll work to make sure most
> people can get _some_ X when that happens, but it's definitely going to
> hurt for about a month.

Actually announcing this again a few days before it happens would
definitely be nice for a permanent rawhide tester :). Not that i cant
survive without X but in that case i would just
be more careful and not update while i am on the road.

thanks,
Rudolf Kastl
>
> - ajax
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From kevin.kofler at chello.at  Thu Oct 25 20:38:25 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 20:38:25 +0000 (UTC)
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
Message-ID: <loom.20071025T203314-276@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> Just to note, if you fix multiarch conflicts by moving libraries to
> a -libs package, your new -libs package should obsolete the older
> versions of the package where the libraries came from. This is so
> that yum upgrades work properly.

This hack is a bad idea, it breaks APT-RPM! (Even for non-multilib systems!)

I just tested this hack with a dummy package: I have installed a package called 
multilib-obsoletes-test Version: 1, Release: 1, then put 1-2 into a test repo 
(created just for this purpose), with a -libs subpackage which obsoletes 
multilib-obsoletes-test < 1-2. This confuses apt-get dist-upgrade, which reacts 
the following way:
The following packages have been kept back
   multilib-obsoletes-test (1-1 => 1-2)
In other words, it gets confused by the hack, and it won't update the package 
at all!

Doing apt-get install multilib-obsoletes-test or apt-get install 
multilib-obsoletes-test-libs by hand will do the right thing, but breaking the 
dist-upgrade is bad.

An if the packager used this idiom:
Obsoletes: %{name} < %{?epoch:%{epoch}:}%{version}-%{release}
i.e. is bumping the Obsoletes with each release, then EVERY SINGLE UPGRADE of 
the affected package with apt-rpm will break!

Please test your hacks with apt and smart too.

        Kevin Kofler



From skvidal at fedoraproject.org  Thu Oct 25 20:40:38 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 25 Oct 2007 16:40:38 -0400
Subject: multlib and splitting packages
In-Reply-To: <loom.20071025T203314-276@post.gmane.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
Message-ID: <1193344838.7863.15.camel@cutter>


On Thu, 2007-10-25 at 20:38 +0000, Kevin Kofler wrote:
> Bill Nottingham <notting <at> redhat.com> writes:
> > Just to note, if you fix multiarch conflicts by moving libraries to
> > a -libs package, your new -libs package should obsolete the older
> > versions of the package where the libraries came from. This is so
> > that yum upgrades work properly.
> 
> This hack is a bad idea, it breaks APT-RPM! (Even for non-multilib systems!)
> 
> I just tested this hack with a dummy package: I have installed a package called 
> multilib-obsoletes-test Version: 1, Release: 1, then put 1-2 into a test repo 
> (created just for this purpose), with a -libs subpackage which obsoletes 
> multilib-obsoletes-test < 1-2. This confuses apt-get dist-upgrade, which reacts 
> the following way:
> The following packages have been kept back
>    multilib-obsoletes-test (1-1 => 1-2)
> In other words, it gets confused by the hack, and it won't update the package 
> at all!
> 

it sounds like apt is doing updates then obsoletes in its processing?
Have you reported this as a bug, yet?


-sv




From jkeating at redhat.com  Thu Oct 25 20:42:00 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 25 Oct 2007 16:42:00 -0400
Subject: multlib and splitting packages
In-Reply-To: <loom.20071025T203314-276@post.gmane.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
Message-ID: <20071025164200.5ffd11e8@redhat.com>

On Thu, 25 Oct 2007 20:38:25 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Doing apt-get install multilib-obsoletes-test or apt-get install 
> multilib-obsoletes-test-libs by hand will do the right thing, but
> breaking the dist-upgrade is bad.
> 
> An if the packager used this idiom:
> Obsoletes: %{name} < %{?epoch:%{epoch}:}%{version}-%{release}
> i.e. is bumping the Obsoletes with each release, then EVERY SINGLE
> UPGRADE of the affected package with apt-rpm will break!
> 
> Please test your hacks with apt and smart too.

Apt and smart need to be adjusted to work with this.  yum is our
package tool of choice and the tool we'll develop our policies and
procedures around.  It's up to the ancillary package tools to be
compatible with Fedora, not the other way around.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/72d15cf8/attachment.sig>

From notting at redhat.com  Thu Oct 25 20:44:30 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 16:44:30 -0400
Subject: multlib and splitting packages
In-Reply-To: <loom.20071025T203314-276@post.gmane.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
Message-ID: <20071025204430.GC23259@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> Bill Nottingham <notting <at> redhat.com> writes:
> > Just to note, if you fix multiarch conflicts by moving libraries to
> > a -libs package, your new -libs package should obsolete the older
> > versions of the package where the libraries came from. This is so
> > that yum upgrades work properly.
> 
> This hack is a bad idea, it breaks APT-RPM! (Even for non-multilib systems!)

This solution works in:

- rpm
- yum

i.e., both the default depedency solvers.

Moreover, it has already been used in packages that shipped in Fedora 7, and
there were no complaints then.

Bill



From valent.turkovic at gmail.com  Thu Oct 25 20:53:06 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 22:53:06 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <4720F01E.9030802@fedoraproject.org>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
Message-ID: <64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>

On 10/25/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Valent Turkovic wrote:
>
> > Thank you, thank you, thank you :)
> >
> > chcon -t textrel_shlib_t ~/.gstreamer-0.10/plugins/*
> >
> > this fixes the issue :)
> >
> > where and to whom should I post bug in order for selinux not to stop
> > fluendo codecs from working?
>
> Ideally Fluendo should fix their code. Otherwise you can file a bug
> report against SELinux policy and see if they are agreeable to
> workaround this.
>
> Rahul
>

Agreed. I reopened the ticket on their bugtracker:
https://core.fluendo.com/gstreamer/trac/ticket/54

Thank all of you for your help.

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From kevin.kofler at chello.at  Thu Oct 25 20:55:19 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 20:55:19 +0000 (UTC)
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
	<1193344838.7863.15.camel@cutter>
Message-ID: <loom.20071025T205435-760@post.gmane.org>

seth vidal <skvidal <at> fedoraproject.org> writes:
> it sounds like apt is doing updates then obsoletes in its processing?

I don't know how it happens, I just know it doesn't work.

> Have you reported this as a bug, yet?

No, I just noticed it, filing now.

        Kevin Kofler



From valent.turkovic at gmail.com  Thu Oct 25 20:56:24 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 25 Oct 2007 22:56:24 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
Message-ID: <64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>

https://core.fluendo.com/gstreamer/trac/ticket/24
previous link was a duplicate, sorry.

Valent.



From kevin.kofler at chello.at  Thu Oct 25 20:56:17 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 20:56:17 +0000 (UTC)
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
	<20071025204430.GC23259@nostromo.devel.redhat.com>
Message-ID: <loom.20071025T205532-544@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> Moreover, it has already been used in packages that shipped in Fedora 7, and
> there were no complaints then.

Hmmm, that might explain why some updates have been held back for reasons I 
didn't understand, must have been this exact problem.

        Kevin Kofler



From notting at redhat.com  Thu Oct 25 21:00:52 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Oct 2007 17:00:52 -0400
Subject: multlib and splitting packages
In-Reply-To: <loom.20071025T205532-544@post.gmane.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
	<20071025204430.GC23259@nostromo.devel.redhat.com>
	<loom.20071025T205532-544@post.gmane.org>
Message-ID: <20071025210052.GD23259@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> Bill Nottingham <notting <at> redhat.com> writes:
> > Moreover, it has already been used in packages that shipped in Fedora 7, and
> > there were no complaints then.
> 
> Hmmm, that might explain why some updates have been held back for reasons I 
> didn't understand, must have been this exact problem.

Both hal and mkinitrd use this construct already.

Bill



From kevin.kofler at chello.at  Thu Oct 25 21:15:28 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 25 Oct 2007 21:15:28 +0000 (UTC)
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
	<1193344838.7863.15.camel@cutter>
	<loom.20071025T205435-760@post.gmane.org>
Message-ID: <loom.20071025T211435-963@post.gmane.org>

I wrote:
> No, I just noticed it, filing now.

Filed: https://bugzilla.redhat.com/show_bug.cgi?id=353271

        Kevin Kofler



From darrellpf at gmail.com  Thu Oct 25 21:22:27 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Thu, 25 Oct 2007 14:22:27 -0700
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193341373.15341.52.camel@localhost.localdomain>
References: <1193341373.15341.52.camel@localhost.localdomain>
Message-ID: <f6e5806f0710251422w42045253t6d64d3b613502622@mail.gmail.com>

On 10/25/07, Adam Jackson <ajackson at redhat.com> wrote:
> Hopefully I have your attention.
>
> We're working on a lot of stuff that's going into upstream X really
> soon.  It's going to be quite disruptive, many drivers will fail to
> launch, etc.  Good stuff, but disruptive.
>

As a daily rawhide update addict I really appreciate the warning.

Over the last few years I've developed a few skills to mitigate and
undo the breakage.

My usual reaction is just to back out the changes, particularly with
obviously new stuff. During the breakage, if you can provide hints or
workarounds, or indications of any specifics you'd like to see in bug
reports, I'm happy to help do a bit of debugging.

darrell



From cebbert at redhat.com  Thu Oct 25 21:33:38 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Thu, 25 Oct 2007 17:33:38 -0400
Subject: ALSA 1.0.15 update test kernels available
Message-ID: <47210BB2.3040201@redhat.com>

We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
would get us up-to-date with the latest audio drivers and fix many
problems with audio drivers not working, or only partially working.

Test kernels for i686 and x86_64 are available at:

  http://people.redhat.com/cebbert/kernels/F8/

Also, kernel 2.6.23.1-36 has the update and is now building.

It would be very helpful if people would test these kernels and reply
to this message with their experiences, so we can see if this update
causes any problems.



From orion at cora.nwra.com  Thu Oct 25 21:38:29 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 25 Oct 2007 15:38:29 -0600
Subject: Why is my %dist resolving to rh8?
Message-ID: <47210CD5.2050207@cora.nwra.com>

Looks like we've wrapped into redhat version numbers:

  dist       %{expand:%%(if echo %{distlong} | grep "[^0-9.]"> 
/dev/null; then
   echo .%{rheldist}
else
   case "%{distlong}" in
     ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" )
     echo .%{rhldist}
     ;;
     ( "1" | "2" | "3" | "4" | "5" | "6" )
     echo .%{fcdist}
     ;;
   esac;
   if echo %{distlong} | grep "[^0-9]" > /dev/null; then
     if [ %{distsver} -ge 90 ]; then
       echo .%{fctdist}
     fi
   fi
fi;)}


Time to drop the rhldist stuff?

Can't figure out where this is defined though...


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From mmcgrath at redhat.com  Thu Oct 25 21:49:34 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 25 Oct 2007 16:49:34 -0500
Subject: Koji issues
Message-ID: <47210F6E.6020102@redhat.com>

We've had a couple of issues with the koji master today OOMing.  We were 
planning on building a newer and better koji master (one thats 
clustered) but now is not a good time in the release cycle to do it.  
Needless to say if we continue to have these issues we may just have to 
migrate now.  Stop by #fedora-admin if you have any questions, 
unfortunately I don't know any more at this time.  We're keeping an eye 
on it.

    -Mike



From ml at deadbabylon.de  Thu Oct 25 22:00:19 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Fri, 26 Oct 2007 00:00:19 +0200
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
Message-ID: <200710260000.24041.ml@deadbabylon.de>

Hi.

Since beryl is sadly being removed from the repository, KDE users don't have 
the ability to easily switch from kwin to compiz and back again. The KDE-SIG 
was asked to write such a tool but after the confirmation [1] that compiz 
wouldn't obsolete beryl it hasn't become primary attention.

After the removal of beryl I've modified a script by Kevin Kofler so that it 
uses compiz-manager to switch between compiz and kwin. compiz-manager itself 
passed review today (but isn't branched yet). [2]

The switching script itself should go into compiz-kde and so I've modified the 
latest compiz.spec to include this. But I must fairly say that this is only 
tested by me.

My question is: 
Is it anyhow possible to include the script into compiz-kde and compiz-manager 
in f8final to enable KDE users to use compiz in an easy way (and also on the 
live images where possible)?

The tarball with the script and the patch for compiz.spec could be downloaded 
here: http://www.deadbabylon.de/files/compiz-kde/

Sebastian

P.S.: I want to ask this on fedora-devel first to get bigger audience.


[1] 
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00202.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=349621
-------------- 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/20071026/4884c680/attachment.sig>

From lightsolphoenix at gmail.com  Thu Oct 25 22:24:18 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 25 Oct 2007 18:24:18 -0400
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
 compiz
In-Reply-To: <200710260000.24041.ml@deadbabylon.de>
References: <200710260000.24041.ml@deadbabylon.de>
Message-ID: <47211792.8030105@gmail.com>

Sebastian Vahl wrote:
> Hi.
>
> Since beryl is sadly being removed from the repository, KDE users don't have 
> the ability to easily switch from kwin to compiz and back again. The KDE-SIG 
> was asked to write such a tool but after the confirmation [1] that compiz 
> wouldn't obsolete beryl it hasn't become primary attention.
>   
Um, when I tested out the new version of compiz on openSUSE, I noticed 
that compiz itself seems to have a tool for switching between window 
managers.  It seemed to work fine for me in KDE.



From ml at deadbabylon.de  Thu Oct 25 22:28:51 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Fri, 26 Oct 2007 00:28:51 +0200
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <47211792.8030105@gmail.com>
References: <200710260000.24041.ml@deadbabylon.de> <47211792.8030105@gmail.com>
Message-ID: <200710260028.51648.ml@deadbabylon.de>

Am Fr 26.Oktober 2007 schrieb Kelly Miller:
> Sebastian Vahl wrote:
> > Hi.
> >
> > Since beryl is sadly being removed from the repository, KDE users don't
> > have the ability to easily switch from kwin to compiz and back again. The
> > KDE-SIG was asked to write such a tool but after the confirmation [1]
> > that compiz wouldn't obsolete beryl it hasn't become primary attention.
>
> Um, when I tested out the new version of compiz on openSUSE, I noticed
> that compiz itself seems to have a tool for switching between window
> managers.  It seemed to work fine for me in KDE.

Do you remember the name of that tool? AFAIK suse also includes 
compiz-manager, eg see: http://en.opensuse.org/Compiz-Fusion

Maybe this is fusion-icon? But that has no official release, yet.

Sebastian


-------------- 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/20071026/8504b0d6/attachment.sig>

From drago01 at gmail.com  Thu Oct 25 22:33:10 2007
From: drago01 at gmail.com (dragoran)
Date: Fri, 26 Oct 2007 00:33:10 +0200
Subject: Multiarch crazyiness
In-Reply-To: <20071025174507.GA2549@nostromo.devel.redhat.com>
References: <1193011897.5168.52.camel@perihelion>
	<1193013121.5168.68.camel@perihelion> <471C64C4.2090705@redhat.com>
	<20071022085313.GB2941@free.fr> <471CACBD.2080706@redhat.com>
	<20071022100132.76f33bbd@redhat.com>
	<20071022185644.GG9625@nostromo.devel.redhat.com>
	<1193080444.28655.8.camel@rousalka.dyndns.org>
	<20071022192036.GH9625@nostromo.devel.redhat.com>
	<20071025174507.GA2549@nostromo.devel.redhat.com>
Message-ID: <f6ca9fed0710251533o76718842n82586a4b8dcfbf26@mail.gmail.com>

On 10/25/07, Bill Nottingham <notting at redhat.com> wrote:
> Bill Nottingham (notting at redhat.com) said:
> > Nicolas Mailhot (nicolas.mailhot at laposte.net) said:
> > > > So, on upgrade, yum will grab foo.x86_64 to upgrade the older install. It
> > > > will then pull in foo-libs.x86_64 for dependencies. Meanwhile, the old
> > > > foo.i386 will remain, often leading to conflicts.
> > >
> > > Wouldn't an Obsoletes: foo < current_version fix this? Unless we want to
> > > ship 32bit & 64bit versions of foo in the same repo
> >
> > It *should*; need some more testing so this can be 100% codified.
>
> Yes, obsoletes works here.

even thought it requires a bit of work its imho the best solution to
fix the bindir issue.



From mclasen at redhat.com  Thu Oct 25 22:38:12 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 25 Oct 2007 18:38:12 -0400
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193341373.15341.52.camel@localhost.localdomain>
References: <1193341373.15341.52.camel@localhost.localdomain>
Message-ID: <1193351892.11902.4.camel@localhost.localdomain>


On Thu, 2007-10-25 at 15:42 -0400, Adam Jackson wrote:
> Hopefully I have your attention.
> 
> We're working on a lot of stuff that's going into upstream X really
> soon.  It's going to be quite disruptive, many drivers will fail to
> launch, etc.  Good stuff, but disruptive.
> 
> I want to rebase rawhide to git xserver really soon, before November if
> possible but definitely before December.  I'll work to make sure most
> people can get _some_ X when that happens, but it's definitely going to
> hurt for about a month.
> 
> I want to make sure everyone knows this is coming, and if anyone has
> suggestions for how to time this best and communicate all the caveats
> and workarounds, please, speak up now.

I'd say it would be best to break X right at the beginning of the cycle.
People who are not ready for it can just stay with stable F8 for a while
then, while we have the maximal time to fix it up.



From lightsolphoenix at gmail.com  Thu Oct 25 22:57:09 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 25 Oct 2007 18:57:09 -0400
Subject: Feedback from PulseAudio 0.9.7 SVN (Was: Current problems with
	Rawhide)
In-Reply-To: <c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<1193240595.25405.126.camel@cookie.hadess.net>	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
Message-ID: <47211F45.30303@gmail.com>

I managed to figure out the problem with PulseAudio giving me errors 
related to the ALSA devices; however, it still doesn't seem to be 
working correctly.  I've noticed it's mostly fine if I send sound 
through ALSA to PulseAudio, but if I use something that uses either 
PulseAudio or ESound plugins, things quickly go south.  In fact, it 
looks to me from the play record that PulseAudio is forgetting to shut 
down ESound streams after it is done with them (if I play audio through 
xine's esd plugin, I can get as many separate dead threads as I feel 
like appearing in paman, none of which are actually doing anything, 
which is when PulseAudio's use jumps to 70% and it kills itself).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulse-log.log
Type: text/x-log
Size: 18594 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/224fa697/attachment.bin>

From cebbert at redhat.com  Thu Oct 25 23:18:58 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Thu, 25 Oct 2007 19:18:58 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47210BB2.3040201@redhat.com>
References: <47210BB2.3040201@redhat.com>
Message-ID: <47212462.2040301@redhat.com>

On 10/25/2007 05:33 PM, Chuck Ebbert wrote:
> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.
> 

Please reply on fedora-test-list...



From laurent.rineau__fedora at normalesup.org  Thu Oct 25 23:33:40 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Fri, 26 Oct 2007 01:33:40 +0200
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <200710260000.24041.ml@deadbabylon.de>
References: <200710260000.24041.ml@deadbabylon.de>
Message-ID: <200710260133.40391@rineau.tsetse>

On Friday 26 October 2007 00:00:19 Sebastian Vahl wrote:
> After the removal of beryl I've modified a script by Kevin Kofler so that
> it uses compiz-manager to switch between compiz and kwin. compiz-manager
> itself passed review today (but isn't branched yet). [2]
>
> The switching script itself should go into compiz-kde and so I've modified
> the latest compiz.spec to include this. But I must fairly say that this is
> only tested by me.

I just tested your package. After having launched it from the KDE menu, it 
displays a very simple popup menu, that allows to choose between compiz or 
KWin. It is far from the possibility of the old beryl-manager. I am looking 
forward to a full port of beryl-manager to compiz-fusion.

The following line in kde-desktop-effects.sh are useless, because one cannot 
see them when launched outside of a terminal (eg with the KDE menu or the 
ALT-F2 launcher):
   echo "Save choice window manager to use it on next startup of KDE"
   echo "Remove ~/.kde/env/kdewm.sh if you encounter problems."

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From ndbecker2 at gmail.com  Thu Oct 25 23:53:48 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 25 Oct 2007 19:53:48 -0400
Subject: ALSA 1.0.15 update test kernels available
References: <47210BB2.3040201@redhat.com>
Message-ID: <ffraac$v7c$1@ger.gmane.org>

Chuck Ebbert wrote:

> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.
> 

Works great here.
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)

Only tiny problem, I have a little touch sensitive volume control.  Right
now, it seems to control the headphone volume.  Wonder how to make it
control something else (maybe master volume?)



From ml at deadbabylon.de  Thu Oct 25 23:52:58 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Fri, 26 Oct 2007 01:52:58 +0200
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <200710260133.40391@rineau.tsetse>
References: <200710260000.24041.ml@deadbabylon.de>
	<200710260133.40391@rineau.tsetse>
Message-ID: <200710260153.03963.ml@deadbabylon.de>

Am Fr 26.Oktober 2007 schrieb Laurent Rineau:
> On Friday 26 October 2007 00:00:19 Sebastian Vahl wrote:
> > After the removal of beryl I've modified a script by Kevin Kofler so that
> > it uses compiz-manager to switch between compiz and kwin. compiz-manager
> > itself passed review today (but isn't branched yet). [2]
> >
> > The switching script itself should go into compiz-kde and so I've
> > modified the latest compiz.spec to include this. But I must fairly say
> > that this is only tested by me.
>
> I just tested your package. After having launched it from the KDE menu, it
> displays a very simple popup menu, that allows to choose between compiz or
> KWin. It is far from the possibility of the old beryl-manager. I am looking
> forward to a full port of beryl-manager to compiz-fusion.

This port would be (in some way) fusion-icon. But this one doesn't have an 
official release, yet.

>
> The following line in kde-desktop-effects.sh are useless, because one
> cannot see them when launched outside of a terminal (eg with the KDE menu
> or the ALT-F2 launcher):
>    echo "Save choice window manager to use it on next startup of KDE"
>    echo "Remove ~/.kde/env/kdewm.sh if you encounter problems."

I know. I've inlcuded the "echo" messages to maybe help some debugging in user 
forums (where the call for starting a script is a normal procedure).

Sebastian
-------------- 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/20071026/f217e3ff/attachment.sig>

From ndbecker2 at gmail.com  Thu Oct 25 23:58:25 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 25 Oct 2007 19:58:25 -0400
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
References: <200710260000.24041.ml@deadbabylon.de> <47211792.8030105@gmail.com>
	<200710260028.51648.ml@deadbabylon.de>
Message-ID: <ffraj1$vve$1@ger.gmane.org>

Sebastian Vahl wrote:

> Am Fr 26.Oktober 2007 schrieb Kelly Miller:
>> Sebastian Vahl wrote:
>> > Hi.
>> >
>> > Since beryl is sadly being removed from the repository, KDE users don't
>> > have the ability to easily switch from kwin to compiz and back again.
>> > The KDE-SIG was asked to write such a tool but after the confirmation
>> > [1] that compiz wouldn't obsolete beryl it hasn't become primary
>> > attention.
>>
>> Um, when I tested out the new version of compiz on openSUSE, I noticed
>> that compiz itself seems to have a tool for switching between window
>> managers.  It seemed to work fine for me in KDE.
> 
> Do you remember the name of that tool? AFAIK suse also includes
> compiz-manager, eg see: http://en.opensuse.org/Compiz-Fusion
> 
> Maybe this is fusion-icon? But that has no official release, yet.
> 
> Sebastian

Also, how are you configuring compiz?  I grabbed the ccsm (which is
currently under review).  It looks nice, except it doesn't seem to do
anything.  You can choose lots of options, but I don't see anything like
an 'apply' button.



From ml at deadbabylon.de  Fri Oct 26 00:04:49 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Fri, 26 Oct 2007 02:04:49 +0200
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <ffraj1$vve$1@ger.gmane.org>
References: <200710260000.24041.ml@deadbabylon.de>
	<200710260028.51648.ml@deadbabylon.de> <ffraj1$vve$1@ger.gmane.org>
Message-ID: <200710260204.52573.ml@deadbabylon.de>

Am Fr 26.Oktober 2007 schrieb Neal Becker:
> Sebastian Vahl wrote:
> > Am Fr 26.Oktober 2007 schrieb Kelly Miller:
> >> Sebastian Vahl wrote:
> >> > Hi.
> >> >
> >> > Since beryl is sadly being removed from the repository, KDE users
> >> > don't have the ability to easily switch from kwin to compiz and back
> >> > again. The KDE-SIG was asked to write such a tool but after the
> >> > confirmation [1] that compiz wouldn't obsolete beryl it hasn't become
> >> > primary attention.
> >>
> >> Um, when I tested out the new version of compiz on openSUSE, I noticed
> >> that compiz itself seems to have a tool for switching between window
> >> managers.  It seemed to work fine for me in KDE.
> >
> > Do you remember the name of that tool? AFAIK suse also includes
> > compiz-manager, eg see: http://en.opensuse.org/Compiz-Fusion
> >
> > Maybe this is fusion-icon? But that has no official release, yet.
> >
> > Sebastian
>
> Also, how are you configuring compiz?  I grabbed the ccsm (which is
> currently under review).  It looks nice, except it doesn't seem to do
> anything.  You can choose lots of options, but I don't see anything like
> an 'apply' button.

This is done by compiz-manager. ATM it is: compiz --replace glib gconf
Until compizconfig-backend-kconfig gets into Fedora. But I'm open for 
suggestions.

ccsm has no ability to _start_ compiz, just to configure it's options.

Sebastian

-------------- 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/20071026/696241e2/attachment.sig>

From mzerqung at 0pointer.de  Fri Oct 26 00:24:19 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 26 Oct 2007 02:24:19 +0200
Subject: Feedback from PulseAudio 0.9.7 SVN (Was: Current problems with
	Rawhide)
In-Reply-To: <472020BB.9080804@gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
	<472020BB.9080804@gmail.com>
Message-ID: <20071026002419.GA8549@tango.0pointer.de>

On Thu, 25.10.07 00:51, Kelly Miller (lightsolphoenix at gmail.com) wrote:

Hi!

> Okay, I'm attaching my logs related to PulseAudio to this email.  I hope
> someone can tell me the right place to go.

Those logs don't tell much. Except that PA cannot get hold of the
audio device because some other process is using it.

> I guess it's important to describe the setup as well.  I'm using
> alsa-plugins-pulse to redirect ALSA sound to PulseAudio, so pcm.default!
> and ctl.default! are both set to module: pulse.  The actual hardware is
> aliased as hw:0 (I keep getting errors that it's busy, even though nothing
> is running that would use sound because I automatically kill aRts before I
> start PulseAudio, and none of the other sound daemons are
> running...)

Try fuser -v /dev/snd/*

It will tell you which processes have opened your audio devices.

> BTW, for some odd reason, Thunderbird seems to pass between a phase of
> being fine and a phase where it takes up 90% of the system resources and
> grinds to a halt for a period of time.  I'm not sure what's up with that,
> either...

I'd bet this is not PA's fault ;-)

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From yabraham2 at gmail.com  Fri Oct 26 00:48:58 2007
From: yabraham2 at gmail.com (yonas Abraham)
Date: Thu, 25 Oct 2007 20:48:58 -0400
Subject: Package XYZ is not signed
Message-ID: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>

yum update fedora-release-notes

produce

Package fedora-release-notes-8.0.0-2.noarch.rpm is not signed


this is true for about 16 pakages on my Rahwid system today

/Yonas



From nando at ccrma.Stanford.EDU  Fri Oct 26 00:59:43 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Thu, 25 Oct 2007 17:59:43 -0700
Subject: repoview & templates in Fedora site
In-Reply-To: <1193334473.3517.39.camel@cutter>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
	<1193334473.3517.39.camel@cutter>
Message-ID: <1193360383.15465.20.camel@cmn3.stanford.edu>

On Thu, 2007-10-25 at 13:47 -0400, seth vidal wrote:
> On Thu, 2007-10-25 at 10:45 -0700, Fernando Lopez-Lezcano wrote:
> > Hi all, is there a place where the "modified" repoview used in the
> > Fedora site could be found? I really could use the layout (where package
> > pages do not include the version in their name). I'm trying to tweak the
> > original 0.5.2 to get the same result but it is not that easy...
> > 
> 
> 1. use repoview 0.6
> 2. I've got some fedora-specific ones, now that'll be in the repoview
> pkg in f8 this afternoon.

Here?
ftp://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/

-- Fernando




From david at lovesunix.net  Fri Oct 26 01:36:48 2007
From: david at lovesunix.net (David Nielsen)
Date: Fri, 26 Oct 2007 03:36:48 +0200
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193341373.15341.52.camel@localhost.localdomain>
References: <1193341373.15341.52.camel@localhost.localdomain>
Message-ID: <1193362628.3411.15.camel@dawkins>


tor, 25 10 2007 kl. 15:42 -0400, skrev Adam Jackson:
> Hopefully I have your attention.
> 
> We're working on a lot of stuff that's going into upstream X really
> soon.  It's going to be quite disruptive, many drivers will fail to
> launch, etc.  Good stuff, but disruptive.
> 
> I want to rebase rawhide to git xserver really soon, before November if
> possible but definitely before December.  I'll work to make sure most
> people can get _some_ X when that happens, but it's definitely going to
> hurt for about a month.
> 
> I want to make sure everyone knows this is coming, and if anyone has
> suggestions for how to time this best and communicate all the caveats
> and workarounds, please, speak up now.

Could I convince you to do a brief little write up as to what wonderous
magic this will bring us, I mean aside the fun breakage.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/b372e7ea/attachment.sig>

From airlied at redhat.com  Fri Oct 26 11:46:42 2007
From: airlied at redhat.com (Dave Airlie)
Date: Fri, 26 Oct 2007 21:46:42 +1000
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193362628.3411.15.camel@dawkins>
References: <1193341373.15341.52.camel@localhost.localdomain>
	<1193362628.3411.15.camel@dawkins>
Message-ID: <1193399202.26495.19.camel@clockmaker.usersys.redhat.com>

On Fri, 2007-10-26 at 03:36 +0200, David Nielsen wrote:
> tor, 25 10 2007 kl. 15:42 -0400, skrev Adam Jackson:
> > Hopefully I have your attention.
> > 
> > We're working on a lot of stuff that's going into upstream X really
> > soon.  It's going to be quite disruptive, many drivers will fail to
> > launch, etc.  Good stuff, but disruptive.
> > 
> > I want to rebase rawhide to git xserver really soon, before November if
> > possible but definitely before December.  I'll work to make sure most
> > people can get _some_ X when that happens, but it's definitely going to
> > hurt for about a month.
> > 
> > I want to make sure everyone knows this is coming, and if anyone has
> > suggestions for how to time this best and communicate all the caveats
> > and workarounds, please, speak up now.
> 
> Could I convince you to do a brief little write up as to what wonderous
> magic this will bring us, I mean aside the fun breakage.
> 

We have two projects that I thought were written up somewhere but maybe
not :)

1. Composite by default.

This fixes up open source drivers and infrastructure to allow composited
desktops to be enabled by default, especially with 3D apps and movie
playing. Its mostly catching the open source DRI infrastructure up with
the needs of the modern desktop. It will mostly be targeting Intel
hardware in the initial release.

2. Smooth GUI booting.

The aim is to get from grub to gdm login with only one mode set and make
it all transition smoothly between applications... Again initially
targeted at Intel hardware, we want to move to kernel side device
drivers for graphics cards which should allows up only set the mode once
on boot in an optimal configuration and avoid nasty flickering and stuff
as the machine starts.

Jumping to an Xorg 1.5 pre-release means we also need to deal with a new
pci layer and input hotplug layers.

Dave.




From rodd at clarkson.id.au  Fri Oct 26 02:09:19 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 26 Oct 2007 12:09:19 +1000
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <f6e5806f0710251422w42045253t6d64d3b613502622@mail.gmail.com>
References: <1193341373.15341.52.camel@localhost.localdomain>
	<f6e5806f0710251422w42045253t6d64d3b613502622@mail.gmail.com>
Message-ID: <1193364559.4234.5.camel@localhost.localdomain>


On Thu, 2007-10-25 at 14:22 -0700, darrell pfeifer wrote:
> On 10/25/07, Adam Jackson <ajackson at redhat.com> wrote:
> > Hopefully I have your attention.
> >
> > We're working on a lot of stuff that's going into upstream X really
> > soon.  It's going to be quite disruptive, many drivers will fail to
> > launch, etc.  Good stuff, but disruptive.
> >
> 
> As a daily rawhide update addict I really appreciate the warning.
> 
> Over the last few years I've developed a few skills to mitigate and
> undo the breakage.
> 
> My usual reaction is just to back out the changes, particularly with
> obviously new stuff. During the breakage, if you can provide hints or
> workarounds, or indications of any specifics you'd like to see in bug
> reports, I'm happy to help do a bit of debugging.

Yeah, I'll agree with this.

I'm happy to test rawhide (hell, it's kinda fun), and I don't mind
installing software (or I wouldn't want to touch rawhide with it's mass
of updates) but in this case it would also be nice to have a backup
option, so you can test the new X stuff and then back down to a more
working desktop.


R.

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From wwoods at redhat.com  Fri Oct 26 02:51:24 2007
From: wwoods at redhat.com (Will Woods)
Date: Thu, 25 Oct 2007 22:51:24 -0400
Subject: Package XYZ is not signed
In-Reply-To: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
Message-ID: <1193367084.5910.2.camel@localhost.localdomain>

On Thu, 2007-10-25 at 20:48 -0400, yonas Abraham wrote:
> yum update fedora-release-notes
> 
> produce
> 
> Package fedora-release-notes-8.0.0-2.noarch.rpm is not signed
> 
> 
> this is true for about 16 pakages on my Rahwid system today

This has been discussed a bunch of times already. Rawhide packages
aren't signed. This is intentional. Until we hit the final release,
either:

1) disable 'fedora' and 'updates' repositories, and re-enable
'development' 
- this is best if you're planning to follow rawhide in the future

or:

2) disable 'gpgcheck' for 'fedora'
- you need to remember to re-enable it when Fedora 8 is released!

Hope that helps, 

-w



From yabraham2 at gmail.com  Fri Oct 26 04:02:04 2007
From: yabraham2 at gmail.com (yonas Abraham)
Date: Fri, 26 Oct 2007 00:02:04 -0400
Subject: Package XYZ is not signed
In-Reply-To: <1193367084.5910.2.camel@localhost.localdomain>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
Message-ID: <47324ed80710252102v88f02a5kb02162c8a5912c96@mail.gmail.com>

On 10/25/07, Will Woods <wwoods at redhat.com> wrote:
> On Thu, 2007-10-25 at 20:48 -0400, yonas Abraham wrote:
> > yum update fedora-release-notes
> >
> > produce
> >
> > Package fedora-release-notes-8.0.0-2.noarch.rpm is not signed
> >
> >
> > this is true for about 16 pakages on my Rahwid system today
>
> This has been discussed a bunch of times already. Rawhide packages
> aren't signed. This is intentional. Until we hit the final release,
> either:
>
> 1) disable 'fedora' and 'updates' repositories, and re-enable
> 'development'
> - this is best if you're planning to follow rawhide in the future
>
> or:
>
> 2) disable 'gpgcheck' for 'fedora'
> - you need to remember to re-enable it when Fedora 8 is released!
>
> Hope that helps,
>
> -w

Thanks, I was not aware that my machine switched to "Fedora release 8
(Werewolf)". I am back to rawhide now and every thing is good now.

/Yonas



From zaitcev at redhat.com  Fri Oct 26 04:12:35 2007
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 25 Oct 2007 21:12:35 -0700
Subject: Sierra Wireless on Rawhide
In-Reply-To: <20071009100727.GB3537@iota.fab.redhat.com>
References: <20071007122026.GA5994@iota.fab.redhat.com>
	<20071008192328.84405765.zaitcev@redhat.com>
	<20071009100727.GB3537@iota.fab.redhat.com>
Message-ID: <20071025211235.956b999f.zaitcev@redhat.com>

On Tue, 9 Oct 2007 11:07:27 +0100, Anders Karlsson <anders at trudheim.co.uk> wrote:

> > Please send me a usbmon trace
> > (see /usr/share/doc/kernel-doc-2.6.22/Documentation/usb/usbmon.txt).
> 
> I'll have to instrument something to run early enough in rc.sysinit or
> from the initrd so that this can be captured. The point in time where
> the device is disconnected is just to early.
> 
> Would an initrd generated without usb support allow me to load the
> modules one at a time to get this set up so I can use usbmon you
> think?

Good thinking, but I think it might be easier just do rmmod uhci_hcd
than rebuild your initrd.

> > Also, I'd like to see /proc/bus/usb/devices (please disable sierra
> > driver by renaming or blacklisting it temporarily so it does not
> > kill the device before you can capture the devices file). I'll poke
> > the upstream about it we can put together an error case.
> 
> sierra and usbserial is blacklisted, and the device still get
> disconnected. 

Well, I said that because the original dmesg you posted had drivers
involved. I may be wrong about it though.

-- Pete



From peter at thecodergeek.com  Fri Oct 26 05:09:35 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 25 Oct 2007 22:09:35 -0700
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193399202.26495.19.camel@clockmaker.usersys.redhat.com>
References: <1193341373.15341.52.camel@localhost.localdomain>
	<1193362628.3411.15.camel@dawkins>
	<1193399202.26495.19.camel@clockmaker.usersys.redhat.com>
Message-ID: <1193375375.3528.6.camel@localhost.localdomain>

On Fri, 2007-10-26 at 21:46 +1000, Dave Airlie wrote:
> We have two projects that I thought were written up somewhere but maybe
> not :)
> 
> 1. Composite by default.
> [...]
> 2. Smooth GUI booting.
> [...]

Ooh. I was already tempted to go Rawhide on my workstation starting at
F8 GA, but this is just icing on the cake. my hardware is almost
entirely Intel, too (except for the wifi, which is Orinoco), so I'd love
to help test/break/debug this stuff and make it that much better for
users. 

So much awesomeness, so little time! @_@
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071025/bc7470a3/attachment.sig>

From nicu_fedora at nicubunu.ro  Fri Oct 26 05:59:49 2007
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 26 Oct 2007 08:59:49 +0300
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193375375.3528.6.camel@localhost.localdomain>
References: <1193341373.15341.52.camel@localhost.localdomain>	<1193362628.3411.15.camel@dawkins>	<1193399202.26495.19.camel@clockmaker.usersys.redhat.com>
	<1193375375.3528.6.camel@localhost.localdomain>
Message-ID: <47218255.7040804@nicubunu.ro>

Peter Gordon wrote:
> On Fri, 2007-10-26 at 21:46 +1000, Dave Airlie wrote:
>> We have two projects that I thought were written up somewhere but maybe
>> not :)
>>
>> 1. Composite by default.
>> [...]
>> 2. Smooth GUI booting.
>> [...]
> 
> Ooh. I was already tempted to go Rawhide on my workstation starting at
> F8 GA, but this is just icing on the cake. 
> 
> So much awesomeness, so little time! @_@

Indeed, you guys really do steal all the thunder from the F8 release 
with those awesome (and much expected) features in Rawhide :p

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From airlied at redhat.com  Fri Oct 26 15:59:55 2007
From: airlied at redhat.com (Dave Airlie)
Date: Sat, 27 Oct 2007 01:59:55 +1000
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <47218255.7040804@nicubunu.ro>
References: <1193341373.15341.52.camel@localhost.localdomain>
	<1193362628.3411.15.camel@dawkins>
	<1193399202.26495.19.camel@clockmaker.usersys.redhat.com>
	<1193375375.3528.6.camel@localhost.localdomain>
	<47218255.7040804@nicubunu.ro>
Message-ID: <1193414395.26495.23.camel@clockmaker.usersys.redhat.com>

On Fri, 2007-10-26 at 08:59 +0300, Nicu Buculei wrote:
> Peter Gordon wrote:
> > On Fri, 2007-10-26 at 21:46 +1000, Dave Airlie wrote:
> >> We have two projects that I thought were written up somewhere but maybe
> >> not :)
> >>
> >> 1. Composite by default.
> >> [...]
> >> 2. Smooth GUI booting.
> >> [...]
> > 
> > Ooh. I was already tempted to go Rawhide on my workstation starting at
> > F8 GA, but this is just icing on the cake. 
> > 
> > So much awesomeness, so little time! @_@
> 
> Indeed, you guys really do steal all the thunder from the F8 release 
> with those awesome (and much expected) features in Rawhide :p
> 

Well we haven't done all of the work yet :-0

We just need to get the pieces in place so we can get more testing on
them...

Dave.



From rhally at mindspring.com  Fri Oct 26 06:25:22 2007
From: rhally at mindspring.com (Richard Hally)
Date: Fri, 26 Oct 2007 02:25:22 -0400
Subject: BIG FAT WARNING: Breaking X in rawhide
In-Reply-To: <1193414395.26495.23.camel@clockmaker.usersys.redhat.com>
References: <1193341373.15341.52.camel@localhost.localdomain>	<1193362628.3411.15.camel@dawkins>	<1193399202.26495.19.camel@clockmaker.usersys.redhat.com>	<1193375375.3528.6.camel@localhost.localdomain>	<47218255.7040804@nicubunu.ro>
	<1193414395.26495.23.camel@clockmaker.usersys.redhat.com>
Message-ID: <47218852.7070007@mindspring.com>

Dave Airlie wrote:
> On Fri, 2007-10-26 at 08:59 +0300, Nicu Buculei wrote:
>> Peter Gordon wrote:
>>> On Fri, 2007-10-26 at 21:46 +1000, Dave Airlie wrote:
>>>> We have two projects that I thought were written up somewhere but maybe
>>>> not :)
>>>>
>>>> 1. Composite by default.
>>>> [...]
>>>> 2. Smooth GUI booting.
>>>> [...]
>>> Ooh. I was already tempted to go Rawhide on my workstation starting at
>>> F8 GA, but this is just icing on the cake. 
>>>
>>> So much awesomeness, so little time! @_@
>> Indeed, you guys really do steal all the thunder from the F8 release 
>> with those awesome (and much expected) features in Rawhide :p
>>
> 
> Well we haven't done all of the work yet :-0
> 
> We just need to get the pieces in place so we can get more testing on
> them...
> 
> Dave.
> 

May I suggest that after rawhide switches to F9 that you push at least one set 
of the "old" stuff so that those of us that have keepcache=1 (for yum) will have 
the "old" stuff as a fall back in case the "new" stuff is "extra raw".
Looking forward to testing...
Thanks,



From pmatilai at laiskiainen.org  Fri Oct 26 06:26:25 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 26 Oct 2007 09:26:25 +0300 (EEST)
Subject: multlib and splitting packages
In-Reply-To: <loom.20071025T203314-276@post.gmane.org>
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
Message-ID: <alpine.DEB.0.9999.0710260923060.30943@gotcha.dreamhost.com>

On Thu, 25 Oct 2007, Kevin Kofler wrote:

> Bill Nottingham <notting <at> redhat.com> writes:
>> Just to note, if you fix multiarch conflicts by moving libraries to
>> a -libs package, your new -libs package should obsolete the older
>> versions of the package where the libraries came from. This is so
>> that yum upgrades work properly.
>
> This hack is a bad idea, it breaks APT-RPM! (Even for non-multilib systems!)
>
> I just tested this hack with a dummy package: I have installed a package called
> multilib-obsoletes-test Version: 1, Release: 1, then put 1-2 into a test repo
> (created just for this purpose), with a -libs subpackage which obsoletes
> multilib-obsoletes-test < 1-2. This confuses apt-get dist-upgrade, which reacts
> the following way:
> The following packages have been kept back
>   multilib-obsoletes-test (1-1 => 1-2)
> In other words, it gets confused by the hack, and it won't update the package
> at all!
>
> Doing apt-get install multilib-obsoletes-test or apt-get install
> multilib-obsoletes-test-libs by hand will do the right thing, but breaking the
> dist-upgrade is bad.
>
> An if the packager used this idiom:
> Obsoletes: %{name} < %{?epoch:%{epoch}:}%{version}-%{release}
> i.e. is bumping the Obsoletes with each release, then EVERY SINGLE UPGRADE of
> the affected package with apt-rpm will break!
>
> Please test your hacks with apt and smart too.

Versioned obsoletes like that is a perfectly valid dependency construct, 
doesn't qualify as a hack IMO. If apt and smart can't handle that they 
just need to be fixed...

 	- Panu -



From peter at thecodergeek.com  Fri Oct 26 07:24:34 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Fri, 26 Oct 2007 00:24:34 -0700
Subject: rpms/soprano/devel soprano.spec, 1.6, 1.7
	soprano-1.95.0-beta2-findclucene.diff, 1.1, NONE
In-Reply-To: <200710260646.l9Q6kliI003212@cvs-int.fedora.redhat.com>
References: <200710260646.l9Q6kliI003212@cvs-int.fedora.redhat.com>
Message-ID: <1193383474.3528.10.camel@localhost.localdomain>

On Fri, 2007-10-26 at 02:46 -0400, Kevin Kofler wrote:
> Log Message:
> Drop findclucene patch, fixed in clucene-0.9.20-2.
> (IMPORTANT: When building for the other branches, please check what
> clucene you're about to build against to see if the patch is still
> needed or not. clucene < 0.9.20-2 needs the patch, with >= 0.9.20-2
> the patch must not be used!)

Would it not be simpler to hardcode the version dependency as part o
fthe BuildRequires instead of having to manually track that?

Thanks.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479


-------------- 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/20071026/c35dc236/attachment.sig>

From kevin.kofler at chello.at  Fri Oct 26 07:25:17 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 26 Oct 2007 07:25:17 +0000 (UTC)
Subject: multlib and splitting packages
References: <20071025180523.GA15925@nostromo.devel.redhat.com>
	<loom.20071025T203314-276@post.gmane.org>
	<alpine.DEB.0.9999.0710260923060.30943@gotcha.dreamhost.com>
Message-ID: <loom.20071026T072214-809@post.gmane.org>

Panu Matilainen <pmatilai <at> laiskiainen.org> writes:
> Versioned obsoletes like that is a perfectly valid dependency construct, 
> doesn't qualify as a hack IMO. If apt and smart can't handle that they 
> just need to be fixed...

This isn't just a versioned Obsoletes, it's a package being both obsoleted and 
having a regular update available.

If you can fix apt to do the right thing in this case, that'll be the ideal 
solution.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 26 07:34:29 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 26 Oct 2007 07:34:29 +0000 (UTC)
Subject: rpms/soprano/devel soprano.spec, 1.6,
	1.7	soprano-1.95.0-beta2-findclucene.diff, 1.1, NONE
References: <200710260646.l9Q6kliI003212@cvs-int.fedora.redhat.com>
	<1193383474.3528.10.camel@localhost.localdomain>
Message-ID: <loom.20071026T073336-85@post.gmane.org>

Peter Gordon <peter <at> thecodergeek.com> writes:
> Would it not be simpler to hardcode the version dependency as part o
> fthe BuildRequires instead of having to manually track that?

Duh, of course, done.

        Kevin Kofler



From harald at redhat.com  Fri Oct 26 08:24:05 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 26 Oct 2007 10:24:05 +0200
Subject: Current problems with Rawhide
In-Reply-To: <1193240595.25405.126.camel@cookie.hadess.net>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
Message-ID: <ffs875$6hg$1@ger.gmane.org>

Bastien Nocera wrote:
> On Wed, 2007-10-24 at 11:09 -0400, Kelly Miller wrote:
>> Um, I meant to report these yesterday, but I was tired and decided to
>> wait until now.  I noticed some problems with the packages currently
>> in Rawhide.  I know Rawhide is supposed to be unstable (it's the
>> development branch, after all), but I figured I'd better report these,
>> since the new version of Fedora is only a few days away. 
>>
>> 1)  PulseAudio is horribly, horribly flaky.  I dunno if it's because
>> it's the SVN version or what, but it crashed more times last night
>> than it has in the 5 months I used it before that.  Is it normal for
>> PulseAudio to consume 50%+ of the system memory? 
> 
> Works fine here. File bugs!

flaky is correct. Sometimes it works without problems, sometimes every audio app stalls.
Especially, if you use the "user switcher" often.



From mcepl at redhat.com  Fri Oct 26 08:55:40 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 26 Oct 2007 10:55:40 +0200
Subject: CD audio: preference to limit drive speed?
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
	<604aa7910710241126u7a2d27b3ocb525eb1ee4024df@mail.gmail.com>
	<adf480660710241145x352cdd98nc135f6f7f3d09e8f@mail.gmail.com>
Message-ID: <clm8v4x4q5.ln2@hubmaier.ceplovi.cz>

On Wed, 24 Oct 2007 22:45:39 +0400, Peter Lemenkov scripst:
> I personally stopped buying CDs completely 5-7 years ago. Actually there
> is no way to play these funny pieces of plastic in my home :).
> Downloading music is better, easy and handy. Also its more easy to share
> with friends by sending them torrent-link or opening ftp-access.

And please tell me, where I can find *legal* P2P source of something like 
this http://tinyurl.com/2bz9kd No, sorry, there are no substitutes for 
another orchestra or conductor.

Mat?j



From fedora at leemhuis.info  Fri Oct 26 09:19:14 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 26 Oct 2007 11:19:14 +0200
Subject: SUID binaries in the repo (was: Re: rpms/nspluginwrapper/F-8
 plugin-config-setuid.patch, 
 NONE,	1.1 nspluginwrapper.spec, 1.25, 1.26)
In-Reply-To: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
Message-ID: <4721B112.1020707@leemhuis.info>

On 26.10.2007 10:44, Martin Stransky (stransky) wrote:
> Author: stransky

Martin, please don't take the mail as offense. Your commit just reminded
me of something I wanted to bring up.

> Update of /cvs/pkgs/rpms/nspluginwrapper/F-8
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21292
> Modified Files:
> 	nspluginwrapper.spec 
> Added Files:
> 	plugin-config-setuid.patch 
> Log Message:
> * Fri Oct 26 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-10
> - mozilla-plugin-config can be run by normal user now
> 
> plugin-config-setuid.patch:
> 
> --- NEW FILE plugin-config-setuid.patch ---
> --- mozilla/plugin-config-1.6/src/Makefile.in.old	2007-07-24 13:28:56.000000000 +0200
> +++ mozilla/plugin-config-1.6/src/Makefile.in	2007-07-24 13:47:24.000000000 +0200
> @@ -44,7 +44,7 @@ mkinstalldirs = $(install_sh) -d
>  CONFIG_HEADER = $(top_builddir)/config.h
>  CONFIG_CLEAN_FILES =
>  am__installdirs = "$(DESTDIR)$(bindir)"
> -binPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
> +binPROGRAMS_INSTALL = $(INSTALL_PROGRAM) -m 4755
>  PROGRAMS = $(bin_PROGRAMS)
>  am_mozilla_plugin_config_OBJECTS = plugin-config.$(OBJEXT) \
>  	plugin-detection.$(OBJEXT) plugin-dir.$(OBJEXT)

We should try to avoid to much bureaucracy, but well, I feel a bit
uncomfortable with to many SUID apps in Fedora. Should we track them
somehow (a script that looks at the repo could likely create such a
list) and review the list now and then?

Or put at least a little hurdle between SUID bits and the Fedora-repo
with a "SUID apps must be reviewed/permitted by FOO" rule or something
like that?

Just wondering.

CU
knurd



From mschwendt.tmp0701.nospam at arcor.de  Fri Oct 26 09:44:43 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 26 Oct 2007 11:44:43 +0200
Subject: repoview & templates in Fedora site
In-Reply-To: <1193334303.24482.2.camel@cmn18.stanford.edu>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
Message-ID: <20071026114443.9802142e.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 25 Oct 2007 10:45:03 -0700, Fernando Lopez-Lezcano wrote:

> Hi all, is there a place where the "modified" repoview used in the
> Fedora site could be found? I really could use the layout (where package
> pages do not include the version in their name). I'm trying to tweak the
> original 0.5.2 to get the same result but it is not that easy...

http://home.arcor.de/ms2002sep/tmp/repoview-0.5.2-1.modified.src.rpm



From stransky at redhat.com  Fri Oct 26 09:50:34 2007
From: stransky at redhat.com (Martin Stransky)
Date: Fri, 26 Oct 2007 11:50:34 +0200
Subject: SUID binaries in the repo
In-Reply-To: <4721B112.1020707@leemhuis.info>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info>
Message-ID: <4721B86A.5040109@redhat.com>

Hello,

please check https://bugzilla.redhat.com/show_bug.cgi?id=334311, Comment 
#27. After discussion with sec guys here I sent it for the review to our 
security standards team.

So this change will not be released without review.

Regards,
martin

Thorsten Leemhuis wrote:
> On 26.10.2007 10:44, Martin Stransky (stransky) wrote:
>> Author: stransky
> 
> Martin, please don't take the mail as offense. Your commit just reminded
> me of something I wanted to bring up.
> 
>> Update of /cvs/pkgs/rpms/nspluginwrapper/F-8
>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21292
>> Modified Files:
>> 	nspluginwrapper.spec 
>> Added Files:
>> 	plugin-config-setuid.patch 
>> Log Message:
>> * Fri Oct 26 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-10
>> - mozilla-plugin-config can be run by normal user now
>>
>> plugin-config-setuid.patch:
>>
>> --- NEW FILE plugin-config-setuid.patch ---
>> --- mozilla/plugin-config-1.6/src/Makefile.in.old	2007-07-24 13:28:56.000000000 +0200
>> +++ mozilla/plugin-config-1.6/src/Makefile.in	2007-07-24 13:47:24.000000000 +0200
>> @@ -44,7 +44,7 @@ mkinstalldirs = $(install_sh) -d
>>  CONFIG_HEADER = $(top_builddir)/config.h
>>  CONFIG_CLEAN_FILES =
>>  am__installdirs = "$(DESTDIR)$(bindir)"
>> -binPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
>> +binPROGRAMS_INSTALL = $(INSTALL_PROGRAM) -m 4755
>>  PROGRAMS = $(bin_PROGRAMS)
>>  am_mozilla_plugin_config_OBJECTS = plugin-config.$(OBJEXT) \
>>  	plugin-detection.$(OBJEXT) plugin-dir.$(OBJEXT)
> 
> We should try to avoid to much bureaucracy, but well, I feel a bit
> uncomfortable with to many SUID apps in Fedora. Should we track them
> somehow (a script that looks at the repo could likely create such a
> list) and review the list now and then?
> 
> Or put at least a little hurdle between SUID bits and the Fedora-repo
> with a "SUID apps must be reviewed/permitted by FOO" rule or something
> like that?
> 
> Just wondering.
> 
> CU
> knurd
> 



From fedora at leemhuis.info  Fri Oct 26 10:09:46 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 26 Oct 2007 12:09:46 +0200
Subject: SUID binaries in the repo
In-Reply-To: <4721B86A.5040109@redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>	<4721B112.1020707@leemhuis.info>
	<4721B86A.5040109@redhat.com>
Message-ID: <4721BCEA.6080805@leemhuis.info>

On 26.10.2007 11:50, Martin Stransky wrote:
>
> please check https://bugzilla.redhat.com/show_bug.cgi?id=334311, Comment 
> #27. After discussion with sec guys here I sent it for the review to our 
> security standards team.
> So this change will not be released without review.

As I said, I didn't care about this particular package or commit. It
seems you did all that is needed before shipping nspluginwrapper as SUID.

But we have other packages (I had two and still have one) that entered
the repo with SUID binaries that were never reviewed by anyone. Do we
care? Do we trust packagers (?) enough to decide?

Just wondering.

CU
Thorsten "package monkey" Leemhuis ;-)

(?) -- some of them not even know the programming language properly the
stuff they package is written in

> Thorsten Leemhuis wrote:
>> On 26.10.2007 10:44, Martin Stransky (stransky) wrote:
>>> Author: stransky
>> Martin, please don't take the mail as offense. Your commit just reminded
>> me of something I wanted to bring up.
>>
>>> Update of /cvs/pkgs/rpms/nspluginwrapper/F-8
>>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21292
>>> Modified Files:
>>> 	nspluginwrapper.spec 
>>> Added Files:
>>> 	plugin-config-setuid.patch 
>>> Log Message:
>>> * Fri Oct 26 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-10
>>> - mozilla-plugin-config can be run by normal user now
>>>
>>> plugin-config-setuid.patch:
>>>
>>> --- NEW FILE plugin-config-setuid.patch ---
>>> --- mozilla/plugin-config-1.6/src/Makefile.in.old	2007-07-24 13:28:56.000000000 +0200
>>> +++ mozilla/plugin-config-1.6/src/Makefile.in	2007-07-24 13:47:24.000000000 +0200
>>> @@ -44,7 +44,7 @@ mkinstalldirs = $(install_sh) -d
>>>  CONFIG_HEADER = $(top_builddir)/config.h
>>>  CONFIG_CLEAN_FILES =
>>>  am__installdirs = "$(DESTDIR)$(bindir)"
>>> -binPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
>>> +binPROGRAMS_INSTALL = $(INSTALL_PROGRAM) -m 4755
>>>  PROGRAMS = $(bin_PROGRAMS)
>>>  am_mozilla_plugin_config_OBJECTS = plugin-config.$(OBJEXT) \
>>>  	plugin-detection.$(OBJEXT) plugin-dir.$(OBJEXT)
>> We should try to avoid to much bureaucracy, but well, I feel a bit
>> uncomfortable with to many SUID apps in Fedora. Should we track them
>> somehow (a script that looks at the repo could likely create such a
>> list) and review the list now and then?
>>
>> Or put at least a little hurdle between SUID bits and the Fedora-repo
>> with a "SUID apps must be reviewed/permitted by FOO" rule or something
>> like that?
>>
>> Just wondering.
>>
>> CU
>> knurd
>>
> 



From d.lesca at solinos.it  Fri Oct 26 10:31:14 2007
From: d.lesca at solinos.it (Dario Lesca)
Date: Fri, 26 Oct 2007 12:31:14 +0200
Subject: kernel-2.6.23: USB key protection problem
Message-ID: <1193394674.9525.68.camel@lesca.home.solinos.it>

Hi, I have Found this issue on:
 o f7   + kernel-2.6.23 (last from development)
 o f8t3 + up to date (then kernel-2.6.23)

In this 2 Scenarios My USB KEY for software protection not work.

On f7 + standard kernel my key work ok (see strace 1), if I install last
kernel from updates (or I use f8t3) my key not work (see strace-2)

Someone can suggest me some work around ... or this is a issue of new
version of kernel?

Many thanks.

strace-1:
> 4243  execve("./testskey", ["./testskey"], [/* 26 vars */]) = 0
> 4243  brk(0)                            = 0x8daf000
> 4243  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> 4243  open("/etc/ld.so.cache", O_RDONLY) = 3
> 4243  fstat64(3, {st_mode=S_IFREG|0644, st_size=44446, ...}) = 0
> 4243  mmap2(NULL, 44446, PROT_READ, MAP_PRIVATE, 3, 0) = 0x111000
> 4243  close(3)                          = 0
> 4243  open("/lib/libc.so.6", O_RDONLY)  = 3
> 4243  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\240\271\0004\0\0\0"..., 512) = 512
> 4243  fstat64(3, {st_mode=S_IFREG|0755, st_size=1673804, ...}) = 0
> 4243  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x11c000
> 4243  mmap2(0xb84000, 1390032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb84000
> 4243  mmap2(0xcd2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14e) = 0xcd2000
> 4243  mmap2(0xcd5000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xcd5000
> 4243  close(3)                          = 0
> 4243  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x11d000
> 4243  set_thread_area({entry_number:-1 -> 6, base_addr:0x11cde0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> 4243  mprotect(0xcd2000, 8192, PROT_READ) = 0
> 4243  mprotect(0xb80000, 4096, PROT_READ) = 0
> 4243  munmap(0x111000, 44446)           = 0
> 4243  fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> 4243  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x111000
> 4243  write(1, "Key Demo Program\n", 22) = 22
> 4243  write(1, "\n", 1)                 = 1
> 4243  access("/dev/bus/usb", F_OK)      = 0
> 4243  open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> 4243  fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 4243  fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
> 4243  brk(0)                            = 0x8daf000
> 4243  brk(0x8dd1000)                    = 0x8dd1000
> 4243  getdents(3, /* 4 entries */, 4096) = 64
> 4243  access("/dev/bus/usb", F_OK)      = 0
> 4243  open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> 4243  fstat64(4, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 4243  fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
> 4243  getdents(4, /* 4 entries */, 4096) = 64
> 4243  getdents(4, /* 0 entries */, 4096) = 0
> 4243  close(4)                          = 0
> 4243  access("/dev/bus/usb", F_OK)      = 0
> 4243  open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> 4243  fstat64(4, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 4243  fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
> 4243  getdents(4, /* 4 entries */, 4096) = 64
> 4243  getdents(4, /* 0 entries */, 4096) = 0
> 4243  close(4)                          = 0
> 4243  getdents(3, /* 0 entries */, 4096) = 0
> 4243  brk(0x8dd0000)                    = 0x8dd0000
> 4243  close(3)                          = 0
> 4243  access("/dev/bus/usb", F_OK)      = 0
> 4243  open("/dev/bus/usb/001/002", O_RDWR) = 3
> 4243  read(3, "\22\1\20\1\377\0\0 =\7%\0\0\2\1\2\0\1", 18) = 18
> 4243  fcntl64(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783343
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5c30) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5c30) = 8
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783345
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5a90) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5a90) = 8
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783346
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5a10) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5a10) = 8
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783347
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5980) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b5980) = 8
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783348
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b59d0) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b59d0) = 8
> 4243  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429783350
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b59d0) = 8
> 4243  ioctl(3, USBDEVFS_CONTROL, 0xbf9b59d0) = 24
> 4243  close(3)                          = 0
> 4243  sched_yield()                     = 0
> 4243  write(1, "Locating : Key found on por"..., 39) = 39

strace-2:
> 3427  execve("./testskey", ["./testskey"], [/* 25 vars */]) = 0
> 3427  brk(0)                            = 0x9581000
> 3427  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> 3427  open("/etc/ld.so.cache", O_RDONLY) = 3
> 3427  fstat64(3, {st_mode=S_IFREG|0644, st_size=44446, ...}) = 0
> 3427  mmap2(NULL, 44446, PROT_READ, MAP_PRIVATE, 3, 0) = 0x111000
> 3427  close(3)                          = 0
> 3427  open("/lib/libc.so.6", O_RDONLY)  = 3
> 3427  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\240\271\0004\0\0\0"..., 512) = 512
> 3427  fstat64(3, {st_mode=S_IFREG|0755, st_size=1673804, ...}) = 0
> 3427  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x11c000
> 3427  mmap2(0xb84000, 1390032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb84000
> 3427  mmap2(0xcd2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14e) = 0xcd2000
> 3427  mmap2(0xcd5000, 9680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xcd5000
> 3427  close(3)                          = 0
> 3427  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x11d000
> 3427  set_thread_area({entry_number:-1 -> 6, base_addr:0x11cde0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> 3427  mprotect(0xcd2000, 8192, PROT_READ) = 0
> 3427  mprotect(0xb80000, 4096, PROT_READ) = 0
> 3427  munmap(0x111000, 44446)           = 0
> 3427  fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> 3427  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x111000
> 3427  write(1, "Key Demo Program\n", 22) = 22
> 3427  write(1, "\n", 1)                 = 1
> 3427  access("/dev/bus/usb", F_OK)      = 0
> 3427  open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> 3427  fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 3427  fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
> 3427  brk(0)                            = 0x9581000
> 3427  brk(0x95a3000)                    = 0x95a3000
> 3427  getdents(3, /* 4 entries */, 4096) = 64
> 3427  access("/dev/bus/usb", F_OK)      = 0
> 3427  open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> 3427  fstat64(4, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 3427  fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
> 3427  getdents(4, /* 4 entries */, 4096) = 64
> 3427  getdents(4, /* 0 entries */, 4096) = 0
> 3427  close(4)                          = 0
> 3427  access("/dev/bus/usb", F_OK)      = 0
> 3427  open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> 3427  fstat64(4, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> 3427  fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
> 3427  getdents(4, /* 4 entries */, 4096) = 64
> 3427  getdents(4, /* 0 entries */, 4096) = 0
> 3427  close(4)                          = 0
> 3427  getdents(3, /* 0 entries */, 4096) = 0
> 3427  brk(0x95a2000)                    = 0x95a2000
> 3427  close(3)                          = 0
> 3427  access("/dev/bus/usb", F_OK)      = 0
> 3427  open("/dev/bus/usb/001/002", O_RDWR) = 3
> 3427  read(3, "\22\1\20\1\377\0\0 =\7%\0\0\2\1\2\0\1", 18) = 18
> 3427  fcntl64(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
> 3427  times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 429463882
> 3427  ioctl(3, USBDEVFS_CONTROL, 0xbfd794c0) = 8
> 3427  ioctl(3, USBDEVFS_CONTROL, 0xbfd794c0) = -1 EILSEQ (Invalid or incomplete multibyte or wide character)
> 3427  ioctl(3, USBDEVFS_CONTROL, 0xbfd794c0) = -1 ETIMEDOUT (Connection timed out)
> 3427  close(3)                          = 0
> 3427  sched_yield()                     = 0

-- 
Dario Lesca <d.lesca at solinos.it>



From bnocera at redhat.com  Fri Oct 26 10:49:01 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 26 Oct 2007 11:49:01 +0100
Subject: [pkgdb] bluez-libs: hadess has requested watchbugzilla
In-Reply-To: <200710261045.l9QAj8nt022071@bastion.fedora.phx.redhat.com>
References: <200710261045.l9QAj8nt022071@bastion.fedora.phx.redhat.com>
Message-ID: <1193395741.25047.3.camel@cookie.hadess.net>

Heya,

On Fri, 2007-10-26 at 03:45 -0700, Fedora PackageDB wrote:
> Bastien Nocera (hadess) has requested the watchbugzilla acl on bluez-libs (Fedora devel)
> 
> To make changes to this package see:
>   https://admin.fedoraproject.org/pkgdb/packages/name/bluez-libs

I'm sure this has been asked before. But why do I need to ask permission
to watch a component in bugzilla?

Cheers



From caillon at redhat.com  Fri Oct 26 11:35:58 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 26 Oct 2007 07:35:58 -0400
Subject: SUID binaries in the repo
In-Reply-To: <4721BCEA.6080805@leemhuis.info>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>	<4721B112.1020707@leemhuis.info>	<4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info>
Message-ID: <4721D11E.90806@redhat.com>

Thorsten Leemhuis wrote:
> But we have other packages (I had two and still have one) that entered
> the repo with SUID binaries that were never reviewed by anyone. Do we
> care? Do we trust packagers (?) enough to decide?

We should definitely make sure they get looked-at.  Copying bressers, 
who might be able to help with drafting a plan.



From bressers at redhat.com  Fri Oct 26 11:47:31 2007
From: bressers at redhat.com (Josh Bressers)
Date: Fri, 26 Oct 2007 07:47:31 -0400
Subject: SUID binaries in the repo
In-Reply-To: <4721D11E.90806@redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
Message-ID: <11699.1193399251@evolution.bress.net>

> Thorsten Leemhuis wrote:
> > But we have other packages (I had two and still have one) that entered
> > the repo with SUID binaries that were never reviewed by anyone. Do we
> > care? Do we trust packagers (??) enough to decide?
> 
> We should definitely make sure they get looked-at.  Copying bressers, 
> who might be able to help with drafting a plan.
> 

Yes, this should get some attention from someone.  There is no reason to
allow any app that wants it to have suid.  Things like consolehelper exist
for just this reason.

Within Red Hat I care for a suid whitelist.  If it's not on the list, I
have to be convinced that it should be.  It works rather well honestly.  It
would probably make sense to give this task to the Fedora Security Response
Team as it will be them cleaning up the mess after a "suid gone wild"
event.

-- 
    JB



From mzerqung at 0pointer.de  Fri Oct 26 12:08:00 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 26 Oct 2007 14:08:00 +0200
Subject: Current problems with Rawhide
In-Reply-To: <ffs875$6hg$1@ger.gmane.org>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<ffs875$6hg$1@ger.gmane.org>
Message-ID: <20071026120800.GB29226@tango.0pointer.de>

On Fri, 26.10.07 10:24, Harald Hoyer (harald at redhat.com) wrote:

>>> 1)  PulseAudio is horribly, horribly flaky.  I dunno if it's because
>>> it's the SVN version or what, but it crashed more times last night
>>> than it has in the 5 months I used it before that.  Is it normal for
>>> PulseAudio to consume 50%+ of the system memory?
>> Works fine here. File bugs!
>
> flaky is correct. Sometimes it works without problems, sometimes
> every audio app stalls.  Especially, if you use the "user switcher"
> often.

Hmm, nebolous claims like this are not really helpful. Please file
bugs and help use tracking down the problems, if there are any.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From limb at jcomserv.net  Fri Oct 26 13:11:47 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 26 Oct 2007 08:11:47 -0500 (CDT)
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 by 
 ausil]
Message-ID: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>

Got a bunch of these, for some of my noarch packages.  We working on sparc
support for the main Koji instance?

---------------------------- Original Message ----------------------------
Subject: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 by ausil
From:    "SPARC Koji Build System" <buildsys at fedoraproject.org>
Date:    Thu, October 25, 2007 3:49 pm
To:      ausil at fedoraproject.org
         limb at fedoraproject.org
         Fedora-sparc at redhat.com
         dennis at auroralinux.org
--------------------------------------------------------------------------

Package: archivemail
NVR: archivemail-0.7.0-6.fc8
User: ausil
Status: complete
Tag Operation: tagged
Into Tag: dist-f8

archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 by ausil


-- 
novus ordo absurdum



From harald at redhat.com  Fri Oct 26 13:24:07 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 26 Oct 2007 15:24:07 +0200
Subject: Current problems with Rawhide
In-Reply-To: <20071026120800.GB29226@tango.0pointer.de>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<1193240595.25405.126.camel@cookie.hadess.net>	<ffs875$6hg$1@ger.gmane.org>
	<20071026120800.GB29226@tango.0pointer.de>
Message-ID: <ffsppn$1jg$1@ger.gmane.org>

Lennart Poettering wrote:
> On Fri, 26.10.07 10:24, Harald Hoyer (harald at redhat.com) wrote:
> 
>>>> 1)  PulseAudio is horribly, horribly flaky.  I dunno if it's because
>>>> it's the SVN version or what, but it crashed more times last night
>>>> than it has in the 5 months I used it before that.  Is it normal for
>>>> PulseAudio to consume 50%+ of the system memory?
>>> Works fine here. File bugs!
>> flaky is correct. Sometimes it works without problems, sometimes
>> every audio app stalls.  Especially, if you use the "user switcher"
>> often.
> 
> Hmm, nebolous claims like this are not really helpful. Please file
> bugs and help use tracking down the problems, if there are any.
> 
> Lennart
> 
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> 

sorry, after some investigation it seems my problems are more ACL related when using the "user switcher".



From P at draigBrady.com  Fri Oct 26 13:26:43 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Fri, 26 Oct 2007 14:26:43 +0100
Subject: laptop hard disk etiquette
Message-ID: <4721EB13.5010701@draigBrady.com>

There is a bit of buzz at the moment about
ubuntu affecting laptop hard drives reliability:
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695

If I run the following on my F7 laptop while it's plugged in:

    while true; do
        smartctl -A /dev/sda |
        grep -F Load_Cycle_Count |
        tr -s ' ' | cut -d ' ' -f 2,10
        sleep 10
    done

I get:

    Load_Cycle_Count 351489
    Load_Cycle_Count 351491
    Load_Cycle_Count 351493
    Load_Cycle_Count 351495
    Load_Cycle_Count 351498

Which is about once every 4 seconds or so.
As mentioned in the bug report I can turn this
off by doing `hdparm -B 255 /dev/sda`

Should anything be changed for the F8 release?

cheers,
P?draig.




From lightsolphoenix at gmail.com  Fri Oct 26 13:29:39 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 26 Oct 2007 09:29:39 -0400
Subject: Feedback from PulseAudio 0.9.7 SVN (Was: Current problems with
 Rawhide)
In-Reply-To: <20071026002419.GA8549@tango.0pointer.de>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>	<1193240595.25405.126.camel@cookie.hadess.net>	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>	<472020BB.9080804@gmail.com>
	<20071026002419.GA8549@tango.0pointer.de>
Message-ID: <4721EBC3.3060906@gmail.com>

Lennart Poettering wrote:
> Those logs don't tell much. Except that PA cannot get hold of the
> audio device because some other process is using it.
>
> It will tell you which processes have opened your audio devices
Yeah, I managed to find the cause; PulseAudio was trying to grab the 
audio device twice, and the error came from the second attempt.  When I 
corrected the error in the configuration file, those errors went away.

However, I can confirm that there's some kind of memory leak problem in 
the ESound protocol handling, which I narrowed down to the do_read 
method via tracking the error message I got in the source.  As I 
mentioned before, sometimes PulseAudio will jump to 50%+ memory used and 
then shut itself off; when I ran it using pulseaudio -vv, the error I 
got lines up with the do_read function's general error messages.  I can 
get a log of that if necessary as well.



From jkeating at redhat.com  Fri Oct 26 13:53:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 09:53:24 -0400
Subject: SUID binaries in the repo
In-Reply-To: <11699.1193399251@evolution.bress.net>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
Message-ID: <20071026095324.1797840a@redhat.com>

On Fri, 26 Oct 2007 07:47:31 -0400
Josh Bressers <bressers at redhat.com> wrote:

> Within Red Hat I care for a suid whitelist.  If it's not on the list,
> I have to be convinced that it should be.  It works rather well
> honestly.  It would probably make sense to give this task to the
> Fedora Security Response Team as it will be them cleaning up the mess
> after a "suid gone wild" event.

Can you help us draft up a new package review rule that will bring suid
things to your attention?  I think rpmlint may point out suid files, or
could be made to easily.  What's missing is a point of contact or a
bugzilla keyword or blocker list we set or something.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/c23f1391/attachment.sig>

From jkeating at redhat.com  Fri Oct 26 13:54:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 09:54:35 -0400
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8
 by  ausil]
In-Reply-To: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
Message-ID: <20071026095435.7d6592c7@redhat.com>

On Fri, 26 Oct 2007 08:11:47 -0500 (CDT)
"Jon Ciesla" <limb at jcomserv.net> wrote:

> Got a bunch of these, for some of my noarch packages.  We working on
> sparc support for the main Koji instance?


Actually we're working on a Koji instance for sparc that ties into
Fedora's main koji instance.  This is for secondary arch support.
Sparc is leading the way, to follow there is ia64, s390(x), arm, alpha,
and we'll probably transition ppc to a secondary arch once that system
is proving viable.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/578440c7/attachment.sig>

From limb at jcomserv.net  Fri Oct 26 13:57:33 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 26 Oct 2007 08:57:33 -0500 (CDT)
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 
 by  ausil]
In-Reply-To: <20071026095435.7d6592c7@redhat.com>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
	<20071026095435.7d6592c7@redhat.com>
Message-ID: <36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>


> On Fri, 26 Oct 2007 08:11:47 -0500 (CDT)
> "Jon Ciesla" <limb at jcomserv.net> wrote:
>
>> Got a bunch of these, for some of my noarch packages.  We working on
>> sparc support for the main Koji instance?
>
>
> Actually we're working on a Koji instance for sparc that ties into
> Fedora's main koji instance.  This is for secondary arch support.
> Sparc is leading the way, to follow there is ia64, s390(x), arm, alpha,
> and we'll probably transition ppc to a secondary arch once that system
> is proving viable.

Cool.  So I can probably expect a lot more of these for various arches?

> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From jkeating at redhat.com  Fri Oct 26 14:09:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 10:09:28 -0400
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8
 by  ausil]
In-Reply-To: <36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
	<20071026095435.7d6592c7@redhat.com>
	<36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>
Message-ID: <20071026100928.5e66c196@redhat.com>

On Fri, 26 Oct 2007 08:57:33 -0500 (CDT)
"Jon Ciesla" <limb at jcomserv.net> wrote:

> Cool.  So I can probably expect a lot more of these for various
> arches?

Eventually.  Dennis should have given folks a heads up on this though.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/639295c2/attachment.sig>

From notting at redhat.com  Fri Oct 26 14:33:23 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 10:33:23 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47210BB2.3040201@redhat.com>
References: <47210BB2.3040201@redhat.com>
Message-ID: <20071026143323.GA11789@nostromo.devel.redhat.com>

Chuck Ebbert (cebbert at redhat.com) said: 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.

Works for me (Intel HDA); then again, it worked fine beforehand as well.

Bill



From limb at jcomserv.net  Fri Oct 26 14:28:29 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 26 Oct 2007 09:28:29 -0500 (CDT)
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 
 by  ausil]
In-Reply-To: <20071026100928.5e66c196@redhat.com>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
	<20071026095435.7d6592c7@redhat.com>
	<36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>
	<20071026100928.5e66c196@redhat.com>
Message-ID: <63004.63.85.68.164.1193408909.squirrel@mail.jcomserv.net>


> On Fri, 26 Oct 2007 08:57:33 -0500 (CDT)
> "Jon Ciesla" <limb at jcomserv.net> wrote:
>
>> Cool.  So I can probably expect a lot more of these for various
>> arches?
>
> Eventually.  Dennis should have given folks a heads up on this though.

Well, sure, but I wouldn't get too bent out of shape about it.  It doesn't
impact current production, and I found it intriguing.  Heck, where I work,
you can schedule an electrician to run power in a data center and not have
to tell ANYONE! ;)

> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From mzerqung at 0pointer.de  Fri Oct 26 14:41:56 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 26 Oct 2007 16:41:56 +0200
Subject: Feedback from PulseAudio 0.9.7 SVN (Was: Current problems with
	Rawhide)
In-Reply-To: <4721EBC3.3060906@gmail.com>
References: <a785db460710240809t3ca6f564i9ab25b660a83993e@mail.gmail.com>
	<1193240595.25405.126.camel@cookie.hadess.net>
	<a785db460710240848y60f8f422u40e831bf89ae5d17@mail.gmail.com>
	<c44298520710240926h1413ad8t4539a0022a9b4c74@mail.gmail.com>
	<472020BB.9080804@gmail.com>
	<20071026002419.GA8549@tango.0pointer.de>
	<4721EBC3.3060906@gmail.com>
Message-ID: <20071026144155.GA4706@tango.0pointer.de>

On Fri, 26.10.07 09:29, Kelly Miller (lightsolphoenix at gmail.com) wrote:

Hi!

>> It will tell you which processes have opened your audio devices
> Yeah, I managed to find the cause; PulseAudio was trying to grab the audio 
> device twice, and the error came from the second attempt.  When I corrected 
> the error in the configuration file, those errors went away.

So you modified PA's config file, right? The default config file
should work fine for most people.

So if I understand correctly this was not fault at all on PA's side,
but just a configuration error on your side?

> However, I can confirm that there's some kind of memory leak problem in the 
> ESound protocol handling, which I narrowed down to the do_read method via 
> tracking the error message I got in the source.  As I mentioned before, 
> sometimes PulseAudio will jump to 50%+ memory used and then shut itself 
> off; when I ran it using pulseaudio -vv, the error I got lines up with the 
> do_read function's general error messages.  I can get a log of that if 
> necessary as well.

Yes, please!

Most helpful would be some kind of memory trace. Best would be an
output of valgrind's massif tool.

Thank you,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From myfedora at richip.dhs.org  Fri Oct 26 14:41:00 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 26 Oct 2007 08:41:00 -0600
Subject: laptop hard disk etiquette
In-Reply-To: <4721EB13.5010701@draigBrady.com>
References: <4721EB13.5010701@draigBrady.com>
Message-ID: <1193409660.23295.1.camel@localhost6.localdomain6>

Here's a link to more related stuff that should probably go on a bug
report:

http://www.linux-hero.com/rant/explanation-ubuntu-hard-drive-wear-and-tear

On Fri, 2007-10-26 at 14:26 +0100, P?draig Brady wrote:
> There is a bit of buzz at the moment about
> ubuntu affecting laptop hard drives reliability:
> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
> 
> If I run the following on my F7 laptop while it's plugged in:
> 
>     while true; do
>         smartctl -A /dev/sda |
>         grep -F Load_Cycle_Count |
>         tr -s ' ' | cut -d ' ' -f 2,10
>         sleep 10
>     done
> 
> I get:
> 
>     Load_Cycle_Count 351489
>     Load_Cycle_Count 351491
>     Load_Cycle_Count 351493
>     Load_Cycle_Count 351495
>     Load_Cycle_Count 351498
> 
> Which is about once every 4 seconds or so.
> As mentioned in the bug report I can turn this
> off by doing `hdparm -B 255 /dev/sda`
> 
> Should anything be changed for the F8 release?
> 
> cheers,
> P?draig.
> 
> 



From dennis at ausil.us  Fri Oct 26 14:44:57 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 26 Oct 2007 09:44:57 -0500
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8
	by ausil]
In-Reply-To: <20071026100928.5e66c196@redhat.com>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
	<36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>
	<20071026100928.5e66c196@redhat.com>
Message-ID: <200710260944.58851.dennis@ausil.us>

On Friday 26 October 2007 9:09:28 am Jesse Keating wrote:
> On Fri, 26 Oct 2007 08:57:33 -0500 (CDT)
>
> "Jon Ciesla" <limb at jcomserv.net> wrote:
> > Cool.  So I can probably expect a lot more of these for various
> > arches?
>
> Eventually.  Dennis should have given folks a heads up on this though.

I meant to send out notificationa and forgot to,  sorry for that.

Im going to work out a way so that you only get one email per build  unless it 
fails on a secondary arch.  Otherwise you will end up getting 5 or 6 success 
emails for each and every build  this will equate to alot more email for 
people who rebuild often  or have alot of packages

Dennis




From notting at redhat.com  Fri Oct 26 14:48:05 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 10:48:05 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <4721EB13.5010701@draigBrady.com>
References: <4721EB13.5010701@draigBrady.com>
Message-ID: <20071026144805.GB11789@nostromo.devel.redhat.com>

P?draig Brady (P at draigBrady.com) said: 
> Which is about once every 4 seconds or so.
> As mentioned in the bug report I can turn this
> off by doing `hdparm -B 255 /dev/sda`
> 
> Should anything be changed for the F8 release?

Fedora doesn't change the power management values for your drives from
the defaults set by your BIOS.

Bill



From limb at jcomserv.net  Fri Oct 26 14:43:01 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 26 Oct 2007 09:43:01 -0500 (CDT)
Subject: [Fwd: archivemail-0.7.0-6.fc8 successfully tagged into dist-f8 
 by ausil]
In-Reply-To: <200710260944.58851.dennis@ausil.us>
References: <59558.63.85.68.164.1193404307.squirrel@mail.jcomserv.net>
	<36638.63.85.68.164.1193407053.squirrel@mail.jcomserv.net>
	<20071026100928.5e66c196@redhat.com>
	<200710260944.58851.dennis@ausil.us>
Message-ID: <11441.63.85.68.164.1193409781.squirrel@mail.jcomserv.net>


> On Friday 26 October 2007 9:09:28 am Jesse Keating wrote:
>> On Fri, 26 Oct 2007 08:57:33 -0500 (CDT)
>>
>> "Jon Ciesla" <limb at jcomserv.net> wrote:
>> > Cool.  So I can probably expect a lot more of these for various
>> > arches?
>>
>> Eventually.  Dennis should have given folks a heads up on this though.
>
> I meant to send out notificationa and forgot to,  sorry for that.
>
> Im going to work out a way so that you only get one email per build
> unless it
> fails on a secondary arch.  Otherwise you will end up getting 5 or 6
> success
> emails for each and every build  this will equate to alot more email for
> people who rebuild often  or have alot of packages

Good idea.  All in all, I'm just glad to see we're moving toward
supporting more arches.  Good for more users, more eyes for bugs, and
better for the long-term future of Fedora.  Plus, if I manage to find an
Alpha at a garage sale. . .

Keep up the good work. :)

> Dennis
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From wtogami at redhat.com  Fri Oct 26 14:59:18 2007
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 26 Oct 2007 10:59:18 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <20071026144805.GB11789@nostromo.devel.redhat.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
Message-ID: <472200C6.6060900@redhat.com>

Bill Nottingham wrote:
> P?draig Brady (P at draigBrady.com) said: 
>> Which is about once every 4 seconds or so.
>> As mentioned in the bug report I can turn this
>> off by doing `hdparm -B 255 /dev/sda`
>>
>> Should anything be changed for the F8 release?
> 
> Fedora doesn't change the power management values for your drives from
> the defaults set by your BIOS.
> 
> Bill
> 

1) Power off completely.
2) Boot up.
3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"

What default value does your firmware or BIOS have?  notting's drive 
defaulted to 128.

Warren Togami
wtogami at redhat.com



From cdhouch at gmail.com  Fri Oct 26 15:07:55 2007
From: cdhouch at gmail.com (Caerie Houchins)
Date: Fri, 26 Oct 2007 10:07:55 -0500
Subject: Crash on Gnome startup possibly NetworkManager related
Message-ID: <f0ad54e30710260807t3ea9f9e4qd6a2387175e3cf4e@mail.gmail.com>

Is anyone else getting a crash popup box when you loginto Gnome, then not
seeing the standand NetworkManager panel control?  When I scan for the
NetworkManager process I can see that its still running, and the crash
window isn't really telling me WHAT crashed.

Could it be NetworkManagerDispatcher?  When I tried to run that separately
it just does nothing (but the pid stays running).

I'm just trying to collect more information about this.  I don't even have
enough to file a bug report as of yet.

-- 
Caerie Houchins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/44dbef1a/attachment.htm>

From jkeating at redhat.com  Fri Oct 26 15:09:06 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 11:09:06 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <472200C6.6060900@redhat.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<472200C6.6060900@redhat.com>
Message-ID: <20071026110906.07daf580@redhat.com>

On Fri, 26 Oct 2007 10:59:18 -0400
Warren Togami <wtogami at redhat.com> wrote:

> 1) Power off completely.
> 2) Boot up.
> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
> 
> What default value does your firmware or BIOS have?  notting's drive 
> defaulted to 128.

Advanced power management level: unknown setting (0x8080)

So helpful.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/94698210/attachment.sig>

From tcallawa at redhat.com  Fri Oct 26 15:14:47 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 26 Oct 2007 11:14:47 -0400
Subject: Why is my %dist resolving to rh8?
In-Reply-To: <47210CD5.2050207@cora.nwra.com>
References: <47210CD5.2050207@cora.nwra.com>
Message-ID: <1193411688.3400.14.camel@localhost.localdomain>


On Thu, 2007-10-25 at 15:38 -0600, Orion Poplawski wrote:
> Looks like we've wrapped into redhat version numbers:
> 
>   dist       %{expand:%%(if echo %{distlong} | grep "[^0-9.]"> 
> /dev/null; then
>    echo .%{rheldist}
> else
>    case "%{distlong}" in
>      ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" )
>      echo .%{rhldist}
>      ;;
>      ( "1" | "2" | "3" | "4" | "5" | "6" )
>      echo .%{fcdist}
>      ;;
>    esac;
>    if echo %{distlong} | grep "[^0-9]" > /dev/null; then
>      if [ %{distsver} -ge 90 ]; then
>        echo .%{fctdist}
>      fi
>    fi
> fi;)}
> 
> 
> Time to drop the rhldist stuff?
> 
> Can't figure out where this is defined though...

I'm pretty sure we don't define %{dist} like that anymore, I suspect
this is a legacy hack.

~spot



From sandeen at redhat.com  Fri Oct 26 15:18:52 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 26 Oct 2007 10:18:52 -0500
Subject: laptop hard disk etiquette
In-Reply-To: <4721EB13.5010701@draigBrady.com>
References: <4721EB13.5010701@draigBrady.com>
Message-ID: <4722055C.7090403@redhat.com>

P?draig Brady wrote:
> There is a bit of buzz at the moment about
> ubuntu affecting laptop hard drives reliability:
> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695

FWIW, my OSX laptop hard drive, less than a year old, shows > 600k.
It's *cough* never run linux.

I've asked someone I know at seagate to see if they might be willing to
comment on this, perhaps this is a misinterpretation of the smart data
and/or the specsheet?

-Eric



From bruno at wolff.to  Fri Oct 26 15:20:47 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 26 Oct 2007 10:20:47 -0500
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471F8FDB.8070405@codewiz.org>
References: <200710230846.25736.sgrubb@redhat.com>
	<471DFECE.5080704@redhat.com> <ffkves$49f$1@ger.gmane.org>
	<1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
	<471F8FDB.8070405@codewiz.org>
Message-ID: <20071026152047.GD8416@wolff.to>

On Wed, Oct 24, 2007 at 14:32:59 -0400,
  Bernardo Innocenti <bernie at codewiz.org> wrote:
> 
> Uh?  I wasn't aware SHA1 has been broken (at least, not in
> a practically exploitable way).

Schneier has written some blog entries related to sha1 and the process for
getting a new has standard.

http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html
http://www.schneier.com/blog/archives/2005/10/nist_hash_works_2.html
http://www.schneier.com/blog/archives/2006/09/notes_from_the.html



From fedora at leemhuis.info  Fri Oct 26 15:26:14 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 26 Oct 2007 17:26:14 +0200
Subject: laptop hard disk etiquette
In-Reply-To: <20071026110906.07daf580@redhat.com>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>	<472200C6.6060900@redhat.com>
	<20071026110906.07daf580@redhat.com>
Message-ID: <47220716.6000402@leemhuis.info>

On 26.10.2007 17:09, Jesse Keating wrote:
> On Fri, 26 Oct 2007 10:59:18 -0400
> Warren Togami <wtogami at redhat.com> wrote:
> 
>> 1) Power off completely.
>> 2) Boot up.
>> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
>>
>> What default value does your firmware or BIOS have?  notting's drive 
>> defaulted to 128.
> Advanced power management level: unknown setting (0x8080)

Same here. ST980813AS in a Dell Latitude D630, rawhide.

Additional note: the hard driver does strange noise (sounds a bit like
parking and unparking the heads maybe) now and then (sometimes every ten
seconds or so, sometimes a lot less).

Cu
knurd



From P at draigBrady.com  Fri Oct 26 15:26:30 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Fri, 26 Oct 2007 16:26:30 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <20071026144805.GB11789@nostromo.devel.redhat.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
Message-ID: <47220726.2040603@draigBrady.com>

Bill Nottingham wrote:
> P?draig Brady (P at draigBrady.com) said: 
>> Which is about once every 4 seconds or so.
>> As mentioned in the bug report I can turn this
>> off by doing `hdparm -B 255 /dev/sda`
>>
>> Should anything be changed for the F8 release?
> 
> Fedora doesn't change the power management values for your drives from
> the defaults set by your BIOS.

I understand from the comments in the bug that windows sets
the values so the BIOSes don't bother setting appropriate values.

Also what is causing the drive to "load"
so often after an "unload"?

P?draig.



From nicolas.mailhot at laposte.net  Fri Oct 26 15:33:37 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 26 Oct 2007 17:33:37 +0200 (CEST)
Subject: laptop hard disk etiquette
Message-ID: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>


Le Ven 26 octobre 2007 17:26, P?draig Brady a ?crit :

> I understand from the comments in the bug that windows sets
> the values so the BIOSes don't bother setting appropriate values.
>
> Also what is causing the drive to "load"
> so often after an "unload"?

On old hard drives pretty much anything can cause the disk to spin up
again. Sometimes querrying the hard drive status (are you suspended?)
is sufficient to wake it up (don't laugh)

-- 
Nicolas Mailhot



From P at draigBrady.com  Fri Oct 26 15:35:25 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Fri, 26 Oct 2007 16:35:25 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <472200C6.6060900@redhat.com>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<472200C6.6060900@redhat.com>
Message-ID: <4722093D.2090004@draigBrady.com>

Warren Togami wrote:
> Bill Nottingham wrote:
>> P?draig Brady (P at draigBrady.com) said:
>>> Which is about once every 4 seconds or so.
>>> As mentioned in the bug report I can turn this
>>> off by doing `hdparm -B 255 /dev/sda`
>>>
>>> Should anything be changed for the F8 release?
>>
>> Fedora doesn't change the power management values for your drives from
>> the defaults set by your BIOS.
>>
>> Bill
>>
> 
> 1) Power off completely.
> 2) Boot up.
> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"

# hdparm -I /dev/sda

ATA device, with non-removable media
        Model Number:       Hitachi HTS541060G9AT00
        Serial Number:      MPB3PAX5KM1E5G
        Firmware Revision:  MB3OA61A
Capabilities:
        Advanced power management level: 128 (0x80)


> What default value does your firmware or BIOS have?  notting's drive
> defaulted to 128.

The BIOS setup didn't give any interface to this value,
so I presume 128 was the default set by the drive/BIOS?

P?draig.



From P at draigBrady.com  Fri Oct 26 15:37:54 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Fri, 26 Oct 2007 16:37:54 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
Message-ID: <472209D2.7090803@draigBrady.com>

Nicolas Mailhot wrote:
> Le Ven 26 octobre 2007 17:26, P?draig Brady a ?crit :
>> Also what is causing the drive to "load"
>> so often after an "unload"?
> 
> On old hard drives pretty much anything can cause the disk to spin up
> again. Sometimes querrying the hard drive status (are you suspended?)
> is sufficient to wake it up (don't laugh)

So possibly running smartctl -A will cause the drive to load.
I.E. it's a self fulfilling prophecy :)

P?draig.




From pertusus at free.fr  Fri Oct 26 15:46:55 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 26 Oct 2007 17:46:55 +0200
Subject: SUID binaries in the repo
In-Reply-To: <20071026095324.1797840a@redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
Message-ID: <20071026154655.GB5248@free.fr>

On Fri, Oct 26, 2007 at 09:53:24AM -0400, Jesse Keating wrote:
> 
> Can you help us draft up a new package review rule that will bring suid
> things to your attention?  I think rpmlint may point out suid files, or
> could be made to easily.  What's missing is a point of contact or a
> bugzilla keyword or blocker list we set or something.

rpmlint already points out suid files. I don't think that a specific
guideline is needed, a word of caution would be nice. We should expect
maintainers to know what they are doing when packaging suid stuff.
I personally maintain pmount which is, I hope, rightfully suid.

--
Pat



From mattdm at mattdm.org  Fri Oct 26 15:57:19 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 26 Oct 2007 11:57:19 -0400
Subject: Package XYZ is not signed
In-Reply-To: <1193367084.5910.2.camel@localhost.localdomain>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
Message-ID: <20071026155719.GA18301@jadzia.bu.edu>

On Thu, Oct 25, 2007 at 10:51:24PM -0400, Will Woods wrote:
> > this is true for about 16 pakages on my Rahwid system today
> This has been discussed a bunch of times already. Rawhide packages
> aren't signed. This is intentional. Until we hit the final release,

Although, for the past six months or so, new packages hitting rawhide have
in fact happened to have been signed.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jkeating at redhat.com  Fri Oct 26 15:57:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 11:57:38 -0400
Subject: Package XYZ is not signed
In-Reply-To: <20071026155719.GA18301@jadzia.bu.edu>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<20071026155719.GA18301@jadzia.bu.edu>
Message-ID: <20071026115738.1c153f22@redhat.com>

On Fri, 26 Oct 2007 11:57:19 -0400
Matthew Miller <mattdm at mattdm.org> wrote:

> Although, for the past six months or so, new packages hitting rawhide
> have in fact happened to have been signed.

Not all of them.  Only packages that were in say a test release, or
inherited from a previous release.  There is no autosigning happening.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/3cdc4363/attachment.sig>

From jkeating at redhat.com  Fri Oct 26 16:01:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 12:01:40 -0400
Subject: SUID binaries in the repo
In-Reply-To: <20071026154655.GB5248@free.fr>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
	<20071026154655.GB5248@free.fr>
Message-ID: <20071026120140.4d536703@redhat.com>

On Fri, 26 Oct 2007 17:46:55 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> rpmlint already points out suid files. I don't think that a specific
> guideline is needed, a word of caution would be nice. We should expect
> maintainers to know what they are doing when packaging suid stuff.
> I personally maintain pmount which is, I hope, rightfully suid.

If we want somebody to explicitly examine all suid instances they yes,
we do need a guideline.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/944ef508/attachment.sig>

From mattdm at mattdm.org  Fri Oct 26 16:04:49 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 26 Oct 2007 12:04:49 -0400
Subject: Package XYZ is not signed
In-Reply-To: <20071026155719.GA18301@jadzia.bu.edu>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<20071026155719.GA18301@jadzia.bu.edu>
Message-ID: <20071026160449.GA19217@jadzia.bu.edu>

On Fri, Oct 26, 2007 at 11:57:19AM -0400, Matthew Miller wrote:
> Although, for the past six months or so, new packages hitting rawhide have
> in fact happened to have been signed.

No, wait, never mind me. I am speaking crazy-talk.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From cebbert at redhat.com  Fri Oct 26 16:06:04 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Fri, 26 Oct 2007 12:06:04 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <47220716.6000402@leemhuis.info>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>	<472200C6.6060900@redhat.com>	<20071026110906.07daf580@redhat.com>
	<47220716.6000402@leemhuis.info>
Message-ID: <4722106C.20802@redhat.com>

On 10/26/2007 11:26 AM, Thorsten Leemhuis wrote:
>>> 1) Power off completely.
>>> 2) Boot up.
>>> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
>>>
>>> What default value does your firmware or BIOS have?  notting's drive 
>>> defaulted to 128.
>> Advanced power management level: unknown setting (0x8080)
> 
> Same here. ST980813AS in a Dell Latitude D630, rawhide.
> 

Yep, same with Seagate ST9160821AS.

Is yours SATA too?



From fedora at leemhuis.info  Fri Oct 26 16:12:23 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 26 Oct 2007 18:12:23 +0200
Subject: laptop hard disk etiquette
In-Reply-To: <4722106C.20802@redhat.com>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>	<472200C6.6060900@redhat.com>	<20071026110906.07daf580@redhat.com>	<47220716.6000402@leemhuis.info>
	<4722106C.20802@redhat.com>
Message-ID: <472211E7.20806@leemhuis.info>



On 26.10.2007 18:06, Chuck Ebbert wrote:
> On 10/26/2007 11:26 AM, Thorsten Leemhuis wrote:
>>>> 1) Power off completely.
>>>> 2) Boot up.
>>>> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
>>>>
>>>> What default value does your firmware or BIOS have?  notting's drive 
>>>> defaulted to 128.
>>> Advanced power management level: unknown setting (0x8080)
>> Same here. ST980813AS in a Dell Latitude D630, rawhide.
> Yep, same with Seagate ST9160821AS.
> Is yours SATA too?

Yeah -- controller (ICH8M) in AHCI mode. Just guessing, but maybe AHCI
is the reason for the "unknown setting"

Cu
knurd



From cebbert at redhat.com  Fri Oct 26 16:18:01 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Fri, 26 Oct 2007 12:18:01 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <472211E7.20806@leemhuis.info>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>	<472200C6.6060900@redhat.com>	<20071026110906.07daf580@redhat.com>	<47220716.6000402@leemhuis.info>	<4722106C.20802@redhat.com>
	<472211E7.20806@leemhuis.info>
Message-ID: <47221339.4010109@redhat.com>

On 10/26/2007 12:12 PM, Thorsten Leemhuis wrote:
> 
> On 26.10.2007 18:06, Chuck Ebbert wrote:
>> On 10/26/2007 11:26 AM, Thorsten Leemhuis wrote:
>>>>> 1) Power off completely.
>>>>> 2) Boot up.
>>>>> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
>>>>>
>>>>> What default value does your firmware or BIOS have?  notting's drive 
>>>>> defaulted to 128.
>>>> Advanced power management level: unknown setting (0x8080)
>>> Same here. ST980813AS in a Dell Latitude D630, rawhide.
>> Yep, same with Seagate ST9160821AS.
>> Is yours SATA too?
> 
> Yeah -- controller (ICH8M) in AHCI mode. Just guessing, but maybe AHCI
> is the reason for the "unknown setting"

sata_nv here, and apparently not in ADMA mode.



From buildsys at fedoraproject.org  Fri Oct 26 16:25:25 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri, 26 Oct 2007 12:25:25 -0400 (EDT)
Subject: Package EVR problems in Fedora 2007-10-26
Message-ID: <20071026162525.C4E1815212E@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8

aportal AT univ-montp2 fr:
    kbackup
      FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
      FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)
    
    pikloops
      FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)
    
cgoorah AT yahoo com au:
    piklab
      FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
      FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)
    
    xcircuit
      FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
      F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)
    
chris stone AT gmail com:
    poker-network
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)
    
    poker2d
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)
    
cweyl AT alumni drew edu:
    Zim
      FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
      F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
esandeen AT redhat com:
    xfsprogs
      FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)
    
foolish AT guezz net:
    gtranslator
      F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)
    
frank-buettner AT gmx net:
    ctapi-cyberjack
      FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
      F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)
    
gecko-maint AT redhat com:
    seamonkey
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)
    
gemi AT bluewin ch:
    yap
      F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
john AT ncphotography com:
    bugzilla
      FE6 > F7-updates (0:3.0.2-1.fc6 > 0:3.0.2-0.fc7)
      FE6 > F8 (0:3.0.2-1.fc6 > 0:3.0.2-0.fc8)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
lemenkov AT gmail com:
    fuse-python
      FE6 > F7-updates (0:0.2-6.fc6 > 0:0.2-5.fc7)
      FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
    
lvm-team AT redhat com:
    dmraid
      F7-updates > F8 (0:1.0.0.rc14-4.fc7 > 0:1.0.0.rc14-2.fc7)
    
lxtnow AT gmail com:
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
    wammu
      FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
      F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)
    
michel sylvan AT gmail com:
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)
    
    phpMyAdmin
      FE6 > F7-updates (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc7)
      FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)
    
    python-meld3
      FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
      FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
    
    smolt
      FE6 > F7-updates (0:0.9.9.1-4.fc6 > 0:0.9.8.4-4.fc7)
      FE6 > F8 (0:0.9.9.1-4.fc6 > 0:0.9.9-1.fc8)
    
mtasaka AT ioa s u-tokyo ac jp:
    mirage
      FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
      F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
ondrejj AT salstar sk:
    climm
      FE6 > F7-updates (0:0.6.1-1.fc6 > 0:0.6-2.fc7)
      FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
    
pingoufc4 AT yahoo fr:
    rkward
      FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
      FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)
    
rcritten AT redhat com:
    mod_nss
      FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
      F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)
    
rmeggins AT redhat com:
    adminutil
      FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)
    
    mozldap
      FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
      F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
roland AT redhat com:
    monotone
      FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)
    
s adam AT diffingo com:
    fwfstab
      FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
      F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
----------------------------------------------------------------------

adminutil: rmeggins AT redhat com
  FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)

bugzilla: john AT ncphotography com
  FE6 > F7-updates (0:3.0.2-1.fc6 > 0:3.0.2-0.fc7)
  FE6 > F8 (0:3.0.2-1.fc6 > 0:3.0.2-0.fc8)

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)

climm: ondrejj AT salstar sk
  FE6 > F7-updates (0:0.6.1-1.fc6 > 0:0.6-2.fc7)
  FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)

ctapi-cyberjack: frank-buettner AT gmx net
  FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
  F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)

dmraid: lvm-team AT redhat com
  F7-updates > F8 (0:1.0.0.rc14-4.fc7 > 0:1.0.0.rc14-2.fc7)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

fuse-python: lemenkov AT gmail com
  FE6 > F7-updates (0:0.2-6.fc6 > 0:0.2-5.fc7)
  FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)

fwfstab: s adam AT diffingo com
  FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
  F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)

gtranslator: foolish AT guezz net
  F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

kbackup: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
  FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

mirage: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
  F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)

mod_nss: rcritten AT redhat com
  FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
  F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)

monotone: roland AT redhat com
  FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)

mozldap: rmeggins AT redhat com
  FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
  F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

phpMyAdmin: mmcgrath AT redhat com
  FE6 > F7-updates (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc7)
  FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)

piklab: cgoorah AT yahoo com au
  FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
  FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)

poker-network: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)

poker2d: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-meld3: mmcgrath AT redhat com
  FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
  FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

rkward: pingoufc4 AT yahoo fr
  FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
  FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)

seamonkey: gecko-maint AT redhat com
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9.1-4.fc6 > 0:0.9.8.4-4.fc7)
  FE6 > F8 (0:0.9.9.1-4.fc6 > 0:0.9.9-1.fc8)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

wammu: lxtnow AT gmail com
  FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
  F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)

xcircuit: cgoorah AT yahoo com au
  FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
  F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)

xfsprogs: esandeen AT redhat com
  FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

yap: gemi AT bluewin ch
  F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)

Zim: cweyl AT alumni drew edu
  FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
  F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From mschwendt.tmp0701.nospam at arcor.de  Fri Oct 26 16:33:24 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 26 Oct 2007 18:33:24 +0200
Subject: dwysocha : User unknown in local recipient table
Message-ID: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>

Somebody's mail address in the Fedora Account System refuses delivery
of mail:

Traceback (most recent call last):
  File "./upgradecheckspam.py", line 267, in ?
    main()
  File "./upgradecheckspam.py", line 258, in main
    s.sendmail(mail_from, [owner], msg.as_string())
  File "/usr/lib64/python2.3/smtplib.py", line 687, in sendmail
    raise SMTPRecipientsRefused(senderrs)
smtplib.SMTPRecipientsRefused: {'dwysocha': (550, '<dwysocha>: Recipient address rejected: User unknown in local recipient table')}



From mastahnke at gmail.com  Fri Oct 26 16:43:18 2007
From: mastahnke at gmail.com (Michael Stahnke)
Date: Fri, 26 Oct 2007 11:43:18 -0500
Subject: SUID binaries in the repo
In-Reply-To: <20071026120140.4d536703@redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com> <20071026154655.GB5248@free.fr>
	<20071026120140.4d536703@redhat.com>
Message-ID: <7874d9dd0710260943x6fcd2b08w8c4d818686ad3a50@mail.gmail.com>

On 10/26/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Fri, 26 Oct 2007 17:46:55 +0200
> Patrice Dumas <pertusus at free.fr> wrote:
>
> > rpmlint already points out suid files. I don't think that a specific
> > guideline is needed, a word of caution would be nice. We should expect
> > maintainers to know what they are doing when packaging suid stuff.
> > I personally maintain pmount which is, I hope, rightfully suid.
>
> If we want somebody to explicitly examine all suid instances they yes,
> we do need a guideline.
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
Also keep in mind that not everyone runs rpmlint after each
commit/change.  Some only use it when submitting/reviewing new
packages.

stahnma



From a.badger at gmail.com  Fri Oct 26 16:51:17 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 26 Oct 2007 09:51:17 -0700
Subject: Autoapprove watch* acls in the pkgdb (was Re: [pkgdb] bluez-libs:
 hadess has requested watchbugzilla)
Message-ID: <47221B05.9080807@gmail.com>

References: <200710261045.l9QAj8nt022071 at bastion.fedora.phx.redhat.com> <1193395741.25047.3.camel at cookie.hadess.net>
In-Reply-To: <1193395741.25047.3.camel at cookie.hadess.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bastien Nocera wrote:
> Heya,
> 
> On Fri, 2007-10-26 at 03:45 -0700, Fedora PackageDB wrote:
>> Bastien Nocera (hadess) has requested the watchbugzilla acl on bluez-libs (Fedora devel)
>>
>> To make changes to this package see:
>>   https://admin.fedoraproject.org/pkgdb/packages/name/bluez-libs
> 
> I'm sure this has been asked before. But why do I need to ask permission
> to watch a component in bugzilla?
> 
It hasn't been asked before on the list but that's a piece of 
code/policy that I have on my list to fix[1]_.  No time like the present 
to get some feedback :-)

Proposal:

I'd like to have watchbugzilla and watchcommits (and any other watch* 
acls in the future) auto-approve.  By example:

1) Bastien goes to the bluez-libs webpage.
2) Clicks the checkbox for watchbugzilla.
3) Request is sent to the packagedb which immediately sets the acl.
4) Bastien will immediately start being CC'd on all future bluez-libs bugs.

Does anyone have problems with this piece?

I'm also thinking that we don't need to be as complete about sending 
mail when someone signs up for a watch* acl.  Currently mail goes out to:

* fedora-extras-commits at r.c
* Package owner
* Package maintainers with approveacls set

I don't see a reason to send a message to the commits list in this 
scenario.  Sending to package owner and maintainers I'm hesitant about 
-- on the one hand, they no longer need to approve the acls so why 
bother.  On the other, maybe maintainers want to know who has shown 
interest in their package.

If you have opinions on this, please let me know!

Now that Bastien's brought it up, I'd like to start working on this.  If 
  I don't hear objections, I'll start coding this towards the end of 
next week (deployment to occur after F8 has been released.)

.. _[1]: https://hosted.fedoraproject.org/projects/packagedb/ticket/66

Thanks,
Toshio



From buildsys at fedoraproject.org  Fri Oct 26 16:55:17 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri, 26 Oct 2007 12:55:17 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-26
Message-ID: <20071026165517.0CA8015212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 5

    bugzilla-3.0.2-2.fc6
    nagios-plugins-1.4.8-9.fc6
    qt4-theme-quarticurve-0.0-0.6.1.beta5.fc6
    ruby-gnome2-0.16.0-14.fc6
    smolt-0.9.9.2-1.fc6


Changes in Fedora Extras 6: 


bugzilla-3.0.2-2.fc6
--------------------
* Fri Oct 26 2007 John Berninger <john at ncphotography dot com> - 3.0.2-2
- fix issue with AlowOverride Options

nagios-plugins-1.4.8-9.fc6
--------------------------
* Fri Oct 26 2007 Mike McGrath <mmcgrath at redhat.com> 1.4.8-9
- Fix for Bug 348731 and CVE-2007-5623

* Wed Aug 22 2007 Mike McGrath <mmcgrath at redhat.com> 1.4.8-7
- Rebuild for BuildID
- License change

* Fri Aug 10 2007 Mike McGrath <mmcgrath at redhat.com> 1.4.8-6
- Fix for check_linux_raid - #234416
- Fix for check_ide_disk - #251635

qt4-theme-quarticurve-0.0-0.6.1.beta5.fc6
-----------------------------------------
* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.6.1.beta5
- Fix setup command (forgot to update directory name).

* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.6.beta5
- Update to beta 5:
  - Force selection color to always active (as in Qt/KDE 3)
  - Dock widgets now look much closer to the Qt 3 theme
  - Draw frames around status bar sections (as in Qt 3)

ruby-gnome2-0.16.0-14.fc6
-------------------------
* Thu Oct 25 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-14
- Rebuild against gecko-libs and gecko-devel

* Wed Oct 24 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-13
- Rebuild against new firefox

* Thu Sep 13 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-12
- Newpoppler.patch updated for poppler 0.6

* Sat Sep 08 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-11
- Rebuild against new poppler
- Changed license to LGPLv2+

* Thu Aug 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.16.0-10
- Adjust to GLib 2.14 API + typo fix in glib module

* Thu Aug 09 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-9
- Rebuild against new firefox

* Sat Aug 04 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.16.0-8
- Apply patch extracted from CVS to build glib gtk poppler

* Fri Jul 20 2007 Jesse Keating <jkeating at redhat.com> 0.16.0-7
- Rebuild against new firefox

smolt-0.9.9.2-1.fc6
-------------------
* Thu Oct 25 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9.2-1
- Upstream released new version



From jkeating at redhat.com  Fri Oct 26 16:53:25 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 12:53:25 -0400
Subject: SUID binaries in the repo
In-Reply-To: <7874d9dd0710260943x6fcd2b08w8c4d818686ad3a50@mail.gmail.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
	<20071026154655.GB5248@free.fr>
	<20071026120140.4d536703@redhat.com>
	<7874d9dd0710260943x6fcd2b08w8c4d818686ad3a50@mail.gmail.com>
Message-ID: <20071026125325.6cc184d4@redhat.com>

On Fri, 26 Oct 2007 11:43:18 -0500
"Michael Stahnke" <mastahnke at gmail.com> wrote:

> Also keep in mind that not everyone runs rpmlint after each
> commit/change.  Some only use it when submitting/reviewing new
> packages.

Honestly we need rpmlint ran after every build in Koji as part of
post-build processing.  Maybe even stuff the rpmlint output into the
koji db for future reference, or at least on the filesystem in the same
places as the buildlogs.

Just needs code.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/f2e59054/attachment.sig>

From berrange at redhat.com  Fri Oct 26 17:01:31 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 26 Oct 2007 18:01:31 +0100
Subject: SUID binaries in the repo
In-Reply-To: <20071026125325.6cc184d4@redhat.com>
References: <4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
	<20071026154655.GB5248@free.fr>
	<20071026120140.4d536703@redhat.com>
	<7874d9dd0710260943x6fcd2b08w8c4d818686ad3a50@mail.gmail.com>
	<20071026125325.6cc184d4@redhat.com>
Message-ID: <20071026170131.GF31349@redhat.com>

On Fri, Oct 26, 2007 at 12:53:25PM -0400, Jesse Keating wrote:
> On Fri, 26 Oct 2007 11:43:18 -0500
> "Michael Stahnke" <mastahnke at gmail.com> wrote:
> 
> > Also keep in mind that not everyone runs rpmlint after each
> > commit/change.  Some only use it when submitting/reviewing new
> > packages.
> 
> Honestly we need rpmlint ran after every build in Koji as part of
> post-build processing.  Maybe even stuff the rpmlint output into the
> koji db for future reference, or at least on the filesystem in the same
> places as the buildlogs.

Merely reporting rpmlint output after every build isn't going to be too
scalable, because there can be alot of noise in its output. What we really 
need is to compare the new rpmlint output to the rpmlint output of the 
previous build in that build target. So that we only see 'differences' 
& thus can easily spot regressions.  You can extend this to other RPM
semantics comparisons beyond just rpmlints, so we can do better at spotting
regressions in Fedora updates automatically.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From notting at redhat.com  Fri Oct 26 17:02:06 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 13:02:06 -0400
Subject: Autoapprove watch* acls in the pkgdb (was Re: [pkgdb]
	bluez-libs: hadess has requested watchbugzilla)
In-Reply-To: <47221B05.9080807@gmail.com>
References: <47221B05.9080807@gmail.com>
Message-ID: <20071026170206.GC18423@nostromo.devel.redhat.com>

Toshio Kuratomi (a.badger at gmail.com) said: 
> Does anyone have problems with this piece?
> 
> I'm also thinking that we don't need to be as complete about sending 
> mail when someone signs up for a watch* acl.  Currently mail goes out to:
> 
> * fedora-extras-commits at r.c
> * Package owner
> * Package maintainers with approveacls set
> 
> I don't see a reason to send a message to the commits list in this 
> scenario.  Sending to package owner and maintainers I'm hesitant about 
> -- on the one hand, they no longer need to approve the acls so why 
> bother.  On the other, maybe maintainers want to know who has shown 
> interest in their package.
> 
> If you have opinions on this, please let me know!

autoapprove with mail to package owner & maintainers seems sane to me.

Bill



From nando at ccrma.Stanford.EDU  Fri Oct 26 17:25:06 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Fri, 26 Oct 2007 10:25:06 -0700
Subject: repoview & templates in Fedora site
In-Reply-To: <20071026114443.9802142e.mschwendt.tmp0701.nospam@arcor.de>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
	<20071026114443.9802142e.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1193419506.18470.2.camel@cmn3.stanford.edu>

On Fri, 2007-10-26 at 11:44 +0200, Michael Schwendt wrote:
> On Thu, 25 Oct 2007 10:45:03 -0700, Fernando Lopez-Lezcano wrote:
> 
> > Hi all, is there a place where the "modified" repoview used in the
> > Fedora site could be found? I really could use the layout (where package
> > pages do not include the version in their name). I'm trying to tweak the
> > original 0.5.2 to get the same result but it is not that easy...
> 
> http://home.arcor.de/ms2002sep/tmp/repoview-0.5.2-1.modified.src.rpm

Thank you very much!! Big patch... I was not going to get anywhere close
by myself :-)

(makes it possible to link to individual package pages from outside...)
-- Fernando




From bnocera at redhat.com  Fri Oct 26 17:26:11 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 26 Oct 2007 18:26:11 +0100
Subject: Autoapprove watch* acls in the pkgdb
In-Reply-To: <47221B05.9080807@gmail.com>
References: <47221B05.9080807@gmail.com>
Message-ID: <1193419571.25047.24.camel@cookie.hadess.net>

Hey Toshio,

On Fri, 2007-10-26 at 09:51 -0700, Toshio Kuratomi wrote:
> References: <200710261045.l9QAj8nt022071 at bastion.fedora.phx.redhat.com> <1193395741.25047.3.camel at cookie.hadess.net>
> In-Reply-To: <1193395741.25047.3.camel at cookie.hadess.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Bastien Nocera wrote:
> > Heya,
> > 
> > On Fri, 2007-10-26 at 03:45 -0700, Fedora PackageDB wrote:
> >> Bastien Nocera (hadess) has requested the watchbugzilla acl on bluez-libs (Fedora devel)
> >>
> >> To make changes to this package see:
> >>   https://admin.fedoraproject.org/pkgdb/packages/name/bluez-libs
> > 
> > I'm sure this has been asked before. But why do I need to ask permission
> > to watch a component in bugzilla?
> > 
> It hasn't been asked before on the list but that's a piece of 
> code/policy that I have on my list to fix[1]_.  No time like the present 
> to get some feedback :-)
> 
> Proposal:
> 
> I'd like to have watchbugzilla and watchcommits (and any other watch* 
> acls in the future) auto-approve.  By example:
> 
> 1) Bastien goes to the bluez-libs webpage.
> 2) Clicks the checkbox for watchbugzilla.
> 3) Request is sent to the packagedb which immediately sets the acl.
> 4) Bastien will immediately start being CC'd on all future bluez-libs bugs.
> 
> Does anyone have problems with this piece?

The only problem I could see, is if the bugs filed are security
bugs/sensitive bugs, people adding themselves on the CC: would basically
get access to all those. Probably more a problem on the bugzilla-end
though.

You'd have the same problem if you wanted to enable commits watch
without approval.

> I'm also thinking that we don't need to be as complete about sending 
> mail when someone signs up for a watch* acl.  Currently mail goes out to:
> 
> * fedora-extras-commits at r.c
> * Package owner
> * Package maintainers with approveacls set
> 
> I don't see a reason to send a message to the commits list in this 
> scenario.  Sending to package owner and maintainers I'm hesitant about 
> -- on the one hand, they no longer need to approve the acls so why 
> bother.  On the other, maybe maintainers want to know who has shown 
> interest in their package.

I think we'd still need to keep the approvals for the reasons above.

Cheers



From a.badger at gmail.com  Fri Oct 26 17:26:10 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 26 Oct 2007 10:26:10 -0700
Subject: dwysocha : User unknown in local recipient table
In-Reply-To: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>
References: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <47222332.9050203@gmail.com>

Michael Schwendt wrote:
> Somebody's mail address in the Fedora Account System refuses delivery
> of mail:
> 
> Traceback (most recent call last):
>   File "./upgradecheckspam.py", line 267, in ?
>     main()
>   File "./upgradecheckspam.py", line 258, in main
>     s.sendmail(mail_from, [owner], msg.as_string())
>   File "/usr/lib64/python2.3/smtplib.py", line 687, in sendmail
>     raise SMTPRecipientsRefused(senderrs)
> smtplib.SMTPRecipientsRefused: {'dwysocha': (550, '<dwysocha>: Recipient address rejected: User unknown in local recipient table')}
> 
dwysocha at fp.o isn't going to work because the user is only in cla_done 
and thus has no email alias.

Checking why they aren't showing up on dump-group.cgi....

-Toshio



From jkeating at redhat.com  Fri Oct 26 17:28:54 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 13:28:54 -0400
Subject: SUID binaries in the repo
In-Reply-To: <20071026170131.GF31349@redhat.com>
References: <4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
	<20071026154655.GB5248@free.fr>
	<20071026120140.4d536703@redhat.com>
	<7874d9dd0710260943x6fcd2b08w8c4d818686ad3a50@mail.gmail.com>
	<20071026125325.6cc184d4@redhat.com>
	<20071026170131.GF31349@redhat.com>
Message-ID: <20071026132854.786cc81d@redhat.com>

On Fri, 26 Oct 2007 18:01:31 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> Merely reporting rpmlint output after every build isn't going to be
> too scalable, because there can be alot of noise in its output. What
> we really need is to compare the new rpmlint output to the rpmlint
> output of the previous build in that build target. So that we only
> see 'differences' & thus can easily spot regressions.  You can extend
> this to other RPM semantics comparisons beyond just rpmlints, so we
> can do better at spotting regressions in Fedora updates automatically.

And would we call this magical thing "rpmdiff"  'cause that would be
awesome...

If only there were some opensource software that did this.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/b3dff4cf/attachment.sig>

From icon at fedoraproject.org  Fri Oct 26 17:33:53 2007
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Fri, 26 Oct 2007 13:33:53 -0400
Subject: repoview & templates in Fedora site
In-Reply-To: <1193335539.24482.8.camel@cmn18.stanford.edu>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
	<1193334473.3517.39.camel@cutter>
	<1193335539.24482.8.camel@cmn18.stanford.edu>
Message-ID: <f8f6300f0710261033m2ecd1286p94a4526c6ca3ab07@mail.gmail.com>

On 10/25/07, Fernando Lopez-Lezcano <nando at ccrma.stanford.edu> wrote:
> I tried 0.6.1... With that one I could not see immediately how to get
> the (small) group list to appear on the left pane of the pages

That is not coming back.

> (and I
> had to patch it to avoid problems with non ascii characters in, for
> example, changelog entries).

Did you pass that patch upstream? :)

-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From bruno at wolff.to  Fri Oct 26 17:51:16 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 26 Oct 2007 12:51:16 -0500
Subject: SUID binaries in the repo
In-Reply-To: <20071026095324.1797840a@redhat.com>
References: <200710260844.l9Q8iJeB021313@cvs-int.fedora.redhat.com>
	<4721B112.1020707@leemhuis.info> <4721B86A.5040109@redhat.com>
	<4721BCEA.6080805@leemhuis.info> <4721D11E.90806@redhat.com>
	<11699.1193399251@evolution.bress.net>
	<20071026095324.1797840a@redhat.com>
Message-ID: <20071026175116.GA29709@wolff.to>

On Fri, Oct 26, 2007 at 09:53:24 -0400,
  Jesse Keating <jkeating at redhat.com> wrote:
> On Fri, 26 Oct 2007 07:47:31 -0400
> Josh Bressers <bressers at redhat.com> wrote:
> 
> > Within Red Hat I care for a suid whitelist.  If it's not on the list,
> > I have to be convinced that it should be.  It works rather well
> > honestly.  It would probably make sense to give this task to the
> > Fedora Security Response Team as it will be them cleaning up the mess
> > after a "suid gone wild" event.
> 
> Can you help us draft up a new package review rule that will bring suid
> things to your attention?  I think rpmlint may point out suid files, or
> could be made to easily.  What's missing is a point of contact or a
> bugzilla keyword or blocker list we set or something.

Note that a patch for capabilities being attached to files is going into
2.6.24 and you should probably have a plan for that. (Even scarier is that
I saw a comment that the nosuid mount parameter would not effect these files;
but that's a different problem than what's being discussed here.)



From jkeating at redhat.com  Fri Oct 26 17:52:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 13:52:34 -0400
Subject: Potential changes to Fedora development cycle
Message-ID: <20071026135234.3f9cf626@redhat.com>

The release engineering team as put together a proposed set of
development cycle changes [1] that could affect Fedora 9 development.
This proposed set of changes has been reviewed on fedora-devel-list and
other lists for a period of time and input has been incorporated as
best it could.  Now it's coming time for FESCo to vote on adopting the
new development cycle.

Since this has such far reaching implications we want to give you all
enough heads up so that you can either prepare arguments ahead of time
or show up for the FESCo meeting [2] and discuss it there.

Thank you for your time.

[1]
http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal

[2] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/baf3afc7/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From a.badger at gmail.com  Fri Oct 26 18:06:09 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 26 Oct 2007 11:06:09 -0700
Subject: dwysocha : User unknown in local recipient table
In-Reply-To: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>
References: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <47222C91.5020104@gmail.com>

Michael Schwendt wrote:
> Somebody's mail address in the Fedora Account System refuses delivery
> of mail:
> 
> Traceback (most recent call last):
>   File "./upgradecheckspam.py", line 267, in ?
>     main()
>   File "./upgradecheckspam.py", line 258, in main
>     s.sendmail(mail_from, [owner], msg.as_string())
>   File "/usr/lib64/python2.3/smtplib.py", line 687, in sendmail
>     raise SMTPRecipientsRefused(senderrs)
> smtplib.SMTPRecipientsRefused: {'dwysocha': (550, '<dwysocha>: Recipient address rejected: User unknown in local recipient table')}
> 
dwysocha had a field set incorrectly in the fedora account system.  I've 
corrected that so that he now shows up on::
   https://admin.fedoraproject.org/accounts/dump-group.cgi

-Toshio



From jonathan at jonmasters.org  Fri Oct 26 18:11:02 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Fri, 26 Oct 2007 14:11:02 -0400
Subject: initscript "feature" questions
Message-ID: <1193422262.5646.23.camel@perihelion>

Yo,

Why do we do this in /etc/rc:

# First, run the KILL scripts.
for i in /etc/rc$runlevel.d/K* ; do
        check_runlevel "$i" || continue

        # Check if the subsystem is already up.
        subsys=${i#/etc/rc$runlevel.d/K??}
        [ -f /var/lock/subsys/$subsys -o
-f /var/lock/subsys/$subsys.init ] \
                || continue

        # Bring the subsystem down.
        if LC_ALL=C egrep -q "^..*init.d/functions" $i ; then
                $i stop
        else
                action $"Stopping $subsys: " $i stop
        fi
done

Specifically, why is there the broken assumption that everything must
relate to a daemon (which is now called a subsystem), and that this must
be first running with a lock file before the killscript can run?

On several other $random distributions, I don't have this getting in the
way of me running designated actions on shutdown, and I'd love to know
why it's done this way in Fedora - is this standards compliance or
simply a bug? I'm not criticising, but this wasted time with a number of
unneeded reboots before I went looking for why :-)

Jon.




From notting at redhat.com  Fri Oct 26 18:25:11 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 14:25:11 -0400
Subject: initscript "feature" questions
In-Reply-To: <1193422262.5646.23.camel@perihelion>
References: <1193422262.5646.23.camel@perihelion>
Message-ID: <20071026182511.GC31268@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> Specifically, why is there the broken assumption that everything must
> relate to a daemon (which is now called a subsystem), 

Huh?

> and that this must
> be first running with a lock file before the killscript can run?

We only shut things down that have been started successfully (have a lock file.)

Bill



From jcm at redhat.com  Fri Oct 26 18:32:36 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 14:32:36 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47210BB2.3040201@redhat.com>
References: <47210BB2.3040201@redhat.com>
Message-ID: <1193423556.3113.3.camel@perihelion>


On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.

It looks like you've introduced an unintentional side-effect in this
latest test kernel, that prevented testing, and means that I think it
shouldn't be considered as the final F8 candidate kernel (Jesse hinted
that this might be the case otherwise).

Specifically, either nash is unhappy, you changed the kernel config, or
some other module is busted - I'll start thinking about what - but you
end up with a modprobe fork bomb taking down my machine.

Audio is at best extremely dicey on my (Nvidia HDA) and certainly not
suitable for productive use as a Linux desktop ;-)

Jon.

--- begin quote ---

        /* If modprobe needs a service that is in a module, we get a
recursive
         * loop.  Limit the number of running kmod threads to
max_threads/2 or
         * MAX_KMOD_CONCURRENT, whichever is the smaller.  A cleaner
method
         * would be to run the parents of this process, counting how
many times
         * kmod was invoked.  That would mean accessing the internals of
the
         * process tables to get the command line, proc_pid_cmdline is
static
         * and it is not worth changing the proc code just to handle
this case. 
         * KAO.
         *
         * "trace the ppid" is simple, but will fail if someone's
         * parent exits.  I think this is as good as it gets. --RR
         */
        max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
        atomic_inc(&kmod_concurrent);
        if (atomic_read(&kmod_concurrent) > max_modprobes) {
                /* We may be blaming an innocent here, but unlikely */
                if (kmod_loop_msg++ < 5)
                        printk(KERN_ERR
                               "request_module: runaway loop modprobe %s
\n",
                               module_name);
                atomic_dec(&kmod_concurrent);
                return -ENOMEM;
        }

        ret = call_usermodehelper(modprobe_path, argv, envp, 1);
        atomic_dec(&kmod_concurrent);
        return ret;




From jcm at redhat.com  Fri Oct 26 18:33:32 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 14:33:32 -0400
Subject: initscript "feature" questions
In-Reply-To: <20071026182511.GC31268@nostromo.devel.redhat.com>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
Message-ID: <1193423612.3113.5.camel@perihelion>


On Fri, 2007-10-26 at 14:25 -0400, Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
> > Specifically, why is there the broken assumption that everything must
> > relate to a daemon (which is now called a subsystem), 
> 
> Huh?
> 
> > and that this must
> > be first running with a lock file before the killscript can run?
> 
> We only shut things down that have been started successfully (have a lock file.)

Right. But what if I want to run something on shutdown that's unrelated
to a daemon? And I want to do this from a package, so without manually
modifying the local rc config?

Jon.




From notting at redhat.com  Fri Oct 26 18:34:14 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 14:34:14 -0400
Subject: initscript "feature" questions
In-Reply-To: <1193423612.3113.5.camel@perihelion>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
Message-ID: <20071026183414.GA18386@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> > We only shut things down that have been started successfully (have a lock file.)
> 
> Right. But what if I want to run something on shutdown that's unrelated
> to a daemon? And I want to do this from a package, so without manually
> modifying the local rc config?

Create a SXX service that runs in runlevel 0/6, or add a /sbin/halt.local.

Bill



From cebbert at redhat.com  Fri Oct 26 18:38:00 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Fri, 26 Oct 2007 14:38:00 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <1193423556.3113.3.camel@perihelion>
References: <47210BB2.3040201@redhat.com> <1193423556.3113.3.camel@perihelion>
Message-ID: <47223408.8030908@redhat.com>

On 10/26/2007 02:32 PM, Jon Masters wrote:
> On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
>> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
>> would get us up-to-date with the latest audio drivers and fix many
>> problems with audio drivers not working, or only partially working.
>>
>> Test kernels for i686 and x86_64 are available at:
>>
>>   http://people.redhat.com/cebbert/kernels/F8/
>>
>> Also, kernel 2.6.23.1-36 has the update and is now building.
>>
>> It would be very helpful if people would test these kernels and reply
>> to this message with their experiences, so we can see if this update
>> causes any problems.
> 
> It looks like you've introduced an unintentional side-effect in this
> latest test kernel, that prevented testing, and means that I think it
> shouldn't be considered as the final F8 candidate kernel (Jesse hinted
> that this might be the case otherwise).
> 
> Specifically, either nash is unhappy, you changed the kernel config, or
> some other module is busted - I'll start thinking about what - but you
> end up with a modprobe fork bomb taking down my machine.
> 
> Audio is at best extremely dicey on my (Nvidia HDA) and certainly not
> suitable for productive use as a Linux desktop ;-)
> 

Did it work in the previous kernel? What codec is yours using?
Is your rawhide installation up-to-date with the latest mkinitrd?




From jcm at redhat.com  Fri Oct 26 18:38:27 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 14:38:27 -0400
Subject: initscript "feature" questions
In-Reply-To: <20071026183414.GA18386@nostromo.devel.redhat.com>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
	<20071026183414.GA18386@nostromo.devel.redhat.com>
Message-ID: <1193423907.3113.8.camel@perihelion>


On Fri, 2007-10-26 at 14:34 -0400, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
> > > We only shut things down that have been started successfully (have a lock file.)
> > 
> > Right. But what if I want to run something on shutdown that's unrelated
> > to a daemon? And I want to do this from a package, so without manually
> > modifying the local rc config?
> 
> Create a SXX service that runs in runlevel 0/6, or add a /sbin/halt.local.

Right. I considered that, but this is not "starting" something, it's
shutting something down. In the end, I wound up having a useless start
action that touches a lockfile on startup, just so I can have a "stop"
action to take it down again :-)

Nothing personal, I know you own that package, but I think the logic
there is not ideal ;-)

Jon.




From lemenkov at gmail.com  Fri Oct 26 18:45:50 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 26 Oct 2007 22:45:50 +0400
Subject: Packaging doc/xls-files?
Message-ID: <adf480660710261145h5e9fda55kc0094835170123d0@mail.gmail.com>

Hello All!
Trying to package one software piece I found that there is one
*.doc-file between documentation. There is also its html-source
created with Microsoft Word so I may simply drop non-standard file
format in this particular case, but what should someone do later in
such cases? Are any RFC's or policies for handling such situations?

I personally vote against proprietary doc-format, but we include some
software to deal with so maybe its just my personal paranoia.

-- 
With best regards!



From a.badger at gmail.com  Fri Oct 26 18:50:36 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 26 Oct 2007 11:50:36 -0700
Subject: Autoapprove watch* acls in the pkgdb
In-Reply-To: <1193419571.25047.24.camel@cookie.hadess.net>
References: <47221B05.9080807@gmail.com>
	<1193419571.25047.24.camel@cookie.hadess.net>
Message-ID: <472236FC.5040501@gmail.com>

Bastien Nocera wrote:
> Hey Toshio,
> 
> On Fri, 2007-10-26 at 09:51 -0700, Toshio Kuratomi wrote:
>> References: <200710261045.l9QAj8nt022071 at bastion.fedora.phx.redhat.com> <1193395741.25047.3.camel at cookie.hadess.net>
>> In-Reply-To: <1193395741.25047.3.camel at cookie.hadess.net>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> Bastien Nocera wrote:
>>> Heya,
>>>
>>> On Fri, 2007-10-26 at 03:45 -0700, Fedora PackageDB wrote:
>>>> Bastien Nocera (hadess) has requested the watchbugzilla acl on bluez-libs (Fedora devel)
>>>>
>>>> To make changes to this package see:
>>>>   https://admin.fedoraproject.org/pkgdb/packages/name/bluez-libs
>>> I'm sure this has been asked before. But why do I need to ask permission
>>> to watch a component in bugzilla?
>>>
>> It hasn't been asked before on the list but that's a piece of 
>> code/policy that I have on my list to fix[1]_.  No time like the present 
>> to get some feedback :-)
>>
>> Proposal:
>>
>> I'd like to have watchbugzilla and watchcommits (and any other watch* 
>> acls in the future) auto-approve.  By example:
>>
>> 1) Bastien goes to the bluez-libs webpage.
>> 2) Clicks the checkbox for watchbugzilla.
>> 3) Request is sent to the packagedb which immediately sets the acl.
>> 4) Bastien will immediately start being CC'd on all future bluez-libs bugs.
>>
>> Does anyone have problems with this piece?
> 
> The only problem I could see, is if the bugs filed are security
> bugs/sensitive bugs, people adding themselves on the CC: would basically
> get access to all those. Probably more a problem on the bugzilla-end
> though.
> 
> You'd have the same problem if you wanted to enable commits watch
> without approval.
> 
Hmm... So it sounds like autoapproval is a no-go until we can easily 
create embargoed branches.  Then the workflow would look like:

1) Maintainer is informed of a security issue.
2) Maintainer creates an embargoed branch for F-7, F-8, and devel
3) Maintainer adds necessary people to the acls of the embargoed branch(es).
4) Maintainer opens a bug for the issue against the embargoed branch.
5) Maintainer and others on the embargoed branch's acl commit fixes to 
the embargoed branch in the vcs.
6) When the release can be made, changes are merged from the embargoed 
vcs branch back to the release branches in the vcs, bug gets closed. 
Embargoed branch in the pkgdb and bugzilla component can remain but is 
inactive until the next issue.

-Toshio



From jkeating at redhat.com  Fri Oct 26 18:49:47 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 26 Oct 2007 14:49:47 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47210BB2.3040201@redhat.com>
References: <47210BB2.3040201@redhat.com>
Message-ID: <20071026144947.4eb05c5f@redhat.com>

On Thu, 25 Oct 2007 17:33:38 -0400
Chuck Ebbert <cebbert at redhat.com> wrote:

> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.

If you experience problems we really need to know if the kernel right
before the alsa drop also has the problems.
http://koji.fedoraproject.org/koji/buildinfo?buildID=22273

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/080ff4b0/attachment.sig>

From notting at redhat.com  Fri Oct 26 19:04:36 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 15:04:36 -0400
Subject: initscript "feature" questions
In-Reply-To: <1193423907.3113.8.camel@perihelion>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
	<20071026183414.GA18386@nostromo.devel.redhat.com>
	<1193423907.3113.8.camel@perihelion>
Message-ID: <20071026190436.GA21098@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> > Create a SXX service that runs in runlevel 0/6, or add a /sbin/halt.local.
> 
> Right. I considered that, but this is not "starting" something, it's
> shutting something down. In the end, I wound up having a useless start
> action that touches a lockfile on startup, just so I can have a "stop"
> action to take it down again :-)

What are you shutting down? If it's something to shut down, why isn't it
being started correctly?

Bill



From alan at redhat.com  Fri Oct 26 19:14:40 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 26 Oct 2007 15:14:40 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <472200C6.6060900@redhat.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<472200C6.6060900@redhat.com>
Message-ID: <20071026191440.GC30562@devserv.devel.redhat.com>

On Fri, Oct 26, 2007 at 10:59:18AM -0400, Warren Togami wrote:
> 1) Power off completely.
> 2) Boot up.
> 3) Run `hdparm -I /dev/sda` and see "Advanced power management level:"
> 
> What default value does your firmware or BIOS have?  notting's drive 
> defaulted to 128.

The settings we use are those set by the firmware or the preboot environment
we don't force them and its not our business to do so as far as I can see.



From jcm at redhat.com  Fri Oct 26 19:30:37 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 15:30:37 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47223408.8030908@redhat.com>
References: <47210BB2.3040201@redhat.com>
	<1193423556.3113.3.camel@perihelion>  <47223408.8030908@redhat.com>
Message-ID: <1193427037.3202.1.camel@perihelion>

On Fri, 2007-10-26 at 14:38 -0400, Chuck Ebbert wrote:

> Did it work in the previous kernel?

Ok. So -35 and -36 break for me, I'm running:

[jcm at perihelion ~]$ uname -r
2.6.23-0.214.rc8.git2.fc8

Apologies for slightly outdated version. This box isn't supposed to run
rawhide longer term - once F8 freezes, this is going to be purely a KVM
hosting box for testing contained rawhide/Factory/Unstable/others.

Using the latest mkinitrd and nash, I cannot boot or install any of
these. I will start looking at when it broke.

Jon.




From jcm at redhat.com  Fri Oct 26 19:31:41 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 15:31:41 -0400
Subject: initscript "feature" questions
In-Reply-To: <20071026190436.GA21098@nostromo.devel.redhat.com>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
	<20071026183414.GA18386@nostromo.devel.redhat.com>
	<1193423907.3113.8.camel@perihelion>
	<20071026190436.GA21098@nostromo.devel.redhat.com>
Message-ID: <1193427101.3202.3.camel@perihelion>


On Fri, 2007-10-26 at 15:04 -0400, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
> > > Create a SXX service that runs in runlevel 0/6, or add a /sbin/halt.local.
> > 
> > Right. I considered that, but this is not "starting" something, it's
> > shutting something down. In the end, I wound up having a useless start
> > action that touches a lockfile on startup, just so I can have a "stop"
> > action to take it down again :-)
> 
> What are you shutting down? If it's something to shut down, why isn't it
> being started correctly?

Actually this is something on RHEL4, I just notice the same behavior
exists in current Fedora too. I'm playing around linking kernel modules
on boot and shutdown - there's no service per se.

Jon.




From notting at redhat.com  Fri Oct 26 19:41:01 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 15:41:01 -0400
Subject: initscript "feature" questions
In-Reply-To: <1193427101.3202.3.camel@perihelion>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
	<20071026183414.GA18386@nostromo.devel.redhat.com>
	<1193423907.3113.8.camel@perihelion>
	<20071026190436.GA21098@nostromo.devel.redhat.com>
	<1193427101.3202.3.camel@perihelion>
Message-ID: <20071026194101.GA22682@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> > What are you shutting down? If it's something to shut down, why isn't it
> > being started correctly?
> 
> Actually this is something on RHEL4, I just notice the same behavior
> exists in current Fedora too. I'm playing around linking kernel modules
> on boot and shutdown - there's no service per se.

Well, if you've got a service that does this on boot, you want to create a lock
file anyway, otherwise it will run on changes between runlevels 3 and 5.

Bill



From jcm at redhat.com  Fri Oct 26 19:47:20 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 15:47:20 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <1193427037.3202.1.camel@perihelion>
References: <47210BB2.3040201@redhat.com>
	<1193423556.3113.3.camel@perihelion>  <47223408.8030908@redhat.com>
	<1193427037.3202.1.camel@perihelion>
Message-ID: <1193428040.3202.5.camel@perihelion>


On Fri, 2007-10-26 at 15:30 -0400, Jon Masters wrote:
> On Fri, 2007-10-26 at 14:38 -0400, Chuck Ebbert wrote:
> 
> > Did it work in the previous kernel?
> 
> Ok. So -35 and -36 break for me, I'm running:
> 
> [jcm at perihelion ~]$ uname -r
> 2.6.23-0.214.rc8.git2.fc8
> 
> Apologies for slightly outdated version. This box isn't supposed to run
> rawhide longer term - once F8 freezes, this is going to be purely a KVM
> hosting box for testing contained rawhide/Factory/Unstable/others.
> 
> Using the latest mkinitrd and nash, I cannot boot or install any of
> these. I will start looking at when it broke.

Ok. So the error in question is that we can't modprobe binfmt-464c. I
had to remember what that was - it's ELF. Which is plain weird. This
suggests that the initrd being built is bogus. I'm checking...

Jon.




From jcm at redhat.com  Fri Oct 26 19:49:20 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 15:49:20 -0400
Subject: initscript "feature" questions
In-Reply-To: <20071026194101.GA22682@nostromo.devel.redhat.com>
References: <1193422262.5646.23.camel@perihelion>
	<20071026182511.GC31268@nostromo.devel.redhat.com>
	<1193423612.3113.5.camel@perihelion>
	<20071026183414.GA18386@nostromo.devel.redhat.com>
	<1193423907.3113.8.camel@perihelion>
	<20071026190436.GA21098@nostromo.devel.redhat.com>
	<1193427101.3202.3.camel@perihelion>
	<20071026194101.GA22682@nostromo.devel.redhat.com>
Message-ID: <1193428160.3202.7.camel@perihelion>


On Fri, 2007-10-26 at 15:41 -0400, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
> > > What are you shutting down? If it's something to shut down, why isn't it
> > > being started correctly?
> > 
> > Actually this is something on RHEL4, I just notice the same behavior
> > exists in current Fedora too. I'm playing around linking kernel modules
> > on boot and shutdown - there's no service per se.
> 
> Well, if you've got a service that does this on boot, you want to create a lock
> file anyway, otherwise it will run on changes between runlevels 3 and 5.

I guess you're right. <moan> <grumble> <moan>. I'll just go get some
coffee...feel free to LART me with a big stick next time I'm in RDU.

Jon.




From cebbert at redhat.com  Fri Oct 26 19:50:06 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Fri, 26 Oct 2007 15:50:06 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <fftel1$lb5$1@ger.gmane.org>
References: <47210BB2.3040201@redhat.com> <fftel1$lb5$1@ger.gmane.org>
Message-ID: <472244EE.5020104@redhat.com>

On 10/26/2007 03:20 PM, Harald Hoyer wrote:
> 
> kernel-devel .i686 seems to have x86_64 built helper bins in scrpts/*
> 

Which ones? I can't find any.



From jcm at redhat.com  Fri Oct 26 19:53:00 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 15:53:00 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <1193428040.3202.5.camel@perihelion>
References: <47210BB2.3040201@redhat.com>
	<1193423556.3113.3.camel@perihelion>  <47223408.8030908@redhat.com>
	<1193427037.3202.1.camel@perihelion>
	<1193428040.3202.5.camel@perihelion>
Message-ID: <1193428380.3202.10.camel@perihelion>


On Fri, 2007-10-26 at 15:47 -0400, Jon Masters wrote:
> On Fri, 2007-10-26 at 15:30 -0400, Jon Masters wrote:
> > On Fri, 2007-10-26 at 14:38 -0400, Chuck Ebbert wrote:
> > 
> > > Did it work in the previous kernel?
> > 
> > Ok. So -35 and -36 break for me, I'm running:
> > 
> > [jcm at perihelion ~]$ uname -r
> > 2.6.23-0.214.rc8.git2.fc8
> > 
> > Apologies for slightly outdated version. This box isn't supposed to run
> > rawhide longer term - once F8 freezes, this is going to be purely a KVM
> > hosting box for testing contained rawhide/Factory/Unstable/others.
> > 
> > Using the latest mkinitrd and nash, I cannot boot or install any of
> > these. I will start looking at when it broke.
> 
> Ok. So the error in question is that we can't modprobe binfmt-464c. I
> had to remember what that was - it's ELF. Which is plain weird. This
> suggests that the initrd being built is bogus. I'm checking...

As Jesse says "are we goign to set wagers on if this is a pebcak
thing?"...and he's right. I'm forgetting that I just upgraded this test
box to x86_64 and have spent the last few years installing i686 kernels.

Grumble. I suck. Testing it properly now.

Jon.




From harald at redhat.com  Fri Oct 26 19:59:30 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 26 Oct 2007 21:59:30 +0200
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <472244EE.5020104@redhat.com>
References: <47210BB2.3040201@redhat.com> <fftel1$lb5$1@ger.gmane.org>
	<472244EE.5020104@redhat.com>
Message-ID: <fftgv2$tn1$1@ger.gmane.org>

Chuck Ebbert wrote:
> On 10/26/2007 03:20 PM, Harald Hoyer wrote:
>> kernel-devel .i686 seems to have x86_64 built helper bins in scrpts/*
>>
> 
> Which ones? I can't find any.
> 

e.g.
/lib/modules/2.6.23.1-32.ALSA/build/scripts/basic/fixdep



From harald at redhat.com  Fri Oct 26 20:04:33 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 26 Oct 2007 22:04:33 +0200
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <472244EE.5020104@redhat.com>
References: <47210BB2.3040201@redhat.com> <fftel1$lb5$1@ger.gmane.org>
	<472244EE.5020104@redhat.com>
Message-ID: <ffth8h$vjt$1@ger.gmane.org>

Chuck Ebbert wrote:
> On 10/26/2007 03:20 PM, Harald Hoyer wrote:
>> kernel-devel .i686 seems to have x86_64 built helper bins in scrpts/*
>>
> 
> Which ones? I can't find any.
> 

# rpm -ivh 
http://people.redhat.com/cebbert/kernels/F8/i686/kernel-devel-2.6.23.1-32.ALSA.i686.rpm 

Retrieving 
http://people.redhat.com/cebbert/kernels/F8/i686/kernel-devel-2.6.23.1-32.ALSA.i686.rpm
Preparing...                ########################################### 
[100%]
    1:kernel-devel           ########################################### 
[100%]
[root at backslash ~]# file 
/lib/modules/2.6.23.1-32.ALSA/build/scripts/basic/fixdep

/lib/modules/2.6.23.1-32.ALSA/build/scripts/basic/fixdep: ELF 64-bit LSB 
executable, x86-64, version 1 (SYSV), dynamically linked (uses shared 
libs), for GNU/Linux 2.6.9, not stripped



From agk at redhat.com  Fri Oct 26 20:05:44 2007
From: agk at redhat.com (Alasdair G Kergon)
Date: Fri, 26 Oct 2007 21:05:44 +0100
Subject: Autoapprove watch* acls in the pkgdb
In-Reply-To: <1193419571.25047.24.camel@cookie.hadess.net>
References: <47221B05.9080807@gmail.com>
	<1193419571.25047.24.camel@cookie.hadess.net>
Message-ID: <20071026200544.GE20802@agk.fab.redhat.com>

On Fri, Oct 26, 2007 at 06:26:11PM +0100, Bastien Nocera wrote:
> The only problem I could see, is if the bugs filed are security
> bugs/sensitive bugs, people adding themselves on the CC: would basically
> get access to all those. Probably more a problem on the bugzilla-end
> though.

Indeed - but how often are Fedora security bugs first notified via bugzilla
with the "Security Sensitive" box ticked?

Perhaps sensitive packages or ones with frequent security problems could just
opt out of the "anyone may be a cc" arrangement until a better workflow
through bugzilla is found.  (One change might be to not allow the cc list
access by default on a bug in the security sensitive group, requiring either
a member of that group or the default bug owner to clean up the cc list
before allowing the cc list access to the bug.)

If the maintainer raises the bug, then they can already easily restrict access
- open the bug without any information in it, then restrict it as required,
then add the details.

Alasdair
-- 
agk at redhat.com



From jcm at redhat.com  Fri Oct 26 20:13:37 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 26 Oct 2007 16:13:37 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <47210BB2.3040201@redhat.com>
References: <47210BB2.3040201@redhat.com>
Message-ID: <1193429617.3186.4.camel@perihelion>


On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.

Ok. Once I dealt with a slight PEBKAC issue[0], I have tested this and
confirm that I no longer experience the random jumpy audio, volume
control jumping all over the place (halfline: that BZ I filed yesterday
is definitely not a GNOME applets issue therefore! like I suspected) and
my system is happily playing Garbage (the band, not random whitenoise).

Tangetially, I'll note that pulseaudio failed to start properly, then
crashed, and when I started it manually, it now adds that it can't find
the PCM channel...though it still works. I'll upgrade pulseaudio, but I
think this is all unrelated.

Ship it!

Jon.

[0] One of these days, I'll learn to try the simple fix of turning brain
on briefly, rather than extracting initrd images and assuming the world
has fallen apart every time. I love drama way too much ;-)




From cebbert at redhat.com  Fri Oct 26 20:14:20 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Fri, 26 Oct 2007 16:14:20 -0400
Subject: ALSA 1.0.15 update test kernels available
In-Reply-To: <fftgv2$tn1$1@ger.gmane.org>
References: <47210BB2.3040201@redhat.com>
	<fftel1$lb5$1@ger.gmane.org>	<472244EE.5020104@redhat.com>
	<fftgv2$tn1$1@ger.gmane.org>
Message-ID: <47224A9C.9090403@redhat.com>

On 10/26/2007 03:59 PM, Harald Hoyer wrote:
> Chuck Ebbert wrote:
>> On 10/26/2007 03:20 PM, Harald Hoyer wrote:
>>> kernel-devel .i686 seems to have x86_64 built helper bins in scrpts/*
>>>
>>
>> Which ones? I can't find any.
>>
> 
> e.g.
> /lib/modules/2.6.23.1-32.ALSA/build/scripts/basic/fixdep
> 

Oh those, I thought you meant the ones from Koji. Those were manually
built on a native x86_64 machine and there's probably something
making it build native instead of for the target arch. The official
ones are okay, though.




From seg at haxxed.com  Fri Oct 26 20:14:51 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 26 Oct 2007 15:14:51 -0500
Subject: CD audio: preference to limit drive speed?
In-Reply-To: <adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
References: <47190B89.1030506@BitWagon.com>
	<adf480660710240714t17ea4ee9o9b3f994917851f26@mail.gmail.com>
	<471F5EFB.9000407@BitWagon.com>
	<adf480660710240821l1236961ai97227d3c92ce425d@mail.gmail.com>
Message-ID: <1193429691.9794.6.camel@localhost>

On Wed, 2007-10-24 at 19:21 +0400, Peter Lemenkov wrote:
> I also heard about FLAC-support in modern media-centers (even in
> AppleTV and Playstation3, using plugins of course)...

The iAudio U3 (And most other Cowon players) supports OGG/Vorbis and
FLAC right out of the box:

http://www.cowonamerica.com/products/iaudio/u3/

I have two. :)
-------------- 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/20071026/97fab2fd/attachment.sig>

From linuxsemi at gmail.com  Fri Oct 26 20:18:14 2007
From: linuxsemi at gmail.com (semi linux)
Date: Fri, 26 Oct 2007 13:18:14 -0700
Subject: Upgrade a USB thumb drive image
Message-ID: <e53321d30710261318p3b492588m9741631a1cb9dc5b@mail.gmail.com>

I've CC'ed the devel list as they might have already written a script
to do this...

I'm trying to create a USB install image like diskboot.img from and
for FC4.  The thing is, I have to replace the default kernel with a
new tree to accommodate a new RAID card and Ethernet card which isn't
supported by the standard default kernel.  I've got my upgrade drivers
in - no problems there; the kernel boots and finds the newer cards w/o
problem.  The problem seems to be with updating the diskboot.img...
I'm using a FC4-updated kernel image (2.6.12-1.1447_FC4smp).

I've created the script below to help, but I can't figure-out why the
new kernel or the installer can't find my Ethernet card...  Any tips
or suggestions on how to debug this would be great.

BTW> I'm planning to write this into a how-to once I finish for
everyone to follow as it's quite an involved process.


cp /media/cdrecorder/images/diskboot.img ~/
mkdir ~/bootwork
cd ~/bootwork
mkdir -p initrd-old initrd-new/modules diskboot-old floppy 2.6.12-1.1447_FC4smp
dd if=/dev/zero of=initrd bs=512 count=128000
/sbin/mke2fs -F -m0 initrd
dd if=/dev/zero of=floppy.img bs=512 count=128000
/sbin/mkfs.vfat floppy.img
syslinux floppy.img
mount -o loop ~/diskboot.img diskboot-old
mount -o loop floppy.img floppy
cp diskboot-old/*.msg diskboot-old/syslinux.cfg diskboot-old/splash.lss floppy/
cp /boot/vmlinuz-2.6.12-1.1447_FC4smp floppy/vmlinuz
gunzip -dc diskboot-old/initrd.img > initrd.old
cd initrd-old
cpio -i -d -m < ../initrd.old
cd -
find /lib/modules/2.6.12-1.1447_FC4smp/ -name *.ko | xargs -n 1 -I {}
cp {} 2.6.12-1.1447_FC4smp
cp -a initrd-old/bin initrd-new
cp -a initrd-old/dev initrd-new
cp -a initrd-old/etc initrd-new
cp -a initrd-old/proc initrd-new
cp -a initrd-old/sbin initrd-new
cp -a initrd-old/selinux initrd-new
cp -a initrd-old/sys initrd-new
cp -a initrd-old/tmp initrd-new
cp -a initrd-old/var initrd-new
cp -a initrd-old/modules/module-info initrd-new/modules
cp -a /lib/modules/2.6.12-1.1447_FC4smp/modules.dep initrd-new/modules
cp -a /lib/modules/2.6.12-1.1447_FC4smp/modules.pcimap initrd-new/modules

TMPFILE="pcitable.$$"
OUTFILE="pcitable"
INFILE="/lib/modules/2.6.12-1.1447_FC4smp/modules.pcimap"

# Loop through the PCI map
cat "$INFILE" | while read line; do

  MODULE=`echo "$line" | awk '{ print $1 }'`

  # Skip the comments
  if [ "$MODULE" != "#" ]; then
    VENDOR="0x"`echo "$line" | awk '{ print $2 }' | cut -c 7-`
    DEVICE="0x"`echo "$line" | awk '{ print $3 }' | cut -c 7-`
    SUBVENDOR="0x"`echo "$line" | awk '{ print $4 }' | cut -c 7-`
    SUBDEVICE="0x"`echo "$line" | awk '{ print $5 }' | cut -c 7-`
    DESCRIPTION=`modinfo "$MODULE" | grep "^description:" | cut -c 17-`

    if [ "$VENDOR" != "0xffff" ] && [ "$DEVICE" != "0xffff" ]; then
      if [ "$SUBVENDOR" == "0xffff" ] && [ "$SUBDEVICE" == "0xffff" ]; then
        # Print two IDs
        echo -ne "$VENDOR\t$DEVICE\t\"$MODULE\"" >> "$TMPFILE"
        if [ "$DESCRIPTION" != "" ]; then echo -e "\t\"$DESCRIPTION\""
>> "$TMPFILE"
        else echo >> "$TMPFILE"
        fi
      elif [ "$SUBDEVICE" == "0xffff" ]; then
        # Print three IDs
        echo -ne "$VENDOR\t$DEVICE\t$SUBVENDOR\t\"$MODULE\"" >> "$TMPFILE"
        if [ "$DESCRIPTION" != "" ]; then echo -e "\t\"$DESCRIPTION\""
>> "$TMPFILE"
        else echo >> "$TMPFILE"
        fi
      else
        # Print all four IDs
        echo -ne
"$VENDOR\t$DEVICE\t$SUBVENDOR\t$SUBDEVICE\t\"$MODULE\"" >> "$TMPFILE"
        if [ "$DESCRIPTION" != "" ]; then echo -e "\t\"$DESCRIPTION\""
>> "$TMPFILE"
        else echo >> "$TMPFILE"
        fi
      fi
    fi
  fi
done

sort "$TMPFILE" -o "$TMPFILE".sorted
uniq "$TMPFILE".sorted "$OUTFILE"
rm -f "$TMPFILE" "$TMPFILE".sorted
cp -a pcitable initrd-new/modules


find 2.6.12-1.1447_FC4smp | cpio -o -H crc | gzip -c9 > modules.cgz
cp -a modules.cgz initrd-new/modules
cd initrd-old
find . | cpio -o -H newc -O ../initrd
cd -
gzip -c9 initrd > initrd.img
cp initrd.img floppy
sync
umount floppy
umount diskboot-old
dd if=floppy.img of=/dev/sdb
cd


Thanks,
- G.



From debarshi.ray at gmail.com  Fri Oct 26 21:22:18 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sat, 27 Oct 2007 02:52:18 +0530
Subject: Announcing Opyum 0.0.3 for Fedora
Message-ID: <3170f42f0710261422g60addcafx7e95ea95d5a0f07d@mail.gmail.com>

I hereby announce the second stable release of Opyum, the Fedora
Offline Package Manager, version 0.0.3.

Opyum (pronounced 'opium') provides a set of tools to enable users,
who do not have a good network (eg., Internet) connection at their
ready disposal, to easily install new packages or update existing ones
through the conventional package management system available in
Fedora.

Tar ball: http://rishi.fedorapeople.org/opyum/opyum-0.0.3.tar.gz
MD5SUM: 693bc38845aaef5ecf599d7564483f09
SHA1SUM: c21186d6b1f31ff8e7a4b9b9fa57dba74f12adae

New features:
Installing or updating from Yum-Packs is easier now with the
introduction of system-install-yumpacks. Apart from that, there is a
new repository manager to let users to add, remove, edit, enable and
disable repositories.

Installation instructions:
# yum install opyum

Documentation page:
https://fedoraproject.org/wiki/DebarshiRay/Opyum

Project page:
https://hosted.fedoraproject.org/projects/opyum/

Bug reports:
https://bugzilla.redhat.com/

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From P at draigBrady.com  Fri Oct 26 21:48:17 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Fri, 26 Oct 2007 22:48:17 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <472209D2.7090803@draigBrady.com>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>
Message-ID: <472260A1.9080208@draigBrady.com>

P?draig Brady wrote:
> Nicolas Mailhot wrote:
>> Le Ven 26 octobre 2007 17:26, P?draig Brady a ?crit :
>>> Also what is causing the drive to "load"
>>> so often after an "unload"?
>> On old hard drives pretty much anything can cause the disk to spin up
>> again. Sometimes querrying the hard drive status (are you suspended?)
>> is sufficient to wake it up (don't laugh)
> 
> So possibly running smartctl -A will cause the drive to load.
> I.E. it's a self fulfilling prophecy :)

Well with me being a muppet it definitely will cause the drive to "load"
Each time I ran smartctl previously the atime was updated, causing a "load".

I did some more investigation, the summary of which is:

1. ubuntu dicks with the drive spin down timers when on battery
2. fedora does not (as Bill suggested)
3. fedora should probably not (as Alan suggested)
4. fedora should probably default to relatime mount option
   on laptops at least (as Ingo suggested here:
   http://kerneltrap.org/node/14148 )


Details....

I turned off atime updates using:
# mount -oremount,noatime /

And verified there were no disk accesses using:
# /etc/init.d/syslog stop
# echo 1 > /proc/sys/vm/block_dump
# dmesg -c
# dmesg -c
# ...

So testing again using this function:

lcc() {
    sec=$1
    while true; do
        smartctl -i -A /dev/sda |
        grep -F Load_Cycle_Count |
        tr -s ' ' | cut -d ' '  -f 2,10

        sleep $sec
    done
}

This shows that smartctl does in fact seem to cause a "load" :)
# lcc 10
Load_Cycle_Count 351623
Load_Cycle_Count 351624
Load_Cycle_Count 351625
Load_Cycle_Count 351626
Load_Cycle_Count 351627

Here the disk isn't given a chance to unload
# lcc 5
Load_Cycle_Count 351629
Load_Cycle_Count 351629
Load_Cycle_Count 351629
Load_Cycle_Count 351629
Load_Cycle_Count 351629

This implies it's the disk has an adaptive rather than a simple timeout
as 10 seconds was previously long enough for the drive to "unload"
# lcc 10
Load_Cycle_Count 351636
Load_Cycle_Count 351636
Load_Cycle_Count 351636
Load_Cycle_Count 351636
Load_Cycle_Count 351636

Taking averages over a long time seems to be appropriate so.
Noting that this laptop was running FC4 for most of its life,
and that it has the following defaults:
# hdparm -I /dev/sda | grep "Advanced power management level"
        Advanced power management level: 128 (0x80)
Using the smart Power_On_Hours value, shows that in total
it has load cycled on average once every 48s:
# echo "scale=2; (4718*60*60)/351675" | bc
48.29

That's far too aggressive, especially considering this
laptop is plugged in most of the time.
But also note that atime updates were enabled (as per default),
which probably exacerbated the problem.
I'll disable that first on all partitions and if that
doesn't suffice I'll make the "unloading" less agressive
using the `hdparam -B $level /dev/sda` command.

cheers,
P?draig.

p.s. I did a quick check using the following
to show that on an idle F7 laptop with noatime set,
the disk is not accessed for 15 min at least, which is encouraging:

while true; do
    date
    dmesg -c | grep sda | grep -Ev '(pdflush|kjournald)'
    sleep 10
done




From bpepple at fedoraproject.org  Fri Oct 26 22:48:15 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Fri, 26 Oct 2007 18:48:15 -0400
Subject: FESCo Meeting Summary for 2007-10-25
Message-ID: <1193438895.2782.2.camel@kennedy>

= Members Present =
      * Brian Pepple (bpepple) 
      * Jason Tibbitts (tibbs) 
      * Jesse Keating (f13) 
      * Dennis Gilmore (dgilmore) 
      * Bill Nottingham (notting) 
      * Tom Callaway (spot) 
      * Warren Togami (warren) 
      * Jeremy Katz (jeremy) 
      * Christopher Aillon (caillon)

= Members Absent =
      * David Woodhouse (dwmw2) 
      * Christian Iseli (c4chris) 
      * Josh Boyer (jwb) 
      * Kevin Fenzi (nirik)

= Summary =
== Branch Policy for Packages on Soon-to-be-EOL Releases ==
      * FESCo members were pretty sure this had already decided. bpepple
        will search the wiki to verify this.

== NetworkManager ==
      * FESCo received an update on the status of NM for F8 from Dan
        Williams: 
              * Reached feature parity with 0.6.x from F7. 
              * Multiple device support won't be finished in time for F8
                gold, but can come in as an F8 update.
                
Misc
      * Brief discussion on when the feature process for F9 will start,
        and what changes to the process needs to be made. 
      * Rahul Sundaram (mether) asked if the FESCo mailing list archive
        could be opened. bpepple will check with the other FESCo members
        to see if anyone objecFESCo Meeting Summary for 2007-10-18ts to
        that.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2007-10-25.html

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071026/16ac842e/attachment.sig>

From wwoods at redhat.com  Fri Oct 26 23:18:58 2007
From: wwoods at redhat.com (Will Woods)
Date: Fri, 26 Oct 2007 19:18:58 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
Message-ID: <1193440738.3838.71.camel@metroid.rdu.redhat.com>

As promised, here's an update on the current Fedora 8 Blocker list. 

As a note: the deadline for blocker fixes is Tuesday, October 29. If we
still have unfixed critical bugs Tuesday, the release will have to be
delayed.

But I don't think that'll happen. Things are looking OK. We currently
have 14 bugs on the blocker list, which I'll talk about in detail below.
About half of them have fixes that are waiting for confirmation, and a
couple of them could be dropped if necessary because they only affect
particular, uncommon hardware.

What we need help testing is:

1) ALSA - 1.0.15 was released last week, and we decided it was a
low-risk update that would fix audio problems. for a lot of people. You
probably saw mail from Chuck Ebbert about this already.

2) Intel wireless - John Linville, our fearless (and handsome) wireless
maintainer, just added a fix for iwlwifi that should help some Intel
wireless users. 

Both of the above patches are in kernel-2.6.23.1-37.fc8, which should
land in rawhide tomorrow. You can get it from koji in the meantime:
http://koji.fedoraproject.org/koji/buildinfo?buildID=22511

3) dmraid, especially Intel
See bug 349161 below. Something is causing mkinitrd to mess up the /init
script, which leaves the reporter's system unbootable. We can't
reproduce it at all. 

If you've got dmraid (aka BIOS RAID aka fakeraid) hardware, ESPECIALLY
the one mentioned in this bug (ICH9R chipset + Intel Matrix Raid),
please try to install rawhide and let us know if it works or not.

Here's the full blocker list, in detail:

=== Miscellaneous bugs from last time ===

* Bug 208607: ASSIGNED - kernel maintainers
- mkinitrd: iSCSI root requires crc32c module

I believe we plan to fix this by building crc32c into the kernel for
release (which would make this a non-blocker). We'll hopefully have a
smarter fix for F9 that will actually close the bug.


* Bug 242766: ASSIGNED - alan
- [pata_via via82c596a] hard drive not found during install attempt

All testing with pata_via seems to indicate that it works for most
people. Alan's debugging efforts indicate that this is a drive-specific
failure on a machine with a buggy BIOS. Fun. This will be dropped from
the blocker list, since it works under normal circumstances.

(By the way- thanks to everyone who answered the call for testing here.
You guys rock!)


* Bug 335161: ASSIGNED - triad (Linus Walleij)
- multilib file conflicts in gnokii

Fix was incomplete, needs a rebuild. This prevents people from being
able to yum upgrade from F8Test3 to F8 final. 


* Bug 330931: MODIFIED - katzj
- liveinst fails - sg devices confuse anaconda?

This was waiting on some info from the reporter, which has been
provided. It involves some uncommon hardware so this bug may be dropped
from the blocker list if it can't be fixed easily.


=== NetworkManager bugs ===

* Bug 311511: NEW - dcbw
- x86_64 iwl3945 NM crash after Keyring loop Deny

Comments indicate that the crash is fixed, but it still loops on bad
passwords. 


* Bug 323371: NEEDINFO - dcbw
- NM 0.7 doesn't support WPA/WPA2 Enterprise (certificate-based
authentication)

Reporter seems to indicate that this is mostly fixed, but some testing
on a fresh install is needed to confirm the fix.


* Bug 353091: MODIFIED - dcbw
- NetworkManager-0.7.0-0.3.svn3020.fc8 crashes when trying to switch to
wireless Network

nm-applet crasher. A fix will be in the next build, and then this can be
retested and (hopefully) closed. 


=== Added since Wednesday ===

* Bug 349161: NEW - pjones
- Missing entries in the init script of the initrd image makes the
system unbootable on dmraid

This is a mysterious one. mkinitrd is creating a bad /init script for a
dmraid (aka fakeraid, aka BIOS RAID) raid0 set. But we can't reproduce
it on any of the dmraid machines we've tried.

It's a fixable problem, and I don't think the hardware is very common,
and we can't reproduce the bug ourselves, so.. if push comes to shove
this bug might get dropped from the blocker list and fixed post-F8.


* Bug 352511: MODIFIED - dwalsh
- return of an avc on useradd with livecd user

Should be fixed in selinux-policy -33 - we'll confirm as soon as Jeremy
makes some Live images.


* Bug 353571: MODIFIED - dwalsh
- /usr/bin/crontab blocked by selinux


Apparently fixed in selinux-policy-3.0.8-36; waiting for confirmation
from the reporter.

* Bug 353961: NEW - twoerner
- lokkit doesn't write iptables config with --nostart

This was reported earlier this morning - no response from the maintainer
yet. Technically I don't think this breaks any of the ReleaseCriteria,
so it could be dropped. But proper firewall function is important for
security so we want to keep an eye on this.


* Bug 354531: ASSIGNED - dwmw2
- script failure

This is a simple scriptlet problem with bluez-utils, but it keeps the
'bluetooth' service from being installed properly. Improved Bluetooth
support is one of the major features of F8, so we want this to work
right. The maintainer is aware of the problem and working to fix it.


* Bug 354571: MODIFIED - anaconda maintainers
- live install fails when there's a pre-existing install

Fixed in anaconda CVS - the next set of Live images should allow us to
retest and close this.


* Bug 354781: NEW - skvidal
- yum-skip-broken changes yum's dependency solver even when it's not
active

This is a bug with the popular yum-skip-broken plugin that could cause
it to make upgrades from F7 fail. Upgrade failures are bad. 



And there you have it. Most of those bugs already have fixes pending,
and none of the rest are hair-on-fire critical bugs, so I think we're in
good shape. If you can help test the stuff I mentioned above, or you
have found some huge problem that we've missed, please let us know.

Thanks for helping make Fedora more awesome!

-w
-------------- 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/20071026/a25cad5c/attachment.sig>

From sundaram at fedoraproject.org  Fri Oct 26 23:29:15 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 27 Oct 2007 04:59:15 +0530
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <4722784B.50508@fedoraproject.org>

Will Woods wrote:
> As promised, here's an update on the current Fedora 8 Blocker list. 
> 
> As a note: the deadline for blocker fixes is Tuesday, October 29. If we
> still have unfixed critical bugs Tuesday, the release will have to be
> delayed.
> 
> But I don't think that'll happen. Things are looking OK. We currently
> have 14 bugs on the blocker list, which I'll talk about in detail below.
> About half of them have fixes that are waiting for confirmation, and a
> couple of them could be dropped if necessary because they only affect
> particular, uncommon hardware.

Thanks for doing this. We should be doing more of these status reports 
in the last couple of months towards a new release.

You might want to look at the status of

https://bugzilla.redhat.com/show_bug.cgi?id=251493

This appears to be hardware specific. If it can't fixed, the workaround 
should be documented in the common bugs page.

Workaround is to boot with "pci=nomsi,nommconf"

Rahul



From ndbecker2 at gmail.com  Sat Oct 27 00:17:50 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 26 Oct 2007 20:17:50 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <ffu03e$ap7$1@ger.gmane.org>

Tested kernel-2.6.23.1-26.fc8.x86_64

Sound working great! (IHC8)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

iwl4965 working great!
02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)

Thanks - you guys rock!



From alan at redhat.com  Sat Oct 27 00:38:47 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 26 Oct 2007 20:38:47 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <47220726.2040603@draigBrady.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<47220726.2040603@draigBrady.com>
Message-ID: <20071027003847.GD30562@devserv.devel.redhat.com>

On Fri, Oct 26, 2007 at 04:26:30PM +0100, P?draig Brady wrote:
> I understand from the comments in the bug that windows sets
> the values so the BIOSes don't bother setting appropriate values.

Windows will set values if the user has set preferences but as I understand
it not otherwise. Ditto Linux

> Also what is causing the drive to "load"
> so often after an "unload"?

Using it ? It unloads when it parks the head and sleeps, it loads again
when it unparks the drive.



From nando at ccrma.Stanford.EDU  Sat Oct 27 00:45:07 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Fri, 26 Oct 2007 17:45:07 -0700
Subject: repoview & templates in Fedora site
In-Reply-To: <f8f6300f0710261033m2ecd1286p94a4526c6ca3ab07@mail.gmail.com>
References: <1193334303.24482.2.camel@cmn18.stanford.edu>
	<1193334473.3517.39.camel@cutter>
	<1193335539.24482.8.camel@cmn18.stanford.edu>
	<f8f6300f0710261033m2ecd1286p94a4526c6ca3ab07@mail.gmail.com>
Message-ID: <1193445907.18470.22.camel@cmn3.stanford.edu>

On Fri, 2007-10-26 at 13:33 -0400, Konstantin Ryabitsev wrote:
> On 10/25/07, Fernando Lopez-Lezcano <nando at ccrma.stanford.edu> wrote:
> > I tried 0.6.1... With that one I could not see immediately how to get
> > the (small) group list to appear on the left pane of the pages
> 
> That is not coming back.

:-<
That's too bad... I thought it was very useful. 

> > (and I
> > had to patch it to avoid problems with non ascii characters in, for
> > example, changelog entries).
> 
> Did you pass that patch upstream? :)

If it were a patch I would have, but it is (was) just a hack, and it was
applied to a build on centos5 (it may work fine on Fedora for all I
know, sorry to not have been more precise about this):

--------
--- repoview-0.6.1/repoview.py~	2007-09-27 08:43:45.000000000 -0700
+++ repoview-0.6.1/repoview.py	2007-10-24 15:20:31.000000000 -0700
@@ -40,6 +40,9 @@
 import time
 import md5
 
+# set default encoding to utf
+sys.setappdefaultencoding('utf-8')
+
 from optparse import OptionParser
 from kid      import Template
 
--------

and to work it needs something like this, that reenables changing he
default unicode python encoding at runtime, somewhere in the python
search path:

--------
#
# sitecustomize.py - saving a useful function.
# so that apps can change the default encoding
# (used by repoview 0.6.1)
#

import sys

sys.setappdefaultencoding = sys.setdefaultencoding
--------

Or perhaps it could be something that looks up the locale and changes
things accordingly (the default behavior I was seeing was that strings
were being decoded as 'ascii' and repoview would crash when hitting
characters > 128). 

I'm sure there's a better way of doing the same thing...
-- Fernando




From alan at redhat.com  Sat Oct 27 00:50:04 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 26 Oct 2007 20:50:04 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <20071027005004.GE30562@devserv.devel.redhat.com>

On Fri, Oct 26, 2007 at 07:18:58PM -0400, Will Woods wrote:
> 3) dmraid, especially Intel
> See bug 349161 below. Something is causing mkinitrd to mess up the /init
> script, which leaves the reporter's system unbootable. We can't
> reproduce it at all. 

Is this the same as the open FC7 reports about initrd problems with dmraid
and LVM etc that are sitting there one with a patch that claims to fix it ?

Alan



From bnocera at redhat.com  Sat Oct 27 00:53:33 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Sat, 27 Oct 2007 01:53:33 +0100
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <1193446413.25047.34.camel@cookie.hadess.net>


On Fri, 2007-10-26 at 19:18 -0400, Will Woods wrote:
> As promised, here's an update on the current Fedora 8 Blocker list. 
<snip>
> * Bug 335161: ASSIGNED - triad (Linus Walleij)
> - multilib file conflicts in gnokii
> 
> Fix was incomplete, needs a rebuild. This prevents people from being
> able to yum upgrade from F8Test3 to F8 final. 

I was under the impression Jeremy's fix did the trick but it didn't. To
be honest, gnokii's build system is a pile of crap, and using the
autotools will be a step forward (believe it or not, and it's on my TODO
list).

<snip>
> * Bug 354531: ASSIGNED - dwmw2
> - script failure
> 
> This is a simple scriptlet problem with bluez-utils, but it keeps the
> 'bluetooth' service from being installed properly. Improved Bluetooth
> support is one of the major features of F8, so we want this to work
> right. The maintainer is aware of the problem and working to fix it.

I blame Joe for half-fixing it. I'll try and fix it again come Monday.



From david at lovesunix.net  Sat Oct 27 01:21:54 2007
From: david at lovesunix.net (David Nielsen)
Date: Sat, 27 Oct 2007 03:21:54 +0200
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <1193448114.2775.6.camel@dawkins>


fre, 26 10 2007 kl. 19:18 -0400, skrev Will Woods: 
> As promised, here's an update on the current Fedora 8 Blocker list. 
> 
> As a note: the deadline for blocker fixes is Tuesday, October 29. If we
> still have unfixed critical bugs Tuesday, the release will have to be
> delayed.
> 
> But I don't think that'll happen. Things are looking OK. We currently
> have 14 bugs on the blocker list, which I'll talk about in detail below.
> About half of them have fixes that are waiting for confirmation, and a
> couple of them could be dropped if necessary because they only affect
> particular, uncommon hardware.
> 
> What we need help testing is:
> 
> 1) ALSA - 1.0.15 was released last week, and we decided it was a
> low-risk update that would fix audio problems. for a lot of people. You
> probably saw mail from Chuck Ebbert about this already.

using the snd-intel8x0 driver, things work just fine after this update.
I'll test a few more drivers if I can find more soundcards in the
hardware graveyard.

> 2) Intel wireless - John Linville, our fearless (and handsome) wireless
> maintainer, just added a fix for iwlwifi that should help some Intel
> wireless users. 

My laptop has one of these, I'm not seeing any crashing but NM is still
not fond of correctly interacting with the keyring, also establishing
the connection to the AP often takes several tries. I will try after
todays update I saw some NM rpms in the queue. Regardless the connection
establishing issue seems common on my network, my desktop (rt61pc1)
displays the same problem as well as frequent disconnects.

On my desktop I often find that repeatedly rmmoding the driver will
allow me restore the connection.

Regardless, while not super stable, the wifi setup I have going has
improved massively just over the last week.

> Both of the above patches are in kernel-2.6.23.1-37.fc8, which should
> land in rawhide tomorrow. You can get it from koji in the meantime:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22511
> 
> 3) dmraid, especially Intel
> See bug 349161 below. Something is causing mkinitrd to mess up the /init
> script, which leaves the reporter's system unbootable. We can't
> reproduce it at all. 

nForce3 dmraid has been stunningly stable and bugfree all during F8, I'm
sorry to report no entertaining breakage.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071027/d79de675/attachment.sig>

From ngompa13 at gmail.com  Sat Oct 27 02:42:28 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Fri, 26 Oct 2007 21:42:28 -0500
Subject: Packaging doc/xls-files?
In-Reply-To: <adf480660710261145h5e9fda55kc0094835170123d0@mail.gmail.com>
References: <adf480660710261145h5e9fda55kc0094835170123d0@mail.gmail.com>
Message-ID: <8278b1b0710261942q554a158dnada3f3cfe3e1d7f7@mail.gmail.com>

Use OOo and convert it to ODF. Then package the resultant ODF, and make note
of the conversion of the documents in the RPM changelog. That is what I do,
though I haven't yet released my packages containing these documents...

On 10/26/07, Peter Lemenkov <lemenkov at gmail.com> wrote:
>
> Hello All!
> Trying to package one software piece I found that there is one
> *.doc-file between documentation. There is also its html-source
> created with Microsoft Word so I may simply drop non-standard file
> format in this particular case, but what should someone do later in
> such cases? Are any RFC's or policies for handling such situations?
>
> I personally vote against proprietary doc-format, but we include some
> software to deal with so maybe its just my personal paranoia.
>
> --
> With best regards!
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/155142ea/attachment.htm>

From cra at WPI.EDU  Sat Oct 27 02:55:07 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 26 Oct 2007 22:55:07 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <20071027025507.GK25455@angus.ind.WPI.EDU>

On Fri, Oct 26, 2007 at 07:18:58PM -0400, Will Woods wrote:
> * Bug 323371: NEEDINFO - dcbw
> - NM 0.7 doesn't support WPA/WPA2 Enterprise (certificate-based
> authentication)
> 
> Reporter seems to indicate that this is mostly fixed, but some testing
> on a fresh install is needed to confirm the fix.

I updated this bug since you composed this message.  The new WPA 
Enterprise support isn't yet working for me with PEM certificates.  I 
think it is important to get this case working, as many sites use 
cert-based authentication for wireless, and it used to work in earlier 
releases.



From ngompa13 at gmail.com  Sat Oct 27 03:03:01 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Fri, 26 Oct 2007 22:03:01 -0500
Subject: Some thoughts about firmware inclusion.
In-Reply-To: <1193335817.15341.45.camel@localhost.localdomain>
References: <6798.192.54.193.51.1193137693.squirrel@rousalka.dyndns.org>
	<adf480660710230425w36c8277dofec4ca3cb0c068f0@mail.gmail.com>
	<20071024005354.2f2cc521@lain.camperquake.de>
	<8278b1b0710241506k74a5b87ep8f478a00b080b3d7@mail.gmail.com>
	<47209C4E.3000903@camperquake.de>
	<1193320154.15341.27.camel@localhost.localdomain>
	<4720ABAF.7090801@hhs.nl>
	<1193335817.15341.45.camel@localhost.localdomain>
Message-ID: <8278b1b0710262003r6ef7f749med45f13add4d9233@mail.gmail.com>

The problem I see with including Win32 binaries in the current state of
things is that Fedora DOES NOT have the MinGW cross-tools packages
available. I hope that with GCC4 being available for MinGW that someone
would take the incentive to package MinGW for Fedora (I am not skilled
enough to do it!), which then will permit rpmbuild to be able to build Win32
based programs from source to install. Though at the moment, I don't think
it would be possible to package VirtualDub with the current rules regarding
binaries of this nature since at the moment, no one has made VirtualDub
buildable using a makefile system + GCC. Also, VirtualDub requires MASM
currently, though Avery Lee was considering switching to YASM at one point.
Though PopAsm could fix that problem (it can build MASM assembly code). If
there was a way to turn MSVC2005 solutions and project files into makefiles,
then it could possibly be packaged in Fedora.

On 10/25/07, Adam Jackson <ajackson at redhat.com> wrote:
>
> On Thu, 2007-10-25 at 16:43 +0200, Hans de Goede wrote:
> > Adam Jackson wrote:
> > > I suppose, if I had to think about it, that the policy on game data
> sort
> > > of contradicts this nice clean delineation, since game data files
> often
> > > include a scripting language for in-game logic.  That's not
> necessarily
> > > a problem, merely an exception.  Personally I'm fine with it, but it
> > > seems difficult to construct a (non-emotional) justification for it
> that
> > > doesn't expand to cover win32 binaries or ROMs without source.
> >
> > Well written, and I fully agree, except that besides an exception for
> game
> > data, I would also like to see an exception for system ROM's for old
> computers
> > like the amstrad, where amstrad has been so kind to allow free
> redistribution
> > of the roms. I'm not advocating to make the same exception for software
> that
> > ran on these old computers, merely for the code that was in ROM's
> _inside_ the
> > sytem and thus is needed for the emulator to function _at all_, to me
> this
> > clearly is firmware.
>
> Yeah, that's pretty clearly firmware to me too.
>
> - ajax
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071026/dcb3a6a5/attachment.htm>

From notting at redhat.com  Sat Oct 27 03:29:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 26 Oct 2007 23:29:15 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <20071027032915.GA3454@nostromo.devel.redhat.com>

> * Bug 330931: MODIFIED - katzj
> - liveinst fails - sg devices confuse anaconda?
> 
> This was waiting on some info from the reporter, which has been
> provided. It involves some uncommon hardware so this bug may be dropped
> from the blocker list if it can't be fixed easily.

Should be fixed in currently built anaconda.

> * Bug 353961: NEW - twoerner
> - lokkit doesn't write iptables config with --nostart
> 
> This was reported earlier this morning - no response from the maintainer
> yet. Technically I don't think this breaks any of the ReleaseCriteria,
> so it could be dropped. But proper firewall function is important for
> security so we want to keep an eye on this.

Should already be fixed and tagged in 1.0.8-3.fc8.

Bill



From buildsys at redhat.com  Sat Oct 27 04:27:20 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 27 Oct 2007 00:27:20 -0400
Subject: rawhide report: 20071026 changes
Message-ID: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>

 

 
Updated Packages:

Miro-0.9.8.1-7.fc8
------------------
* Thu Oct 25 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.9.8.1-7
- Rebuild for new Firefox (2.0.0.8)
- License: GPLv2+ to conform with Fedora licensing guidelines

ORBit-1:0.5.17-22.fc8
---------------------
* Thu Oct 25 2007 Paul Howarth <paul at city-fan.org> 1:0.5.17-22
- Fix multiarch conflicts in -config scripts (#342801)
- Clarify licensing (libs LGPLv2+, binaries GPLv2+)
- Preserve timestamps for files copied from source into installed package
- Build and install using system libtool to avoid bogus rpath on 64-bit arches

anaconda-11.3.0.46-1
--------------------
* Thu Oct 25 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.46-1
- Fix mirrorlist used to be the fedora8 one
- Ignore sg devices (#330930)
- Add kdepim to multilib upgrade blacklist (#339981)
- Fix retries (clumens, #330641)

bluez-utils-3.20-3.fc8
----------------------
* Fri Oct 26 2007 - Bastien Nocera <bnocera at redhat.com> 3.20-3
- Apply fixes from rawhide by Joe Orton, making sure hcid
  gets started on new installs (#351981)

chmsee-1.0.0-1.25.fc8
---------------------
* Wed Oct 24 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.25
- build for firefox-2.0.0.8

* Sat Aug 11 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.23
- update to 1.0.0
- build for firefox-2.0.0.6
- update License field to GPLv2

* Sat Jul 21 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-0.22.beta2
- fix desktop file

egoboo-2.4.3-4.fc8
------------------
* Thu Oct 25 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 2.4.3-4
- Fix yet another crash only occuring on i386 and another one only occuring
  when playing a paladin on x86_64 (bz 351171)
gdm-1:2.20.1-5.fc8
------------------
* Fri Oct 26 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.1-5
- fix gdmflexiserver -n (bug 352491)

gedit-1:2.20.3-1.fc8
--------------------
* Thu Oct 25 2007 Ray Strode <rstrode at redhat.com> - 1:2.20.3-1
- Update to 2.20.3 at the request of upstream 
  (fixes upstream bug 468578)
gnome-keyring-2.20.1-3.fc8
--------------------------
* Thu Oct 25 2007 Christopher Aillon <caillon at redhat.com> - 2.20.1-3
- Rebuild

* Mon Oct 15 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-2
- Disable the auto-unlock question for now (#312531)

* Mon Oct 15 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1
- Drop obsolete patches
- Add bug ref for selinux patch

gnome-python2-extras-2.19.1-9.fc8
---------------------------------
* Thu Oct 25 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-9.fc8
- Require gecko-libs instead of firefox (RH bug #532111).

* Wed Oct 24 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-8.fc8
- Rebuild against firefox 2.0.0.8.

gtk2-2.12.1-5.fc8
-----------------
* Thu Oct 25 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-5
- Fix a bug that prevents GtkBuilder-using apps (like totem)
  to run in some locales (like Turkish) (#348631)

* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-4
- Fix a crash in gnome-system-log (#321701)

* Wed Oct 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-2
- Fix a crash in the firefox print preview (#336771)

hal-cups-utils-0.6.13-2.fc8
---------------------------
* Thu Oct 25 2007 Tim Waugh <twaugh at redhat.com> 0.6.13-2
- Don't disable printers that are unplugged (works around bug #352681 and
  bug #352691).

hwdata-0.207-2.fc8
------------------
* Thu Oct 25 2007 Matt Domsch <Matt_Domsch at dell.com> 0.207-2
- MonitorsDB: add 20 new Dell monitors

kazehakase-0.4.9-2.svn3312.fc8
------------------------------
* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2.svn3312
- Try svn 3312

kdeaccessibility-1:3.5.8-3.fc8
------------------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 1:3.5.8-3
- Obsoletes: %name ... to help out multilib upgrades

kdeaddons-3.5.8-2.fc8
---------------------
* Wed Oct 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.5.8-2
- -extras: Requires: kdegames3

* Tue Oct 16 2007 Than Ngo <than at redhat.com> 3.5.8-1
- 3.5.8

kdebase-6:3.5.8-4.fc8
---------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -libs conditional (f8+)

kdebase4-3.94.0-2.fc8
---------------------
* Thu Oct 25 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.94.0-2
- patch dolphin.desktop to get Dolphin to start from the menu

kdeedu-3.5.8-3.fc8
------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-3
- -libs: Obsoletes: %name ... to help out multilib upgrades

* Wed Oct 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-2
- -libs conditional (f8+)
- %post/%postun libs /sbin/ldconfig

kdegames-6:3.5.8-3.fc8
----------------------
* Wed Oct 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-3 
- -libs conditional (f8+)
- -libs: %post/%postun -p /sbin/ldconfig

* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-2
- fix/update trademarks patch

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-1
- kde-3.5.8
- libs subpkg (more multilib friendly)

kdegraphics-7:3.5.8-4.fc8
-------------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-4
- -libs: Obsoletes: %name ... to help out multilib upgrades

* Tue Oct 16 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-3
- -libs: exclude libkpovmodeler
- -libs conditional (f8+)

kdelibs-6:3.5.8-7.fc8
---------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-7
- fix application of custom zoom patch (rh#335461)

* Tue Oct 23 2007 Than Ngo <than at redhat.com> - 3.5.8-6
- Resolves: rh#335461, kpdf and kview lost custom zoom

* Thu Oct 18 2007 Than Ngo <than at redhat.com> - 3.5.8-5
- bz273681, add vhdl syntax for kate, thanks to Chitlesh GOORAH

kdemultimedia-6:3.5.8-6.fc8
---------------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-6
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -extras-libs: Obsoletes %name-extras ... likewise

* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-5
- -extras-libs: (re)include libnoatun*.la

kdenetwork-7:3.5.8-3.fc8
------------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-3
- -libs: Obsoletes: %name ... to help out multilib upgrades

kdepim-6:3.5.8-3.svn20071013.ent.fc8
------------------------------------
* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3.20071013.ent
- -libs: %post/%postun /sbin/ldconfig
- -libs conditional (f8+)

* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-2.20071013.ent
- -libs subpkg (to be more multilib friendly)

kdesdk-3.5.8-2.fc8
------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.5.8-2
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -libs conditional (f8+)

kdeutils-6:3.5.8-3.fc8
----------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3
- Obsoletes: %name ... to help out multilib upgrades

kdevelop-9:3.5.0-2.fc8
----------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-2
- autosave patch

* Sat Oct 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-1
- kdevelop-3.5.0 (kde-3.5.8)

kdewebdev-6:3.5.8-3.fc8
-----------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 6:3.5.8-3
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -libs conditional (f8+)

kernel-2.6.23.1-35.fc8
----------------------
* Wed Oct 24 2007 Dave Jones <davej at redhat.com>
- Disable early boot debugging for release.

* Wed Oct 24 2007 Roland McGrath <roland at redhat.com>
- Install System.map in kernel-devel packages.

* Tue Oct 23 2007 John W. Linville <linville at redhat.com>
- quiet mac80211 decryption noise when frames may not be for us

libuser-0.56.6-1.fc8
--------------------
* Thu Oct 25 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.6-1
- Set SELinux file contexts when creating home directories, preserve them when
  moving home directories
  Resolves: #351201

libxml-1:1.8.17-18.fc8
----------------------
* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-18
- fix multiarch conflict in xml-config (#342501)
- preserve timestamps for files copied from source to installed package
- re-encode ChangeLog as UTF-8

* Thu Aug 30 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-17
- rebuild for BuildID inclusion
  (http://fedoraproject.org/wiki/Releases/FeatureBuildId)

* Fri Aug 17 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-16
- add mode to fix call to open() with O_CREAT and only 2 args
- unexpand tabs in spec
- update license tag

openoffice.org-1:2.3.0-6.6.fc8
------------------------------
* Wed Oct 24 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.6
- Resolves: rhbz#338701 fix openoffice.org.ooo82608.vcl.gtkbadfree.patch

* Fri Oct 19 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.5
- Resolves: rhbz#338701 fix openoffice.org.ooo82608.vcl.gtkbadfree.patch

* Tue Oct 16 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.4
- Resolves: rhbz#333201 dangling symlinks
- Resolves: rhbz#334841 fix "all files" glob in in mail merge picker
- Resolves: ooo#82671 print crash

openvrml-0.16.6-6.fc8
---------------------
* Thu Oct 25 2007 Braden McDaniel  <braden at endoframe.com> - 0.16.6-6
- Made openvrml depend on gecko-libs instead of firefox.

* Wed Oct 24 2007 Braden McDaniel  <braden at endoframe.com> - 0.16.6-5
- Updated firefox dependency to 2.0.0.8.

pidgin-2.2.2-1.fc8
------------------
* Wed Oct 24 2007 Warren Togami <wtogami at redhat.com> - 2.2.2-1
- 2.2.2 CVE-2007-4999

qt4-theme-quarticurve-0.0-0.6.1.beta5.fc8
-----------------------------------------
* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.6.1.beta5
- Fix setup command (forgot to update directory name).

* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.6.beta5
- Update to beta 5:
  - Force selection color to always active (as in Qt/KDE 3)
  - Dock widgets now look much closer to the Qt 3 theme
  - Draw frames around status bar sections (as in Qt 3)

ruby-gnome2-0.16.0-14.fc8
-------------------------
* Thu Oct 25 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-14
- Rebuild against gecko-libs and gecko-devel

* Wed Oct 24 2007 Allisson Azevedo <allisson at gmail.com> 0.16.0-13
- Rebuild against new firefox

selinux-policy-3.0.8-33.fc8
---------------------------
* Thu Oct 25 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-33
- Allow cupsd_config_t to use usb_device_t
- Dontaudit use of kernel_t
- Fix creation of unconfined_gnome_home_t

valknut-0.3.11-1.fc8
--------------------
* Sun Oct 14 2007 Luke Macken <lmacken at redhat.com> 0.3.11-1
- 0.3.11

vinagre-0.3-2.fc8
-----------------

Broken deps for i386
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.i386 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	polyxmass-bin - 0.9.3-2.fc6.i386 requires libpolyxmass.so.10



Broken deps for x86_64
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.x86_64 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	polyxmass-bin - 0.9.3-2.fc6.x86_64 requires libpolyxmass.so.10()(64bit)



Broken deps for ppc
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
	polyxmass-bin - 0.9.3-2.fc6.ppc requires libpolyxmass.so.10



Broken deps for ppc64
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc64 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From mschwendt.tmp0701.nospam at arcor.de  Sat Oct 27 09:29:44 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sat, 27 Oct 2007 11:29:44 +0200
Subject: dwysocha : User unknown in local recipient table
In-Reply-To: <47222C91.5020104@gmail.com>
References: <20071026183324.ea6a1b53.mschwendt.tmp0701.nospam@arcor.de>
	<47222C91.5020104@gmail.com>
Message-ID: <20071027112944.85e47fd4.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 26 Oct 2007 11:06:09 -0700, Toshio Kuratomi wrote:

> > smtplib.SMTPRecipientsRefused: {'dwysocha': (550, '<dwysocha>: Recipient address rejected: User unknown in local recipient table')}
> > 
> dwysocha had a field set incorrectly in the fedora account system.  I've 
> corrected that so that he now shows up on::
>    https://admin.fedoraproject.org/accounts/dump-group.cgi

Thanks, Toshio. I'm going to add fault-tolerant exception handling to
the upgradecheckspam.py script nevertheless. 



From mikem.rtp at gmail.com  Sat Oct 27 09:59:27 2007
From: mikem.rtp at gmail.com (Mike McLean)
Date: Sat, 27 Oct 2007 05:59:27 -0400
Subject: Koji Garbage Collection
In-Reply-To: <20071024231118.GA6298@redhat.com>
References: <20071022204127.220d62b8@redhat.com>
	<20071023013127.GD15801@redhat.com>
	<1193104148.10460.41.camel@localhost.localdomain>
	<20071024231118.GA6298@redhat.com>
Message-ID: <4f50e0680710270259m98db3ddj71557c1ca766ba2b@mail.gmail.com>

On 10/24/07, Dave Jones <davej at redhat.com> wrote:
>  > Then, there's koji download-build[1] which will
>  > download all the packages for a specific build into the current
>  > directory
>
> Indeed. kudos to whoever wrote that. That's going to be really useful.

$ git-log -n1 8b1f311482eb373e306649485641a1587a7f53c4
commit 8b1f311482eb373e306649485641a1587a7f53c4
Author: Mike Bonnet <mikeb at redhat.com>
Date:   Thu May 31 13:15:09 2007 -0400

    new koji download-build command (patch provided by Dan Berrange)
    koji.spec: require python-urlgrabber (needed by download-build)
    cli/koji.conf: add new pkgurl option (needed by download-build)



From pertusus at free.fr  Sat Oct 27 10:00:07 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 27 Oct 2007 12:00:07 +0200
Subject: Potential changes to Fedora development cycle
In-Reply-To: <20071026135234.3f9cf626@redhat.com>
References: <20071026135234.3f9cf626@redhat.com>
Message-ID: <20071027100007.GC2643@free.fr>

On Fri, Oct 26, 2007 at 01:52:34PM -0400, Jesse Keating wrote:
> The release engineering team as put together a proposed set of
> development cycle changes [1] that could affect Fedora 9 development.
> This proposed set of changes has been reviewed on fedora-devel-list and
> other lists for a period of time and input has been incorporated as
> best it could.  Now it's coming time for FESCo to vote on adopting the
> new development cycle.

This seems right to me. The section 'Release Candidate and Final release'
is a bit too dense to me. I think I understand it, but it seems to me
that it could be clearer. A specific point that could be clarified is:

  This freeze point is also the point in which we would create any
  remaining needed branches in CVS for the release. Any builds from the
  branch would be held in an updates candidate tag to be potential updates
  for after the release, or to be pulled in to the release by request.

It is not clear to me what the 'remaining needed branches in CVS for the
release' are at that point. This explained in the next paragraph, however,
unless I am wrong, but should certainly appear before since some branches 
could be created between beta and RC.

Maybe what could be done is add, between 'Beta' and 'Release Candidate
and Final release':

=== Early (optional) CVS branching ===

Right after Beta release or sometime between Beta and RC release, we
allow for early branching of software. This allows developers to check
in new features and otherwise unstable changes that would not be
suitable to introduce to the current release.

=== Release Candidate and Final release ===

..... This freeze point is also the point in which we would create any
remaining needed branches in CVS (that haven't been created during the
early CVS branching) for the release.





Not a big deal.

--
Pat



From kevin.kofler at chello.at  Sat Oct 27 11:37:05 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 27 Oct 2007 11:37:05 +0000 (UTC)
Subject: rawhide report: 20071026 changes
References: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>
Message-ID: <loom.20071027T113620-193@post.gmane.org>

Build System <buildsys <at> redhat.com> writes:
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.i386 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.x86_64 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc64 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8

3.5.8-7.fc8 with a fix for this typo is now building.

        Kevin Kofler



From caillon at redhat.com  Sat Oct 27 12:16:47 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 27 Oct 2007 08:16:47 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <ffu03e$ap7$1@ger.gmane.org>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
	<ffu03e$ap7$1@ger.gmane.org>
Message-ID: <47232C2F.80308@redhat.com>

Neal Becker wrote:
> Tested kernel-2.6.23.1-26.fc8.x86_64

Which is much older than the kernel we want tested.  It would be good to 
know that the newer kernels work, too.  :-)


> Sound working great! (IHC8)
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
> 
> iwl4965 working great!
> 02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
> 
> Thanks - you guys rock!
> 



From ndbecker2 at gmail.com  Sat Oct 27 13:22:21 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 27 Oct 2007 09:22:21 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
	<ffu03e$ap7$1@ger.gmane.org> <47232C2F.80308@redhat.com>
Message-ID: <ffve2d$ipp$1@ger.gmane.org>

Christopher Aillon wrote:

> Neal Becker wrote:
>> Tested kernel-2.6.23.1-26.fc8.x86_64
> 
> Which is much older than the kernel we want tested.  It would be good to
> know that the newer kernels work, too.  :-)
> 
> 
>> Sound working great! (IHC8)
>> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
>> Controller (rev 03)
>> 
>> iwl4965 working great!
>> 02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN
>> Network Connection (rev 61)
>> 
>> Thanks - you guys rock!
>> 
> 

I'm sorry That should be:
tested: kernel-2.6.23.1-37.fc8.x86_64




From skvidal at fedoraproject.org  Sat Oct 27 14:09:15 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 27 Oct 2007 10:09:15 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <1193494155.2784.20.camel@cutter>


On Fri, 2007-10-26 at 19:18 -0400, Will Woods wrote:

> * Bug 354781: NEW - skvidal
> - yum-skip-broken changes yum's dependency solver even when it's not
> active
> 
> This is a bug with the popular yum-skip-broken plugin that could cause
> it to make upgrades from F7 fail. Upgrade failures are bad. 

Neither I nor the reporter (notting) can make this happen again and
looking at the code which runs in skip-broken it isn't even possible so
something else happened during that run where he noticed the issue but
it's not this bug. So this one is closed.

-sv




From valent.turkovic at gmail.com  Sat Oct 27 14:20:58 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 27 Oct 2007 16:20:58 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
	<64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
Message-ID: <64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>

On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> https://core.fluendo.com/gstreamer/trac/ticket/24
> previous link was a duplicate, sorry.
>
> Valent.
>

This is the reply I got from fluendo support:

	to		Valent Turkovic <valent.turkovic at gmail.com>	
	cc		Fluendo Store Manager <contact at fluendo.com>	
	date		Oct 26, 2007 10:42 AM	
	subject		Re: Fluendo codecs in Fedora 8?	

Yes we know about that problem and we are pushing Intel everyday to
provide us with a version of IPP that does not do text relocation.

Sorry for the frustration that it creates.

Best regards,

Julien Moutte,
FLUENDO S.A.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From sundaram at fedoraproject.org  Sat Oct 27 14:25:35 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 27 Oct 2007 19:55:35 +0530
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>	<4720F01E.9030802@fedoraproject.org>	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>	<64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
	<64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>
Message-ID: <47234A5F.4000701@fedoraproject.org>

Valent Turkovic wrote:
> On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
>> https://core.fluendo.com/gstreamer/trac/ticket/24
>> previous link was a duplicate, sorry.
>>
>> Valent.
>>
> 
> This is the reply I got from fluendo support:
> 
> 	to		Valent Turkovic <valent.turkovic at gmail.com>	
> 	cc		Fluendo Store Manager <contact at fluendo.com>	
> 	date		Oct 26, 2007 10:42 AM	
> 	subject		Re: Fluendo codecs in Fedora 8?	
> 
> Yes we know about that problem and we are pushing Intel everyday to
> provide us with a version of IPP that does not do text relocation.
> 
> Sorry for the frustration that it creates.

You can consider filing a RFE against SELinux policy to not deny this.

Rahul



From valent.turkovic at gmail.com  Sat Oct 27 14:52:04 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sat, 27 Oct 2007 16:52:04 +0200
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <47234A5F.4000701@fedoraproject.org>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
	<64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
	<64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>
	<47234A5F.4000701@fedoraproject.org>
Message-ID: <64b14b300710270752r68bda22eqfa901c3db7c16e3d@mail.gmail.com>

On 10/27/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Valent Turkovic wrote:
> > On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> >> https://core.fluendo.com/gstreamer/trac/ticket/24
> >> previous link was a duplicate, sorry.
> >>
> >> Valent.
> >>
> >
> > This is the reply I got from fluendo support:
> >
> >       to              Valent Turkovic <valent.turkovic at gmail.com>
> >       cc              Fluendo Store Manager <contact at fluendo.com>
> >       date            Oct 26, 2007 10:42 AM
> >       subject         Re: Fluendo codecs in Fedora 8?
> >
> > Yes we know about that problem and we are pushing Intel everyday to
> > provide us with a version of IPP that does not do text relocation.
> >
> > Sorry for the frustration that it creates.
>
> You can consider filing a RFE against SELinux policy to not deny this.
>
> Rahul
>

Thanks Rahul, I'll try that...

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jreiser at BitWagon.com  Sat Oct 27 15:00:29 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 27 Oct 2007 08:00:29 -0700
Subject: readline-devel-5.2-7.fc8.i386.rpm trouble
In-Reply-To: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>
References: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>
Message-ID: <4723528D.6060103@BitWagon.com>

pungi fails to download  readline-devel-5.2-7.fc8.i386.rpm .
It exists on all the mirrors.  Could some saved checksum be mangled?

-- 



From stefan at seekline.net  Sat Oct 27 15:07:34 2007
From: stefan at seekline.net (Stefan Schulze Frielinghaus)
Date: Sat, 27 Oct 2007 16:07:34 +0100
Subject: correct spec file creation
Message-ID: <1193497654.30404.11.camel@vogon>

I found some differences in the building process of a spec file.

I will refer to the following document as A
http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html
and this one as B
http://fedoraproject.org/wiki/Packaging/Guidelines

A suggests to use %makeinstall (as seen in the example and in the
description of the example) while B says exactly the opposite _not_ to
use %makeinstall ("Why the %makeinstall macro should not be used").

Another difference ist the use of PreReq (and maybe BuildPreReq too?)
which is used in A and B suggests _not_ to use it.

While I'm new to RPM and I just wanted to setup my first packet, could
someone point out the difference and just say what is right and wrong?

cheers,
Stefan



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Oct 27 15:14:23 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 28 Oct 2007 00:14:23 +0900
Subject: correct spec file creation
In-Reply-To: <1193497654.30404.11.camel@vogon>
References: <1193497654.30404.11.camel@vogon>
Message-ID: <472355CF.2040709@ioa.s.u-tokyo.ac.jp>

Stefan Schulze Frielinghaus wrote, at 10/28/2007 12:07 AM +9:00:
> I will refer to the following document as A
> http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html
> and this one as B
> http://fedoraproject.org/wiki/Packaging/Guidelines
> 
If there is some conflicting description between these two, please
follow B.

Regards,
Mamoru



From jkeating at redhat.com  Sat Oct 27 15:59:50 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 27 Oct 2007 11:59:50 -0400
Subject: Potential changes to Fedora development cycle
In-Reply-To: <20071027100007.GC2643@free.fr>
References: <20071026135234.3f9cf626@redhat.com>
	<20071027100007.GC2643@free.fr>
Message-ID: <20071027115950.794eda19@redhat.com>

On Sat, 27 Oct 2007 12:00:07 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> This seems right to me. The section 'Release Candidate and Final
> release' is a bit too dense to me. I think I understand it, but it
> seems to me that it could be clearer. A specific point that could be
> clarified is:
> 
>   This freeze point is also the point in which we would create any
>   remaining needed branches in CVS for the release. Any builds from
> the branch would be held in an updates candidate tag to be potential
> updates for after the release, or to be pulled in to the release by
> request.
> 
> It is not clear to me what the 'remaining needed branches in CVS for
> the release' are at that point. This explained in the next paragraph,
> however, unless I am wrong, but should certainly appear before since
> some branches could be created between beta and RC.
> 
> Maybe what could be done is add, between 'Beta' and 'Release Candidate
> and Final release':
> 
> === Early (optional) CVS branching ===
> 
> Right after Beta release or sometime between Beta and RC release, we
> allow for early branching of software. This allows developers to check
> in new features and otherwise unstable changes that would not be
> suitable to introduce to the current release.
> 
> === Release Candidate and Final release ===
> 
> ..... This freeze point is also the point in which we would create any
> remaining needed branches in CVS (that haven't been created during the
> early CVS branching) for the release.

Awesome, thanks for the input.  I've made this change.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071027/062b2248/attachment.sig>

From oisin.feeley at gmail.com  Sat Oct 27 16:16:27 2007
From: oisin.feeley at gmail.com (Oisin Feeley)
Date: Sat, 27 Oct 2007 12:16:27 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <471F8FDB.8070405@codewiz.org>
References: <471C94BD.6080801@codewiz.org> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
	<471F8FDB.8070405@codewiz.org>
Message-ID: <e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>

On 10/24/07, Bernardo Innocenti <bernie at codewiz.org> wrote:
> On 10/24/07 13:09, Alan Cox wrote:

[snip]

> > Which presumably means they'll not be using SHA1 much longer - right ?
>
> Uh?  I wasn't aware SHA1 has been broken (at least, not in
> a practically exploitable way).

It hasn't ... yet.  But the US government is mandating that it not be
used after 2010, so anyone wanting to be able to fulfill that needs to
plan now how to make the transition:

"March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224,
SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all
applications using secure hash algorithms. Federal agencies should
stop using SHA-1 for digital signatures, digital time stamping and
other applications that require collision resistance as soon as
practical, and must use the SHA-2 family of hash functions for these
applications after 2010."

http://csrc.nist.gov/groups/ST/hash/policy.html

Best wishes,

Oisin Feeley



From sgrubb at redhat.com  Sat Oct 27 17:23:18 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 27 Oct 2007 13:23:18 -0400
Subject: Should we settle on one SSL implementation?
In-Reply-To: <e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
References: <471C94BD.6080801@codewiz.org> <471F8FDB.8070405@codewiz.org>
	<e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
Message-ID: <200710271323.19149.sgrubb@redhat.com>

On Saturday 27 October 2007 12:16:27 pm Oisin Feeley wrote:
> It hasn't ... yet. ?But the US government is mandating that it not be
> used after 2010, so anyone wanting to be able to fulfill that needs to
> plan now how to make the transition:

Correct. This is probably the reason why Vista is SHA256 everywhere, too. 

During F9, there will be another parallel and somewhat related project to hunt 
down places where md-5 and sha-1 are being used and look at improving the 
situation so that sha-256, and in some cases other hash algorithms, could be 
used.

-Steve



From paul at xelerance.com  Sat Oct 27 17:27:14 2007
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 27 Oct 2007 13:27:14 -0400 (EDT)
Subject: Should we settle on one SSL implementation?
In-Reply-To: <e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
References: <471C94BD.6080801@codewiz.org> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
	<471F8FDB.8070405@codewiz.org>
	<e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0710271321140.20500@newtla.xelerance.com>

On Sat, 27 Oct 2007, Oisin Feeley wrote:

> > Uh?  I wasn't aware SHA1 has been broken (at least, not in
> > a practically exploitable way).
>
> It hasn't ... yet.  But the US government is mandating that it not be
> used after 2010, so anyone wanting to be able to fulfill that needs to
> plan now how to make the transition:
>
> "March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224,
> SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all
> applications using secure hash algorithms. Federal agencies should
> stop using SHA-1 for digital signatures, digital time stamping and
> other applications that require collision resistance as soon as
> practical, and must use the SHA-2 family of hash functions for these
> applications after 2010."
>
> http://csrc.nist.gov/groups/ST/hash/policy.html

Note that this applies to sha1 being used for hashes of filenames, X.509
attributes, etc. It does not apply to IPsec's use of md5/sha1, which does not
require collision resistance because of its use of HMAC.

The official IETF policy is "walk, not run, to a new secure hashing algorithm".
Also, it is believed that if SHA-1 is compromised, the attack would work
similarly to SHA-256 et al.

Paul



From mszpak at wp.pl  Sat Oct 27 18:05:40 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sat, 27 Oct 2007 20:05:40 +0200
Subject: Upgrade 7.92 -> 8
Message-ID: <ffvull$3pq$1@ger.gmane.org>

Hi,


I would like to install Fedora 8 Test 3 to help testing new Fedora
version. I know it could be less stable that final, but it's not very
important me.
Later, I would like to upgrade it to F-8 final (without a new
installation). Would it be possible to use updates from a development
version and after 9 XI smoothly switch to updates for F-8?
Or the only way is to call "Upgrade" option from F-8 DVD?


Thanks for info
Marcin



From jkeating at redhat.com  Sat Oct 27 18:08:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 27 Oct 2007 14:08:31 -0400
Subject: Upgrade 7.92 -> 8
In-Reply-To: <ffvull$3pq$1@ger.gmane.org>
References: <ffvull$3pq$1@ger.gmane.org>
Message-ID: <20071027140831.2bcb2171@redhat.com>

On Sat, 27 Oct 2007 20:05:40 +0200
"Marcin Zaj?czkowski" <mszpak at wp.pl> wrote:

> I would like to install Fedora 8 Test 3 to help testing new Fedora
> version. I know it could be less stable that final, but it's not very
> important me.
> Later, I would like to upgrade it to F-8 final (without a new
> installation). Would it be possible to use updates from a development
> version and after 9 XI smoothly switch to updates for F-8?
> Or the only way is to call "Upgrade" option from F-8 DVD?

If you install now, and then do all your updates, the fedora-release
package will turn off 'development' and turn on 'fedora' and
'updates-release' repos.  These repos right now redirect to rawhide
until F8 goes live and then they will point to F8.  This will "pin" you
to Fedora 8.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071027/581879d3/attachment.sig>

From wwoods at redhat.com  Sat Oct 27 18:51:05 2007
From: wwoods at redhat.com (Will Woods)
Date: Sat, 27 Oct 2007 14:51:05 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <4722784B.50508@fedoraproject.org>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
	<4722784B.50508@fedoraproject.org>
Message-ID: <1193511065.4523.4.camel@localhost.localdomain>

On Sat, 2007-10-27 at 04:59 +0530, Rahul Sundaram wrote:

> Thanks for doing this. We should be doing more of these status reports
> in the last couple of months towards a new release.

Wish they were easier to do. Hopefully next release we can start doing
this around the Beta release and keep the blocker list under control
enough that it doesn't take me 2 hours to write the status mail every
time.

> You might want to look at the status of
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=251493
> 
> This appears to be hardware specific. If it can't fixed, the workaround 
> should be documented in the common bugs page.
> 
> Workaround is to boot with "pci=nomsi,nommconf"

Added to http://fedoraproject.org/wiki/Bugs/F8Common

davej's comment sounds like we might get a fix for this before F8. Cool!

-w
-------------- 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/20071027/f387e52d/attachment.sig>

From paul at xelerance.com  Sat Oct 27 19:07:12 2007
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 27 Oct 2007 15:07:12 -0400 (EDT)
Subject: Should we settle on one SSL implementation?
In-Reply-To: <200710271323.19149.sgrubb@redhat.com>
References: <471C94BD.6080801@codewiz.org> <471F8FDB.8070405@codewiz.org>
	<e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
	<200710271323.19149.sgrubb@redhat.com>
Message-ID: <Pine.LNX.4.64.0710271506081.20848@newtla.xelerance.com>

On Sat, 27 Oct 2007, Steve Grubb wrote:

> During F9, there will be another parallel and somewhat related project to hunt
> down places where md-5 and sha-1 are being used and look at improving the
> situation so that sha-256, and in some cases other hash algorithms, could be
> used.

Also, as Michael Richardson <mcr at xelerance.com> reminded me:

	SHA256 is slower, and there are no hardware accelerators for it.
	(while, I think, VIA supports SHA1 acceleration?)
	If you want to switch, a switch to accelerated AES-XCBC would be a
	better choice, I think.  Or, AES-GCM mode, which hashes and encrypts in
	one step.

Paul



From ndbecker2 at gmail.com  Sat Oct 27 19:24:12 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 27 Oct 2007 15:24:12 -0400
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
References: <200710260000.24041.ml@deadbabylon.de>
Message-ID: <fg038s$h3p$1@ger.gmane.org>

Thanks.  I grabbed compiz-manager.  It needs minor fixes for x86_64.

All /usr/lib needs to be /usr/lib64 on x86_64.



From abo at kth.se  Sat Oct 27 19:29:28 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 27 Oct 2007 21:29:28 +0200
Subject: laptop hard disk etiquette
In-Reply-To: <47220716.6000402@leemhuis.info>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<472200C6.6060900@redhat.com> <20071026110906.07daf580@redhat.com>
	<47220716.6000402@leemhuis.info>
Message-ID: <1193513368.9273.45.camel@home.alexander.bostrom.net>

fre 2007-10-26 klockan 17:26 +0200 skrev Thorsten Leemhuis:

> Additional note: the hard driver does strange noise (sounds a bit like
> parking and unparking the heads maybe) now and then (sometimes every ten
> seconds or so, sometimes a lot less). 

Oooohh... Yeah, this old Thinkpad T21 makes irritating noises like that
too. And the Load_Cycle_Count increases every time it does that. (Disk
model is IBM-DJSA-232.) Thanks for the explanation.

/abo



From misselt at as.arizona.edu  Sat Oct 27 16:33:32 2007
From: misselt at as.arizona.edu (Karl Misselt)
Date: Sat, 27 Oct 2007 09:33:32 -0700
Subject: Reporting NM 'bug'?
Message-ID: <4723685C.1040905@as.arizona.edu>

Hi - I'm running F8 Test 3, fully updated on a new Inspiron 1420n.
Upgrading NetworkManager to 0.7.0-0.3.svn3020 breaks my wireless;
rolling back to 0.7.0-0.3.svn2914 results in a working wireless.  I don't
see anything about NM breakage in bugzilla, so was going to file a
bug against it.  what additional info would be useful to attach
(beyond lspci, dmesg output)?  
-Karl



From jonathan.underwood at gmail.com  Sat Oct 27 20:05:42 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sat, 27 Oct 2007 21:05:42 +0100
Subject: Reporting NM 'bug'?
In-Reply-To: <4723685C.1040905@as.arizona.edu>
References: <4723685C.1040905@as.arizona.edu>
Message-ID: <645d17210710271305s983d5bam5949988c1e15ece9@mail.gmail.com>

On 27/10/2007, Karl Misselt <misselt at as.arizona.edu> wrote:
> Hi - I'm running F8 Test 3, fully updated on a new Inspiron 1420n.
> Upgrading NetworkManager to 0.7.0-0.3.svn3020 breaks my wireless;
> rolling back to 0.7.0-0.3.svn2914 results in a working wireless.  I don't
> see anything about NM breakage in bugzilla, so was going to file a
> bug against it.  what additional info would be useful to attach
> (beyond lspci, dmesg output)?
> -Karl

You can get some extra info  stopping NetworkManager and starting it as

NetworkManager --nodaemon

and looking at the output.

HTH./



From wwoods at redhat.com  Sat Oct 27 20:25:34 2007
From: wwoods at redhat.com (Will Woods)
Date: Sat, 27 Oct 2007 16:25:34 -0400
Subject: Reporting NM 'bug'?
In-Reply-To: <4723685C.1040905@as.arizona.edu>
References: <4723685C.1040905@as.arizona.edu>
Message-ID: <1193516734.4523.11.camel@localhost.localdomain>


On Sat, 2007-10-27 at 09:33 -0700, Karl Misselt wrote:
> Hi - I'm running F8 Test 3, fully updated on a new Inspiron 1420n.
> Upgrading NetworkManager to 0.7.0-0.3.svn3020 breaks my wireless;
> rolling back to 0.7.0-0.3.svn2914 results in a working wireless.  I don't
> see anything about NM breakage in bugzilla, 

Seriously? We have a whole tracker bug just to keep track of the other
NetworkManager bugs:
https://bugzilla.redhat.com/showdependencytree.cgi?id=336531

> so was going to file a
> bug against it.  what additional info would be useful to attach
> (beyond lspci, dmesg output)?  

First, update to NetworkManager-0.7.0-0.5.svn3030.fc8, which you can get
here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=22556
(it missed last night's rawhide push by a few minutes - will land
tomorrow, but we need testing ASAP)

If the problem persists, useful info to include would be:
- type of wireless network adapter in your machine (lspci is fine)
- type of network you are connecting to (security type, etc)
- NetworkManager log messages from /var/log/messages
and maybe some other stuff that I'm not remembering at the moment.

-w
-------------- 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/20071027/9d26e321/attachment.sig>

From markg85 at gmail.com  Sat Oct 27 21:50:12 2007
From: markg85 at gmail.com (Mark)
Date: Sat, 27 Oct 2007 23:50:12 +0200
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora repo?
Message-ID: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>

Hey,

I've just read a article on eWeek about the new netbeans release (6.0
beta 2) which is now released under GPLv2.

So now that it's GPLv2 i'm hoping that it can be added to the fedora
(7, 8 and up) repo? or do we have to wait till it gets out beta into
RC or final? i would be good for me to have it because i use it a lot
in combination with fedora. The current netbeans releases are
installing fine in Fedora but i just rather install it with the fedora
package manager.

Source: http://www.netbeans.org/cddl-gplv2.html
Source 2: http://blogs.sun.com/barton808/entry/netbeans_now_dual_licensed_cddl

Thanx,
Mark.



From ivazqueznet at gmail.com  Sat Oct 27 22:29:50 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 27 Oct 2007 18:29:50 -0400
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
Message-ID: <1193524190.2269.7.camel@ignacio.lan>

On Sat, 2007-10-27 at 23:50 +0200, Mark wrote:
> So now that it's GPLv2 i'm hoping that it can be added to the fedora
> (7, 8 and up) repo?

http://fedoraproject.org/wiki/PackageMaintainers/Join
http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071027/7834eda1/attachment.sig>

From markg85 at gmail.com  Sat Oct 27 22:34:14 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 28 Oct 2007 00:34:14 +0200
Subject: Firefox backspace button action should be "Previous Page" not "Page
	Up"
Message-ID: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>

Hey,

i was just wondering why Firefox had page up action bound to the
backspace button. and i end up reading this bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=358764

Now the default action for Firefox in fedora is "page up" and i think
nearly every keyboard in the world _has_ a page up key so please
remove that silly default action. A patch for this to give the
backspace the "previous page" (or whatever you want to call it) action
is very simple:

type (in the address bar): about:config
find: browser.backspace_action
The value is likely to be on: 1. Change that value to 0 and backspace
is acting the way it should do.

I don't know where firefox is getting the "logic" to make firefox
default backspace action "previous page" in windows and "page up" in
linux.. just doesn't make sense to me.

And could this be patched in the firefox that is in the fedora repo?
or (if fedora chooses not to patch it to the "previous page" action)
than make it no action at all!! "page up" is just not good.

Bigzilla: https://bugzilla.redhat.com/show_bug.cgi?id=355511

Posted here because i would like to know the users and developer
opinions about this.

Thanx,
Mark.



From markg85 at gmail.com  Sat Oct 27 22:36:27 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 28 Oct 2007 00:36:27 +0200
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <1193524190.2269.7.camel@ignacio.lan>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
Message-ID: <6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>

2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Sat, 2007-10-27 at 23:50 +0200, Mark wrote:
> > So now that it's GPLv2 i'm hoping that it can be added to the fedora
> > (7, 8 and up) repo?
>
> http://fedoraproject.org/wiki/PackageMaintainers/Join
> http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide

Nice reply.
i know those links but i am not in the packaging (yet).
so i pass that.



From ivazqueznet at gmail.com  Sat Oct 27 22:38:34 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 27 Oct 2007 18:38:34 -0400
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
Message-ID: <1193524714.2269.8.camel@ignacio.lan>

On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
> I don't know where firefox is getting the "logic" to make firefox
> default backspace action "previous page" in windows and "page up" in
> linux.. just doesn't make sense to me.

It's "Back" in Internet Explorer... but nowhere else (other than
FF/Win32).

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- 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/20071027/05326d50/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Sat Oct 27 22:45:45 2007
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sun, 28 Oct 2007 00:45:45 +0200
Subject: Should we settle on one SSL implementation?
In-Reply-To: <Pine.LNX.4.64.0710271321140.20500@newtla.xelerance.com> (Paul
	Wouters's message of "Sat, 27 Oct 2007 13:27:14 -0400 (EDT)")
References: <471C94BD.6080801@codewiz.org> <471DFECE.5080704@redhat.com>
	<ffkves$49f$1@ger.gmane.org> <1193148798.8542.285.camel@cutter>
	<20071023101828.28ab1670@redhat.com>
	<1193149404.6746.5.camel@vespa.kabelta.loc>
	<20071023103410.46acd566@redhat.com> <471F6F4C.6040307@codewiz.org>
	<20071024170913.GC12628@devserv.devel.redhat.com>
	<471F8FDB.8070405@codewiz.org>
	<e5f157b0710270916j714f9abbs33ea5ac42a888519@mail.gmail.com>
	<Pine.LNX.4.64.0710271321140.20500@newtla.xelerance.com>
Message-ID: <87myu4i3c6.fsf@kosh.bigo.ensc.de>

Paul Wouters <paul at xelerance.com> writes:

> Also, it is believed that if SHA-1 is compromised, the attack would work
> similarly to SHA-256 et al.

Current SHA-1 attacks reduce "only" the numbers of steps to find a
collision (e.g. 2^60 instead of 2^80).  Similar attacks for SHA-256/512
will probably require 2^90 / 2^180 steps which should be enough for the
next ten years...


Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/aa7d3c80/attachment.sig>

From markg85 at gmail.com  Sat Oct 27 22:47:43 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 28 Oct 2007 00:47:43 +0200
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <1193524714.2269.8.camel@ignacio.lan>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<1193524714.2269.8.camel@ignacio.lan>
Message-ID: <6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>

2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
> > I don't know where firefox is getting the "logic" to make firefox
> > default backspace action "previous page" in windows and "page up" in
> > linux.. just doesn't make sense to me.
>
> It's "Back" in Internet Explorer... but nowhere else (other than
> FF/Win32).

Back (for backspace) is intuitive. page up isn't.
Changing this action (to page up(or actually letting it stay on page
up)) isn't platform consistent and will confuse users when converting
from any os to Fedora.



From s0238762 at sms.ed.ac.uk  Sat Oct 27 23:21:26 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Sun, 28 Oct 2007 00:21:26 +0100
Subject: b43 in Fedora 7
Message-ID: <4723C7F6.8040709@sms.ed.ac.uk>

I've been trying to use the broadcom b43 driver in Fedora 7 with 
2.6.22.9-91.fc7, but I have no luck.

I've extracted the 4.80.53.0 with b43-fwcutter in /lib/firmware 
directory. Loaded the b43 driver and even registered the pci id of my 
card using the following (as suggested in the bcm43xx mailing list)

B43_PCI_ID=`/sbin/lspci -n | awk '$2 ~ "^0280" && $3 ~ "^14e4:43" { 
print $3 }' | sed -e 's/:/ /'`
echo "$B43_PCI_ID" > /sys/bus/pci/drivers/b43-pci-bridge/new_id

(actually the suggestion was for the bcm43xx driver and the path was 
'/sys/bus/pci/drivers/bcm43xx/new_id' )

the only thing I get in dmesg is this
ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKB] -> GSI 7 (level, low) 
-> IRQ 7
ssb: Sonics Silicon Backplane found on PCI device 0000:02:03.0

NetworkManager doesn't report a wireless network, same with iwconfig and 
of course 'ifconfig wlan0 up', reports "wlan0: unknown interface: No 
such device".

I have these aliases in my modprobe
alias pci:v000014E4d0x00004324sv*sd*bc*sc*i* b43
alias wlan0 b43

which corresponds to my cards id.

Why does it have to be so complicated ?

regards,
Ioannis



From packages at amiga-hardware.com  Sat Oct 27 23:25:35 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Sun, 28 Oct 2007 00:25:35 +0100
Subject: More multiarch stuff
Message-ID: <4723C8EF.7020406@amiga-hardware.com>

Hi,

Why doesn't rpm/yum complain when I install both the i386 and x86_64
version of kdetv on F7, when /usr/share/doc/HTML/*/kdetv/index.cache.bz2
differs between the two? Has yum or rpms behaviour in this respect
changed for devel, hence the bug reports about multiarch issues?

-- 
Ian Chapman.



From pertusus at free.fr  Sat Oct 27 23:29:13 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 28 Oct 2007 01:29:13 +0200
Subject: please mail multiarch bugs regularly
Message-ID: <20071027232913.GA31427@free.fr>

Hello,

For those who don't have an easy way to check that arch independent
files don't conflict, could it be possible, please, to send a mail
every 2 weeks or every month with the broken packages/files list like
what was done in bugzilla?

--
Pat



From jonathan.underwood at gmail.com  Sun Oct 28 00:13:49 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 28 Oct 2007 01:13:49 +0100
Subject: Problem with the live ISOs and creating bootable USB installation
	media?
Message-ID: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>

Hi,

This evening I downloaded rawhide-20071019-x86_64.iso as found on the
Fedora torrents. I then tried to create a bootable USB stick using a
fully updated F-7 box:

# livecd-iso-to-disk rawhide-20071019-x86_64.iso /dev/sdb1
Already set up as live image.  Deleting old in fifteen seconds...
Copying live image to USB stick
cp: cannot stat `/media/cdtmp.s17912/squashfs.img': No such file or directory
Cleaning up to exit...


For a sanity check I retried using an F-7 livecd iso:

# livecd-iso-to-disk Fedora_ISO/Fedora-7-Live-x86_64.iso /dev/sdb1
Already set up as live image.  Deleting old in fifteen seconds...
Copying live image to USB stick
Updating boot config file
Installing boot loader
USB stick set up as live image!


So that works. It looks like  something changed with how the ISOs are
structured such that the livecd-tools under F-7 are broken with the
F-8 isos. This isn't good, as I think I'm describing what will be
quite a common use case when F-8 is released (i.e. people wishing to
create bootable F-8 sticks under F-7 in order to upgrade).

jonathan



From jonathan.underwood at gmail.com  Sun Oct 28 00:19:22 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 28 Oct 2007 01:19:22 +0100
Subject: Problem with the live ISOs and creating bootable USB
	installation media?
In-Reply-To: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>
References: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>
Message-ID: <645d17210710271719w2b5a700fn5603faa7982f2727@mail.gmail.com>

On 28/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> So that works. It looks like  something changed with how the ISOs are
> structured such that the livecd-tools under F-7 are broken with the
> F-8 isos. This isn't good, as I think I'm describing what will be
> quite a common use case when F-8 is released (i.e. people wishing to
> create bootable F-8 sticks under F-7 in order to upgrade).

To answer my own question, the reason is that in the ISO as composed
from current Rawhide squashfs.img is now located in the LiveOS
subdirectory rather than in the root directory. I'll have a look at
pathing the livecd-tools script.



From jonathan.underwood at gmail.com  Sun Oct 28 00:44:40 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 28 Oct 2007 01:44:40 +0100
Subject: Problem with the live ISOs and creating bootable USB
	installation media?
In-Reply-To: <645d17210710271719w2b5a700fn5603faa7982f2727@mail.gmail.com>
References: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>
	<645d17210710271719w2b5a700fn5603faa7982f2727@mail.gmail.com>
Message-ID: <645d17210710271744g755b296av792a5620d27aaa2f@mail.gmail.com>

On 28/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> On 28/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > So that works. It looks like  something changed with how the ISOs are
> > structured such that the livecd-tools under F-7 are broken with the
> > F-8 isos. This isn't good, as I think I'm describing what will be
> > quite a common use case when F-8 is released (i.e. people wishing to
> > create bootable F-8 sticks under F-7 in order to upgrade).
>
> To answer my own question, the reason is that in the ISO as composed
> from current Rawhide squashfs.img is now located in the LiveOS
> subdirectory rather than in the root directory. I'll have a look at
> pathing the livecd-tools script.
>

Sorry to continue the monologue, but just to say I've added a patch to
Bug #355541 to fix this.



From smooge at gmail.com  Sun Oct 28 01:29:06 2007
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 27 Oct 2007 19:29:06 -0600
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
Message-ID: <80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>

On 10/27/07, Mark <markg85 at gmail.com> wrote:
> 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > On Sat, 2007-10-27 at 23:50 +0200, Mark wrote:
> > > So now that it's GPLv2 i'm hoping that it can be added to the fedora
> > > (7, 8 and up) repo?
> >
> > http://fedoraproject.org/wiki/PackageMaintainers/Join
> > http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide
>
> Nice reply.
> i know those links but i am not in the packaging (yet).
> so i pass that.
>

Packaging is not a free thing. It takes time energy and someone who is
going to deal with it. Most people who have packages are usually
swamped as it is... so if you see something you would like to get into
Fedora.. first check to see if someone is already packaging it, and
then volunteer to do it yourself (or help someone who can). Otherwise
its not going to happen.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From misselt at as.arizona.edu  Sun Oct 28 02:37:12 2007
From: misselt at as.arizona.edu (Karl Misselt)
Date: Sat, 27 Oct 2007 19:37:12 -0700
Subject: Reporting NM 'bug'?
In-Reply-To: <1193516734.4523.11.camel@localhost.localdomain>
References: <4723685C.1040905@as.arizona.edu>
	<1193516734.4523.11.camel@localhost.localdomain>
Message-ID: <4723F5D8.200@as.arizona.edu>

Will Woods wrote:
> On Sat, 2007-10-27 at 09:33 -0700, Karl Misselt wrote:
>   
>> Hi - I'm running F8 Test 3, fully updated on a new Inspiron 1420n.
>> Upgrading NetworkManager to 0.7.0-0.3.svn3020 breaks my wireless;
>> rolling back to 0.7.0-0.3.svn2914 results in a working wireless.  I don't
>> see anything about NM breakage in bugzilla, 
>>     
>
> Seriously? We have a whole tracker bug just to keep track of the other
> NetworkManager bugs:
> https://bugzilla.redhat.com/showdependencytree.cgi?id=336531
>   
Sorry, should have been more specific - nothing about breakage related to
an update to 3020 or, from a short perusal, nothing that looked like the 
failure
I was seeing.
>   
>> so was going to file a
>> bug against it.  what additional info would be useful to attach
>> (beyond lspci, dmesg output)?  
>>     
>
> First, update to NetworkManager-0.7.0-0.5.svn3030.fc8, which you can get
> here:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22556
> (it missed last night's rawhide push by a few minutes - will land
> tomorrow, but we need testing ASAP)
>
> If the problem persists, useful info to include would be:
> - type of wireless network adapter in your machine (lspci is fine)
> - type of network you are connecting to (security type, etc)
> - NetworkManager log messages from /var/log/messages
> and maybe some other stuff that I'm not remembering at the moment.
>
> -w
>   
Thanks - I'll update asap (traveling tomorrow, but maybe in the evening will
have a chance) and will see what happens. 
-K



From kagesenshi.87 at gmail.com  Sun Oct 28 03:13:18 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Sun, 28 Oct 2007 11:13:18 +0800
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <200710260204.52573.ml@deadbabylon.de>
References: <200710260000.24041.ml@deadbabylon.de>
	<200710260028.51648.ml@deadbabylon.de> <ffraj1$vve$1@ger.gmane.org>
	<200710260204.52573.ml@deadbabylon.de>
Message-ID: <c44298520710272013o7c6ce8d5lc03b93000413e7be@mail.gmail.com>

On 10/26/07, Sebastian Vahl <ml at deadbabylon.de> wrote:
> Am Fr 26.Oktober 2007 schrieb Neal Becker:
> > Sebastian Vahl wrote:
> > > Am Fr 26.Oktober 2007 schrieb Kelly Miller:
> > >> Sebastian Vahl wrote:
> > >> > Hi.
> > >> >
> > >> > Since beryl is sadly being removed from the repository, KDE users
> > >> > don't have the ability to easily switch from kwin to compiz and back
> > >> > again. The KDE-SIG was asked to write such a tool but after the
> > >> > confirmation [1] that compiz wouldn't obsolete beryl it hasn't become
> > >> > primary attention.
> > >>
> > >> Um, when I tested out the new version of compiz on openSUSE, I noticed
> > >> that compiz itself seems to have a tool for switching between window
> > >> managers.  It seemed to work fine for me in KDE.
> > >
> > > Do you remember the name of that tool? AFAIK suse also includes
> > > compiz-manager, eg see: http://en.opensuse.org/Compiz-Fusion
> > >
> > > Maybe this is fusion-icon? But that has no official release, yet.
> > >
> > > Sebastian
> >
> > Also, how are you configuring compiz?  I grabbed the ccsm (which is
> > currently under review).  It looks nice, except it doesn't seem to do
> > anything.  You can choose lots of options, but I don't see anything like
> > an 'apply' button.

I'm sorry, I forgot that the default compiz uses glib gconf instead
of ccp .. to make use  of ccsm you can either run compiz by "compiz
--replace ccp" .. or install compizconfig-backend-gconf and set  ccsm
to use the Gconf backend in the preferences ..

>
> This is done by compiz-manager. ATM it is: compiz --replace glib gconf
> Until compizconfig-backend-kconfig gets into Fedora. But I'm open for
> suggestions.

compizconfig-backend-kconfig just passed review,   I havent request a
CVS for it yet

>
> ccsm has no ability to _start_ compiz, just to configure it's options.
>
> Sebastian
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>


-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From sandeen at redhat.com  Sun Oct 28 03:14:28 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 27 Oct 2007 22:14:28 -0500
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
 repo?
In-Reply-To: <80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>	<1193524190.2269.7.camel@ignacio.lan>	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
Message-ID: <4723FE94.7030602@redhat.com>

Stephen John Smoogen wrote:
> On 10/27/07, Mark <markg85 at gmail.com> wrote:
>> 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
>>> On Sat, 2007-10-27 at 23:50 +0200, Mark wrote:
>>>> So now that it's GPLv2 i'm hoping that it can be added to the fedora
>>>> (7, 8 and up) repo?
>>> http://fedoraproject.org/wiki/PackageMaintainers/Join
>>> http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide
>> Nice reply.
>> i know those links but i am not in the packaging (yet).
>> so i pass that.
>>
> 
> Packaging is not a free thing. It takes time energy and someone who is
> going to deal with it. Most people who have packages are usually
> swamped as it is... so if you see something you would like to get into
> Fedora.. first check to see if someone is already packaging it, and
> then volunteer to do it yourself (or help someone who can). Otherwise
> its not going to happen.

Plus, there's a little fame if not fortune, and usually a few people
willing to help.

I'd be willing to be that if you can *use* netbeans, you can certainly
learn to *package* netbeans, and as an avid user, you're in excellent
position to make sure the package actually works.  :)

-Eric



From bbbush.yuan at gmail.com  Sun Oct 28 05:21:58 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Sun, 28 Oct 2007 13:21:58 +0800
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <76e72f800710272221n1f8a8850ice0787493eb149fa@mail.gmail.com>

I installed -37 kernel as well as -0.5.svn3030 NetworkManager. The overall
status is good. nm-applet no longer crashes. NM behaves well with keyrings
(no matter if unlock automatically or not). Much better than the previous
one.

iwl3945 has some little problem that when resume from suspend, I have to
rmmod & modprobe to get wireless back. I don't know how to add quirks to
handle this.

My smolt profile is e26cfcbf-a150-4466-a65f-d9c99f5d048e



I have my own problem that scim cannot work well, and all programs become
very slow, unresponsive.



-- 
bbbush ^_^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/54b307bb/attachment.htm>

From dcbw at redhat.com  Sun Oct 28 05:26:56 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 28 Oct 2007 01:26:56 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <76e72f800710272221n1f8a8850ice0787493eb149fa@mail.gmail.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
	<76e72f800710272221n1f8a8850ice0787493eb149fa@mail.gmail.com>
Message-ID: <1193549216.8150.4.camel@localhost.localdomain>

On Sun, 2007-10-28 at 13:21 +0800, Yuan Yijun wrote:
> 
> I installed -37 kernel as well as -0.5.svn3030 NetworkManager. The
> overall status is good. nm-applet no longer crashes. NM behaves well
> with keyrings (no matter if unlock automatically or not). Much better
> than the previous one. 
> 
> iwl3945 has some little problem that when resume from suspend, I have
> to rmmod & modprobe to get wireless back. I don't know how to add
> quirks to handle this.

There's some pm-utils stuff that you might look into.  Obviously the
driver _needs_ to be fixed, but for now...

Add a file to /etc/pm/config.d that contains:

SUSPEND_MODULES="iwl3945"

and see where that gets you.

Dan

> My smolt profile is e26cfcbf-a150-4466-a65f-d9c99f5d048e 
> 
> 
> 
> I have my own problem that scim cannot work well, and all programs
> become very slow, unresponsive.
> 
> 
> 
> -- 
> bbbush ^_^ 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From mschwendt.tmp0701.nospam at arcor.de  Sun Oct 28 08:35:30 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 28 Oct 2007 09:35:30 +0100
Subject: More multiarch stuff
In-Reply-To: <4723C8EF.7020406@amiga-hardware.com>
References: <4723C8EF.7020406@amiga-hardware.com>
Message-ID: <20071028093530.96cf1bca.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 28 Oct 2007 00:25:35 +0100, Ian Chapman wrote:

> Why doesn't rpm/yum complain when I install both the i386 and x86_64
> version of kdetv on F7, when /usr/share/doc/HTML/*/kdetv/index.cache.bz2
> differs between the two? Has yum or rpms behaviour in this respect
> changed for devel, hence the bug reports about multiarch issues?

How do you install them? At once? Or after eachother? AFAIK, meanwhile
it has been noticed that a conflict is reported only if you install
them one by one. [Previously, there have been rumours that RPM would
do something special with %_defaultdocdir.]



From rc040203 at freenet.de  Sun Oct 28 09:00:59 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 28 Oct 2007 10:00:59 +0100
Subject: rpms/flashrom/F-7 .cvsignore, 1.3, 1.4 flashrom.spec, 1.2, 1.3
	sources, 1.3, 1.4
In-Reply-To: <200710280653.l9S6rMxj026409@cvs-int.fedora.redhat.com>
References: <200710280653.l9S6rMxj026409@cvs-int.fedora.redhat.com>
Message-ID: <1193562059.9878.143.camel@mccallum.corsepiu.local>

On Sun, 2007-10-28 at 02:53 -0400, Peter Lemenkov wrote:
> Author: peter
> 
> Update of /cvs/extras/rpms/flashrom/F-7
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26258/F-7


> Index: flashrom.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/flashrom/F-7/flashrom.spec,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- flashrom.spec	3 Oct 2007 13:00:48 -0000	1.2
> +++ flashrom.spec	28 Oct 2007 06:52:48 -0000	1.3
[...]
> @@ -23,6 +23,7 @@
>  %prep
>  %setup -q -n %{name}
>  %patch0 -b .Makefile_cleanup
> +gzip %{name}.8
>  
>  %build
>  # currently disabling DiscOnChip due to instability
> @@ -30,9 +31,9 @@
[...]
> +install -D -p -m644 %{name}.8.gz $RPM_BUILD_ROOT%{_mandir}/man8/%{name}.8.gz

Why these steps? There shouldn't be any need to manually compress a
man-page. Simply installing the uncompressed man-pages should be
sufficient. Rpmbuild compresses them automatically, afterwards.

Ralf




From nicolas.mailhot at laposte.net  Sun Oct 28 09:46:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 28 Oct 2007 10:46:07 +0100
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
Message-ID: <1193564767.25751.7.camel@rousalka.dyndns.org>


Le samedi 27 octobre 2007 ? 23:50 +0200, Mark a ?crit :

> So now that it's GPLv2 i'm hoping that it can be added to the fedora
> (7, 8 and up) repo? 

The problem with netbeans has never been the license but the whole
difficulty of packaging it. A rich ide like netbeans has dependencies on
pretty much every bit of the java stack, and sorting them is hard.
There's been several half-hearted attempts to package it @jpp (by sun
and others),

http://www.jpackage.org/cgi-bin/cvsweb.cgi/rpms/free/netbeans/?cvsroot=jpackage;hideattic=0

but so far no one has been persistent enough to keep netbeans packaged
by fixing the spec every release.

The root problem being of course SUN only acknowledged it needed shared
java components last year (and they're targeted for java 7), so all the
java dependency tracking must be done by hand in rpm specs.

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

From caolanm at redhat.com  Sun Oct 28 10:40:00 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Sun, 28 Oct 2007 10:40:00 +0000
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<1193524714.2269.8.camel@ignacio.lan>
	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
Message-ID: <1193568000.31627.6.camel@Jehannum>


On Sun, 2007-10-28 at 00:47 +0200, Mark wrote:
> 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
> > > I don't know where firefox is getting the "logic" to make firefox
> > > default backspace action "previous page" in windows and "page up" in
> > > linux.. just doesn't make sense to me.
> >
> > It's "Back" in Internet Explorer... but nowhere else (other than
> > FF/Win32).
> 
> Back (for backspace) is intuitive. 

Back for backspace is the stupidest thing ever, backspace should be
restricted to delete text. All that happens is that you just forget to
click into the form, hit backspace thinking you're about to delete a
letter and loose the entire page, horrific. Bind it to nothing at all I
say.

C.



From giallu at gmail.com  Sun Oct 28 10:13:15 2007
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 28 Oct 2007 12:13:15 +0200
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <1193568000.31627.6.camel@Jehannum>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<1193524714.2269.8.camel@ignacio.lan>
	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
	<1193568000.31627.6.camel@Jehannum>
Message-ID: <d5ad21470710280313p1ff4ca06s3ff222f20369a794@mail.gmail.com>

On 10/28/07, Caolan McNamara <caolanm at redhat.com> wrote:
>
> On Sun, 2007-10-28 at 00:47 +0200, Mark wrote:
> > 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > > On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
> > > > I don't know where firefox is getting the "logic" to make firefox
> > > > default backspace action "previous page" in windows and "page up" in
> > > > linux.. just doesn't make sense to me.
> > >
> > > It's "Back" in Internet Explorer... but nowhere else (other than
> > > FF/Win32).
> >
> > Back (for backspace) is intuitive.
>
> Back for backspace is the stupidest thing ever, backspace should be
> restricted to delete text. All that happens is that you just forget to
> click into the form, hit backspace thinking you're about to delete a
> letter and loose the entire page, horrific. Bind it to nothing at all I
> say.

+1

That is even worse when it happens using the touchpad, where the
bottom area act as the "back" button.



From lkundrak at redhat.com  Sun Oct 28 10:21:29 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 28 Oct 2007 11:21:29 +0100
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <1193568000.31627.6.camel@Jehannum>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<1193524714.2269.8.camel@ignacio.lan>
	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
	<1193568000.31627.6.camel@Jehannum>
Message-ID: <1193566889.7744.5.camel@localhost.localdomain>


On Sun, 2007-10-28 at 10:40 +0000, Caolan McNamara wrote:
> On Sun, 2007-10-28 at 00:47 +0200, Mark wrote:
> > 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > > On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
> > > > I don't know where firefox is getting the "logic" to make firefox
> > > > default backspace action "previous page" in windows and "page up" in
> > > > linux.. just doesn't make sense to me.
> > >
> > > It's "Back" in Internet Explorer... but nowhere else (other than
> > > FF/Win32).
> > 
> > Back (for backspace) is intuitive. 
> 
> Back for backspace is the stupidest thing ever, backspace should be
> restricted to delete text. All that happens is that you just forget to
> click into the form, hit backspace thinking you're about to delete a
> letter and loose the entire page, horrific. Bind it to nothing at all I
> say.

+1
Exactly!

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From andy at warmcat.com  Sun Oct 28 11:14:41 2007
From: andy at warmcat.com (Andy Green)
Date: Sun, 28 Oct 2007 11:14:41 +0000
Subject: Firefox backspace button action should be "Previous Page" not
 "Page Up"
In-Reply-To: <1193568000.31627.6.camel@Jehannum>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>	<1193524714.2269.8.camel@ignacio.lan>	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
	<1193568000.31627.6.camel@Jehannum>
Message-ID: <47246F21.9040701@warmcat.com>

Somebody in the thread at some point said:
> On Sun, 2007-10-28 at 00:47 +0200, Mark wrote:
>> 2007/10/28, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
>>> On Sun, 2007-10-28 at 00:34 +0200, Mark wrote:
>>>> I don't know where firefox is getting the "logic" to make firefox
>>>> default backspace action "previous page" in windows and "page up" in
>>>> linux.. just doesn't make sense to me.
>>> It's "Back" in Internet Explorer... but nowhere else (other than
>>> FF/Win32).
>> Back (for backspace) is intuitive. 
> 
> Back for backspace is the stupidest thing ever, backspace should be
> restricted to delete text. All that happens is that you just forget to
> click into the form, hit backspace thinking you're about to delete a
> letter and loose the entire page, horrific. Bind it to nothing at all I
> say.

Makes complete sense, but this is Firefox TM, meddling with it isn't so
simple unless you want to make an IceWeasel type non-TM variant.

-Andy



From dgboles at gmail.com  Sun Oct 28 11:25:29 2007
From: dgboles at gmail.com (David Boles)
Date: Sun, 28 Oct 2007 07:25:29 -0400
Subject: Firefox backspace button action should be "Previous Page" not
 "Page Up"
In-Reply-To: <47246F21.9040701@warmcat.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>	<1193524714.2269.8.camel@ignacio.lan>	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>	<1193568000.31627.6.camel@Jehannum>
	<47246F21.9040701@warmcat.com>
Message-ID: <472471A9.1060908@gmail.com>

on 10/28/2007 7:14 AM, Andy Green wrote:
> Somebody in the thread at some point said:
>> On Sun, 2007-10-28 at 00:47 +0200, Mark wrote:
>> Back for backspace is the stupidest thing ever, backspace should be
>> restricted to delete text. All that happens is that you just forget to
>> click into the form, hit backspace thinking you're about to delete a
>> letter and loose the entire page, horrific. Bind it to nothing at all I
>> say.
> 
> Makes complete sense, but this is Firefox TM, meddling with it isn't so
> simple unless you want to make an IceWeasel type non-TM variant.



About:config entries

http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries#Browser..2A

-- 

  David


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/3fbb1103/attachment.sig>

From rodd at clarkson.id.au  Sun Oct 28 11:29:28 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sun, 28 Oct 2007 22:29:28 +1100
Subject: rawhide report: 20071026 changes
In-Reply-To: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>
References: <200710270427.l9R4RK27031757@porkchop.devel.redhat.com>
Message-ID: <1193570968.25510.5.camel@localhost.localdomain>


On Sat, 2007-10-27 at 00:27 -0400, Build System wrote:

> gnome-keyring-2.20.1-3.fc8
> --------------------------
> * Thu Oct 25 2007 Christopher Aillon <caillon at redhat.com> - 2.20.1-3
> - Rebuild
> 
> * Mon Oct 15 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-2
> - Disable the auto-unlock question for now (#312531)
> 
> * Mon Oct 15 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-1
> - Update to 2.20.1
> - Drop obsolete patches
> - Add bug ref for selinux patch


I'm seeing this sore of thing on a lot of packages in this update.


[rodd at localhost ~]$ sudo yum update --exclude=kernel
--exclude=kmod-nvidia gnome-keyring
Loading "refresh-updatesd" plugin
Loading "skip-broken" plugin
Excluding Packages in global exclude list
Finished
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: gnome-keyring = 2.20-6.fc8 for package:
gnome-keyring-pam
---> Package gnome-keyring.i386 0:2.20.1-3.fc8 set to be updated
--> Running transaction check
---> Package gnome-keyring-pam.i386 0:2.20.1-3.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository
Size 
=============================================================================
Updating:
 gnome-keyring           i386       2.20.1-3.fc8     development
209 k
Updating for dependencies:
 gnome-keyring-pam       i386       2.20.1-3.fc8     development
21 k

Transaction Summary
=============================================================================
Install      0 Package(s)         
Update       2 Package(s)         
Remove       0 Package(s)         

Total download size: 230 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): gnome-keyring-2.20 100% |=========================| 210 kB
00:04     
http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/gnome-keyring-2.20.1-3.fc8.i386.rpm: [Errno -1] Package does not match intended download
Trying other mirror.
(2/2): gnome-keyring-pam- 100% |=========================|  21 kB
00:00     
http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/gnome-keyring-pam-2.20.1-3.fc8.i386.rpm: [Errno -1] Package does not match intended download
Trying other mirror.


Error Downloading Packages:
  gnome-keyring - 2.20.1-3.fc8.i386: failure:
Packages/gnome-keyring-2.20.1-3.fc8.i386.rpm from development: [Errno
256] No more mirrors to try.
  gnome-keyring-pam - 2.20.1-3.fc8.i386: failure:
Packages/gnome-keyring-pam-2.20.1-3.fc8.i386.rpm from development:
[Errno 256] No more mirrors to try.

[rodd at localhost ~]$ 





-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jonathan.underwood at gmail.com  Sun Oct 28 11:59:58 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 28 Oct 2007 11:59:58 +0000
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <1193568000.31627.6.camel@Jehannum>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<1193524714.2269.8.camel@ignacio.lan>
	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>
	<1193568000.31627.6.camel@Jehannum>
Message-ID: <645d17210710280459u3f3fe6eet69777718cd48d3aa@mail.gmail.com>

On 28/10/2007, Caolan McNamara <caolanm at redhat.com> wrote:
> Back for backspace is the stupidest thing ever, backspace should be
> restricted to delete text. All that happens is that you just forget to
> click into the form, hit backspace thinking you're about to delete a
> letter and loose the entire page, horrific. Bind it to nothing at all I
> say.

Fully agreed.



From dwmw2 at infradead.org  Sun Oct 28 12:03:43 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 28 Oct 2007 08:03:43 -0400
Subject: b43 in Fedora 7
In-Reply-To: <4723C7F6.8040709@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>
Message-ID: <1193573023.2915.42.camel@shinybook.infradead.org>

On Sun, 2007-10-28 at 00:21 +0100, Ioannis Nousias wrote:
> I've been trying to use the broadcom b43 driver in Fedora 7 with 
> 2.6.22.9-91.fc7, but I have no luck.

 cat /sys/bus/ssb/devices/*/uevent

-- 
dwmw2



From dgboles at gmail.com  Sun Oct 28 12:16:54 2007
From: dgboles at gmail.com (David Boles)
Date: Sun, 28 Oct 2007 08:16:54 -0400
Subject: Firefox backspace button action should be "Previous Page" not
 "Page Up"
In-Reply-To: <645d17210710280459u3f3fe6eet69777718cd48d3aa@mail.gmail.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>	<1193524714.2269.8.camel@ignacio.lan>	<6e24a8e80710271547t3efdcd32sefb078a07dbeb79b@mail.gmail.com>	<1193568000.31627.6.camel@Jehannum>
	<645d17210710280459u3f3fe6eet69777718cd48d3aa@mail.gmail.com>
Message-ID: <47247DB6.6090408@gmail.com>

on 10/28/2007 7:59 AM, Jonathan Underwood wrote:
> On 28/10/2007, Caolan McNamara <caolanm at redhat.com> wrote:
>> Back for backspace is the stupidest thing ever, backspace should be
>> restricted to delete text. All that happens is that you just forget to
>> click into the form, hit backspace thinking you're about to delete a
>> letter and loose the entire page, horrific. Bind it to nothing at all I
>> say.
> 
> Fully agreed.


Read my post to Andy Green in this thread.


-- 

  David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/8cb2ce03/attachment.sig>

From markg85 at gmail.com  Sun Oct 28 12:21:29 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 28 Oct 2007 13:21:29 +0100
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <4723FE94.7030602@redhat.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
Message-ID: <6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>

> > Packaging is not a free thing. It takes time energy and someone who is
> > going to deal with it. Most people who have packages are usually
> > swamped as it is... so if you see something you would like to get into
> > Fedora.. first check to see if someone is already packaging it, and
> > then volunteer to do it yourself (or help someone who can). Otherwise
> > its not going to happen.
>
> Plus, there's a little fame if not fortune, and usually a few people
> willing to help.
>
> I'd be willing to be that if you can *use* netbeans, you can certainly
> learn to *package* netbeans, and as an avid user, you're in excellent
> position to make sure the package actually works.  :)
>
> -Eric

I can't make RPM packages from scratch so therefore i think it's best
to leave that to a professional RPM packager. But if noone else is
willing to do it than i would like to give it a try.. and i probably
need a lot of help along the way.

So is anyone up to this? or is there someone that is willing to help
me with this? i have nearly no rpm packaging experience. (i edited
specs before and compiled the package but i didn't made a spec from
scratch)



From s0238762 at sms.ed.ac.uk  Sun Oct 28 13:05:29 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Sun, 28 Oct 2007 13:05:29 +0000
Subject: b43 in Fedora 7
In-Reply-To: <1193573023.2915.42.camel@shinybook.infradead.org>
References: <4723C7F6.8040709@sms.ed.ac.uk>
	<1193573023.2915.42.camel@shinybook.infradead.org>
Message-ID: <47248919.6000505@sms.ed.ac.uk>

David Woodhouse wrote:
> On Sun, 2007-10-28 at 00:21 +0100, Ioannis Nousias wrote:
>   
>> I've been trying to use the broadcom b43 driver in Fedora 7 with 
>> 2.6.22.9-91.fc7, but I have no luck.
>>     
>
>  cat /sys/bus/ssb/devices/*/uevent
>
>   
$ cat /sys/bus/ssb/devices/*/uevent
PHYSDEVBUS=ssb
MODALIAS=ssb:v4243id0812rev04
PHYSDEVBUS=ssb
MODALIAS=ssb:v4243id0807rev01
PHYSDEVBUS=ssb
MODALIAS=ssb:v4243id0812rev04



From dtimms at iinet.net.au  Sun Oct 28 13:07:01 2007
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 29 Oct 2007 00:07:01 +1100
Subject: Fedorability of dvbcut ?
Message-ID: <47248975.7050901@iinet.net.au>

I'm keen to repackage dvbcut for Fedora.
http://dvbcut.sourceforge.net/installation.html
The application can be used to trim up a mpeg2 transport stream for 
example recorded from a DVB tuner card, and output in mpeg2 program 
stream format.

As packaged in packman, it warns:
- qt3 is needed by dvbcut-0.5.4-0.pm.0.i586
- libffmpeg0 is needed by dvbcut-0.5.4-0.pm.0.i586
It can also use mplayer, and finds this through name within your path, 
ie it is not actually required for the program to run.
With ffmpeg and mplayer installed, a rpm -Uvh --nodeps allows it to run 
fine.

It's main function is the conversion from transport stream to program 
stream of given selections, however, it does recode frames at the start 
and end of each clip.

So given the linking {I think} of ffmpeg, and the need for easiest use 
of having mplayer installed, am I correct in assuming this will be no go 
in FedoraPC ?

And if that's the case, how does the included kernel module for 
controlling / receiving mpeg2 transport streams from my DVB card fit 
with Fedora ?

DaveT.



From dwmw2 at infradead.org  Sun Oct 28 13:17:38 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 28 Oct 2007 09:17:38 -0400
Subject: b43 in Fedora 7
In-Reply-To: <47248919.6000505@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>
	<1193573023.2915.42.camel@shinybook.infradead.org>
	<47248919.6000505@sms.ed.ac.uk>
Message-ID: <1193577458.2915.45.camel@shinybook.infradead.org>

On Sun, 2007-10-28 at 13:05 +0000, Ioannis Nousias wrote:
> MODALIAS=ssb:v4243id0812rev04

That would be b43legacy. Did the b43legacy driver not get loaded? If you
load it, what do you see in dmesg?

You'll need to extract firmware from a v3 driver with b43-fwcutter.

-- 
dwmw2



From s0238762 at sms.ed.ac.uk  Sun Oct 28 13:39:43 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Sun, 28 Oct 2007 13:39:43 +0000
Subject: b43 in Fedora 7
In-Reply-To: <1193577458.2915.45.camel@shinybook.infradead.org>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>
	<1193577458.2915.45.camel@shinybook.infradead.org>
Message-ID: <4724911F.4050308@sms.ed.ac.uk>

David Woodhouse wrote:
> On Sun, 2007-10-28 at 13:05 +0000, Ioannis Nousias wrote:
>   
>> MODALIAS=ssb:v4243id0812rev04
>>     
>
> That would be b43legacy. Did the b43legacy driver not get loaded? If you
> load it, what do you see in dmesg?
>
> You'll need to extract firmware from a v3 driver with b43-fwcutter.
>
>   
I see. I thought b43legacy was for BCM4306/2 cards. I have a BCM4309(rev02).

I've extracted the 3.130.20 firmware now, but I don't have a b43legacy 
kernel module. Isn't it included in the fedora kernel package? I 
reloaded the 'b43' one, but I get the same behaviour.

thanks





From mike at miketc.com  Sun Oct 28 13:55:13 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 28 Oct 2007 08:55:13 -0500
Subject: On Board video vs AGP/PCI
Message-ID: <1193579713.14059.5.camel@scrappy.miketc.com>

I have an ATI 1300 card via agp, and am thinking of using my on board
video.  But when I hook up the monitor to it, it's like it doesn't
exist, even when it first boots and you just see BIOS boot msgs.  I even
double checked my BIOS, and the only thing I can find is to have display
start with PCI or AGP.  Nothing about on board or anything.  Is there a
way to get it detected initially, without removing the card itself?
Would even that do it?  Now I feel stupid, but I couldn't find the
hardware menu in my menu to at least see what video driver it might
would use or which type it is on my motherboard.  It's an MSI 7060
board, which is a SiS make I think?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Sun Oct 28 13:58:58 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 28 Oct 2007 08:58:58 -0500
Subject: On Board video vs AGP/PCI
In-Reply-To: <1193579713.14059.5.camel@scrappy.miketc.com>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
Message-ID: <1193579938.14059.8.camel@scrappy.miketc.com>

On Sun, 2007-10-28 at 08:55 -0500, Mike Chambers wrote:
> I have an ATI 1300 card via agp, and am thinking of using my on board
> video.  But when I hook up the monitor to it, it's like it doesn't
> exist, even when it first boots and you just see BIOS boot msgs.  I even
> double checked my BIOS, and the only thing I can find is to have display
> start with PCI or AGP.  Nothing about on board or anything.  Is there a
> way to get it detected initially, without removing the card itself?
> Would even that do it?  Now I feel stupid, but I couldn't find the
> hardware menu in my menu to at least see what video driver it might
> would use or which type it is on my motherboard.  It's an MSI 7060
> board, which is a SiS make I think?

Here is an output of lspci that from what I can tell, doesn't even show
the onboard video?

[root at scrappy sbin]# lspci -vv

00:00.0 Host bridge: Silicon Integrated Systems [SiS]
661FX/M661FX/M661MX Host (rev 11)
        Subsystem: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX
Host
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 32
        Region 0: Memory at e0000000 (32-bit, non-prefetchable)
[size=128M]
        Capabilities: [c0] AGP version 3.5
                Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=<none>

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port
(virtual PCI-to-PCI bridge) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: c0000000-dfffffff
        Prefetchable memory behind bridge: 50000000-500fffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL
Media IO] (rev 36)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev
01) (prog-if 80 [Master])
        Subsystem: Micro-Star International Co., Ltd. Unknown device
7060
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 128
        Interrupt: pin ? routed to IRQ 20
        Region 0: I/O ports at 01f0 [size=8]
        Region 1: I/O ports at 03f4 [size=1]
        Region 2: I/O ports at 0170 [size=8]
        Region 3: I/O ports at 0374 [size=1]
        Region 4: I/O ports at 4000 [size=16]
        Capabilities: [58] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
AC'97 Sound Controller (rev a0)
        Subsystem: Micro-Star International Co., Ltd. Unknown device
b010
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (13000ns min, 2750ns max)
        Interrupt: pin C routed to IRQ 22
        Region 0: I/O ports at e000 [size=256]
        Region 1: I/O ports at e100 [size=128]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f) (prog-if 10 [OHCI])
        Subsystem: Micro-Star International Co., Ltd. Unknown device
7060
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at e8033000 (32-bit, non-prefetchable)
[size=4K]

00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f) (prog-if 10 [OHCI])
        Subsystem: Micro-Star International Co., Ltd. Unknown device
7060
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 32 bytes
        Interrupt: pin B routed to IRQ 18
        Region 0: Memory at e8034000 (32-bit, non-prefetchable)
[size=4K]

00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f) (prog-if 10 [OHCI])
        Subsystem: Micro-Star International Co., Ltd. Unknown device
7060
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max), Cache Line Size: 32 bytes
        Interrupt: pin C routed to IRQ 19
        Region 0: Memory at e8030000 (32-bit, non-prefetchable)
[size=4K]

00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0
Controller (prog-if 20 [EHCI])
        Subsystem: Micro-Star International Co., Ltd. Unknown device
5332
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (20000ns max)
        Interrupt: pin D routed to IRQ 16
        Region 0: Memory at e8031000 (32-bit, non-prefetchable)
[size=4K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0
+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI
Fast Ethernet (rev 90)
        Subsystem: Micro-Star International Co., Ltd. Unknown device
7060
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (13000ns min, 2750ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at e200 [size=256]
        Region 1: Memory at e8032000 (32-bit, non-prefetchable)
[size=4K]
        [virtual] Expansion ROM at 50100000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1
+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 Multimedia audio controller: Creative Labs SB Audigy LS
        Subsystem: Creative Labs Unknown device 100a
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 3
        Region 0: I/O ports at e300 [size=32]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:08.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
        Subsystem: Conexant Dynalink 56PMi
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e8020000 (32-bit, non-prefetchable)
[size=64K]
        Region 1: I/O ports at e400 [size=8]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon
X1300/X1550 Series] (prog-if 00 [VGA])
        Subsystem: VISIONTEK Unknown device 1914
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at d0030000 (64-bit, non-prefetchable)
[size=64K]
        Region 4: I/O ports at d000 [size=256]
        [virtual] Expansion ROM at 50000000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] AGP version 3.0
                Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW-
Rate=<none>
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000

01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300
Pro] (Secondary)
        Subsystem: VISIONTEK Unknown device 1915
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Region 0: Memory at d0020000 (64-bit, non-prefetchable)
[disabled] [size=64K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From valent.turkovic at gmail.com  Sun Oct 28 14:01:10 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 28 Oct 2007 15:01:10 +0100
Subject: problems updating and installing?
Message-ID: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>

Hi,

I have problems installing and updating fedora devel, it that normal
behaviour due to some infrastructure work or is it "bug"?

I can't update nor install any package with yum.

# yum install Miro -y
Loading "refresh-updatesd" plugin
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package Miro.i386 0:0.9.8.1-7.fc8 set to be updated
--> Processing Dependency: gnome-python2-gtkmozembed for package: Miro
--> Running transaction check
---> Package gnome-python2-gtkmozembed.i386 0:2.19.1-9.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 Miro                    i386       0.9.8.1-7.fc8    updates           4.8 M
Installing for dependencies:
 gnome-python2-gtkmozembed  i386       2.19.1-9.fc8     updates            28 k

Transaction Summary
=============================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 4.8 M
Downloading Packages:
(1/2): Miro-0.9.8.1-7.fc8 100% |=========================| 4.8 MB    00:29
http://ultra.linux.cz/MIRRORS/fedora.redhat.com/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno -1] Package does not match intended download
Trying other mirror.
http://mirror.karneval.cz/pub/linux/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.
http://ftp.SURFnet.nl/pub/os/Linux/distr/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.
http://ftp.crc.dk/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.
http://mirror.atrpms.net/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.
http://ftp.rhnet.is/pub/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.
http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/Miro-0.9.8.1-7.fc8.i386.rpm:
[Errno 9] Requested Range Not Satisfiable
Trying other mirror.


and so on....


and update also fails on lots of packages...

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jkeating at redhat.com  Sun Oct 28 14:11:16 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 28 Oct 2007 10:11:16 -0400
Subject: problems updating and installing?
In-Reply-To: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>
References: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>
Message-ID: <20071028101116.3bc6fcf9@redhat.com>

On Sun, 28 Oct 2007 15:01:10 +0100
"Valent Turkovic" <valent.turkovic at gmail.com> wrote:

> and so on....
> 
> 
> and update also fails on lots of packages...

The mirrors are in the process of getting signed versions of all the
packages, so things are a bit out of sync right now.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/cca2b3e0/attachment.sig>

From fedora at leemhuis.info  Sun Oct 28 14:28:11 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 28 Oct 2007 15:28:11 +0100
Subject: problems updating and installing?
In-Reply-To: <20071028101116.3bc6fcf9@redhat.com>
References: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>
	<20071028101116.3bc6fcf9@redhat.com>
Message-ID: <47249C7B.5040304@leemhuis.info>



On 28.10.2007 15:11, Jesse Keating wrote:
> On Sun, 28 Oct 2007 15:01:10 +0100
> "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
> 
>> and so on....
>> and update also fails on lots of packages...
> The mirrors are in the process of getting signed versions of all the
> packages, so things are a bit out of sync right now.

Okay, that's the explanation, but it raises some questions:

Can that happen in stable as well when lots of updates get pushed at once?

If the answer is yes: Should yum be fixed to handle this situation?

And why is the error message for the servers that are tried after the
first one "[Errno 9] Requested Range Not Satisfiable"?

Just wondering...

Cu
knurd



From jkeating at redhat.com  Sun Oct 28 14:26:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 28 Oct 2007 10:26:40 -0400
Subject: problems updating and installing?
In-Reply-To: <47249C7B.5040304@leemhuis.info>
References: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>
	<20071028101116.3bc6fcf9@redhat.com>
	<47249C7B.5040304@leemhuis.info>
Message-ID: <20071028102640.78c1918e@redhat.com>

On Sun, 28 Oct 2007 15:28:11 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Can that happen in stable as well when lots of updates get pushed at
> once?

No, because updates are newer versions of packages, not the same exact
nvr being replaced.

> 
> If the answer is yes: Should yum be fixed to handle this situation?
> 
> And why is the error message for the servers that are tried after the
> first one "[Errno 9] Requested Range Not Satisfiable"?
> 
> Just wondering...

Likely because the mirror has old repodata and new package and thus
things are mismatched.


-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/259b5673/attachment.sig>

From buildsys at redhat.com  Sun Oct 28 14:38:26 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 28 Oct 2007 10:38:26 -0400
Subject: rawhide report: 20071027 changes
Message-ID: <200710281438.l9SEcQLd004268@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-1:0.7.0-0.5.svn3030.fc8
--------------------------------------
* Sat Oct 27 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.5.svn3030
- Fix crash when getting WPA secrets (rh #355041)

* Fri Oct 26 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.4.svn3030
- Bring up ethernet devices by default if no connections are defined (rh #339201)
- Fix crash when switching networks or bringing up secrets dialog (rh #353091)
- Fix crash when editing VPN connection properties a second time
- Fix crash when cancelling the secrets dialog if another connection was
    activated in the mean time
- Fix disembodied notification bubbles (rh #333391)

* Thu Oct 25 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.4.svn3020
- Handle PEM certificates
- Hide WPA-PSK Type combo since it's as yet unused
- Fix applet crash when AP security options changed and old secrets are still
    in the keyring
- Fix applet crash connecting to unencrypted APs via the other network dialog

NetworkManager-vpnc-1:0.7.0-0.4.svn3030.fc8
-------------------------------------------
* Sat Oct 27 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.4.svn3030
- Fix a crash when editing VPN properties a second time

anaconda-11.3.0.47-1
--------------------
* Fri Oct 26 2007 Bill Nottingham <notting at redhat.com> - 11.3.0.47-1
- fix live install (#354571)

bug-buddy-1:2.20.1-1.fc8
------------------------
* Fri Oct 26 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.1-1
- Update to 2.20.1
- Drop obsolete patches

esound-1:0.2.38-6.fc8
---------------------
* Fri Oct 26 2007 - Bastien Nocera <bnocera at redhat.com> - 1:0.2.38-6
- Kill the main esound package, so people don't try to use it instead of
  pulseaudio itself (#353051)

gnome-libs-1:1.4.2-6.fc8
------------------------
* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-6
- Clarify licensing (db 1.85 is BSD with advertising, and many objects link
  to it)
- Don't manually install files in %install that aren't going to be packaged
- Preserve timestamps of files copied directly from source to installed package
- Encode ChangeLog as UTF-8
- Fix multiarch conflicts in %{_bindir}/gnome-config,
  %{_bindir}/libart-config, and
  %{_includedir}/gnome-1.0/libart_lgpl/art_config.h (#341321)
- Add patch to help configure find umode_t and hence avoid ppc64 build failure
- Use xdg-open in preference to htmlview for Fedora 7 onwards

kdepim-6:3.5.8-4.svn20071013.ent.fc8
------------------------------------
* Fri Oct 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4.20071013.ent
- -libs: Obsoletes: %name ... to help out multilib upgrades

* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3.20071013.ent
- -libs: %post/%postun /sbin/ldconfig
- -libs conditional (f8+)

* Sun Oct 14 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-2.20071013.ent
- -libs subpkg (to be more multilib friendly)

kernel-2.6.23.1-37.fc8
----------------------
* Fri Oct 26 2007 John W. Linville <linville at redhat.com>
- iwlwifi: clear irqs before enabling them

* Thu Oct 25 2007 Chuck Ebbert <cebbert at redhat.com>
- ALSA 1.0.15
- Fix ppc64 DSO unwinder bug (#350291).
- Fix linker script bug preventing Fedora bringup on IA64.
- Kill not-always-relevant debug message in ath5k driver.

* Wed Oct 24 2007 Dave Jones <davej at redhat.com>
- Disable early boot debugging for release.

opyum-0.0.3-1.fc8
-----------------

polyxmass-bin-0.9.7-2.fc8
-------------------------
* Fri Oct 26 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.7-2
- migrate to new tooltips

* Wed Aug 22 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.7-1
- version upgrade
- new license tag

pungi-1.1.8-1.fc8
-----------------
* Sat Oct 27 2007 Jesse Keating <jkeating at redhat.com> - 1.1.8-1
- Add eclipse group.

* Tue Oct 23 2007 Jesse Keating <jkeating at redhat.com> - 1.1.7-1
- Add java-development to the group set.

selinux-policy-3.0.8-36.fc8
---------------------------
* Fri Oct 26 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-36
- Allow unconfined_t to run crontab -e as root

* Thu Oct 25 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-35
- Add ecryptfs definition

* Thu Oct 25 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-34
- Allow automounter to create a sock file in /var/run/autofs
- Fix corecmd_search_sbin to  be corecmd_search_bin

system-config-firewall-1.0.8-3.fc8
----------------------------------
* Fri Oct 26 2007 Thomas Woerner <twoerner at redhat.com> 1.0.8-3
- bump release for CVS

* Fri Oct 26 2007 Thomas Woerner <twoerner at redhat.com> 1.0.8-2
- lokkit: write new config with nostart option (rhbz#353961)
- translation fixes for de, it, nb, sr at latin

xen-3.1.0-13.fc8
----------------
* Fri Oct 26 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-13.fc8
- Fixed xenbaked tmpfile flaw (CVE-2007-3919)

Broken deps for i386
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.i386 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.x86_64 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8



Broken deps for ppc
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp



Broken deps for ppc64
----------------------------------------------------------
	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc64 requires kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From j.w.r.degoede at hhs.nl  Sun Oct 28 14:44:49 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 28 Oct 2007 15:44:49 +0100
Subject: howto convert configfile on library update?
Message-ID: <4724A061.3050901@hhs.nl>

Hi All,

As discussed previously I'm working on getting lm_sensors-3.0.0 into F-9, this 
not only means updating applications because the API has changed, but also 
requires updating the /etc/sensors.conf configfile. A script for converting it 
is provided by upstream.

But how / when do I run this script, obviously it should get run on %post, and 
only if this is an update. But when?

I can rename the configfile installed by the package from /etc/sensors.conf to 
/etc/sensors3.conf (the new lib will first check for sensors3.conf and then 
sensors.conf to allow parallel installation). Then if the configfile was edited 
an /etc/sensors.conf.rpmsave will be made. I could then check for the existence 
of this and use the convert script to convert it to the new format and install 
the converted file as /etc/sensors3.conf, and last remove 
/etc/sensors.conf.rpmsave to make sure this is only done once.

But what if someone has an old /etc/sensors.conf.rpmsave around and is 
currently happily using a pristine version of /etc/sensors.conf? I could check 
the timestamp on the /etc/sensors.conf.rpmsave, assuming it has a timestamps 
dating from when rpm backed it up, does it? Still feels a bit hacky to me.

Regards,

Hans




From misselt at as.arizona.edu  Sun Oct 28 15:21:42 2007
From: misselt at as.arizona.edu (Karl Misselt)
Date: Sun, 28 Oct 2007 08:21:42 -0700
Subject: Reporting NM 'bug'?
In-Reply-To: <1193516734.4523.11.camel@localhost.localdomain>
References: <4723685C.1040905@as.arizona.edu>
	<1193516734.4523.11.camel@localhost.localdomain>
Message-ID: <4724A906.5030101@as.arizona.edu>

Will Woods wrote:
> On Sat, 2007-10-27 at 09:33 -0700, Karl Misselt wrote:
>   
>> Hi - I'm running F8 Test 3, fully updated on a new Inspiron 1420n.
>> Upgrading NetworkManager to 0.7.0-0.3.svn3020 breaks my wireless;
>> rolling back to 0.7.0-0.3.svn2914 results in a working wireless.  I don't
>> see anything about NM breakage in bugzilla, 
>>     
>
> Seriously? We have a whole tracker bug just to keep track of the other
> NetworkManager bugs:
> https://bugzilla.redhat.com/showdependencytree.cgi?id=336531
>
>   
>> so was going to file a
>> bug against it.  what additional info would be useful to attach
>> (beyond lspci, dmesg output)?  
>>     
>
> First, update to NetworkManager-0.7.0-0.5.svn3030.fc8, which you can get
> here:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22556
> (it missed last night's rawhide push by a few minutes - will land
> tomorrow, but we need testing ASAP)
>   

Ok.  Downloaded and installed 0.7..0-0.5.svn3030.fc8 and the wireless is
working again.  Still need to perfect the suspend recovery, but at least 
I'm back
online with the new one!  Thanks
-Karl

> If the problem persists, useful info to include would be:
> - type of wireless network adapter in your machine (lspci is fine)
> - type of network you are connecting to (security type, etc)
> - NetworkManager log messages from /var/log/messages
> and maybe some other stuff that I'm not remembering at the moment.
>
> -w
>   



From Matt_Domsch at dell.com  Sun Oct 28 15:30:47 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 28 Oct 2007 10:30:47 -0500
Subject: Fedorability of dvbcut ?
In-Reply-To: <47248975.7050901@iinet.net.au>
References: <47248975.7050901@iinet.net.au>
Message-ID: <20071028153047.GC23359@auslistsprd01.us.dell.com>

On Mon, Oct 29, 2007 at 12:07:01AM +1100, David Timms wrote:
> I'm keen to repackage dvbcut for Fedora.
> http://dvbcut.sourceforge.net/installation.html
> The application can be used to trim up a mpeg2 transport stream for 
> example recorded from a DVB tuner card, and output in mpeg2 program 
> stream format.
> 
> As packaged in packman, it warns:
> - qt3 is needed by dvbcut-0.5.4-0.pm.0.i586
> - libffmpeg0 is needed by dvbcut-0.5.4-0.pm.0.i586
> It can also use mplayer, and finds this through name within your path, 
> ie it is not actually required for the program to run.
> With ffmpeg and mplayer installed, a rpm -Uvh --nodeps allows it to run 
> fine.
> 
> It's main function is the conversion from transport stream to program 
> stream of given selections, however, it does recode frames at the start 
> and end of each clip.
> 
> So given the linking {I think} of ffmpeg, and the need for easiest use 
> of having mplayer installed, am I correct in assuming this will be no go 
> in FedoraPC ?

ffmpeg is patent-encumbered, thus no-go in Fedora.  If your
application can use other codecs that are free and are included in
Fedora (e.g. Ogg Theora), but may also use ffmpeg if present, then
it could fit.

> And if that's the case, how does the included kernel module for 
> controlling / receiving mpeg2 transport streams from my DVB card fit 
> with Fedora ?

The hardware manufacturer will have a patent license that allows them
to use mpeg2.  That same patent license most likely does not extend to you
as an end user for use outside of their hardware.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From fedora at leemhuis.info  Sun Oct 28 15:31:31 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 28 Oct 2007 16:31:31 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <1193513368.9273.45.camel@home.alexander.bostrom.net>
References: <4721EB13.5010701@draigBrady.com>	<20071026144805.GB11789@nostromo.devel.redhat.com>	<472200C6.6060900@redhat.com>
	<20071026110906.07daf580@redhat.com>	<47220716.6000402@leemhuis.info>
	<1193513368.9273.45.camel@home.alexander.bostrom.net>
Message-ID: <4724AB53.90500@leemhuis.info>



On 27.10.2007 21:29, Alexander Bostr?m wrote:
> fre 2007-10-26 klockan 17:26 +0200 skrev Thorsten Leemhuis:
> 
>> Additional note: the hard driver does strange noise (sounds a bit like
>> parking and unparking the heads maybe) now and then (sometimes every ten
>> seconds or so, sometimes a lot less). 
> 
> Oooohh... Yeah, this old Thinkpad T21 makes irritating noises like that
> too. And the Load_Cycle_Count increases every time it does that. (Disk
> model is IBM-DJSA-232.) Thanks for the explanation.

Hmmm -- Yesterday and today I tried to disable the Advanced Power
Management feature by using
# sudo /sbin/hdparm -B 255 /dev/sda

The strange noises I often heard every few seconds when the systems was
idle went away.

*Uneducated guess*: Dell (my notebook vendor) in the BIOS enabled the
Power Management feature (good) with a short idle-timeout (debatable if
that's good or bad (?)) and expects that the OS set a more sane value
once the system is up (which we don't do, which I'd say would be the
correct way if those nosies wouldn't make me nervous).

CU
knurd

(?) -- might be a good way to save power until the OS is up and running
to take care of it



From dwmw2 at infradead.org  Sun Oct 28 15:36:25 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 28 Oct 2007 11:36:25 -0400
Subject: b43 in Fedora 7
In-Reply-To: <4724911F.4050308@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>
	<1193573023.2915.42.camel@shinybook.infradead.org>
	<47248919.6000505@sms.ed.ac.uk>
	<1193577458.2915.45.camel@shinybook.infradead.org>
	<4724911F.4050308@sms.ed.ac.uk>
Message-ID: <1193585785.2915.56.camel@shinybook.infradead.org>

On Sun, 2007-10-28 at 13:39 +0000, Ioannis Nousias wrote:
> I see. I thought b43legacy was for BCM4306/2 cards. I have a
> BCM4309(rev02).
> 
> I've extracted the 3.130.20 firmware now, but I don't have a b43legacy
> kernel module. Isn't it included in the fedora kernel package? I 
> reloaded the 'b43' one, but I get the same behaviour.

Oh, for F7 I suppose you'll still want to be using the old bcm43xx
driver. I was thinking of the rawhide kernel.

Either update to rawhide, or alternatively unload the ssb drivers, load
bcm43xx, and add your device's PCI ident to bcm43xx (as you seem to know
how to do, but my preferred technique would be this
in /etc/modprobe.d/bcm43xx):

install pci:v000014E4d00004324sv*sd*bc*sc*i* /sbin/modprobe --ignore-install bcm43xx && echo "14e4 4324" > /sys/bus/pci/drivers/bcm43xx/new_id

-- 
dwmw2



From Matt_Domsch at dell.com  Sun Oct 28 15:36:14 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 28 Oct 2007 10:36:14 -0500
Subject: problems updating and installing?
In-Reply-To: <20071028102640.78c1918e@redhat.com>
References: <64b14b300710280701i314d1afbh69db6cb5e8efa9c@mail.gmail.com>
	<20071028101116.3bc6fcf9@redhat.com>
	<47249C7B.5040304@leemhuis.info>
	<20071028102640.78c1918e@redhat.com>
Message-ID: <20071028153614.GD23359@auslistsprd01.us.dell.com>

On Sun, Oct 28, 2007 at 10:26:40AM -0400, Jesse Keating wrote:
> On Sun, 28 Oct 2007 15:28:11 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
> > Can that happen in stable as well when lots of updates get pushed at
> > once?
> 
> No, because updates are newer versions of packages, not the same exact
> nvr being replaced.
> 
> > 
> > If the answer is yes: Should yum be fixed to handle this situation?
> > 
> > And why is the error message for the servers that are tried after the
> > first one "[Errno 9] Requested Range Not Satisfiable"?
> > 
> > Just wondering...
> 
> Likely because the mirror has old repodata and new package and thus
> things are mismatched.

I saw this last night myself once, and a 'yum clean metadata' fixed it
up.  I'll remind the mirror servers to use rsync --delete-after --delay-updates which
decreases the liklihood of this kind of error.  The updated metadata
then isn't made available until the very end of the rsync transaction,
and the older RPMs pointed to by the metadata remain until the end of
the transaction too.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From kevin.kofler at chello.at  Sun Oct 28 15:59:02 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 28 Oct 2007 15:59:02 +0000 (UTC)
Subject: rawhide report: 20071027 changes
References: <200710281438.l9SEcQLd004268@porkchop.devel.redhat.com>
Message-ID: <loom.20071028T155805-875@post.gmane.org>

Build System <buildsys <at> redhat.com> writes:
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.i386 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.x86_64 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8
> 	kdemultimedia-extras - 6:3.5.8-6.fc8.ppc64 requires 
kdemultimedia-extras-libs- = 6:3.5.8-6.fc8

The fix for this typo is already tagged f8-final, but missed the Rawhide 
cutoff. It will be in the next Rawhide cut.

        Kevin Kofler



From packages at amiga-hardware.com  Sun Oct 28 16:01:42 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Sun, 28 Oct 2007 16:01:42 +0000
Subject: More multiarch stuff
In-Reply-To: <20071028093530.96cf1bca.mschwendt.tmp0701.nospam@arcor.de>
References: <4723C8EF.7020406@amiga-hardware.com>
	<20071028093530.96cf1bca.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <4724B266.9050908@amiga-hardware.com>

Michael Schwendt wrote:

>> Why doesn't rpm/yum complain when I install both the i386 and x86_64
>> version of kdetv on F7, when /usr/share/doc/HTML/*/kdetv/index.cache.bz2
>> differs between the two?
> How do you install them? At once? Or after eachother? 

Ah yes, I installed them simultaneously and rpm/yum doesn't complain, 
but I've just tried now and if they are installed separately then it 
does complain.

> AFAIK, meanwhile
> it has been noticed that a conflict is reported only if you install
> them one by one.

Indeed that appears to be the case. Thanks for pointer Michael.

-- 
Ian Chapman.



From kevin.kofler at chello.at  Sun Oct 28 16:01:15 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 28 Oct 2007 16:01:15 +0000 (UTC)
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the
	fedora	repo?
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
Message-ID: <loom.20071028T160035-90@post.gmane.org>

Mark <markg85 <at> gmail.com> writes:
> I can't make RPM packages from scratch so therefore i think it's best
> to leave that to a professional RPM packager.

Many of us packagers aren't "professionals" in the literal sense.

        Kevin Kofler



From m.a.young at durham.ac.uk  Sun Oct 28 16:14:03 2007
From: m.a.young at durham.ac.uk (M A Young)
Date: Sun, 28 Oct 2007 16:14:03 +0000 (GMT)
Subject: b43 in Fedora 7
In-Reply-To: <4724911F.4050308@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>
	<1193573023.2915.42.camel@shinybook.infradead.org>
	<47248919.6000505@sms.ed.ac.uk>
	<1193577458.2915.45.camel@shinybook.infradead.org>
	<4724911F.4050308@sms.ed.ac.uk>
Message-ID: <Pine.LNX.4.58.0710281612010.12799@vega2.dur.ac.uk>

On Sun, 28 Oct 2007, Ioannis Nousias wrote:

> David Woodhouse wrote:
> > You'll need to extract firmware from a v3 driver with b43-fwcutter.
> >
> >
> I see. I thought b43legacy was for BCM4306/2 cards. I have a BCM4309(rev02).
>
> I've extracted the 3.130.20 firmware now, but I don't have a b43legacy
> kernel module. Isn't it included in the fedora kernel package? I
> reloaded the 'b43' one, but I get the same behaviour.

Actually, for fedora 7 you probably what to extract the firmware with the
bcm43xx-fwcutter package.

	Michael Young



From s0238762 at sms.ed.ac.uk  Sun Oct 28 17:20:00 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Sun, 28 Oct 2007 17:20:00 +0000
Subject: b43 in Fedora 7
In-Reply-To: <1193585785.2915.56.camel@shinybook.infradead.org>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>	<1193577458.2915.45.camel@shinybook.infradead.org>	<4724911F.4050308@sms.ed.ac.uk>
	<1193585785.2915.56.camel@shinybook.infradead.org>
Message-ID: <4724C4C0.4020007@sms.ed.ac.uk>

David Woodhouse wrote:
> On Sun, 2007-10-28 at 13:39 +0000, Ioannis Nousias wrote:
>   
>> I see. I thought b43legacy was for BCM4306/2 cards. I have a
>> BCM4309(rev02).
>>
>> I've extracted the 3.130.20 firmware now, but I don't have a b43legacy
>> kernel module. Isn't it included in the fedora kernel package? I 
>> reloaded the 'b43' one, but I get the same behaviour.
>>     
>
> Oh, for F7 I suppose you'll still want to be using the old bcm43xx
> driver. I was thinking of the rawhide kernel.
>
> Either update to rawhide, or alternatively unload the ssb drivers, load
> bcm43xx, and add your device's PCI ident to bcm43xx (as you seem to know
> how to do, but my preferred technique would be this
> in /etc/modprobe.d/bcm43xx):
>
> install pci:v000014E4d00004324sv*sd*bc*sc*i* /sbin/modprobe --ignore-install bcm43xx && echo "14e4 4324" > /sys/bus/pci/drivers/bcm43xx/new_id
>
>   
ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for me.


thanks



From lsof at nodata.co.uk  Sun Oct 28 17:22:07 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 28 Oct 2007 18:22:07 +0100
Subject: Package XYZ is not signed
In-Reply-To: <1193367084.5910.2.camel@localhost.localdomain>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
Message-ID: <1193592127.7011.4.camel@sb-home>

Am Donnerstag, den 25.10.2007, 22:51 -0400 schrieb Will Woods:
> This has been discussed a bunch of times already. Rawhide packages
> aren't signed. This is intentional.

That's nice. So I'll stop testing rawhide now because I don't know where
the packages are from. Conveniently jumping off and on the security
bandwagon at different stages in the release is a bit churlish.

It only takes one malicious unsigned package to be installed for the box
to be compromised, and nothing will protect against that.

Come on though, we have auto-signing now, what was the killer reason for
unsigned rpms?



From katzj at redhat.com  Sun Oct 28 17:43:10 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 28 Oct 2007 13:43:10 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <472260A1.9080208@draigBrady.com>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>  <472260A1.9080208@draigBrady.com>
Message-ID: <1193593390.12284.1.camel@localhost.localdomain>

On Fri, 2007-10-26 at 22:48 +0100, P?draig Brady wrote:
> 4. fedora should probably default to relatime mount option
>    on laptops at least (as Ingo suggested here:
>    http://kerneltrap.org/node/14148 )

[katzj at aglarond ~]$ grep CONFIG_DEFAULT_RELATIME /boot/config*
CONFIG_DEFAULT_RELATIME=y
CONFIG_DEFAULT_RELATIME_VAL=1

And it's been that way for months now :)

Jeremy



From Curtis at GreenKey.net  Sun Oct 28 17:54:31 2007
From: Curtis at GreenKey.net (Curtis Doty)
Date: Sun, 28 Oct 2007 10:54:31 -0700 (PDT)
Subject: laptop hard disk etiquette
In-Reply-To: <1193593390.12284.1.camel@localhost.localdomain>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>  <472260A1.9080208@draigBrady.com>
	<1193593390.12284.1.camel@localhost.localdomain>
Message-ID: <20071028175432.3DD786F1C2@alopias.GreenKey.net>

1:43pm Jeremy Katz said:

> On Fri, 2007-10-26 at 22:48 +0100, P?draig Brady wrote:
>> 4. fedora should probably default to relatime mount option
>>    on laptops at least (as Ingo suggested here:
>>    http://kerneltrap.org/node/14148 )
>
> [katzj at aglarond ~]$ grep CONFIG_DEFAULT_RELATIME /boot/config*
> CONFIG_DEFAULT_RELATIME=y
> CONFIG_DEFAULT_RELATIME_VAL=1
>
> And it's been that way for months now :)
>

Which is great. But don't make the mistake of thinking you can explictly 
add the relatime option to / in fstab. Because mkinitrd cannot handle. :-(

 	http://bugzilla.redhat.com/296361

../C

From debarshi.ray at gmail.com  Sun Oct 28 18:06:09 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 28 Oct 2007 23:36:09 +0530
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
Message-ID: <3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>

> I can't make RPM packages from scratch so therefore i think it's best
> to leave that to a professional RPM packager. But if noone else is
> willing to do it than i would like to give it a try.. and i probably
> need a lot of help along the way.

Better assume that no is willing to package Netbeans for you, and do
it yourself.

It is really not hard. Use Max RPM (http://www.rpm.org/max-rpm/) and
the Fedora packaging guidelines
(http://fedoraproject.org/wiki/Packaging/Guidelines) for help and you
will be ready to go. If you stumble, look at some pre-existing SPEC
files for help.

It is really fun to be a Fedora packager. Go for it. ;-)

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From a.badger at gmail.com  Sun Oct 28 18:06:25 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 28 Oct 2007 11:06:25 -0700
Subject: Package XYZ is not signed
In-Reply-To: <1193592127.7011.4.camel@sb-home>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home>
Message-ID: <4724CFA1.2050007@gmail.com>

nodata wrote:
> Come on though, we have auto-signing now, what was the killer reason for
> unsigned rpms?
> 

We don't have auto-sign yet.  Which is the main reason we don't have 
signed rawhide packages.

-Toshio



From fedora at camperquake.de  Sun Oct 28 18:17:57 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 28 Oct 2007 19:17:57 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <20071027003847.GD30562@devserv.devel.redhat.com>
References: <4721EB13.5010701@draigBrady.com>
	<20071026144805.GB11789@nostromo.devel.redhat.com>
	<47220726.2040603@draigBrady.com>
	<20071027003847.GD30562@devserv.devel.redhat.com>
Message-ID: <20071028191757.1d5c6e8c@lain.camperquake.de>

Hi.

On Fri, 26 Oct 2007 20:38:47 -0400, Alan Cox wrote

> Windows will set values if the user has set preferences but as I
> understand it not otherwise. Ditto Linux

Does anyone know a program for Windows that will display this information?
I have a Windows partition on this laptop next to the Linux one.



From katzj at redhat.com  Sun Oct 28 18:20:26 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 28 Oct 2007 14:20:26 -0400
Subject: laptop hard disk etiquette
In-Reply-To: <20071028175432.3DD786F1C2@alopias.GreenKey.net>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>  <472260A1.9080208@draigBrady.com>
	<1193593390.12284.1.camel@localhost.localdomain>
	<20071028175432.3DD786F1C2@alopias.GreenKey.net>
Message-ID: <1193595626.12284.6.camel@localhost.localdomain>

On Sun, 2007-10-28 at 10:54 -0700, Curtis Doty wrote:
> 1:43pm Jeremy Katz said:
> > On Fri, 2007-10-26 at 22:48 +0100, P?draig Brady wrote:
> >> 4. fedora should probably default to relatime mount option
> >>    on laptops at least (as Ingo suggested here:
> >>    http://kerneltrap.org/node/14148 )
> >
> > [katzj at aglarond ~]$ grep CONFIG_DEFAULT_RELATIME /boot/config*
> > CONFIG_DEFAULT_RELATIME=y
> > CONFIG_DEFAULT_RELATIME_VAL=1
> >
> > And it's been that way for months now :)
> >
> 
> Which is great. But don't make the mistake of thinking you can explictly 
> add the relatime option to / in fstab. Because mkinitrd cannot handle. :-(

You don't have to add the option.  The right thing happens when the
kernel mounts the filesystem

Jeremy



From fedora at camperquake.de  Sun Oct 28 18:33:37 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 28 Oct 2007 19:33:37 +0100
Subject: On Board video vs AGP/PCI
In-Reply-To: <1193579713.14059.5.camel@scrappy.miketc.com>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
Message-ID: <20071028193337.3ff475e1@lain.camperquake.de>

Hi.

On Sun, 28 Oct 2007 08:55:13 -0500, Mike Chambers wrote
> I have an ATI 1300 card via agp, and am thinking of using my on board
> video.

Usually the on-board video chip is attached to the AGP bus, also,
and thus gets disabled as soon as you put in a "real" AGP card.

Sorry, no cookie.



From Curtis at GreenKey.net  Sun Oct 28 18:38:16 2007
From: Curtis at GreenKey.net (Curtis Doty)
Date: Sun, 28 Oct 2007 11:38:16 -0700 (PDT)
Subject: laptop hard disk etiquette
In-Reply-To: <1193595626.12284.6.camel@localhost.localdomain>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>  <472260A1.9080208@draigBrady.com>
	<1193593390.12284.1.camel@localhost.localdomain>
	<20071028175432.3DD786F1C2@alopias.GreenKey.net>
	<1193595626.12284.6.camel@localhost.localdomain>
Message-ID: <20071028183816.5877D6F1C2@alopias.GreenKey.net>

2:20pm Jeremy Katz said:

> On Sun, 2007-10-28 at 10:54 -0700, Curtis Doty wrote:
>> 1:43pm Jeremy Katz said:
>>> On Fri, 2007-10-26 at 22:48 +0100, P?draig Brady wrote:
>>>> 4. fedora should probably default to relatime mount option
>>>>    on laptops at least (as Ingo suggested here:
>>>>    http://kerneltrap.org/node/14148 )
>>>
>>> [katzj at aglarond ~]$ grep CONFIG_DEFAULT_RELATIME /boot/config*
>>> CONFIG_DEFAULT_RELATIME=y
>>> CONFIG_DEFAULT_RELATIME_VAL=1
>>>
>>> And it's been that way for months now :)
>>>
>>
>> Which is great. But don't make the mistake of thinking you can explictly
>> add the relatime option to / in fstab. Because mkinitrd cannot handle. :-(
>
> You don't have to add the option.  The right thing happens when the
> kernel mounts the filesystem
>

True, but when a *valid* option to the rootfs prevents boot, that's a very 
bad thing. .. I wonder what will happen if / has norelatime in fstab...

../C

From debarshi.ray at gmail.com  Sun Oct 28 18:43:53 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 29 Oct 2007 00:13:53 +0530
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>
Message-ID: <3170f42f0710281143x1d3f356fj84b9dc610657c16c@mail.gmail.com>

> Better assume that no is willing to package Netbeans for you, and do
> it yourself.

http://www.jpackage.org/cgi-bin/cvsweb.cgi/rpms/free/netbeans/Attic/netbeans.spec?rev=1.7.2.1;content-type=text%2Fplain;cvsroot=jpackage;hideattic=0

That is an old attempt at packaging Netbeans (thanks to Nicolas Mailhot).

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From nicolas.mailhot at laposte.net  Sun Oct 28 18:43:51 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 28 Oct 2007 19:43:51 +0100
Subject: laptop hard disk etiquette
In-Reply-To: <20071028183816.5877D6F1C2@alopias.GreenKey.net>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>
	<472209D2.7090803@draigBrady.com>  <472260A1.9080208@draigBrady.com>
	<1193593390.12284.1.camel@localhost.localdomain>
	<20071028175432.3DD786F1C2@alopias.GreenKey.net>
	<1193595626.12284.6.camel@localhost.localdomain>
	<20071028183816.5877D6F1C2@alopias.GreenKey.net>
Message-ID: <1193597032.3224.0.camel@rousalka.dyndns.org>


Le dimanche 28 octobre 2007 ? 11:38 -0700, Curtis Doty a ?crit :

> True, but when a *valid* option to the rootfs prevents boot, that's a very 
> bad thing. .. I wonder what will happen if / has norelatime in fstab...

You do not need to wonder, boot just fails

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

From mszpak at wp.pl  Sun Oct 28 18:50:28 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sun, 28 Oct 2007 19:50:28 +0100
Subject: Upgrade 7.92 -> 8
In-Reply-To: <20071027140831.2bcb2171@redhat.com>
References: <ffvull$3pq$1@ger.gmane.org> <20071027140831.2bcb2171@redhat.com>
Message-ID: <fg2llm$j2q$1@ger.gmane.org>

On 2007-10-27 20:08, Jesse Keating wrote:
> On Sat, 27 Oct 2007 20:05:40 +0200
> "Marcin Zaj?czkowski" <mszpak at wp.pl> wrote:
> 
>> I would like to install Fedora 8 Test 3 to help testing new Fedora
>> version. I know it could be less stable that final, but it's not very
>> important me.
>> Later, I would like to upgrade it to F-8 final (without a new
>> installation). Would it be possible to use updates from a development
>> version and after 9 XI smoothly switch to updates for F-8?
>> Or the only way is to call "Upgrade" option from F-8 DVD?
> 
> If you install now, and then do all your updates, the fedora-release
> package will turn off 'development' and turn on 'fedora' and
> 'updates-release' repos.  These repos right now redirect to rawhide
> until F8 goes live and then they will point to F8.  This will "pin" you
> to Fedora 8.

Great. Thanks for your info.


Best
Marcin



From debarshi.ray at gmail.com  Sun Oct 28 19:14:06 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 29 Oct 2007 00:44:06 +0530
Subject: Orphaning some packages
In-Reply-To: <20071014200614.0c957e31@vader.jdub.homelinux.org>
References: <20071014200614.0c957e31@vader.jdub.homelinux.org>
Message-ID: <3170f42f0710281214u256037b1h4ae7688973a0cbad@mail.gmail.com>

Is there any reason for not updating tla to 1.3.5 and sticking to 1.3.4?

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From mjs at CLEMSON.EDU  Sun Oct 28 19:16:26 2007
From: mjs at CLEMSON.EDU (Matthew Saltzman)
Date: Sun, 28 Oct 2007 15:16:26 -0400
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>
Message-ID: <1193598986.15338.40.camel@vincent52.localdomain>

On Fri, 2007-10-26 at 19:18 -0400, Will Woods wrote:
> As promised, here's an update on the current Fedora 8 Blocker list. 
> 
> As a note: the deadline for blocker fixes is Tuesday, October 29. If we
> still have unfixed critical bugs Tuesday, the release will have to be
> delayed.
> 
> But I don't think that'll happen. Things are looking OK. We currently
> have 14 bugs on the blocker list, which I'll talk about in detail below.
> About half of them have fixes that are waiting for confirmation, and a
> couple of them could be dropped if necessary because they only affect
> particular, uncommon hardware.
> 
> What we need help testing is:
> 
> 1) ALSA - 1.0.15 was released last week, and we decided it was a
> low-risk update that would fix audio problems. for a lot of people. You
> probably saw mail from Chuck Ebbert about this already.

kernel-2.6.23.1-37.fc8: 

Most sound works well on my ThinkPad T61, except that the volume buttons
don't control volume level.  The mute button mutes, and the volume
buttons unmute, but volume doesn't change.  Also, lowering volume to
minimum turns on the mute indicator in the volume-level pop-up (even
though it's not muted), but the mute button doesn't.  Software sliders
in gnome-volume-control and system-config-soundcard do work.

> 
> 2) Intel wireless - John Linville, our fearless (and handsome) wireless
> maintainer, just added a fix for iwlwifi that should help some Intel
> wireless users.

Almost everything seems OK, except for attaching to a hidden SSID
(wasn't working before, but I can't test till tomorrow) and vpnc
dropping it's connection.  I need to test if that's an issue with wired
connection before I conclude it's iwl3945-related.

>  
> 
> Both of the above patches are in kernel-2.6.23.1-37.fc8, which should
> land in rawhide tomorrow. You can get it from koji in the meantime:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22511
>
> ...
> 
> === NetworkManager bugs ===
> 
> * Bug 311511: NEW - dcbw
> - x86_64 iwl3945 NM crash after Keyring loop Deny
> 
> Comments indicate that the crash is fixed, but it still loops on bad
> passwords. 

I think that was my comment.  By "loops" I meant that one is prompted
repeatedly for the keyring password.  There's no failure mode other than
getting the password right or clicking "deny".  Not sure if that's by
design or not.

> 
> 
> * Bug 323371: NEEDINFO - dcbw
> - NM 0.7 doesn't support WPA/WPA2 Enterprise (certificate-based
> authentication)
> 
> Reporter seems to indicate that this is mostly fixed, but some testing
> on a fresh install is needed to confirm the fix.
> 
> 
> * Bug 353091: MODIFIED - dcbw
> - NetworkManager-0.7.0-0.3.svn3020.fc8 crashes when trying to switch to
> wireless Network
> 
> nm-applet crasher. A fix will be in the next build, and then this can be
> retested and (hopefully) closed. 
> 
> 
> ...
> 
> And there you have it. Most of those bugs already have fixes pending,
> and none of the rest are hair-on-fire critical bugs, so I think we're in
> good shape. If you can help test the stuff I mentioned above, or you
> have found some huge problem that we've missed, please let us know.
> 
> Thanks for helping make Fedora more awesome!
> 
> -w
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From markg85 at gmail.com  Sun Oct 28 19:22:05 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 28 Oct 2007 20:22:05 +0100
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>
Message-ID: <6e24a8e80710281222i467a2004m891ebe193b7f1b68@mail.gmail.com>

> It is really fun to be a Fedora packager. Go for it. ;-)
>
> Cheers,
> Debarshi

well.. it's puzzling a lot!!

> http://www.jpackage.org/cgi-bin/cvsweb.cgi/rpms/free/netbeans/Attic/netbeans.spec?rev=1.7.2.1;content-type=text%2Fplain;cvsroot=jpackage;hideattic=0
>
> That is an old attempt at packaging Netbeans (thanks to Nicolas Mailhot).
>

Yea, i've looked at the spec and it's huge.. there must be a faster
way of doing it.
o well. i'm not gonna promiss that i can make this netbeans package
but i will try it. i will post all "news" about it here in this
thread. Also i'm not starting today (still running ubuntu).. somewhere
next week.



From debarshi.ray at gmail.com  Sun Oct 28 19:24:30 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 29 Oct 2007 00:54:30 +0530
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710281222i467a2004m891ebe193b7f1b68@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<3170f42f0710281106u1300b6c4n94efb3d7a06a936e@mail.gmail.com>
	<6e24a8e80710281222i467a2004m891ebe193b7f1b68@mail.gmail.com>
Message-ID: <3170f42f0710281224g5502b883gb630bd4d79b24b6@mail.gmail.com>

> o well. i'm not gonna promiss that i can make this netbeans package
> but i will try it.

That is the spirit. :-)

Good luck,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jwboyer at gmail.com  Sun Oct 28 19:35:07 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 28 Oct 2007 14:35:07 -0500
Subject: Orphaning some packages
In-Reply-To: <3170f42f0710281214u256037b1h4ae7688973a0cbad@mail.gmail.com>
References: <20071014200614.0c957e31@vader.jdub.homelinux.org>
	<3170f42f0710281214u256037b1h4ae7688973a0cbad@mail.gmail.com>
Message-ID: <20071028143507.19234da1@vader.jdub.homelinux.org>

On Mon, 29 Oct 2007 00:44:06 +0530
"Debarshi 'Rishi' Ray" <debarshi.ray at gmail.com> wrote:

> Is there any reason for not updating tla to 1.3.5 and sticking to 1.3.4?

No.

josh



From fedora at leemhuis.info  Sun Oct 28 20:11:26 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 28 Oct 2007 21:11:26 +0100
Subject: EPEL report week 43 2007
Message-ID: <4724ECEE.6080508@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week43

----
= Weekly EPEL Summary =

Week 43/2007

== Most important happenings ==

 * lots of packages in epel5 were moved from testing to the proper repo;
see
[https://www.redhat.com/archives/epel-devel-list/2007-October/msg00045.html
this thread] for some details

== Meeting ==

Meeting was canceled past week. Therefor I'd suggest we schedule the
next meeting for 20071031 at 17:00 UTC in #fedora-meeting

Some status update from task owners in
[https://www.redhat.com/archives/epel-devel-list/2007-October/msg00033.html
this thread]

== Stats ==

=== General ===

Number of EPEL Contributors 137

=== EPEL 5 ===

Number of source packages: 707

Number of binary packages:  1358

There are 8 new Packages:

 * bibexport | Extract entries from BibTeX and .aux files
 * blitz | C++ class library for matrix scientific computing
 * fcgi | FastCGI development kit
 * mlmmj | Mailserver-independent ezmlm-like mailing list manager
 * perl-Data-Dump | Pretty printing of data structures
 * python-flup | Random assortment of WSGI servers for python
 * python-mechanoid | Python Programmatic Web Browser
 * yafc | Yet Another FTP/SFTP Client

=== EPEL 4 ===

Number of source packages: 438

Number of binary packages:  890

There are 3 new Packages:

 * bibexport | Extract entries from BibTeX and .aux files
 * blitz | C++ class library for matrix scientific computing
 * perl-Data-Dump | Pretty printing of data structures

----
["CategoryEPELReports"]



From anders at trudheim.co.uk  Sun Oct 28 20:19:06 2007
From: anders at trudheim.co.uk (Anders Karlsson)
Date: Sun, 28 Oct 2007 20:19:06 +0000
Subject: Sierra Wireless on Rawhide
In-Reply-To: <20071025211235.956b999f.zaitcev@redhat.com>
References: <20071007122026.GA5994@iota.fab.redhat.com>
	<20071008192328.84405765.zaitcev@redhat.com>
	<20071009100727.GB3537@iota.fab.redhat.com>
	<20071025211235.956b999f.zaitcev@redhat.com>
Message-ID: <20071028201906.GA5242@iota.fab.redhat.com>

Thus, Pete Zaitcev at Fri Oct 26 05:12:35 2007 inscribed:
> On Tue, 9 Oct 2007 11:07:27 +0100, Anders Karlsson <anders at trudheim.co.uk> wrote:
> 
> > > Please send me a usbmon trace
> > > (see /usr/share/doc/kernel-doc-2.6.22/Documentation/usb/usbmon.txt).
> > 
> > I'll have to instrument something to run early enough in rc.sysinit or
> > from the initrd so that this can be captured. The point in time where
> > the device is disconnected is just to early.
> > 
> > Would an initrd generated without usb support allow me to load the
> > modules one at a time to get this set up so I can use usbmon you
> > think?
> 
> Good thinking, but I think it might be easier just do rmmod uhci_hcd
> than rebuild your initrd.

Hacking of rc.sysinit did the trick. Please find attached, generated
immediately after the 'modprobe usbcore' section, the output from
lsusb, lsusb -v and the data collected from
/sys/kernel/debug/usbmon/3u up until the end of rc.sysinit (by which
time the sierra device have stopped working).

> > > Also, I'd like to see /proc/bus/usb/devices (please disable sierra
> > > driver by renaming or blacklisting it temporarily so it does not
> > > kill the device before you can capture the devices file). I'll poke
> > > the upstream about it we can put together an error case.
> > 
> > sierra and usbserial is blacklisted, and the device still get
> > disconnected. 
> 
> Well, I said that because the original dmesg you posted had drivers
> involved. I may be wrong about it though.

I hope the attached lsusb / lsusb -v data will be sufficient, if not,
I can do more.

Thanks!

-- 
Anders Karlsson <anders at trudheim.co.uk>
All-Round Linux Tinkerer & RHCE
-------------- next part --------------
Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. 
Bus 005 Device 001: ID 0000:0000  
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 002: ID 1199:6804 Sierra Wireless, Inc. 
Bus 003 Device 001: ID 0000:0000  
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000  
-------------- next part --------------

Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0483 SGS Thomson Microelectronics
  idProduct          0x2016 Fingerprint Reader
  bcdDevice            0.01
  iManufacturer           1 STMicroelectronics
  iProduct                2 Biometric Coprocessor
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              20

Bus 005 Device 002: ID 0a5c:2110 Broadcom Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           0x0a5c Broadcom Corp.
  idProduct          0x2110 
  bcdDevice            1.00
  iManufacturer           1 Broadcom Corp
  iProduct                2 BCM2045B
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          216
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0009  1x 9 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0009  1x 9 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       2
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0011  1x 17 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0011  1x 17 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       3
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       4
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       5
      bNumEndpoints           2
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      0 
      iInterface              0 

Bus 005 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.23.1-37.fc8 uhci_hcd
  iProduct                2 UHCI Host Controller
  iSerial                 1 0000:00:1d.3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0x96 
 Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0103 power enable connect

Bus 004 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.23.1-37.fc8 uhci_hcd
  iProduct                2 UHCI Host Controller
  iSerial                 1 0000:00:1d.2
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0x96 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power

Bus 003 Device 002: ID 1199:6804 Sierra Wireless, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1199 Sierra Wireless, Inc.
  idProduct          0x6804 
  bcdDevice            0.01
  iManufacturer           1 Sierra Wireless, Incorporated
  iProduct                2 Mini Card
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x00
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           7
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              3 Data Interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval             128
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

Bus 003 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.23.1-37.fc8 uhci_hcd
  iProduct                2 UHCI Host Controller
  iSerial                 1 0000:00:1d.1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0x96 
 Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0100 power

Bus 002 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.23.1-37.fc8 uhci_hcd
  iProduct                2 UHCI Host Controller
  iSerial                 1 0000:00:1d.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0x96 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power

Bus 001 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.23.1-37.fc8 ehci_hcd
  iProduct                2 EHCI Host Controller
  iSerial                 1 0000:00:1d.7
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength              11
  bDescriptorType      41
  nNbrPorts             8
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0 0x96
  PortPwrCtrlMask    0xfd  0xb7 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
   Port 5: 0000.0100 power
   Port 6: 0000.0100 power
   Port 7: 0000.0100 power
   Port 8: 0000.0100 power
-------------- next part --------------
f7f94680 4146359235 C Ii:3:001:1 0:128 1 = 02
f7f94680 4146359244 S Ii:3:001:1 -115:128 2 <
f7f74100 4146359265 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f7f74100 4146359272 C Ci:3:001:0 0 4 = 00010300
f7f74100 4146359275 S Co:3:001:0 s 23 01 0010 0001 0000 0
f7f74100 4146359280 C Co:3:001:0 0 0
f7f74100 4146359282 S Co:3:001:0 s 23 01 0011 0001 0000 0
f7f74100 4146359286 C Co:3:001:0 0 0
f79f8b00 4146360504 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f79f8b00 4146360515 C Ci:3:001:0 0 4 = 00010000
f7b3d900 4146387206 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f7b3d900 4146387215 C Ci:3:001:0 0 4 = 00010000
f79f8a80 4146413223 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f79f8a80 4146413232 C Ci:3:001:0 0 4 = 00010000
f7b3d900 4146440202 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f7b3d900 4146440210 C Ci:3:001:0 0 4 = 00010000
f79f8a80 4146466206 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f79f8a80 4146466213 C Ci:3:001:0 0 4 = 00010000
f7f94680 4148609247 C Ii:3:001:1 -2:128 0
f7f94680 487888930 S Ii:3:001:1 -115:128 2 <
f64d6700 487889008 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f64d6700 487889019 C Ci:3:001:0 0 4 = 00010000
f6a41100 487889057 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
f6a41100 487889071 C Ci:3:001:0 0 4 = 00010000
f7f94680 489945006 C Ii:3:001:1 -2:128 0

From mailings at lordmorgul.net  Sun Oct 28 20:40:25 2007
From: mailings at lordmorgul.net (Andrew Farris)
Date: Sun, 28 Oct 2007 13:40:25 -0700
Subject: Package XYZ is not signed
In-Reply-To: <1193592127.7011.4.camel@sb-home>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home>
Message-ID: <4724F3B9.4010608@lordmorgul.net>

nodata wrote:
> Am Donnerstag, den 25.10.2007, 22:51 -0400 schrieb Will Woods:
>> This has been discussed a bunch of times already. Rawhide packages
>> aren't signed. This is intentional.
> 
> That's nice. So I'll stop testing rawhide now because I don't know where
> the packages are from. Conveniently jumping off and on the security
> bandwagon at different stages in the release is a bit churlish.
> 
> It only takes one malicious unsigned package to be installed for the box
> to be compromised, and nothing will protect against that.
> 
> Come on though, we have auto-signing now, what was the killer reason for
> unsigned rpms?
> 

A malicious package that gets placed into the system by a maintainer would come
flying down into your system 'signed' by an autosign process too... and you'd
happily not notice.  That maintainer would pretty soon get reprimanded and the
packages cleaned up, but really nothing is in place to prevent that either (in
rawhide).  Testing rawhide isn't for boxes with corporate sensitive data...

If you keep an eye on where your packages are coming from, even for rawhide,
then you can be sure that only authorized maintainers have put them into the
system (control which mirrors you're pulling them from).  Actually signing the
package from the build system would change very little other than insure that
the mirror you're downloading from did not bring in a new package that doesn't
belong.

So as it stands, you have to extend trust to the maintainers, and the mirror.
You can pick which mirror you trust.



From fedora at camperquake.de  Sun Oct 28 20:49:37 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 28 Oct 2007 21:49:37 +0100
Subject: Package XYZ is not signed
In-Reply-To: <4724F3B9.4010608@lordmorgul.net>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724F3B9.4010608@lordmorgul.net>
Message-ID: <20071028214937.06e43f0d@lain.camperquake.de>

Hi.

On Sun, 28 Oct 2007 13:40:25 -0700, Andrew Farris wrote

> A malicious package that gets placed into the system by a maintainer
> would come flying down into your system 'signed' by an autosign
> process too... and you'd happily not notice.

Yes. That waoy I'd have to trust the maintainer and our build system.

As it stands now, I have to trust the maintainer, the build system and
the rest of the internet.

Which is rather a lot of trust.



From louisg00 at bellsouth.net  Sun Oct 28 21:41:04 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 28 Oct 2007 17:41:04 -0400
Subject: something not right with sound
Message-ID: <1193607664.3674.2.camel@tiger>

This is rawhide as of 10/28

$ alsamixer
*** PULSEAUDIO: Unable to connect: Connection refused

alsamixer: function snd_ctl_open failed for default: Connection refused




From mzerqung at 0pointer.de  Sun Oct 28 21:58:54 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sun, 28 Oct 2007 22:58:54 +0100
Subject: something not right with sound
In-Reply-To: <1193607664.3674.2.camel@tiger>
References: <1193607664.3674.2.camel@tiger>
Message-ID: <20071028215853.GA1939@tango.0pointer.de>

On Sun, 28.10.07 17:41, Louis E Garcia II (louisg00 at bellsouth.net) wrote:

> This is rawhide as of 10/28
> 
> $ alsamixer
> *** PULSEAUDIO: Unable to connect: Connection refused
> 
> alsamixer: function snd_ctl_open failed for default: Connection refused

Due to some reason PulseAudio seems not to be running. Please make
sure that the "Enable ESD sound daemon" check box in
gnome-sound-properties is enabled. If PA fails to start or crashes,
please provide me with an output of "pulseaudio -vv".

Also, please file reports like this on bz instead of the ML.

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From louisg00 at bellsouth.net  Sun Oct 28 23:08:16 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 28 Oct 2007 19:08:16 -0400
Subject: something not right with sound
In-Reply-To: <1193607664.3674.2.camel@tiger>
References: <1193607664.3674.2.camel@tiger>
Message-ID: <1193612896.8864.6.camel@tiger>

On Sun, 2007-10-28 at 22:58:54 +0100, Lennart Poettering wrote:
> On Sun, 2007-10-28 at 17:41 -0400, Louis E Garcia II wrote:
> > This is rawhide as of 10/28
> 
> > $ alsamixer
> > *** PULSEAUDIO: Unable to connect: Connection refused
> > 
> > alsamixer: function snd_ctl_open failed for default: Connection refused
> Due to some reason PulseAudio seems not to be running. Please make
> sure that the "Enable ESD sound daemon" check box in
> gnome-sound-properties is enabled. If PA fails to start or crashes,
> please provide me with an output of "pulseaudio -vv".
> 
> Also, please file reports like this on bz instead of the ML.
> 
> Thanks,
> 
> Lennart

'Enable software sound mixing (ESD)' is checked 

$ pulseaudio -vv
E: main.c: Failed to create '/tmp/pulse-louisg00': Operation not permitted





From mzerqung at 0pointer.de  Sun Oct 28 23:17:04 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 29 Oct 2007 00:17:04 +0100
Subject: something not right with sound
In-Reply-To: <1193612896.8864.6.camel@tiger>
References: <1193607664.3674.2.camel@tiger> <1193612896.8864.6.camel@tiger>
Message-ID: <20071028231704.GA4947@tango.0pointer.de>

On Sun, 28.10.07 19:08, Louis E Garcia II (louisg00 at bellsouth.net) wrote:

> 
> 'Enable software sound mixing (ESD)' is checked 
> 
> $ pulseaudio -vv
> E: main.c: Failed to create '/tmp/pulse-louisg00': Operation not permitted

Hmm, so, what's up with that directory? Any idea why PA fails to
create it? Is your /tmp correctly set up?

Are you running SELinux in enforcing mode?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From louisg00 at bellsouth.net  Sun Oct 28 23:20:36 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 28 Oct 2007 19:20:36 -0400
Subject: something not right with sound
In-Reply-To: <1193612896.8864.6.camel@tiger>
References: <1193607664.3674.2.camel@tiger>  <1193612896.8864.6.camel@tiger>
Message-ID: <1193613636.9804.5.camel@tiger>

On Sun, 2007-10-28 at 19:08 -0400, Louis E Garcia II wrote:
> On Sun, 2007-10-28 at 22:58:54 +0100, Lennart Poettering wrote:
> > On Sun, 2007-10-28 at 17:41 -0400, Louis E Garcia II wrote:
> > > This is rawhide as of 10/28
> > 
> > > $ alsamixer
> > > *** PULSEAUDIO: Unable to connect: Connection refused
> > > 
> > > alsamixer: function snd_ctl_open failed for default: Connection refused
> > Due to some reason PulseAudio seems not to be running. Please make
> > sure that the "Enable ESD sound daemon" check box in
> > gnome-sound-properties is enabled. If PA fails to start or crashes,
> > please provide me with an output of "pulseaudio -vv".
> > 
> > Also, please file reports like this on bz instead of the ML.
> > 
> > Thanks,
> > 
> > Lennart
> 
> 'Enable software sound mixing (ESD)' is checked 
> 
> $ pulseaudio -vv
> E: main.c: Failed to create '/tmp/pulse-louisg00': Operation not permitted

ok I blew away everything in /tmp and logged back in. I am able to run
alsamixer now. Seems somewhere along the line /tmp got messed up. But I
don't see pulseaudio in ps -A. Should it be running?

On a side note, there was a lot of crap under /tmp. Should it be cleaned
up by itself? 

-Louis



From sundaram at fedoraproject.org  Mon Oct 29 00:01:02 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 29 Oct 2007 05:31:02 +0530
Subject: Custom derivative and generic-logos
Message-ID: <472522BE.6010801@fedoraproject.org>

Hi,

If I wanted to create a custom derivative of Fedora which includes the 
unbranded images from generic-logos, how do I go about doing that? The 
generic-logos has a explicit conflict with fedora-logos which is 
understandable but trying to remove fedora-logos gets me a long list of 
dependencies.

I could do a --nodeps which will likely work well but is there a cleaner 
way to do this without repackaging all the dependencies? Can we include 
a branding option to the remixing tools like livecd-creator, pungi and 
revisor to make this process easier?

Rahul



From myfedora at richip.dhs.org  Mon Oct 29 00:17:02 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sun, 28 Oct 2007 18:17:02 -0600
Subject: Rawhide to Release
Message-ID: <1193617022.25583.2.camel@localhost6.localdomain6>

I've got F8T3 running on one machine. I've run "yum update" on it so I'm
now assuming that I'm running current Rawhide. When F8 becomes final,
how do I transition that machine so that it becomes F8 from there on
(short of re-installing from scratch)?
--

Richi Plana



From dmc.fedora at filteredperception.org  Mon Oct 29 00:16:17 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 28 Oct 2007 19:16:17 -0500
Subject: Problem with the live ISOs and creating bootable
 USB	installation media?
In-Reply-To: <645d17210710271744g755b296av792a5620d27aaa2f@mail.gmail.com>
References: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>	<645d17210710271719w2b5a700fn5603faa7982f2727@mail.gmail.com>
	<645d17210710271744g755b296av792a5620d27aaa2f@mail.gmail.com>
Message-ID: <47252651.4060403@filteredperception.org>

Jonathan Underwood wrote:
> On 28/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
>> On 28/10/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
>>> So that works. It looks like  something changed with how the ISOs are
>>> structured such that the livecd-tools under F-7 are broken with the
>>> F-8 isos. This isn't good, as I think I'm describing what will be
>>> quite a common use case when F-8 is released (i.e. people wishing to
>>> create bootable F-8 sticks under F-7 in order to upgrade).
>> To answer my own question, the reason is that in the ISO as composed
>> from current Rawhide squashfs.img is now located in the LiveOS
>> subdirectory rather than in the root directory. I'll have a look at
>> pathing the livecd-tools script.
>>
> 
> Sorry to continue the monologue, but just to say I've added a patch to
> Bug #355541 to fix this.
> 


Looking at f8t3, it doesn't appear that livecd-iso-to-disk is on the 
desktop livecd.  Perhaps an alternate solution would be to split 
livecd-iso-to-disk away from livecd-tools, and have it in the desktop 
livecd.  While also putting it in the F7 updates repo.  I think the 
f8/git version of l-i-t-d already works without your patch, for both f7 
and f8 LiveISOs.

-dmc



From s0238762 at sms.ed.ac.uk  Mon Oct 29 00:21:08 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Mon, 29 Oct 2007 00:21:08 +0000
Subject: Rawhide to Release
In-Reply-To: <1193617022.25583.2.camel@localhost6.localdomain6>
References: <1193617022.25583.2.camel@localhost6.localdomain6>
Message-ID: <47252774.50307@sms.ed.ac.uk>

Richi Plana wrote:
> I've got F8T3 running on one machine. I've run "yum update" on it so I'm
> now assuming that I'm running current Rawhide. When F8 becomes final,
> how do I transition that machine so that it becomes F8 from there on
> (short of re-installing from scratch)?
> --
>
> Richi Plana
>
>   
that should answer your question:
http://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=46317&forum=11




From mzerqung at 0pointer.de  Mon Oct 29 00:24:48 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 29 Oct 2007 01:24:48 +0100
Subject: something not right with sound
In-Reply-To: <1193613636.9804.5.camel@tiger>
References: <1193607664.3674.2.camel@tiger> <1193612896.8864.6.camel@tiger>
	<1193613636.9804.5.camel@tiger>
Message-ID: <20071029002447.GA6357@tango.0pointer.de>

On Sun, 28.10.07 19:20, Louis E Garcia II (louisg00 at bellsouth.net) wrote:

> ok I blew away everything in /tmp and logged back in. I am able to run
> alsamixer now. Seems somewhere along the line /tmp got messed up. But I
> don't see pulseaudio in ps -A. Should it be running?

It might show up as process "exe". Yepp, it's a bit confusing and I
will fix this in early F9.

> On a side note, there was a lot of crap under /tmp. Should it be cleaned
> up by itself? 

Some distros do that with a cron job, others do not.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From dmc.fedora at filteredperception.org  Mon Oct 29 00:23:46 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Sun, 28 Oct 2007 19:23:46 -0500
Subject: Custom derivative and generic-logos
In-Reply-To: <472522BE.6010801@fedoraproject.org>
References: <472522BE.6010801@fedoraproject.org>
Message-ID: <47252812.4090507@filteredperception.org>

Rahul Sundaram wrote:


Can we include
> a branding option to the remixing tools like livecd-creator, pungi and 
> revisor to make this process easier?

 From a slightly wider perspective, what is really needed is a good set 
of documentation describing the prototypical hello-world example of 
using livecd-creator and/or pungi to roll a redistributable derivative 
distro.

With the aim of course to reduce the complexity to the most sensible 
minimal process.

-dmc



From myfedora at richip.dhs.org  Mon Oct 29 00:30:17 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sun, 28 Oct 2007 18:30:17 -0600
Subject: Rawhide to Release
In-Reply-To: <47252774.50307@sms.ed.ac.uk>
References: <1193617022.25583.2.camel@localhost6.localdomain6>
	<47252774.50307@sms.ed.ac.uk>
Message-ID: <1193617817.25583.4.camel@localhost6.localdomain6>

On Mon, 2007-10-29 at 00:21 +0000, Ioannis Nousias wrote:
> Richi Plana wrote:
> > I've got F8T3 running on one machine. I've run "yum update" on it so I'm
> > now assuming that I'm running current Rawhide. When F8 becomes final,
> > how do I transition that machine so that it becomes F8 from there on
> > (short of re-installing from scratch)?
> > --
> >
> > Richi Plana
> >
> >   
> that should answer your question:
> http://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=46317&forum=11

Ouch. Sorry I missed that. I saw the title but when I read the first
sentence assumed that they meant something else.

Thanks.
--

Richi Plana



From ngompa13 at gmail.com  Mon Oct 29 00:46:33 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Sun, 28 Oct 2007 19:46:33 -0500
Subject: Zimbra packages in Fedora
Message-ID: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>

I had noticed how well that Zimbra has been doing, and I was wondering if it
would be possible for someone to make packages for Zimbra to be included in
Fedora?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071028/08528c8d/attachment.htm>

From mike at miketc.com  Mon Oct 29 03:32:55 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 28 Oct 2007 22:32:55 -0500
Subject: On Board video vs AGP/PCI
In-Reply-To: <20071028193337.3ff475e1@lain.camperquake.de>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
	<20071028193337.3ff475e1@lain.camperquake.de>
Message-ID: <1193628775.15414.2.camel@scrappy.miketc.com>

On Sun, 2007-10-28 at 19:33 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Sun, 28 Oct 2007 08:55:13 -0500, Mike Chambers wrote
> > I have an ATI 1300 card via agp, and am thinking of using my on board
> > video.
> 
> Usually the on-board video chip is attached to the AGP bus, also,
> and thus gets disabled as soon as you put in a "real" AGP card.

I'll maybe try removing the card tomorrow, and will report back with
what happens.  Thanks for the tip.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Mon Oct 29 04:24:43 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 28 Oct 2007 23:24:43 -0500
Subject: On Board video vs AGP/PCI
In-Reply-To: <1193628775.15414.2.camel@scrappy.miketc.com>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
	<20071028193337.3ff475e1@lain.camperquake.de>
	<1193628775.15414.2.camel@scrappy.miketc.com>
Message-ID: <1193631883.2515.3.camel@scrappy.miketc.com>

On Sun, 2007-10-28 at 22:32 -0500, Mike Chambers wrote:
> On Sun, 2007-10-28 at 19:33 +0100, Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Sun, 28 Oct 2007 08:55:13 -0500, Mike Chambers wrote
> > > I have an ATI 1300 card via agp, and am thinking of using my on board
> > > video.
> > 
> > Usually the on-board video chip is attached to the AGP bus, also,
> > and thus gets disabled as soon as you put in a "real" AGP card.
> 
> I'll maybe try removing the card tomorrow, and will report back with
> what happens.  Thanks for the tip.

Welp, it worked fine, so all is well in that regards.  Although, even
did this some with my ATI card, it seems around the middle of my monitor
it gets a little blurry and I can't get rid of it.  I think my monitor
is going bad, as unless I use like 800x600 or something big like that,
it does it on most resolutions.  Did it on Windows to if I remember, so
guess might mean new monitor.

Heh, hope widescreen LCD monitors, or whatever are cheap at Walmart.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From igknighted at gmail.com  Mon Oct 29 04:28:06 2007
From: igknighted at gmail.com (Daniel Fitzgibbons)
Date: Mon, 29 Oct 2007 00:28:06 -0400
Subject: On Board video vs AGP/PCI
In-Reply-To: <1193631883.2515.3.camel@scrappy.miketc.com>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
	<20071028193337.3ff475e1@lain.camperquake.de>
	<1193628775.15414.2.camel@scrappy.miketc.com>
	<1193631883.2515.3.camel@scrappy.miketc.com>
Message-ID: <1c847b0710282128k5dd4d5d0wf0e62110db18f325@mail.gmail.com>

Much cheaper if you buy online, newegg.com and tigerdirect.com are usually
at least $50 cheaper than even walmart when it comes to displays.

On 10/29/07, Mike Chambers <mike at miketc.com> wrote:
>
> On Sun, 2007-10-28 at 22:32 -0500, Mike Chambers wrote:
> > On Sun, 2007-10-28 at 19:33 +0100, Ralf Ertzinger wrote:
> > > Hi.
> > >
> > > On Sun, 28 Oct 2007 08:55:13 -0500, Mike Chambers wrote
> > > > I have an ATI 1300 card via agp, and am thinking of using my on
> board
> > > > video.
> > >
> > > Usually the on-board video chip is attached to the AGP bus, also,
> > > and thus gets disabled as soon as you put in a "real" AGP card.
> >
> > I'll maybe try removing the card tomorrow, and will report back with
> > what happens.  Thanks for the tip.
>
> Welp, it worked fine, so all is well in that regards.  Although, even
> did this some with my ATI card, it seems around the middle of my monitor
> it gets a little blurry and I can't get rid of it.  I think my monitor
> is going bad, as unless I use like 800x600 or something big like that,
> it does it on most resolutions.  Did it on Windows to if I remember, so
> guess might mean new monitor.
>
> Heh, hope widescreen LCD monitors, or whatever are cheap at Walmart.
>
> --
> Mike Chambers
> Madisonville, KY
>
> "Best lil town on Earth!"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/ddf44f40/attachment.htm>

From mike at miketc.com  Mon Oct 29 04:31:50 2007
From: mike at miketc.com (Mike Chambers)
Date: Sun, 28 Oct 2007 23:31:50 -0500
Subject: On Board video vs AGP/PCI
In-Reply-To: <1c847b0710282128k5dd4d5d0wf0e62110db18f325@mail.gmail.com>
References: <1193579713.14059.5.camel@scrappy.miketc.com>
	<20071028193337.3ff475e1@lain.camperquake.de>
	<1193628775.15414.2.camel@scrappy.miketc.com>
	<1193631883.2515.3.camel@scrappy.miketc.com>
	<1c847b0710282128k5dd4d5d0wf0e62110db18f325@mail.gmail.com>
Message-ID: <1193632310.3139.1.camel@scrappy.miketc.com>

On Mon, 2007-10-29 at 00:28 -0400, Daniel Fitzgibbons wrote:
> Much cheaper if you buy online, newegg.com and tigerdirect.com are
> usually at least $50 cheaper than even walmart when it comes to
> displays.

Well, currently work there part-time, so that is why, and can certain %
off as well.  BUT, I just changed my video from sis (that is the
motherboard), to vesa, and it cleared up some.  So wondering if both
drivers and/or both cards themselves are doing this (maybe a lil with
monitor as well)?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From choeger at cs.tu-berlin.de  Mon Oct 29 06:22:46 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-1?Q?Christoph_H=F6ger?=)
Date: Mon, 29 Oct 2007 07:22:46 +0100
Subject: Fedorability of dvbcut ?
In-Reply-To: <20071028153047.GC23359@auslistsprd01.us.dell.com>
References: <47248975.7050901@iinet.net.au>
	<20071028153047.GC23359@auslistsprd01.us.dell.com>
Message-ID: <47257C36.9060607@cs.tu-berlin.de>

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

Matt Domsch schrieb:
> On Mon, Oct 29, 2007 at 12:07:01AM +1100, David Timms wrote:
>> I'm keen to repackage dvbcut for Fedora.
>> http://dvbcut.sourceforge.net/installation.html
>> The application can be used to trim up a mpeg2 transport stream for 
>> example recorded from a DVB tuner card, and output in mpeg2 program 
>> stream format.
>>
>> As packaged in packman, it warns:
>> - qt3 is needed by dvbcut-0.5.4-0.pm.0.i586
>> - libffmpeg0 is needed by dvbcut-0.5.4-0.pm.0.i586
>> It can also use mplayer, and finds this through name within your path, 
>> ie it is not actually required for the program to run.
>> With ffmpeg and mplayer installed, a rpm -Uvh --nodeps allows it to run 
>> fine.
>>
>> It's main function is the conversion from transport stream to program 
>> stream of given selections, however, it does recode frames at the start 
>> and end of each clip.
>>
>> So given the linking {I think} of ffmpeg, and the need for easiest use 
>> of having mplayer installed, am I correct in assuming this will be no go 
>> in FedoraPC ?
> 
> ffmpeg is patent-encumbered, thus no-go in Fedora.  If your
> application can use other codecs that are free and are included in
> Fedora (e.g. Ogg Theora), but may also use ffmpeg if present, then
> it could fit.
> 

As dvb is probably always mpeg2 there won't be a free codec, but I think
 it should not depend on a codec nor decode-library as videoplayers
don't do that too. At least it could work with 3rd party stuff.
If that does not fit fedoras needs (if distributed software must be
usable) you would have to try 3rd party repos.

>> And if that's the case, how does the included kernel module for 
>> controlling / receiving mpeg2 transport streams from my DVB card fit 
>> with Fedora ?
> 
> The hardware manufacturer will have a patent license that allows them
> to use mpeg2.  That same patent license most likely does not extend to you
> as an end user for use outside of their hardware.
> 

As far as I know there is no mpeg2 decoding done in a dvb driver (it
will probably come from videolinux rather then from the hw-mf.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHJXw2hMBO4cVSGS8RApBNAJ9TqEEsL6e2x/gNlYE3fE5Q/WYkWQCePCTD
5rltfo8ZFdanX0T3y9BsDnY=
=d2P5
-----END PGP SIGNATURE-----



From choeger at cs.tu-berlin.de  Mon Oct 29 06:25:46 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-1?Q?Christoph_H=F6ger?=)
Date: Mon, 29 Oct 2007 07:25:46 +0100
Subject: Fedorability of dvbcut ?
In-Reply-To: <20071028153047.GC23359@auslistsprd01.us.dell.com>
References: <47248975.7050901@iinet.net.au>
	<20071028153047.GC23359@auslistsprd01.us.dell.com>
Message-ID: <47257CEA.8050608@cs.tu-berlin.de>

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

Matt Domsch schrieb:
> On Mon, Oct 29, 2007 at 12:07:01AM +1100, David Timms wrote:
>> I'm keen to repackage dvbcut for Fedora.
>> http://dvbcut.sourceforge.net/installation.html
>> The application can be used to trim up a mpeg2 transport stream for 
>> example recorded from a DVB tuner card, and output in mpeg2 program 
>> stream format.
>>
>> As packaged in packman, it warns:
>> - qt3 is needed by dvbcut-0.5.4-0.pm.0.i586
>> - libffmpeg0 is needed by dvbcut-0.5.4-0.pm.0.i586
>> It can also use mplayer, and finds this through name within your path, 
>> ie it is not actually required for the program to run.
>> With ffmpeg and mplayer installed, a rpm -Uvh --nodeps allows it to run 
>> fine.
>>
>> It's main function is the conversion from transport stream to program 
>> stream of given selections, however, it does recode frames at the start 
>> and end of each clip.
>>
>> So given the linking {I think} of ffmpeg, and the need for easiest use 
>> of having mplayer installed, am I correct in assuming this will be no go 
>> in FedoraPC ?
> 
> ffmpeg is patent-encumbered, thus no-go in Fedora.  If your
> application can use other codecs that are free and are included in
> Fedora (e.g. Ogg Theora), but may also use ffmpeg if present, then
> it could fit.
> 

As dvb is probably always mpeg2 there won't be a free codec, but I think
 it should not depend on a codec nor decode-library as videoplayers
don't do that too. At least it could work with 3rd party stuff.
If that does not fit fedoras needs (if distributed software must be
usable) you would have to try 3rd party repos.

>> And if that's the case, how does the included kernel module for 
>> controlling / receiving mpeg2 transport streams from my DVB card fit 
>> with Fedora ?
> 
> The hardware manufacturer will have a patent license that allows them
> to use mpeg2.  That same patent license most likely does not extend to you
> as an end user for use outside of their hardware.
> 

As far as I know there is no mpeg2 decoding done in a dvb driver (it
will probably come from videolinux rather then from the hw-mf.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHJXw2hMBO4cVSGS8RApBNAJ9TqEEsL6e2x/gNlYE3fE5Q/WYkWQCePCTD
5rltfo8ZFdanX0T3y9BsDnY=
=d2P5
-----END PGP SIGNATURE-----



From opensource at till.name  Mon Oct 29 07:27:23 2007
From: opensource at till.name (Till Maas)
Date: Mon, 29 Oct 2007 08:27:23 +0100
Subject: Package XYZ is not signed
In-Reply-To: <4724F3B9.4010608@lordmorgul.net>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193592127.7011.4.camel@sb-home> <4724F3B9.4010608@lordmorgul.net>
Message-ID: <200710290827.28648.opensource@till.name>

On So Oktober 28 2007, Andrew Farris wrote:

> prevent that either (in rawhide).  Testing rawhide isn't for boxes with
> corporate sensitive data...

This seems not to be common knowledge, because afaik even Fedora Maintainers 
use Rawhide on a system, where they create new packages.

> Actually signing the package from the build system would change very little
> other than insure that the mirror you're downloading from did not bring in
> a new package that doesn't belong.

Imho it is a big benefit, because it is very easy for a mirror maintainer to 
change a package. Also someone who breaks into a mirror can easily cause 
heavy damage. And last but not least, the manipulation of the package can 
also happen on the connection to the mirror, e.g. on conferences with 
free/open wifi/internet access.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/6b8ba516/attachment.sig>

From oliver at linux-kernel.at  Mon Oct 29 07:44:54 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Mon, 29 Oct 2007 08:44:54 +0100
Subject: koji server installation
In-Reply-To: <1193334499.21338.6.camel@localhost.localdomain>
References: <4717675F.6000608@codewiz.org>
	<471768A7.3000800@codewiz.org>	<1192719967.3358.6.camel@burren.boston.redhat.com>
	<1193334499.21338.6.camel@localhost.localdomain>
Message-ID: <47258F76.8040004@linux-kernel.at>

On 10/25/2007 07:48 PM, Mike Bonnet wrote:
> On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
>> In terms of your other problems, you need to to bootstrap Koji by
>> importing a bunch of pre-built packages so Koji is able to populate a
>> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
>> guide, I'll point you at it when it's posted.
> 
> I've put up a setup/bootstrapping guide here:
> 
> https://fedoraproject.org/wiki/Koji/ServerBootstrap
> 
> and linked it from the bottom of the ServerHowTo.  Give it a try and let
> me know if you run into problems or have suggestions on how to improve
> the guide.

Much the same like mine, but more complete and added 'features' like the
bypass stuff!

Good work!

-of



From oliver at linux-kernel.at  Mon Oct 29 07:44:54 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Mon, 29 Oct 2007 08:44:54 +0100
Subject: koji server installation
In-Reply-To: <1193334499.21338.6.camel@localhost.localdomain>
References: <4717675F.6000608@codewiz.org>
	<471768A7.3000800@codewiz.org>	<1192719967.3358.6.camel@burren.boston.redhat.com>
	<1193334499.21338.6.camel@localhost.localdomain>
Message-ID: <47258F76.8040004@linux-kernel.at>

On 10/25/2007 07:48 PM, Mike Bonnet wrote:
> On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
>> In terms of your other problems, you need to to bootstrap Koji by
>> importing a bunch of pre-built packages so Koji is able to populate a
>> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
>> guide, I'll point you at it when it's posted.
> 
> I've put up a setup/bootstrapping guide here:
> 
> https://fedoraproject.org/wiki/Koji/ServerBootstrap
> 
> and linked it from the bottom of the ServerHowTo.  Give it a try and let
> me know if you run into problems or have suggestions on how to improve
> the guide.

Much the same like mine, but more complete and added 'features' like the
bypass stuff!

Good work!

-of



From stransky at redhat.com  Mon Oct 29 07:54:32 2007
From: stransky at redhat.com (Martin Stransky)
Date: Mon, 29 Oct 2007 08:54:32 +0100
Subject: ALSA 1.0.15 update test kernels available - user space packages
In-Reply-To: <1193423556.3113.3.camel@perihelion>
References: <47210BB2.3040201@redhat.com> <1193423556.3113.3.camel@perihelion>
Message-ID: <472591B8.10303@redhat.com>

Jon Masters wrote:
> On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
>> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
>> would get us up-to-date with the latest audio drivers and fix many
>> problems with audio drivers not working, or only partially working.
>>
>> Test kernels for i686 and x86_64 are available at:
>>
>>   http://people.redhat.com/cebbert/kernels/F8/
>>

User space packages (alsa 1.0.15) are here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=22679
http://koji.fedoraproject.org/koji/buildinfo?buildID=22680

If the updated kernel is included in F8 please add them there, too.

ma.



From nicolas.mailhot at laposte.net  Mon Oct 29 08:26:01 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Oct 2007 09:26:01 +0100 (CET)
Subject: Package XYZ is not signed
Message-ID: <38509.192.54.193.51.1193646361.squirrel@rousalka.dyndns.org>


Le Lun 29 octobre 2007 08:27, Till Maas a ?crit :
> On So Oktober 28 2007, Andrew Farris wrote:
>
>> prevent that either (in rawhide).  Testing rawhide isn't for boxes
>> with
>> corporate sensitive data...
>
> This seems not to be common knowledge, because afaik even Fedora
> Maintainers use Rawhide on a system, where they create new packages.

And it's totally unrealistic because the only people who're going to
sit before a test box without real data are people paid for testing
(ie not community contributors).

You can't have it both ways - either you pay people to do testing on
fake safe data (very expensive), or you have volunteers testing on
their own systems (with their own data), and you have to work a
minimum so you only eat this data in very rare cases.

>> Actually signing the package from the build system would change very
>> little
>> other than insure that the mirror you're downloading from did not
>> bring in
>> a new package that doesn't belong.
>
> Imho it is a big benefit,

And even kernel.org does it so anyone who feels autosigning packages
before uploading to the root mirrors is "unprofessional" can complain
on LKML and get educated :).

Regards,

-- 
Nicolas Mailhot



From tomek at crocom.com.pl  Mon Oct 29 10:04:31 2007
From: tomek at crocom.com.pl (Tomasz Torcz)
Date: Mon, 29 Oct 2007 11:04:31 +0100
Subject: nautilus/GNOME VFS ACL support capabilities?
In-Reply-To: <1193298155.3393.85.camel@perihelion>
References: <1193298155.3393.85.camel@perihelion>
Message-ID: <1193652271.19214.0.camel@s1.crocom.com.pl>

Dnia 25-10-2007, Cz o godzinie 03:42 -0400, Jon Masters napisa?(a):
> Yo,
> 
> Rather than sleeping, I was just looking at a few capabilities currently
> in F8 and thinking about what would be nice in the future.
> 
> Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
> to understand ACLs. Am I missing something? Heck, I remember 5 or 6
> years ago patching in the original ACL patches from bestbits and even
> setting ACLs remotely from a Windows machine using Samba, by right
> clicking on the export files. Does this not work in nautilus?

  Nautilus in Solaris 10 has ACL support. I don't know if patches were
submitted upstream.


-- 
Tomasz Torcz
Crocom Computer Systems



From buildsys at redhat.com  Mon Oct 29 10:20:07 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 29 Oct 2007 06:20:07 -0400
Subject: rawhide report: 20071029 changes
Message-ID: <200710291020.l9TAK7lx029452@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-11.3.0.48-1
--------------------
* Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.48-1
- Fix docs location (#356021) 
- Live images don't have xfsprogs by default, so look for xfsprogs before 
  allowing xfs as a filesystem (#355351)
- Don't show bridge devices (#354561)

bluez-utils-3.20-4.fc8
----------------------
* Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 3.20-4
- Follow guidelines for scriplets to quiet error (#354531)

compiz-fusion-0.6.0-5.fc8
-------------------------
* Sun Oct 28 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-5
- Rediff patch

* Sun Oct 28 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-4
- Fix previous patch

* Sat Oct 27 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-3
- Apply patch from upstream to fix RH #354601

gnokii-0.6.18-3.fc8
-------------------
* Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
- Even better multilib fixing (#335161)

libsoup-2.2.103-1.fc8
---------------------
* Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 2.2.103-1
- update to 2.2.103 to fix a rhythmbox crasher (#343561)

* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 2.2.102-1
- Update to 2.2.102

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From thomas at apestaart.org  Mon Oct 29 10:42:34 2007
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Mon, 29 Oct 2007 11:42:34 +0100
Subject: hibernation
Message-ID: <1193654555.16185.1.camel@level.fluendo.lan>

Hi,

is hibernation working for other people currently ?

I installed test3 on my new T61, and am running 2.6.23.1-35.fc8, but
when I choose "hibernate" from the logout menu, it hibernates just fine,
and goes to sleep, but on the next boot it just boots the kernel without
restoring state.  This worked fine in F7.

If it's me and not a general problem, how do I debug it further ? Is
there some docs on how this is supposed to be working in Fedora ?

Thomas




From ml at deadbabylon.de  Mon Oct 29 10:48:03 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Mon, 29 Oct 2007 11:48:03 +0100
Subject: Possibility of inclusion of a "kde-desktop-effects" version in
	compiz
In-Reply-To: <fg038s$h3p$1@ger.gmane.org>
References: <200710260000.24041.ml@deadbabylon.de> <fg038s$h3p$1@ger.gmane.org>
Message-ID: <200710291148.08565.ml@deadbabylon.de>

Am Sa 27.Oktober 2007 schrieb Neal Becker:
> Thanks.  I grabbed compiz-manager.  It needs minor fixes for x86_64.
>
> All /usr/lib needs to be /usr/lib64 on x86_64.

This was also an issue in the review process and is fixed now (in the latest 
srpm which was approved).

Sebastian
-------------- 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/20071029/55d8e07a/attachment.sig>

From caillon at redhat.com  Mon Oct 29 10:52:53 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 29 Oct 2007 11:52:53 +0100
Subject: Firefox backspace button action should be "Previous Page" not
 "Page	Up"
In-Reply-To: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
Message-ID: <4725BB85.9000706@redhat.com>

Mark wrote:
> Hey,
> 
> i was just wondering why Firefox had page up action bound to the
> backspace button. and i end up reading this bug report:
> https://bugzilla.mozilla.org/show_bug.cgi?id=358764
> 
> Now the default action for Firefox in fedora is "page up" and i think
> nearly every keyboard in the world _has_ a page up key so please
> remove that silly default action. A patch for this to give the
> backspace the "previous page" (or whatever you want to call it) action
> is very simple:
> 
> type (in the address bar): about:config
> find: browser.backspace_action
> The value is likely to be on: 1. Change that value to 0 and backspace
> is acting the way it should do.
> 
> I don't know where firefox is getting the "logic" to make firefox
> default backspace action "previous page" in windows and "page up" in
> linux.. just doesn't make sense to me.
> 
> And could this be patched in the firefox that is in the fedora repo?
> or (if fedora chooses not to patch it to the "previous page" action)
> than make it no action at all!! "page up" is just not good.
> 
> Bigzilla: https://bugzilla.redhat.com/show_bug.cgi?id=355511
> 
> Posted here because i would like to know the users and developer
> opinions about this.
> 

Authoritatively, the action for backspace should be to do nothing on 
Linux.  This was discussed with the GNOME usability guy, Sun, Novell, 
and Mozilla a bit ago and was checked in as per the bug you posted.  It 
appears that it is still not in the 2.x branch though other distros such 
have patched it in, with a quick glance.

I guess having had this set in my local preferences for ages, I sort of 
forgot about it in the 2.x branch.  I am okay with turning this pref to 
do nothing even though it will be last minute as this is what upstream 
has decided and will be in future versions of Firefox as it best matches 
the platform convention.



From j.w.r.degoede at hhs.nl  Mon Oct 29 10:43:19 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 29 Oct 2007 11:43:19 +0100
Subject: rawhide report: 20071029 changes
In-Reply-To: <200710291020.l9TAK7lx029452@porkchop.devel.redhat.com>
References: <200710291020.l9TAK7lx029452@porkchop.devel.redhat.com>
Message-ID: <4725B947.7070706@hhs.nl>

Build System wrote:
>  
> 
>  
> Updated Packages:
> 
> gnokii-0.6.18-3.fc8
> -------------------
> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
> - Even better multilib fixing (#335161)
> 

How does this match with us being in freeze?

Regards,

Hans



From sundaram at fedoraproject.org  Mon Oct 29 11:03:34 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 29 Oct 2007 16:33:34 +0530
Subject: rawhide report: 20071029 changes
In-Reply-To: <4725B947.7070706@hhs.nl>
References: <200710291020.l9TAK7lx029452@porkchop.devel.redhat.com>
	<4725B947.7070706@hhs.nl>
Message-ID: <4725BE06.4030900@fedoraproject.org>

Hans de Goede wrote:
> Build System wrote:
>>  
>>
>>  
>> Updated Packages:
>>
>> gnokii-0.6.18-3.fc8
>> -------------------
>> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
>> - Even better multilib fixing (#335161)
>>
> 
> How does this match with us being in freeze?

The bug in question has been marked as a blocker.

Rahul



From drago01 at gmail.com  Mon Oct 29 11:06:36 2007
From: drago01 at gmail.com (dragoran)
Date: Mon, 29 Oct 2007 12:06:36 +0100
Subject: rawhide report: 20071029 changes
In-Reply-To: <4725B947.7070706@hhs.nl>
References: <200710291020.l9TAK7lx029452@porkchop.devel.redhat.com>
	<4725B947.7070706@hhs.nl>
Message-ID: <4725BEBC.1000009@gmail.com>

Hans de Goede wrote:
> Build System wrote:
>>  
>>
>>  
>> Updated Packages:
>>
>> gnokii-0.6.18-3.fc8
>> -------------------
>> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
>> - Even better multilib fixing (#335161)
>>
>
> How does this match with us being in freeze?
>
that was a blocker:

--------------------------------

* Bug 335161: ASSIGNED - triad (Linus Walleij)
- multilib file conflicts in gnokii

Fix was incomplete, needs a rebuild. This prevents people from being
able to yum upgrade from F8Test3 to F8 final. 
----------------

or are you talking about the "better fix" ?




From laroche at redhat.com  Mon Oct 29 12:30:46 2007
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 29 Oct 2007 13:30:46 +0100
Subject: dangling symlinks in rpm packages for Fedora-devel
Message-ID: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>

Hello all,

here the output of a test script that checks all rpm packages
for dangling symlinks. It does not look at an installed system,
but only at files included within rpm packages, so there are
a few false reports here for files/dirs created within scripts.

Output is against a current Fedora-devel tree. I welcome help to
review this list, so remaining items can be looked at during the
F9 devel phase.

regards,

Florian La Roche



Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier to /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier-Bold to /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed-Bold.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier-BoldOblique to /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier-Oblique to /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed-Oblique.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Helvetica to /usr/share/fonts/dejavu-fonts/DejaVuSans.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Helvetica-Bold to /usr/share/fonts/dejavu-fonts/DejaVuSans-Bold.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Helvetica-BoldOblique to /usr/share/fonts/dejavu-fonts/DejaVuSans.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Helvetica-Oblique to /usr/share/fonts/dejavu-fonts/DejaVuSans-Oblique.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Times-Roman to /usr/share/fonts/dejavu-fonts/DejaVuSerif.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-Bold to /usr/share/fonts/dejavu-fonts/DejaVuSerif-Bold.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-BoldItalic to /usr/share/fonts/dejavu-fonts/DejaVuSerif-BoldOblique.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-Italic to /usr/share/fonts/dejavu-fonts/DejaVuSerif-Oblique.ttf
Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-Regular to /usr/share/fonts/dejavu-fonts/DejaVuSerif.ttf
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/doc/docbook-xsl.css to /usr/share/doc/asciidoc-8.2.2/stylesheets/docbook-xsl.css
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/doc/images to /usr/share/doc/asciidoc-8.2.2/images
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/ASCIIMathML.js to /usr/share/doc/asciidoc-8.2.2/javascripts/ASCIIMathML.js
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/CHANGELOG.txt to /usr/share/doc/asciidoc-8.2.2/CHANGELOG.txt
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/INSTALL.txt to /usr/share/doc/asciidoc-8.2.2/INSTALL.txt
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/LaTeXMathML.js to /usr/share/doc/asciidoc-8.2.2/javascripts/LaTeXMathML.js
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/README.txt to /usr/share/doc/asciidoc-8.2.2/README.txt
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/asciidoc-docbook-xsl.txt to /usr/share/doc/asciidoc-8.2.2/docbook-xsl/asciidoc-docbook-xsl.txt
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/images to /usr/share/doc/asciidoc-8.2.2/images
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/toc.js to /usr/share/doc/asciidoc-8.2.2/javascripts/toc.js
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/xhtml11-manpage.css to /usr/share/doc/asciidoc-8.2.2/stylesheets/xhtml11-manpage.css
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/xhtml11-quirks.css to /usr/share/doc/asciidoc-8.2.2/stylesheets/xhtml11-quirks.css
asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/xhtml11.css to /usr/share/doc/asciidoc-8.2.2/stylesheets/xhtml11.css
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/16x16/actions/gtk-ok.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/actions/dialog-ok.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/16x16/apps/icon-systemhealth.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/apps/utilities-system-monitor.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/16x16/categories/icon-web-browser.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/categories/applications-internet.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/22x22/categories/icon-web-browser.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/22x22/categories/applications-internet.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/24x24/actions/gtk-ok.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/24x24/actions/dialog-ok.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/24x24/categories/icon-web-browser.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/24x24/categories/applications-internet.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/32x32/categories/icon-web-browser.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/32x32/categories/applications-internet.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/48x48/actions/gtk-ok.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/48x48/actions/dialog-ok.png
echo-icon-theme has dangling symlink from /usr/share/icons/Echo/48x48/categories/icon-web-browser.png to /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/48x48/categories/applications-internet.png
freenx has dangling symlink from /var/lib/nxserver/home/.ssh/authorized_keys to /etc/nxserver/server.id_dsa.pub.key
grace has dangling symlink from /etc/X11/fontpath.d/grace-type1 to /usr/share/grace/type1
httpunit-doc has dangling symlink from /usr/share/doc/httpunit-doc-1.6.2/api to /usr/share/javadoc/httpunit-1.6.2
jakarta-commons-dbcp has dangling symlink from /usr/share/java/hibernate_jdbc_cache.jar to /etc/alternatives/hibernate_jdbc_cache
kdebluetooth has dangling symlink from /usr/share/doc/HTML/ca/kdebluetooth/common to /usr/share/doc/HTML/ca/common
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnadded.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnadded.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnconflicted.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnconflicted.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvndeleted.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvndeleted.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnlocked.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnlocked.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnmodified.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnmodified.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnneedlock.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnneedlock.png
kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-filesys-kdesvnupdates.png to /usr/share/doc/HTML/src/pics/hi128-filesys-kdesvnupdates.png
keurocalc has dangling symlink from /usr/share/doc/HTML/nb/keurocalc/common to /usr/share/doc/HTML/nb/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/karbon/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kchart/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kexi/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kformula/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kivio/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/koffice/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/koshell/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kplato/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kpresenter/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/krita/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kspread/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kugar/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/kword/common to /usr/share/doc/HTML/ca/common
koffice-langpack-ca has dangling symlink from /usr/share/doc/HTML/ca/thesaurus/common to /usr/share/doc/HTML/ca/common
koffice-langpack-gl has dangling symlink from /usr/share/doc/HTML/gl/karbon/common to /usr/share/doc/HTML/gl/common
koffice-langpack-gl has dangling symlink from /usr/share/doc/HTML/gl/kchart/common to /usr/share/doc/HTML/gl/common
koffice-langpack-gl has dangling symlink from /usr/share/doc/HTML/gl/koffice/common to /usr/share/doc/HTML/gl/common
koffice-langpack-gl has dangling symlink from /usr/share/doc/HTML/gl/koshell/common to /usr/share/doc/HTML/gl/common
koffice-langpack-gl has dangling symlink from /usr/share/doc/HTML/gl/thesaurus/common to /usr/share/doc/HTML/gl/common
kpowersave has dangling symlink from /usr/share/doc/HTML/cs/kpowersave/common to /usr/share/doc/HTML/cs/common
kpowersave has dangling symlink from /usr/share/doc/HTML/fi/kpowersave/common to /usr/share/doc/HTML/fi/common
kpowersave has dangling symlink from /usr/share/doc/HTML/hu/kpowersave/common to /usr/share/doc/HTML/hu/common
kpowersave has dangling symlink from /usr/share/doc/HTML/nb/kpowersave/common to /usr/share/doc/HTML/nb/common
libextractor-plugins-thumbnailgtk has dangling symlink from /usr/lib/libextractor/libextractor-thumbnail.so to /usr/lib/libextractor/dummy
libextractor-plugins-thumbnailqt has dangling symlink from /usr/lib/libextractor/libextractor-thumbnail.so to /usr/lib/libextractor/dummy
mantis has dangling symlink from /usr/share/mantis/mantis_offline.php to /etc/mantis/mantis_offline.php
pinentry has dangling symlink from /usr/bin/pinentry to /etc/alternatives/pinentry
pinentry-gtk has dangling symlink from /usr/bin/pinentry to /etc/alternatives/pinentry
pinentry-qt has dangling symlink from /usr/bin/pinentry to /etc/alternatives/pinentry
stellarium has dangling symlink from /usr/bin/stellarium-wrapper to /usr/bin/opengl-game-wrapper
strigi-libs has dangling symlink from /usr/lib/strigi/strigila_cpp.so to /usr/lib/strigi/strigila_cpp.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigila_deb.so to /usr/lib/strigi/strigila_deb.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigila_namespaceharvester.so to /usr/lib/strigi/strigila_namespaceharvester.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigila_xpm.so to /usr/lib/strigi/strigila_xpm.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigita_au.so to /usr/lib/strigi/strigita_au.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigita_gif.so to /usr/lib/strigi/strigita_gif.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigita_pcx.so to /usr/lib/strigi/strigita_pcx.so.0
strigi-libs has dangling symlink from /usr/lib/strigi/strigita_xbm.so to /usr/lib/strigi/strigita_xbm.so.0
tetex-fonts-hebrew has dangling symlink from /usr/share/texmf/fonts/afm/public/culmus to /usr/share/fonts/hebrew
tetex-fonts-hebrew has dangling symlink from /usr/share/texmf/fonts/type1/public/culmus to /usr/share/fonts/hebrew
util-vserver has dangling symlink from /etc/vservers/.defaults/vdirbase to /vservers
xorg-x11-fonts-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-ISO8859-1-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-ISO8859-1-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-ISO8859-14-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-ISO8859-14-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-ISO8859-15-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-ISO8859-15-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-ISO8859-2-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-ISO8859-2-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-ISO8859-9-100dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to /usr/share/X11/fonts/100dpi:unscaled
xorg-x11-fonts-ISO8859-9-75dpi has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to /usr/share/X11/fonts/75dpi:unscaled
xorg-x11-fonts-misc has dangling symlink from /etc/X11/fontpath.d/xorg-x11-fonts-misc:unscaled:pri=10 to /usr/share/X11/fonts/misc:unscaled



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct 29 12:38:47 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 29 Oct 2007 13:38:47 +0100
Subject: EPEL report week 43 2007
In-Reply-To: <4724ECEE.6080508@leemhuis.info>
References: <4724ECEE.6080508@leemhuis.info>
Message-ID: <20071029133847.3d43a32b.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 28 Oct 2007 21:11:26 +0100, Thorsten Leemhuis wrote:

>  * lots of packages in epel5 were moved from testing to the proper repo;
> see
> [https://www.redhat.com/archives/epel-devel-list/2007-October/msg00045.html
> this thread] for some details

Do "cvs up Config_EPEL.py" on the buildsys master to be able to define
in the repoprune_keepdict how many pkgs to keep in the testing repos.

For a very long time we've relied on the old defaults only: keep=1 for
development, keep=2 for stable repos, plus the kmod whitelists. So
for EPEL it has been keep=2 for *all* repos so far.



From kevin.kofler at chello.at  Mon Oct 29 12:46:17 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 29 Oct 2007 12:46:17 +0000 (UTC)
Subject: dangling symlinks in rpm packages for Fedora-devel
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
Message-ID: <loom.20071029T124337-844@post.gmane.org>

Florian La Roche <laroche <at> redhat.com> writes:
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_cpp.so 
to /usr/lib/strigi/strigila_cpp.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_deb.so 
to /usr/lib/strigi/strigila_deb.so.0
> strigi-libs has dangling symlink 
from /usr/lib/strigi/strigila_namespaceharvester.so 
to /usr/lib/strigi/strigila_namespaceharvester.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_xpm.so 
to /usr/lib/strigi/strigila_xpm.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_au.so 
to /usr/lib/strigi/strigita_au.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_gif.so 
to /usr/lib/strigi/strigita_gif.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_pcx.so 
to /usr/lib/strigi/strigita_pcx.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_xbm.so 
to /usr/lib/strigi/strigita_xbm.so.0

Ouch, these are really bad. I don't understand what's going on here. These are 
not supposed to be symlinks, they are supposed to be loadable plugins, and in 
the F7 RPM which is built from the same specfile, they are. How they get 
replaced with symlinks not pointing to anywhere is a mystery to me. Maybe a 
cmake bug? Or some other toolchain component?

        Kevin Kofler



From nicolas.mailhot at laposte.net  Mon Oct 29 12:47:22 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 29 Oct 2007 13:47:22 +0100 (CET)
Subject: dangling symlinks in rpm packages for Fedora-devel
Message-ID: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>


Le Lun 29 octobre 2007 13:30, Florian La Roche a ?crit :

Hi,

> here the output of a test script that checks all rpm packages
> for dangling symlinks. It does not look at an installed system,
> but only at files included within rpm packages, so there are
> a few false reports here for files/dirs created within scripts.

For each package the correct way to test would be to create a fake
root with all package deps installed and check if there are dangling
symlinks then. It looks like quite a few of your "problem" link
targets are provided by packages the "problem" package depends on.

(some of them will break over time BTW, for example dejavu ttf file
naming changed with last release)

The sane thing would probably be to require that packages that have
links pointing outside the package itself add a file dep to the
link(s) target(s), but I'm sure proponents of "yum update speed first,
correctness later" will object loudly.

Regards,

-- 
Nicolas Mailhot



From jonathan.underwood at gmail.com  Mon Oct 29 12:54:12 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 29 Oct 2007 12:54:12 +0000
Subject: Problem with the live ISOs and creating bootable USB
	installation media?
In-Reply-To: <47252651.4060403@filteredperception.org>
References: <645d17210710271713p1f4aa1bdk94e09165ed6e8b2@mail.gmail.com>
	<645d17210710271719w2b5a700fn5603faa7982f2727@mail.gmail.com>
	<645d17210710271744g755b296av792a5620d27aaa2f@mail.gmail.com>
	<47252651.4060403@filteredperception.org>
Message-ID: <645d17210710290554v484ec7e1q30cfe20551b6832@mail.gmail.com>

On 29/10/2007, Douglas McClendon <dmc.fedora at filteredperception.org> wrote:
> Looking at f8t3, it doesn't appear that livecd-iso-to-disk is on the
> desktop livecd.  Perhaps an alternate solution would be to split
> livecd-iso-to-disk away from livecd-tools, and have it in the desktop
> livecd.  While also putting it in the F7 updates repo.

I understand from Jeremy that both those things are planned.

> I think the
> f8/git version of l-i-t-d already works without your patch, for both f7
> and f8 LiveISOs.

Yep, that's correct.

J.



From buildsys at fedoraproject.org  Mon Oct 29 12:56:47 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Mon, 29 Oct 2007 08:56:47 -0400 (EDT)
Subject: Package EVR problems in Fedora 2007-10-29
Message-ID: <20071029125648.28B0815212D@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8

allisson AT gmail com:
    ruby-gnome2
      FE6 > F7-updates (0:0.16.0-14.fc6 > 0:0.16.0-7.fc7)
    
aportal AT univ-montp2 fr:
    kbackup
      FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
      FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)
    
    pikloops
      FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)
    
cgoorah AT yahoo com au:
    piklab
      FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
      FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)
    
    xcircuit
      FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
      F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)
    
chris stone AT gmail com:
    poker-network
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)
    
    poker2d
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)
    
cweyl AT alumni drew edu:
    Zim
      FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
      F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
esandeen AT redhat com:
    xfsprogs
      FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)
    
foolish AT guezz net:
    gtranslator
      F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)
    
frank-buettner AT gmx net:
    ctapi-cyberjack
      FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
      F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)
    
gecko-maint AT redhat com:
    seamonkey
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)
    
gemi AT bluewin ch:
    yap
      F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
john AT ncphotography com:
    bugzilla
      FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
      FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
kevin AT tigcc ticalc org:
    qt4-theme-quarticurve
      FE6 > F7-updates (0:0.0-0.6.1.beta5.fc6 > 0:0.0-0.5.beta4.fc7)
    
lemenkov AT gmail com:
    fuse-python
      FE6 > F7-updates (0:0.2-6.fc6 > 0:0.2-5.fc7)
      FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
    
lvm-team AT redhat com:
    dmraid
      F7-updates > F8 (0:1.0.0.rc14-4.fc7 > 0:1.0.0.rc14-2.fc7)
    
lxtnow AT gmail com:
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
    wammu
      FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
      F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)
    
michel sylvan AT gmail com:
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)
    
    nagios-plugins
      FE6 > F7-updates (0:1.4.8-9.fc6 > 0:1.4.8-4.fc7)
      FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)
    
    phpMyAdmin
      FE6 > F7-updates (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc7)
      FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)
    
    python-meld3
      FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
      FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
    
    smolt
      FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.8.4-4.fc7)
      FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)
    
mtasaka AT ioa s u-tokyo ac jp:
    mirage
      FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
      F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
ondrejj AT salstar sk:
    climm
      FE6 > F7-updates (0:0.6.1-1.fc6 > 0:0.6-2.fc7)
      FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
    
pingoufc4 AT yahoo fr:
    rkward
      FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
      FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)
    
rcritten AT redhat com:
    mod_nss
      FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
      F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)
    
rmeggins AT redhat com:
    adminutil
      FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)
    
    mozldap
      FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
      F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
roland AT redhat com:
    monotone
      FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)
    
s adam AT diffingo com:
    fwfstab
      FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
      F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
----------------------------------------------------------------------

adminutil: rmeggins AT redhat com
  FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)

bugzilla: john AT ncphotography com
  FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
  FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)

climm: ondrejj AT salstar sk
  FE6 > F7-updates (0:0.6.1-1.fc6 > 0:0.6-2.fc7)
  FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)

ctapi-cyberjack: frank-buettner AT gmx net
  FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
  F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)

dmraid: lvm-team AT redhat com
  F7-updates > F8 (0:1.0.0.rc14-4.fc7 > 0:1.0.0.rc14-2.fc7)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

fuse-python: lemenkov AT gmail com
  FE6 > F7-updates (0:0.2-6.fc6 > 0:0.2-5.fc7)
  FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)

fwfstab: s adam AT diffingo com
  FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
  F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)

gtranslator: foolish AT guezz net
  F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

kbackup: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
  FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

mirage: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
  F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)

mod_nss: rcritten AT redhat com
  FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
  F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)

monotone: roland AT redhat com
  FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7)

mozldap: rmeggins AT redhat com
  FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
  F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)

nagios-plugins: mmcgrath AT redhat com
  FE6 > F7-updates (0:1.4.8-9.fc6 > 0:1.4.8-4.fc7)
  FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

phpMyAdmin: mmcgrath AT redhat com
  FE6 > F7-updates (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc7)
  FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)

piklab: cgoorah AT yahoo com au
  FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
  FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)

poker-network: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)

poker2d: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-meld3: mmcgrath AT redhat com
  FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
  FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

qt4-theme-quarticurve: kevin AT tigcc ticalc org
  FE6 > F7-updates (0:0.0-0.6.1.beta5.fc6 > 0:0.0-0.5.beta4.fc7)

rkward: pingoufc4 AT yahoo fr
  FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
  FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)

ruby-gnome2: allisson AT gmail com
  FE6 > F7-updates (0:0.16.0-14.fc6 > 0:0.16.0-7.fc7)

seamonkey: gecko-maint AT redhat com
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.8.4-4.fc7)
  FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

wammu: lxtnow AT gmail com
  FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
  F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)

xcircuit: cgoorah AT yahoo com au
  FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
  F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)

xfsprogs: esandeen AT redhat com
  FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

yap: gemi AT bluewin ch
  F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)

Zim: cweyl AT alumni drew edu
  FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
  F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From mclasen at redhat.com  Mon Oct 29 13:12:55 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 29 Oct 2007 09:12:55 -0400
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
References: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
Message-ID: <1193663576.4067.7.camel@localhost.localdomain>


On Mon, 2007-10-29 at 13:47 +0100, Nicolas Mailhot wrote:
> Le Lun 29 octobre 2007 13:30, Florian La Roche a ?crit :
> 
> Hi,
> 
> > here the output of a test script that checks all rpm packages
> > for dangling symlinks. It does not look at an installed system,
> > but only at files included within rpm packages, so there are
> > a few false reports here for files/dirs created within scripts.
> 
> For each package the correct way to test would be to create a fake
> root with all package deps installed and check if there are dangling
> symlinks then. It looks like quite a few of your "problem" link
> targets are provided by packages the "problem" package depends on.
> 
> (some of them will break over time BTW, for example dejavu ttf file
> naming changed with last release)
> 
> The sane thing would probably be to require that packages that have
> links pointing outside the package itself add a file dep to the
> link(s) target(s), but I'm sure proponents of "yum update speed first,
> correctness later" will object loudly.

Does rpmlint inform about links pointing outside the package ? 
That would be useful.



From buildsys at fedoraproject.org  Mon Oct 29 13:35:07 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Mon, 29 Oct 2007 09:35:07 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-29
Message-ID: <20071029133507.05B3215212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 13

    cksfv-1.3.12-2.fc6
    flashrom-0-0.4.20071028svn2897.fc6
    gputils-0.13.5-1.fc6
    gscan2pdf-0.9.17-2.fc6
    kazehakase-0.5.0-1.fc6
    kdetv-0.8.9-7.fc6
    kdmtheme-1.2.1-1.fc6
    libsieve-2.2.6-2.fc6
    mcabber-0.9.4-1.fc6
    mlmmj-1.2.15-1.fc6
    monotone-0.37-2.fc6
    perl-PDF-API2-0.65-1.fc6
    SILLY-0.1.0-4.fc6


Changes in Fedora Extras 6: 


cksfv-1.3.12-2.fc6
------------------
* Sat Oct 27 2007 Christohper Stone <chris.stone at gmail.com> 1.3.12-2
- Fix rpmlint issues

flashrom-0-0.4.20071028svn2897.fc6
----------------------------------
* Sun Oct 28 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.4.20071028svn2897
- typo fix

* Sun Oct 28 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.3.20071028svn2897
- svn ver. 2897 (support for Gigabyte M61P-S3 SPI m/b, Am29LV040B chip)
- flashrom executable now sits in sbindir since it's administrator's tool

gputils-0.13.5-1.fc6
--------------------
* Sun Oct 28 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.13.5-1
- New upstream version
  - Patches to improve man pages formatting
  - Use macros for rm and make

gscan2pdf-0.9.17-2.fc6
----------------------
* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.17-2
- license clarification

* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.17-1
- v 0.9.17

* Sat Aug 25 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.16-1
- v 0.9.16

* Sun Jul 22 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.15-1
- v 0.9.15

* Wed Jul 11 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.14-1
- v 0.9.14

kazehakase-0.5.0-1.fc6
----------------------
* Mon Oct 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.0
- 0.5.0

* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2.svn3312
- Try svn 3312

* Tue Oct 23 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.9-2.dist.1
- Rebuild against new gecko engine.

kdetv-0.8.9-7.fc6
-----------------
* Sat Oct 27 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-7
- Multiarch fixes (BZ 341781)

* Wed Aug 22 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-6
- Release bump for F8 mass rebuild
- Further license clarifications

* Sun Aug 12 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-5
- Updated license field due to new guidelines
- Fixed .desktop categories

kdmtheme-1.2.1-1.fc6
--------------------
* Sat Oct 27 2007 Chitlesh Goorah <chitlesh at fedoraproject.org> - 1.2.1-1
- New upstream release

* Thu Aug 23 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 1.1.3-2
- queued for mass rebuild for Fedora 8 - BuildID

* Fri Apr 27 2007 Chitlesh Goorah <chitlesh at fedoraproject.org> - 1.1.3-1
- New upstream release

libsieve-2.2.6-2.fc6
--------------------
* Fri Oct 26 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.6-2
- add missing BR: flex, bison
- remove repotag

* Fri Oct 26 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.6-1
- 2.2.6
- license clarification

mcabber-0.9.4-1.fc6
-------------------
* Sun Oct 28 2007 Michael Fleming <mfleming+rpm at enlartenment.com> - 0.9.4-1
- New upstream release
- Use GnuTLS in place of OpenSSL
- Enable OTR (Off The Record) support.

mlmmj-1.2.15-1.fc6
------------------
* Sun Oct 28 2007 Michael Fleming <mfleming+rpm at enlartenment.com> 1.2.15-1
- Long overdue sync with devel
- New upstream release. Please read the release and upgrade notes when
  upgrading.
- Enabled new "enable-recieve-strip" option for MIME handling.

monotone-0.37-2.fc6
-------------------
* Sat Oct 27 2007 Roland McGrath <roland at redhat.com> - 0.37-2
- Updated for 0.37 release.
- Prevent destroying old passphrase file with 'service monotone genkey'.
- Put LSB standard comments in monotone.init for monotone-server subpackage.

perl-PDF-API2-0.65-1.fc6
------------------------
* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.65-1
- 0.65

* Sun Aug 19 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.62-2
- update license tag to LGPLv2+
- remove CHANGELOG references

* Sun Aug 19 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.62-1
- 0.62

SILLY-0.1.0-4.fc6
-----------------
* Sun Oct 28 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.1.0-4
- Multiarch fixes (BZ 343181)

* Wed Aug 22 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.1.0-3
- Release bump for F8 mass rebuild

* Sun Mar 11 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.1.0-2
- Preserve timestamps on install
- Changed source URL
- Improved sed replacements
- Changed encoding of AUTHORS to UTF-8



From dwmw2 at infradead.org  Mon Oct 29 13:45:25 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 29 Oct 2007 09:45:25 -0400
Subject: b43 in Fedora 7
In-Reply-To: <4724C4C0.4020007@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>
	<1193573023.2915.42.camel@shinybook.infradead.org>
	<47248919.6000505@sms.ed.ac.uk>
	<1193577458.2915.45.camel@shinybook.infradead.org>
	<4724911F.4050308@sms.ed.ac.uk>
	<1193585785.2915.56.camel@shinybook.infradead.org>
	<4724C4C0.4020007@sms.ed.ac.uk>
Message-ID: <1193665525.2915.117.camel@shinybook.infradead.org>

On Sun, 2007-10-28 at 17:20 +0000, Ioannis Nousias wrote:
> ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for
> me.

You could just install the f8 kernel, without the rest of the system for
now. What was wrong with bcm43xx, btw? By forcing it to remain at 11Mb/s
with iwconfig, or maybe even lower, I've been able to make it work OK
(although b43legacy is better).

-- 
dwmw2



From pertusus at free.fr  Mon Oct 29 13:51:59 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 29 Oct 2007 14:51:59 +0100
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <1193663576.4067.7.camel@localhost.localdomain>
References: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
	<1193663576.4067.7.camel@localhost.localdomain>
Message-ID: <20071029135159.GB2646@free.fr>

On Mon, Oct 29, 2007 at 09:12:55AM -0400, Matthias Clasen wrote:
> 
> Does rpmlint inform about links pointing outside the package ? 
> That would be useful.

It does. 

but here we also need a periodic check, because change in other packages
may lead to broken links.

--
Pat



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct 29 14:00:29 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 29 Oct 2007 15:00:29 +0100
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <20071029135159.GB2646@free.fr>
References: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
	<1193663576.4067.7.camel@localhost.localdomain>
	<20071029135159.GB2646@free.fr>
Message-ID: <20071029150029.b111f31b.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 29 Oct 2007 14:51:59 +0100, Patrice Dumas wrote:

> On Mon, Oct 29, 2007 at 09:12:55AM -0400, Matthias Clasen wrote:
> > 
> > Does rpmlint inform about links pointing outside the package ? 
> > That would be useful.
> 
> It does. 
> 
> but here we also need a periodic check, because change in other packages
> may lead to broken links.

If you mean that you link from within one package to a file included
within a different package, then the package is missing "Requires:
/path/to/link/target", isn't it?

Of course, you can try to get away with just "Requires: some-pkg-name",
but that is too fragile, especially if you already believe that the
linked file might be dropped any time.



From lkundrak at redhat.com  Mon Oct 29 14:10:32 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 29 Oct 2007 15:10:32 +0100
Subject: hibernation
In-Reply-To: <1193654555.16185.1.camel@level.fluendo.lan>
References: <1193654555.16185.1.camel@level.fluendo.lan>
Message-ID: <1193667032.8734.0.camel@localhost.localdomain>


On Mon, 2007-10-29 at 11:42 +0100, Thomas Vander Stichele wrote:
> Hi,
> 
> is hibernation working for other people currently ?
> 
> I installed test3 on my new T61, and am running 2.6.23.1-35.fc8, but
> when I choose "hibernate" from the logout menu, it hibernates just fine,
> and goes to sleep, but on the next boot it just boots the kernel without
> restoring state.  This worked fine in F7.
> 
> If it's me and not a general problem, how do I debug it further ? Is
> there some docs on how this is supposed to be working in Fedora ?

Works perfectly on my T61. Could you please file a bug? Also, aren't you
running fglrx, are you?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From jkeating at redhat.com  Mon Oct 29 14:14:20 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 10:14:20 -0400
Subject: ALSA 1.0.15 update test kernels available - user space packages
In-Reply-To: <472591B8.10303@redhat.com>
References: <47210BB2.3040201@redhat.com> <1193423556.3113.3.camel@perihelion>
	<472591B8.10303@redhat.com>
Message-ID: <20071029101420.7906cfb0@redhat.com>

On Mon, 29 Oct 2007 08:54:32 +0100
Martin Stransky <stransky at redhat.com> wrote:

> User space packages (alsa 1.0.15) are here:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22679
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22680
> 
> If the updated kernel is included in F8 please add them there, too.

I thought we already had the userland parts, which is what made this
update less scary.  I'm definitely not feeling good about changing
userland stuff wrt audio at this point too.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/9565e73f/attachment.sig>

From stransky at redhat.com  Mon Oct 29 14:30:23 2007
From: stransky at redhat.com (Martin Stransky)
Date: Mon, 29 Oct 2007 15:30:23 +0100
Subject: ALSA 1.0.15 update test kernels available - user space packages
In-Reply-To: <20071029101420.7906cfb0@redhat.com>
References: <47210BB2.3040201@redhat.com>	<1193423556.3113.3.camel@perihelion>	<472591B8.10303@redhat.com>
	<20071029101420.7906cfb0@redhat.com>
Message-ID: <4725EE7F.8090105@redhat.com>

Jesse Keating wrote:
> On Mon, 29 Oct 2007 08:54:32 +0100
> Martin Stransky <stransky at redhat.com> wrote:
> 
>> User space packages (alsa 1.0.15) are here:
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=22679
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=22680
>>
>> If the updated kernel is included in F8 please add them there, too.
> 
> I thought we already had the userland parts, which is what made this
> update less scary.  I'm definitely not feeling good about changing
> userland stuff wrt audio at this point too.

IMHO changing alsa packages from rc3 to final doesn't matter. But we can 
release f8 with rc3 and I'll push the finals as an update. Almost all 
ALSA bugs are in kernel, not in user-space packages.



From david at lovesunix.net  Mon Oct 29 14:39:57 2007
From: david at lovesunix.net (David Nielsen)
Date: Mon, 29 Oct 2007 15:39:57 +0100
Subject: ALSA 1.0.15 update test kernels available - user space packages
In-Reply-To: <472591B8.10303@redhat.com>
References: <47210BB2.3040201@redhat.com>
	<1193423556.3113.3.camel@perihelion>  <472591B8.10303@redhat.com>
Message-ID: <1193668797.2836.6.camel@dawkins>


man, 29 10 2007 kl. 08:54 +0100, skrev Martin Stransky:
> Jon Masters wrote:
> > On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
> >> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> >> would get us up-to-date with the latest audio drivers and fix many
> >> problems with audio drivers not working, or only partially working.
> >>
> >> Test kernels for i686 and x86_64 are available at:
> >>
> >>   http://people.redhat.com/cebbert/kernels/F8/
> >>
> 
> User space packages (alsa 1.0.15) are here:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22679
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22680
> 
> If the updated kernel is included in F8 please add them there, too.

I'm seeing no regressions, things work as they did before - sadly it did
not teach Fedora to correctly pick up my 5.1 setup, I still only have
stereo. But not getting worse is at least something.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/39bb9310/attachment.sig>

From buc at odusz.so-cdu.ru  Mon Oct 29 14:49:06 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 29 Oct 2007 17:49:06 +0300
Subject: Why grub requires gtk2 etc. ?
Message-ID: <4725F2E2.4030609@odu.neva.ru>

An attempt to remove "gtk2" (and all what requires it) from a server 
leads to remove of "grub".

Currently "grub" requires "system-logos", which is provided by 
"fedora-logos" package, but "fedora-logos" requires a lot of GUI stuff 
in F7 ...

I hope "ancient UN*X people" will understand me... We prefer to remove 
unneeded software, including unneeded (for us :) ) GUI stuff, from our 
servers.

Any comments?


Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy





From notting at redhat.com  Mon Oct 29 14:57:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 29 Oct 2007 10:57:15 -0400
Subject: howto convert configfile on library update?
In-Reply-To: <4724A061.3050901@hhs.nl>
References: <4724A061.3050901@hhs.nl>
Message-ID: <20071029145715.GC27104@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> But how / when do I run this script, obviously it should get run on %post, 
> and only if this is an update. But when?

%triggerpostun lm_sensoros <= (last version) would be one way to make
sure it runs once and only once.

Bill



From notting at redhat.com  Mon Oct 29 15:05:03 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 29 Oct 2007 11:05:03 -0400
Subject: Custom derivative and generic-logos
In-Reply-To: <472522BE.6010801@fedoraproject.org>
References: <472522BE.6010801@fedoraproject.org>
Message-ID: <20071029150503.GD27104@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> I could do a --nodeps which will likely work well but is there a cleaner 
> way to do this without repackaging all the dependencies?

You have to do --nodeps and add, or just specify it specifically in your
manifest such as:

-fedora-logos
generic-logos

There's really not a better way to do it, as you don't want a Obsoletes:
in it.

Bill



From skasal at redhat.com  Mon Oct 29 15:12:34 2007
From: skasal at redhat.com (Stepan Kasal)
Date: Mon, 29 Oct 2007 16:12:34 +0100
Subject: Why grub requires gtk2 etc. ?
In-Reply-To: <4725F2E2.4030609@odu.neva.ru>
References: <4725F2E2.4030609@odu.neva.ru>
Message-ID: <20071029151234.GA9360@camelia.ucw.cz>

Hello Dmitry,

On Mon, Oct 29, 2007 at 05:49:06PM +0300, Dmitry Butskoy wrote:
> An attempt to remove "gtk2" (and all what requires it) from a server leads 
> to remove of "grub".
>
> Currently "grub" requires "system-logos", which is provided by 
> "fedora-logos" package, but "fedora-logos" requires a lot of GUI stuff in 
> F7 ...

I believe this problem was fixed in early development of F-8:

* Fri Jun 15 2007 Adam Jackson <ajax at redhat.com> 6.0.98-4
- Remove the Requires on redhat-artwork and fedora-icon-theme, and just
  multi-own the directories.  Fixes some hilarious dependency chains.

Please check F8 Test3, or wait for the final release.

HTH,
	Stepan Kasal



From buc at odusz.so-cdu.ru  Mon Oct 29 15:16:05 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 29 Oct 2007 18:16:05 +0300
Subject: Why grub requires gtk2 etc. ?
In-Reply-To: <20071029151234.GA9360@camelia.ucw.cz>
References: <4725F2E2.4030609@odu.neva.ru>
	<20071029151234.GA9360@camelia.ucw.cz>
Message-ID: <4725F935.9010207@odu.neva.ru>

Stepan Kasal wrote:
> Hello Dmitry,
>
> On Mon, Oct 29, 2007 at 05:49:06PM +0300, Dmitry Butskoy wrote:
>   
>> An attempt to remove "gtk2" (and all what requires it) from a server leads 
>> to remove of "grub".
>>
>> Currently "grub" requires "system-logos", which is provided by 
>> "fedora-logos" package, but "fedora-logos" requires a lot of GUI stuff in 
>> F7 ...
>>     
>
> I believe this problem was fixed in early development of F-8:
>
> * Fri Jun 15 2007 Adam Jackson <ajax at redhat.com> 6.0.98-4
> - Remove the Requires on redhat-artwork and fedora-icon-theme, and just
>   multi-own the directories.  Fixes some hilarious dependency chains.
>
> Please check F8 Test3, or wait for the final release.
>   

Thanks.

Could this fix be ported to F7 too?

(release of F8 is a good time to upgrade production servers to F7  (N-1) 
:) )

~buc



From Curtis at GreenKey.net  Mon Oct 29 15:27:21 2007
From: Curtis at GreenKey.net (Curtis Doty)
Date: Mon, 29 Oct 2007 08:27:21 -0700 (PDT)
Subject: rolling rawhide
Message-ID: <20071029152721.EBA086F1C2@alopias.GreenKey.net>

Did rawhide already start rolling away from f8 freeze? I was just about to 
do some last minute bench testing but cannot find any boot/stage2 images 
up there again.

../C



From jkeating at redhat.com  Mon Oct 29 15:30:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 11:30:15 -0400
Subject: rolling rawhide
In-Reply-To: <20071029152721.EBA086F1C2@alopias.GreenKey.net>
References: <20071029152721.EBA086F1C2@alopias.GreenKey.net>
Message-ID: <20071029113015.12833fc7@redhat.com>

On Mon, 29 Oct 2007 08:27:21 -0700 (PDT)
Curtis Doty <Curtis at GreenKey.net> wrote:

> Did rawhide already start rolling away from f8 freeze? I was just
> about to do some last minute bench testing but cannot find any
> boot/stage2 images up there again.

No, there was a transient error during the "make it installable" phase
of rawhide creation last night.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/7d6e4e6d/attachment.sig>

From buildsys at redhat.com  Mon Oct 29 15:42:00 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 29 Oct 2007 11:42:00 -0400
Subject: rawhide report: 20071028 changes
Message-ID: <200710291542.l9TFg0v0005368@porkchop.devel.redhat.com>

 

 
Updated Packages:

iso-codes-1.5-1.fc8
-------------------
* Fri Oct 26 2007 Christopher Aillon <caillon at redhat.com> 1.5-1
- Update to 1.5

kdemultimedia-6:3.5.8-7.fc8
---------------------------
* Sat Oct 27 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 6:3.5.8-7
- fix typo in dependency

Broken deps for i386
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8



Broken deps for ppc
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp



Broken deps for ppc64
----------------------------------------------------------
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From jkeating at redhat.com  Mon Oct 29 15:42:03 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 11:42:03 -0400
Subject: rawhide report: 20071028 changes
In-Reply-To: <200710291542.l9TFg0v0005368@porkchop.devel.redhat.com>
References: <200710291542.l9TFg0v0005368@porkchop.devel.redhat.com>
Message-ID: <20071029114203.047fd535@redhat.com>

On Mon, 29 Oct 2007 11:42:00 -0400
Build System <buildsys at redhat.com> wrote:

> Subject: rawhide report: 20071028 changes

Disregard this.  There was a stale rsync that held this up and may have
been fooling around a bit with file content.  I've killed the rsync and
it popped out this mail.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/49a5282e/attachment.sig>

From pertusus at free.fr  Mon Oct 29 16:07:05 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 29 Oct 2007 17:07:05 +0100
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <20071029150029.b111f31b.mschwendt.tmp0701.nospam@arcor.de>
References: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
	<1193663576.4067.7.camel@localhost.localdomain>
	<20071029135159.GB2646@free.fr>
	<20071029150029.b111f31b.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071029160705.GF2646@free.fr>

On Mon, Oct 29, 2007 at 03:00:29PM +0100, Michael Schwendt wrote:
> If you mean that you link from within one package to a file included
> within a different package, then the package is missing "Requires:
> /path/to/link/target", isn't it?

It could indeed be a way to ensure that the file is still there. There
is still the issue of avoiding dependencies on files outside of /etc and
*/bin, and one could also imagine a situation where there are a lot of
links.

> Of course, you can try to get away with just "Requires: some-pkg-name",
> but that is too fragile, especially if you already believe that the
> linked file might be dropped any time.

It really depends on the situation, but, agreed, having a file
dependency solves adequately the issue in many cases.

--
Pat



From pertusus at free.fr  Mon Oct 29 16:09:30 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 29 Oct 2007 17:09:30 +0100
Subject: Why grub requires gtk2 etc. ?
In-Reply-To: <4725F935.9010207@odu.neva.ru>
References: <4725F2E2.4030609@odu.neva.ru>
	<20071029151234.GA9360@camelia.ucw.cz>
	<4725F935.9010207@odu.neva.ru>
Message-ID: <20071029160930.GG2646@free.fr>

On Mon, Oct 29, 2007 at 06:16:05PM +0300, Dmitry Butskoy wrote:
>
> Could this fix be ported to F7 too?

That seems to be something that could be nice, but if this implies a
major reorganization of packages split and content, it may be better 
to live with bad deps than port it.

It is very nice that the issue was solved, in any case.

--
Pat



From sundaram at fedoraproject.org  Mon Oct 29 16:15:00 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 29 Oct 2007 21:45:00 +0530
Subject: Custom derivative and generic-logos
In-Reply-To: <20071029150503.GD27104@nostromo.devel.redhat.com>
References: <472522BE.6010801@fedoraproject.org>
	<20071029150503.GD27104@nostromo.devel.redhat.com>
Message-ID: <47260704.5040203@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> I could do a --nodeps which will likely work well but is there a cleaner 
>> way to do this without repackaging all the dependencies?
> 
> You have to do --nodeps and add, or just specify it specifically in your
> manifest such as:
> 
> -fedora-logos
> generic-logos

Wouldn't this be ignored due to dependencies?

> There's really not a better way to do it, as you don't want a Obsoletes:
> in it.

Why?

Rahul



From j.w.r.degoede at hhs.nl  Mon Oct 29 16:05:49 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 29 Oct 2007 17:05:49 +0100
Subject: howto convert configfile on library update?
In-Reply-To: <20071029145715.GC27104@nostromo.devel.redhat.com>
References: <4724A061.3050901@hhs.nl>
	<20071029145715.GC27104@nostromo.devel.redhat.com>
Message-ID: <472604DD.7040404@hhs.nl>

Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> But how / when do I run this script, obviously it should get run on %post, 
>> and only if this is an update. But when?
> 
> %triggerpostun lm_sensoros <= (last version) would be one way to make
> sure it runs once and only once.
> 

Thanks,

Is there any good documentation on triggers anywhere?

BTW shouldn't that be %preun, after uninstall of the old version, the old 
config file will be no more, correct?

Is there a way to check if the configfile was modified?

Regards,

Hans



From myfedora at richip.dhs.org  Mon Oct 29 16:18:15 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Mon, 29 Oct 2007 10:18:15 -0600
Subject: Might Be A Problem With NM
Message-ID: <1193674696.29491.7.camel@localhost6.localdomain6>

Running F8T3, last night I did a "yum update" after not having done so
for a while (to give an idea, I had to yum update rpm* yum* to get past
yum update balking on the nodoka-gnome-theme dependency issue). After a
successful update, I tried logging in as my regular user only to block
for an indefinite amount of time with the background screen loaded and
the panel all grey.

After fiddling around with the system from a virtual console, I found
out what might be the problem. I have $HOME/Music mounted from an NFS
exported directory (via /etc/fstab). It seems as if the session startup
process blocks, prolly stat'ing the filesystem.

The odd thing is this used to work prior to my updating the system. Now,
from gdm, I notice that the ethernet connection that went up via the old
rc network script had gone down, prolly after NM started.

My question is, what should I do to fix it? Can we now remove starting
network interfaces at bootup via the old RC scripts and use
NetworkManager now?
--

Richi Plana



From orion at cora.nwra.com  Mon Oct 29 16:20:54 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 29 Oct 2007 10:20:54 -0600
Subject: Why is my %dist resolving to rh8?
In-Reply-To: <1193411688.3400.14.camel@localhost.localdomain>
References: <47210CD5.2050207@cora.nwra.com>
	<1193411688.3400.14.camel@localhost.localdomain>
Message-ID: <47260866.90804@cora.nwra.com>

Tom "spot" Callaway wrote:
> I'm pretty sure we don't define %{dist} like that anymore, I suspect
> this is a legacy hack.

Yeah, old cruft from my .rpmmacros.  I guess I've been doing this for 
too long now...

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From cebbert at redhat.com  Mon Oct 29 16:32:29 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Mon, 29 Oct 2007 12:32:29 -0400
Subject: b43 in Fedora 7
In-Reply-To: <4724C4C0.4020007@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>	<1193577458.2915.45.camel@shinybook.infradead.org>	<4724911F.4050308@sms.ed.ac.uk>	<1193585785.2915.56.camel@shinybook.infradead.org>
	<4724C4C0.4020007@sms.ed.ac.uk>
Message-ID: <47260B1D.2070200@redhat.com>

On 10/28/2007 01:20 PM, Ioannis Nousias wrote:
>>   
> ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for me.
> 

2.6.23.1 for Fedora 7 will be pushed as an update soon, it's also here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=21666



From katzj at redhat.com  Mon Oct 29 16:38:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 29 Oct 2007 12:38:27 -0400
Subject: Custom derivative and generic-logos
In-Reply-To: <47260704.5040203@fedoraproject.org>
References: <472522BE.6010801@fedoraproject.org>
	<20071029150503.GD27104@nostromo.devel.redhat.com>
	<47260704.5040203@fedoraproject.org>
Message-ID: <1193675907.3927.12.camel@localhost.localdomain>

On Mon, 2007-10-29 at 21:45 +0530, Rahul Sundaram wrote:
> Bill Nottingham wrote:
> > Rahul Sundaram (sundaram at fedoraproject.org) said: 
> >> I could do a --nodeps which will likely work well but is there a cleaner 
> >> way to do this without repackaging all the dependencies?
> > 
> > You have to do --nodeps and add, or just specify it specifically in your
> > manifest such as:
> > 
> > -fedora-logos
> > generic-logos
> 
> Wouldn't this be ignored due to dependencies?

Any dependencies should be on system-logos, not fedora-logos.  And
system-logos is provided by both.

> > There's really not a better way to do it, as you don't want a Obsoletes:
> > in it.
> 
> Why?

If there's an obsoletes, then people pointing at the repo will get their
fedora-logos package replaced

Jeremy



From notting at redhat.com  Mon Oct 29 17:15:38 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 29 Oct 2007 13:15:38 -0400
Subject: howto convert configfile on library update?
In-Reply-To: <472604DD.7040404@hhs.nl>
References: <4724A061.3050901@hhs.nl>
	<20071029145715.GC27104@nostromo.devel.redhat.com>
	<472604DD.7040404@hhs.nl>
Message-ID: <20071029171538.GA21758@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> Is there any good documentation on triggers anywhere?

Other than the RPM docs, no.

> BTW shouldn't that be %preun, after uninstall of the old version, the old 
> config file will be no more, correct?

Correct. 

> Is there a way to check if the configfile was modified?

Not from the level you're executing the trigger from, no.

Bill



From ville.skytta at iki.fi  Mon Oct 29 17:47:44 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 29 Oct 2007 19:47:44 +0200
Subject: howto convert configfile on library update?
In-Reply-To: <20071029171538.GA21758@nostromo.devel.redhat.com>
References: <4724A061.3050901@hhs.nl> <472604DD.7040404@hhs.nl>
	<20071029171538.GA21758@nostromo.devel.redhat.com>
Message-ID: <200710291947.45319.ville.skytta@iki.fi>

On Monday 29 October 2007, Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>
> > Is there a way to check if the configfile was modified?
>
> Not from the level you're executing the trigger from, no.

It's not too pretty, but as long as the old config file is around (not sure if 
that's the case in this particular case) and you know eg. the md5sum of the 
unmodified old one, you can check it.  I've done that in some cases, one 
example is %post of rpmdevtools in F-7.



From ville.skytta at iki.fi  Mon Oct 29 18:06:26 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 29 Oct 2007 20:06:26 +0200
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <20071029160705.GF2646@free.fr>
References: <2224.192.54.193.51.1193662042.squirrel@rousalka.dyndns.org>
	<20071029150029.b111f31b.mschwendt.tmp0701.nospam@arcor.de>
	<20071029160705.GF2646@free.fr>
Message-ID: <200710292006.27316.ville.skytta@iki.fi>

On Monday 29 October 2007, Patrice Dumas wrote:
> On Mon, Oct 29, 2007 at 03:00:29PM +0100, Michael Schwendt wrote:
>
> > Of course, you can try to get away with just "Requires: some-pkg-name",
> > but that is too fragile, especially if you already believe that the
> > linked file might be dropped any time.
>
> It really depends on the situation, but, agreed, having a file
> dependency solves adequately the issue in many cases.

And unless the file dependency happens to be an explicit Provides: in the 
package that contains the target file, doing so also causes yum to download 
filelists.* in many cases which causes more stuff to download for people and 
triggers problem reports every now and then when someone looks into why it's 
happening.

I think having both a package name and a file based dependency could be 
helpful [0] - at least theoretically yum could first resolve all non-file 
dependencies, see if things pulled in by those also satisfy the file based 
ones required in the transaction, and only download filelists as a last 
resort if not.  I don't think it currently does though; at least it didn't 
back when I tried that approach in w3c-markup-validator (it's still in the 
specfile nevertheless).

[0] Yep, the fragility of the package name based dependency would still be 
there, but the additional file based one would reduce the probability of 
silent breakage.



From docs-list at fedoralinks.org  Mon Oct 29 17:47:52 2007
From: docs-list at fedoralinks.org (Robert 'Bob' Jensen)
Date: Mon, 29 Oct 2007 12:47:52 -0500
Subject: Zimbra packages in Fedora
In-Reply-To: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
Message-ID: <47261CC8.8040507@fedoralinks.org>

King InuYasha wrote:
> I had noticed how well that Zimbra has been doing, and I was wondering 
> if it would be possible for someone to make packages for Zimbra to be 
> included in Fedora?
> 

Well just my personal opinion... Zimbra might be doing well but the 
deployment system leaves a lot to be desired. Best I can tell (installed 
on CentOS5) the current version available is packaged with a broken 
tomcat server. There are some other things that should or would need to 
be addressed also such as the way zimbra provides things like mysqld, 
postfix, ok everything that makes zimbra work.

Step one disable the firewall, step two disable SElinux, step three run 
the install script that will do a lot of things including install the 
rpms...

Robert 'Bob' Jensen



From debarshi.ray at gmail.com  Mon Oct 29 18:52:16 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 30 Oct 2007 00:22:16 +0530
Subject: Packaging httrack
Message-ID: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>

I am trying to package HTTrack (http://www.httrack.com/) for Fedora.
Among other things, its upstream versioning is a kind of strange. eg.,
the versions are 3.41 -> 3.41-2 -> 3.41-3 and so on. See
http://www.httrack.com/page/4/en/index.html

So what should be the Fedora NEVRA? Would httrack-3.41.3-1 be fine?

I could not find much in
http://fedoraproject.org/wiki/Packaging/NamingGuidelines

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From tcallawa at redhat.com  Mon Oct 29 18:54:18 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 29 Oct 2007 14:54:18 -0400
Subject: Packaging httrack
In-Reply-To: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>
References: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>
Message-ID: <1193684058.3477.18.camel@localhost.localdomain>


On Tue, 2007-10-30 at 00:22 +0530, Debarshi 'Rishi' Ray wrote:
> I am trying to package HTTrack (http://www.httrack.com/) for Fedora.
> Among other things, its upstream versioning is a kind of strange. eg.,
> the versions are 3.41 -> 3.41-2 -> 3.41-3 and so on. See
> http://www.httrack.com/page/4/en/index.html
> 
> So what should be the Fedora NEVRA? Would httrack-3.41.3-1 be fine?

Sure.

~spot



From thomas at apestaart.org  Mon Oct 29 19:26:23 2007
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Mon, 29 Oct 2007 20:26:23 +0100
Subject: hibernation
In-Reply-To: <1193667032.8734.0.camel@localhost.localdomain>
References: <1193654555.16185.1.camel@level.fluendo.lan>
	<1193667032.8734.0.camel@localhost.localdomain>
Message-ID: <1193685983.16185.71.camel@level.fluendo.lan>

On Mon, 2007-10-29 at 15:10 +0100, Lubomir Kundrak wrote:
> On Mon, 2007-10-29 at 11:42 +0100, Thomas Vander Stichele wrote:
> > Hi,
> > 
> > is hibernation working for other people currently ?
> > 
> > I installed test3 on my new T61, and am running 2.6.23.1-35.fc8, but
> > when I choose "hibernate" from the logout menu, it hibernates just fine,
> > and goes to sleep, but on the next boot it just boots the kernel without
> > restoring state.  This worked fine in F7.
> > 
> > If it's me and not a general problem, how do I debug it further ? Is
> > there some docs on how this is supposed to be working in Fedora ?
> 
> Works perfectly on my T61. Could you please file a bug? Also, aren't you
> running fglrx, are you?

I have an intel i965. I'd like to first figure out myself how to debug
it further, if someone could tell me what command actually gets executed
on hibernation, before I file a bug, because the bug will be relatively
useless as it is right now.

T


> 
> -- 
> Lubomir Kundrak (Red Hat Security Response Team)
> 



From kevin.kofler at chello.at  Mon Oct 29 19:50:21 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 29 Oct 2007 19:50:21 +0000 (UTC)
Subject: dangling symlinks in rpm packages for Fedora-devel
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
	<loom.20071029T124337-844@post.gmane.org>
Message-ID: <loom.20071029T194723-183@post.gmane.org>

I wrote:
> Ouch, these are really bad. I don't understand what's going on here. These
> are not supposed to be symlinks, they are supposed to be loadable plugins,
> and in the F7 RPM which is built from the same specfile, they are. How they
> get replaced with symlinks not pointing to anywhere is a mystery to me. Maybe
> a cmake bug? Or some other toolchain component?

I just tried to rebuild the package for F8, but that doesn't fix anything (I 
canceled the build after i386 completed with strigi-libs still containing the 
offending symlinks). I don't understand why this happens, yet on Fedora 7 the 
exact same spec produced a valid strigi-libs (with actual plugins, not symlinks 
not pointing to anything).

Here's my build attempt (canceled due to invalid output on i386, the first arch 
which completed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=219233

        Kevin Kofler



From airlied at redhat.com  Mon Oct 29 20:09:16 2007
From: airlied at redhat.com (Dave Airlie)
Date: Tue, 30 Oct 2007 06:09:16 +1000
Subject: Might Be A Problem With NM
In-Reply-To: <1193674696.29491.7.camel@localhost6.localdomain6>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
Message-ID: <1193688556.4477.0.camel@optimus>

On Mon, 2007-10-29 at 10:18 -0600, Richi Plana wrote:
> Running F8T3, last night I did a "yum update" after not having done so
> for a while (to give an idea, I had to yum update rpm* yum* to get past
> yum update balking on the nodoka-gnome-theme dependency issue). After a
> successful update, I tried logging in as my regular user only to block
> for an indefinite amount of time with the background screen loaded and
> the panel all grey.
> 
> After fiddling around with the system from a virtual console, I found
> out what might be the problem. I have $HOME/Music mounted from an NFS
> exported directory (via /etc/fstab). It seems as if the session startup
> process blocks, prolly stat'ing the filesystem.
> 
> The odd thing is this used to work prior to my updating the system. Now,
> from gdm, I notice that the ethernet connection that went up via the old
> rc network script had gone down, prolly after NM started.
> 
> My question is, what should I do to fix it? Can we now remove starting
> network interfaces at bootup via the old RC scripts and use
> NetworkManager now?

Have to agree this is most annoying, I wonder is it a blocker...

So machine starts spends its time getting a dhcp address just to have it
thrown away when the networkmanager service starts..

sorta sucks if you don't run X always..

Dave.



From mschwendt.tmp0701.nospam at arcor.de  Mon Oct 29 21:10:21 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 29 Oct 2007 22:10:21 +0100
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <loom.20071029T194723-183@post.gmane.org>
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
	<loom.20071029T124337-844@post.gmane.org>
	<loom.20071029T194723-183@post.gmane.org>
Message-ID: <20071029221021.0c75dc75.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 29 Oct 2007 19:50:21 +0000 (UTC), Kevin Kofler wrote:

> I wrote:
> > Ouch, these are really bad. I don't understand what's going on here. These
> > are not supposed to be symlinks, they are supposed to be loadable plugins,
> > and in the F7 RPM which is built from the same specfile, they are. How they
> > get replaced with symlinks not pointing to anywhere is a mystery to me. Maybe
> > a cmake bug? Or some other toolchain component?
> 
> I just tried to rebuild the package for F8, but that doesn't fix anything (I 
> canceled the build after i386 completed with strigi-libs still containing the 
> offending symlinks). I don't understand why this happens, yet on Fedora 7 the 
> exact same spec produced a valid strigi-libs (with actual plugins, not symlinks 
> not pointing to anything).
> 
> Here's my build attempt (canceled due to invalid output on i386, the first arch 
> which completed):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=219233

Somebody needs to debug it a bit and verify whether it builds the
shared lib with the correct file name:

| cd /builddir/build/BUILD/strigi-0.5.5/fedora/src/streamanalyzer/throughplugins && /usr/bin/cmake -E cmake_symlink_library strigita_pcx.so.0.5.5 strigita_pcx.so.0 strigita_pcx.so
|

It builds a shared lib with a *.so.0 soname, but what file name? Bad
things can happen if it later creates an unversioned symlink and
possibly overwrites the built shared lib file with the symlink.

The package contains at least one other bug anyway, since a -libs pkg
has been split off without moving %post and %postun to it.



From dcbw at redhat.com  Mon Oct 29 21:10:17 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 29 Oct 2007 17:10:17 -0400
Subject: Might Be A Problem With NM
In-Reply-To: <1193688556.4477.0.camel@optimus>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
Message-ID: <1193692217.26629.9.camel@localhost.localdomain>

On Tue, 2007-10-30 at 06:09 +1000, Dave Airlie wrote:
> On Mon, 2007-10-29 at 10:18 -0600, Richi Plana wrote:
> > Running F8T3, last night I did a "yum update" after not having done so
> > for a while (to give an idea, I had to yum update rpm* yum* to get past
> > yum update balking on the nodoka-gnome-theme dependency issue). After a
> > successful update, I tried logging in as my regular user only to block
> > for an indefinite amount of time with the background screen loaded and
> > the panel all grey.
> > 
> > After fiddling around with the system from a virtual console, I found
> > out what might be the problem. I have $HOME/Music mounted from an NFS
> > exported directory (via /etc/fstab). It seems as if the session startup
> > process blocks, prolly stat'ing the filesystem.
> > 
> > The odd thing is this used to work prior to my updating the system. Now,
> > from gdm, I notice that the ethernet connection that went up via the old
> > rc network script had gone down, prolly after NM started.
> > 
> > My question is, what should I do to fix it? Can we now remove starting
> > network interfaces at bootup via the old RC scripts and use
> > NetworkManager now?
> 
> Have to agree this is most annoying, I wonder is it a blocker...
> 
> So machine starts spends its time getting a dhcp address just to have it
> thrown away when the networkmanager service starts..
> 
> sorta sucks if you don't run X always..

This is more of an issue with installs setting the ifcfg-XXX scripts to
star the device at-boot.  If NM is being used, you don't really want the
system networking scripts to bring the device up at all, but to punt
that to the NM start.

Dan




From katzj at redhat.com  Mon Oct 29 21:16:58 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 29 Oct 2007 17:16:58 -0400
Subject: Might Be A Problem With NM
In-Reply-To: <1193692217.26629.9.camel@localhost.localdomain>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
Message-ID: <1193692618.3927.42.camel@localhost.localdomain>

On Mon, 2007-10-29 at 17:10 -0400, Dan Williams wrote:
> On Tue, 2007-10-30 at 06:09 +1000, Dave Airlie wrote:
> > On Mon, 2007-10-29 at 10:18 -0600, Richi Plana wrote:
> > > Running F8T3, last night I did a "yum update" after not having done so
> > > for a while (to give an idea, I had to yum update rpm* yum* to get past
> > > yum update balking on the nodoka-gnome-theme dependency issue). After a
> > > successful update, I tried logging in as my regular user only to block
> > > for an indefinite amount of time with the background screen loaded and
> > > the panel all grey.
> > > 
> > > After fiddling around with the system from a virtual console, I found
> > > out what might be the problem. I have $HOME/Music mounted from an NFS
> > > exported directory (via /etc/fstab). It seems as if the session startup
> > > process blocks, prolly stat'ing the filesystem.
> > > 
> > > The odd thing is this used to work prior to my updating the system. Now,
> > > from gdm, I notice that the ethernet connection that went up via the old
> > > rc network script had gone down, prolly after NM started.
> > > 
> > > My question is, what should I do to fix it? Can we now remove starting
> > > network interfaces at bootup via the old RC scripts and use
> > > NetworkManager now?
> > 
> > Have to agree this is most annoying, I wonder is it a blocker...
> > 
> > So machine starts spends its time getting a dhcp address just to have it
> > thrown away when the networkmanager service starts..
> > 
> > sorta sucks if you don't run X always..
> 
> This is more of an issue with installs setting the ifcfg-XXX scripts to
> star the device at-boot.  If NM is being used, you don't really want the
> system networking scripts to bring the device up at all, but to punt
> that to the NM start.

Or more really, we shouldn't be showing the network screen at all right
now if you're using NetworkManager.  Unfortunately, there's no way to
just divine that so while we have two stacks, the experience sucks a
little. 

When we get to the system-wide daemon in F9, this can be fixed for
realsies

Jeremy



From opensource at till.name  Mon Oct 29 21:24:05 2007
From: opensource at till.name (Till Maas)
Date: Mon, 29 Oct 2007 22:24:05 +0100
Subject: Packaging httrack
In-Reply-To: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>
References: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>
Message-ID: <200710292224.10846.opensource@till.name>

On Mo Oktober 29 2007, Debarshi 'Rishi' Ray wrote:
> I am trying to package HTTrack (http://www.httrack.com/) for Fedora.
> Among other things, its upstream versioning is a kind of strange. eg.,
> the versions are 3.41 -> 3.41-2 -> 3.41-3 and so on. See
> http://www.httrack.com/page/4/en/index.html
>
> So what should be the Fedora NEVRA? Would httrack-3.41.3-1 be fine?

Maybe you can convince upstream to use an "_" instead of an "-" in this 
version string. httrack also uses a versionid, which does not include a "-", 
e.g. httrack 3.41-3 is the same as httrack 3.41.22.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/c3ee8a63/attachment.sig>

From kevin.kofler at chello.at  Mon Oct 29 21:41:32 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 29 Oct 2007 21:41:32 +0000 (UTC)
Subject: dangling symlinks in rpm packages for Fedora-devel
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
	<loom.20071029T124337-844@post.gmane.org>
	<loom.20071029T194723-183@post.gmane.org>
	<20071029221021.0c75dc75.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <loom.20071029T213903-315@post.gmane.org>

Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
> It builds a shared lib with a *.so.0 soname, but what file name? Bad

Hmmm, this is probably it, the files have unversioned .so file names, but 
versioned sonames, e.g.:
 0x0000000e (SONAME)                     Library soname: [strigila_cpp.so.0]

I guess some post-processing (maybe the BuildID processing?) gets confused by 
that. So the SONAME needs to be fixed to be unversioned.

        Kevin Kofler



From jkeating at redhat.com  Mon Oct 29 21:46:57 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 17:46:57 -0400
Subject: dangling symlinks in rpm packages for Fedora-devel
In-Reply-To: <loom.20071029T213903-315@post.gmane.org>
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
	<loom.20071029T124337-844@post.gmane.org>
	<loom.20071029T194723-183@post.gmane.org>
	<20071029221021.0c75dc75.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071029T213903-315@post.gmane.org>
Message-ID: <20071029174657.2f93d092@redhat.com>

On Mon, 29 Oct 2007 21:41:32 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> I guess some post-processing (maybe the BuildID processing?) gets
> confused by that. So the SONAME needs to be fixed to be unversioned.

Why not make the file versioned instead, to match the SONAME?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/f33a6053/attachment.sig>

From kevin.kofler at chello.at  Mon Oct 29 21:53:57 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 29 Oct 2007 21:53:57 +0000 (UTC)
Subject: dangling symlinks in rpm packages for Fedora-devel
References: <20071029123046.GA6541@dudweiler.stuttgart.redhat.com>
	<loom.20071029T124337-844@post.gmane.org>
	<loom.20071029T194723-183@post.gmane.org>
	<20071029221021.0c75dc75.mschwendt.tmp0701.nospam@arcor.de>
	<loom.20071029T213903-315@post.gmane.org>
	<20071029174657.2f93d092@redhat.com>
Message-ID: <loom.20071029T215153-574@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> On Mon, 29 Oct 2007 21:41:32 +0000 (UTC)
> Kevin Kofler <kevin.kofler <at> chello.at> wrote:
> 
> > I guess some post-processing (maybe the BuildID processing?) gets
> > confused by that. So the SONAME needs to be fixed to be unversioned.
> 
> Why not make the file versioned instead, to match the SONAME?

Because these libraries are only ever loaded with dlopen, they're not in the 
linker search path, they're plugins.

It turns out strigi 0.5.7 already fixes this issue (by making the plugins 
unversioned just as I'm doing), however I'm going to kick off a patched 0.5.5 
build with only this fix to rush into f8-final.

        Kevin Kofler



From poelstra at redhat.com  Mon Oct 29 22:08:19 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 29 Oct 2007 15:08:19 -0700
Subject: Request for Comments: Proposed changes to Fedora development
 cycle
In-Reply-To: <20071017100656.30f05b65@redhat.com>
References: <20071016102448.6cc4af82@redhat.com>
	<4714F153.202@leemhuis.info>	<20071016133828.1a1c4cb5@redhat.com>	<4715A3D0.4000109@leemhuis.info>
	<20071017100656.30f05b65@redhat.com>
Message-ID: <472659D3.40805@redhat.com>

Jesse Keating wrote:
> On Wed, 17 Oct 2007 07:55:28 +0200
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>>>  We have to stop changes in order to finalize
>>> the release and get it out the door.  
>> A week IMHO should suffice. If it doesn't I'd say we need more point
>> in the middle to bring rawhide at least in a better shape beforehand.
> 
> I think you severely understimate the amount of time it takes to
> compose trees, including all the Live images, validate that the compose
> itself went fine, final check that all the test cases still work, move
> the bits around to stage for mirrors, get mirrors populated, send gold
> bits off to pressers to produce media to use at events, finalize
> release notes web content, etc, etc, etc...  A week is a severely short
> amount of time to accomplish all of this.
> 

Which is a good argument for why having a "schedule" of tasks with durations would be more informative then a simple list of "milestones" we call a schedule :) 

A list of sub-tasks for "release staging" and how long they take helps people to understand how the release work better and as things get bigger and more complicated manage--reminds of what needs to get done.  

I've been tracking our schedules in TaskJuggler and would like to put it into more active use for F9.

Here are time based schedules with the proposed schedule vs. actual.  Note I've inferred the durations because so far we haven't defined them.  They can easily be blown out to be more detailed or to include other groups (documentation, infrastructure, etc.).

F8: http://poelstra.fedorapeople.org/schedules/f8/f8-tasks-overview.html

Tracking what Jesse created for 
http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal

I created a proposed time based schedule F9: http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html

Source file is here if you'd like to propose a patch to the schedule:
http://poelstra.fedorapeople.org/schedules/f9/f-9-new-devel.tjp

All schedules: http://poelstra.fedorapeople.org/schedules/

John






From austinf at cetoncorp.com  Mon Oct 29 22:10:57 2007
From: austinf at cetoncorp.com (Austin Foxley)
Date: Mon, 29 Oct 2007 15:10:57 -0700
Subject: hibernation
In-Reply-To: <1193685983.16185.71.camel@level.fluendo.lan>
References: <1193654555.16185.1.camel@level.fluendo.lan>	<1193667032.8734.0.camel@localhost.localdomain>
	<1193685983.16185.71.camel@level.fluendo.lan>
Message-ID: <47265A71.80402@cetoncorp.com>

Thomas Vander Stichele wrote:
> I have an intel i965. I'd like to first figure out myself how to debug
> it further, if someone could tell me what command actually gets executed
> on hibernation, before I file a bug, because the bug will be relatively
> useless as it is right now.

pm-hibernate is the command I believe

You can also check out the Sleep Quirks page for some debugging tips:
http://people.freedesktop.org/~hughsient/quirk/index.html


-- 
Austin Foxley
Ceton Corporation
http://www.cetoncorp.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/5bce7e22/attachment.sig>

From ml at deadbabylon.de  Mon Oct 29 22:15:22 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Mon, 29 Oct 2007 23:15:22 +0100
Subject: The KDE-SIG needs (your) help
Message-ID: <200710292315.23149.ml@deadbabylon.de>

This is a request for participation:
The KDE-SIG [1] is atm lacking active contributors. And we really need some 
help in doing our job to provide a good KDE version in Fedora - especially 
with the upcoming KDE 4.0 and the inclusion in Fedora 9.

If you don't know how you could help us here is a list (which is also in the 
wiki):

* Packagers: There are so many interesting packages that are not yet packaged 
for Fedora. Package it to improve the user experience. 

* Reviewers: Only a few persons are doing the kde-related reviews. Help us 
reviewing so that more packages could be included. 

* Testers: If you love KDE use the development version or the updates-testing 
repository and report bugs, bugs, bugs, request enhancements or features. We 
need your feedback to improve KDE. 

* Bugs: Become a BugZapper and help us with kde-related bugs. 

* Documentation writers: The documentation (esp. the DesktopUserGuide) is 
GNOME-centered. Help us to provide an equivalent for KDE. 

* Release Notes: The few people that are working on the new KDE-Spin are quite 
busy with development issues. If you want to help us in writing the release 
notes for the next version of Fedora we would give you all the info you need. 

* Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated with 
end user information. 

* Artists: To provide a matching theme for nodoka-metacity-theme and provide 
an unified desktop experience.

But this is not a complete list. If you're interested in making KDE in Fedora 
better, you're more than welcome.


The list of participants in the wiki is atm not a list of active contributors. 
When setting up the wiki the only demand was an interest in KDE to be listed 
on this page. This list would be changed in the future to be culled down to 
the list of active (or reactivated) participants. This has become necessarely 
because there are only (less or more) 3 active contributors atm (plus Than 
Ngo). But the list indicates that there are enough people helping with KDE.


If you are interested in joining the KDE-SIG please add your name to this 
list, answer to this mail, join us in #fedora-kde at freenode or attend the 
weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic to 
the agenda of the meeting next week to introduce new contributors. [2]
The attendance at the SIG-Meetings is of course not required. But this way we 
would know of each other. And they are also the main place of discussing the 
next steps in the development (besides fedora-devel-list).


If you have any further questions please answer to this mail or write me 
directly. And be sure: If your are willing to help you're welcome (regardless 
of your skills). :)

Sebastian


[1] http://fedoraproject.org/wiki/SIGs/KDE
[2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06
-------------- 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/20071029/3957a6fd/attachment.sig>

From lkundrak at redhat.com  Mon Oct 29 22:21:18 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 29 Oct 2007 23:21:18 +0100
Subject: hibernation
In-Reply-To: <47265A71.80402@cetoncorp.com>
References: <1193654555.16185.1.camel@level.fluendo.lan>
	<1193667032.8734.0.camel@localhost.localdomain>
	<1193685983.16185.71.camel@level.fluendo.lan>
	<47265A71.80402@cetoncorp.com>
Message-ID: <1193696478.8734.10.camel@localhost.localdomain>


On Mon, 2007-10-29 at 15:10 -0700, Austin Foxley wrote:
> Thomas Vander Stichele wrote:
> > I have an intel i965. I'd like to first figure out myself how to debug
> > it further, if someone could tell me what command actually gets executed
> > on hibernation, before I file a bug, because the bug will be relatively
> > useless as it is right now.
> 
> pm-hibernate is the command I believe
> 
> You can also check out the Sleep Quirks page for some debugging tips:
> http://people.freedesktop.org/~hughsient/quirk/index.html

I guess so. The suspend itself without the quirks can be triggered by:
echo disk >/sys/power/state

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From sundaram at fedoraproject.org  Mon Oct 29 22:29:21 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 30 Oct 2007 03:59:21 +0530
Subject: Call For Participation: Fedora 8 Release Summary
Message-ID: <47265EC1.1030502@fedoraproject.org>

Hi

I have added some notes which you can expand further or add additional 
major features not highlighted. Make sure that the major enhancements 
you are working on or your favorites features are covered here.

http://fedoraproject.org/wiki/Releases/8/ReleaseSummary

Rahul



From i at stingr.net  Mon Oct 29 23:11:37 2007
From: i at stingr.net (Paul P Komkoff Jr)
Date: Tue, 30 Oct 2007 02:11:37 +0300
Subject: I want to unorphan pam_mysql
Message-ID: <20071029231137.GL22312@stingr.net>

Hi!

I want to unorphan pam_mysql. I already took ownership in pkgdb for
devel. The package was orphaned for a long time so new bild is
available for review here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=21817

I have no intention to assign older releases to myself (they are EOL
already), but I plan to open F-8 and F-8 branch as soon as I pass the
review (if any).

Any objections?


-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head



From markg85 at gmail.com  Mon Oct 29 23:31:09 2007
From: markg85 at gmail.com (Mark)
Date: Tue, 30 Oct 2007 00:31:09 +0100
Subject: Firefox backspace button action should be "Previous Page" not
	"Page Up"
In-Reply-To: <4725BB85.9000706@redhat.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>
	<4725BB85.9000706@redhat.com>
Message-ID: <6e24a8e80710291631l2e10203n48e1066316a9f556@mail.gmail.com>

2007/10/29, Christopher Aillon <caillon at redhat.com>:
> Authoritatively, the action for backspace should be to do nothing on
> Linux.  This was discussed with the GNOME usability guy, Sun, Novell,
> and Mozilla a bit ago and was checked in as per the bug you posted.  It
> appears that it is still not in the 2.x branch though other distros such
> have patched it in, with a quick glance.
>
> I guess having had this set in my local preferences for ages, I sort of
> forgot about it in the 2.x branch.  I am okay with turning this pref to
> do nothing even though it will be last minute as this is what upstream
> has decided and will be in future versions of Firefox as it best matches
> the platform convention.

Oke good so it's gonna do nothing in Fedora 8 right?



From jkeating at redhat.com  Tue Oct 30 01:51:08 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 21:51:08 -0400
Subject: ALSA 1.0.15 update test kernels available - user space packages
In-Reply-To: <4725EE7F.8090105@redhat.com>
References: <47210BB2.3040201@redhat.com> <1193423556.3113.3.camel@perihelion>
	<472591B8.10303@redhat.com> <20071029101420.7906cfb0@redhat.com>
	<4725EE7F.8090105@redhat.com>
Message-ID: <20071029215108.5857ef5e@redhat.com>

On Mon, 29 Oct 2007 15:30:23 +0100
Martin Stransky <stransky at redhat.com> wrote:

> > I thought we already had the userland parts, which is what made this
> > update less scary.  I'm definitely not feeling good about changing
> > userland stuff wrt audio at this point too.  
> 
> IMHO changing alsa packages from rc3 to final doesn't matter. But we
> can release f8 with rc3 and I'll push the finals as an update. Almost
> all ALSA bugs are in kernel, not in user-space packages.

We discussed this on IRC and looked at the changes.  Risk is low
enough, tagging them.  Need to keep an eye on rawhide over the next day
or so though, just in case.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071029/b44b81ad/attachment.sig>

From myfedora at richip.dhs.org  Tue Oct 30 02:49:21 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Mon, 29 Oct 2007 20:49:21 -0600
Subject: Might Be A Problem With NM
In-Reply-To: <1193692618.3927.42.camel@localhost.localdomain>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
	<1193692618.3927.42.camel@localhost.localdomain>
Message-ID: <1193712561.16349.3.camel@localhost6.localdomain6>

On Mon, 2007-10-29 at 17:16 -0400, Jeremy Katz wrote:
> On Mon, 2007-10-29 at 17:10 -0400, Dan Williams wrote:
> > On Tue, 2007-10-30 at 06:09 +1000, Dave Airlie wrote:
> > > On Mon, 2007-10-29 at 10:18 -0600, Richi Plana wrote:
> > > > Running F8T3, last night I did a "yum update" after not having done so
> > > > for a while (to give an idea, I had to yum update rpm* yum* to get past
> > > > yum update balking on the nodoka-gnome-theme dependency issue). After a
> > > > successful update, I tried logging in as my regular user only to block
> > > > for an indefinite amount of time with the background screen loaded and
> > > > the panel all grey.
> > > > 
> > > > After fiddling around with the system from a virtual console, I found
> > > > out what might be the problem. I have $HOME/Music mounted from an NFS
> > > > exported directory (via /etc/fstab). It seems as if the session startup
> > > > process blocks, prolly stat'ing the filesystem.
> > > > 
> > > > The odd thing is this used to work prior to my updating the system. Now,
> > > > from gdm, I notice that the ethernet connection that went up via the old
> > > > rc network script had gone down, prolly after NM started.
> > > > 
> > > > My question is, what should I do to fix it? Can we now remove starting
> > > > network interfaces at bootup via the old RC scripts and use
> > > > NetworkManager now?
> > > 
> > > Have to agree this is most annoying, I wonder is it a blocker...
> > > 
> > > So machine starts spends its time getting a dhcp address just to have it
> > > thrown away when the networkmanager service starts..
> > > 
> > > sorta sucks if you don't run X always..
> > 
> > This is more of an issue with installs setting the ifcfg-XXX scripts to
> > star the device at-boot.  If NM is being used, you don't really want the
> > system networking scripts to bring the device up at all, but to punt
> > that to the NM start.
> 
> Or more really, we shouldn't be showing the network screen at all right
> now if you're using NetworkManager.  Unfortunately, there's no way to
> just divine that so while we have two stacks, the experience sucks a
> little. 
> 
> When we get to the system-wide daemon in F9, this can be fixed for
> realsies

In the meantime, would a feature request to make NetworkManager leave
the interfaces alone on startup? I'm assuming it doesn't have a startup
configuration (otherwise system-config-network can configure that
instead of ifcfg-XXX). It _COULD_ cause potential problems for systems
which require network connection prior to logging on. (In my case, I
couldn't log on to a Gnome session because the system blocked on NFS).
What about NFS-mounted $HOME dirs?
--

Richi Plana



From debarshi.ray at gmail.com  Tue Oct 30 03:36:28 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 30 Oct 2007 09:06:28 +0530
Subject: Packaging httrack
In-Reply-To: <200710292224.10846.opensource@till.name>
References: <3170f42f0710291152xdd274d1wa0e066fb62d03304@mail.gmail.com>
	<200710292224.10846.opensource@till.name>
Message-ID: <3170f42f0710292036y4c99f24ck85dc15f241b3d40f@mail.gmail.com>

> Maybe you can convince upstream to use an "_" instead of an "-" in this
> version string.

Yes, I will try that.

> httrack also uses a versionid, which does not include a "-",
> e.g. httrack 3.41-3 is the same as httrack 3.41.22.

I am aware of that. However the 3.41-3-like scheme is more visible.
They used it for naming the tarball, widely throughout
http://www.httrack.com/page/2/en/index.html, in history.txt, in
http://www.httrack.com/page/4/en/index.html and in the output of
httrack --help. 3.41.22 has been used for naming the directory that
one gets on extracting the release tarball.

Therefore I am going with the former scheme after modifying it to
3.41.3 until there is some news from upstream.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From petersen at redhat.com  Tue Oct 30 04:16:30 2007
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 30 Oct 2007 14:16:30 +1000
Subject: source file audit - 2007-10-17
In-Reply-To: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
References: <20071019140126.74e84103@ghistelwchlohm.scrye.com>
Message-ID: <4726B01E.1000201@redhat.com>

> petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk

Upstream move the location of the source. :-/
I should probably complain about that.
(There is a new release available which I'll build soon for f9.)

> petersen:BADSOURCE:scim-1.4.7.tar.gz:scim

Upstream re-rolled the source tarball apparently. :-\
(doxygen doc files were updated.)

-Jens



From Lam at Lam.pl  Tue Oct 30 06:20:38 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 30 Oct 2007 07:20:38 +0100
Subject: Might Be A Problem With NM
In-Reply-To: <1193712561.16349.3.camel@localhost6.localdomain6>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
	<1193692618.3927.42.camel@localhost.localdomain>
	<1193712561.16349.3.camel@localhost6.localdomain6>
Message-ID: <20071030072038.65f7c7ca@pensja.lam.pl>

Dnia 2007-10-29, o godz. 20:49:21 Richi Plana <myfedora at richip.dhs.org>
napisa?(a):

> In the meantime, would a feature request to make NetworkManager leave
> the interfaces alone on startup?
It did in F8t3 (not only left it alone, but the GNOME applet correctly
showed which NIC is active), I'd call it a regression. I don't use /home over
NFS, but it's very annoying having to click the same option every time I log
in (and sometimes I do it few times a day with the devel machine, it's not
true that people don't reboot their laptops). It really needs to remember some
settings (I also want it to disable my wireless card, a useless waste of
power).

Oh, and it looks like it's not NM that's disconnecting my network - it's
rather the applet giving NM the command upon startup.

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

From dtimms at iinet.net.au  Tue Oct 30 06:25:40 2007
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 30 Oct 2007 17:25:40 +1100
Subject: Fedorability of dvbcut ?
In-Reply-To: <47257C36.9060607@cs.tu-berlin.de>
References: <47248975.7050901@iinet.net.au>	<20071028153047.GC23359@auslistsprd01.us.dell.com>
	<47257C36.9060607@cs.tu-berlin.de>
Message-ID: <4726CE64.8040506@iinet.net.au>

Christoph H?ger wrote:
> Matt Domsch schrieb:
>> On Mon, Oct 29, 2007 at 12:07:01AM +1100, David Timms wrote:
>>> And if that's the case, how does the included kernel module for 
>>> controlling / receiving mpeg2 transport streams from my DVB card fit 
>>> with Fedora ?
>> The hardware manufacturer will have a patent license that allows them
>> to use mpeg2.  That same patent license most likely does not extend to you
>> as an end user for use outside of their hardware.
>>
> 
> As far as I know there is no mpeg2 decoding done in a dvb driver (it
> will probably come from videolinux rather then from the hw-mf.
That's probably right: it provides the software api to tune a frequency, 
and controls a dsp to demodulate the TV signal, simply placing the whole 
transmitted stream bytes on /dev/dvb/adapter/dvr0.
Fedora's dvb-apps provides tzap used thusly:
tzap -c "a channel" would seem to be actually demuxing the mpeg stream 
to the single program id selected within that tuned frequency. That 
would seem to be needing knowledge of the mpeg data ?

DaveT.



From j.w.r.degoede at hhs.nl  Tue Oct 30 06:40:37 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 30 Oct 2007 07:40:37 +0100
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
 repo?
In-Reply-To: <6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>	<1193524190.2269.7.camel@ignacio.lan>	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
Message-ID: <4726D1E5.8030101@hhs.nl>

Mark wrote:
>>> Packaging is not a free thing. It takes time energy and someone who is
>>> going to deal with it. Most people who have packages are usually
>>> swamped as it is... so if you see something you would like to get into
>>> Fedora.. first check to see if someone is already packaging it, and
>>> then volunteer to do it yourself (or help someone who can). Otherwise
>>> its not going to happen.
>> Plus, there's a little fame if not fortune, and usually a few people
>> willing to help.
>>
>> I'd be willing to be that if you can *use* netbeans, you can certainly
>> learn to *package* netbeans, and as an avid user, you're in excellent
>> position to make sure the package actually works.  :)
>>
>> -Eric
> 
> I can't make RPM packages from scratch so therefore i think it's best
> to leave that to a professional RPM packager. But if noone else is
> willing to do it than i would like to give it a try.. and i probably
> need a lot of help along the way.
> 
> So is anyone up to this? or is there someone that is willing to help
> me with this? i have nearly no rpm packaging experience. (i edited
> specs before and compiled the package but i didn't made a spec from
> scratch)
> 

I think that having netbeans in Fedora would be great, so I'm wlling to help 
were I can (I already maintain 170+ packages). But my java packaging experience 
is limited. Are there any jpackage people here who are also willing to help? 
Nicolas? Ville?

Also if I were you I would start with trying to get it to compile on F-8 using 
icedtea, don't worry about packaging yet, first just try to get it to compile 
and run from the released sources?

(Are the sources complete?)

Regards,

Hans



From nicolas.mailhot at laposte.net  Tue Oct 30 08:43:04 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 30 Oct 2007 09:43:04 +0100 (CET)
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora 
 repo?
Message-ID: <57662.192.54.193.51.1193733784.squirrel@rousalka.dyndns.org>


Le Mar 30 octobre 2007 07:40, Hans de Goede a ?crit :

> I think that having netbeans in Fedora would be great, so I'm wlling
> to help
> were I can (I already maintain 170+ packages). But my java packaging
> experience
> is limited. Are there any jpackage people here who are also willing to
> help?
> Nicolas? Ville?

I can certainly give you some times though I've not been active
java-side for some time (but I don't think things have changed much)

Basically packaging a java app is:
1. download huge "source" archive
2. remove every pre-built jar/war/ear in it
3. comb it for private source copies of external components, and
remove them
4. figure how the file layout should be on disk to respect FHS
5. figure if the result should be split in subpackages
6. try to locate all the deps you've removed in 2. and 3., check
they're all already packaged and if not recurse packaging on them
7. create all the classpathes the app uses at build or run time with
jpackage routines, add needed builddeps manually
8. build
9. merge everything fedora & jpp-side so hopefully someone volunteers
co-maintaining. Merging jpp-side means purging the spec of fedorisms,
though our conventions are not as invasive as those of other distros
10. fix bugs
11. re-do the whole dance for new versions
12. profit (actually I lie there is no profit stage)

If you manage to do netbeans you'll probably be in a good position to
update jpackage doc (in jpackage-utils %doc), copy whatever is
relevant to the Fedora wiki, and comment on the "modules" JSR (which
is supposed to fix most dependency-building problems in java, except
I'm not sure anyone reviewed it yet for rpm integration and when it
ships in java 7 it'll be too late)

-- 
Nicolas Mailhot



From markg85 at gmail.com  Tue Oct 30 09:15:32 2007
From: markg85 at gmail.com (Mark)
Date: Tue, 30 Oct 2007 10:15:32 +0100
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <57662.192.54.193.51.1193733784.squirrel@rousalka.dyndns.org>
References: <57662.192.54.193.51.1193733784.squirrel@rousalka.dyndns.org>
Message-ID: <6e24a8e80710300215m7142c511x745095c27fff0a02@mail.gmail.com>

2007/10/30, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
> Le Mar 30 octobre 2007 07:40, Hans de Goede a ?crit :
>
> > I think that having netbeans in Fedora would be great, so I'm wlling
> > to help
> > were I can (I already maintain 170+ packages). But my java packaging
> > experience
> > is limited. Are there any jpackage people here who are also willing to
> > help?
> > Nicolas? Ville?
>
> I can certainly give you some times though I've not been active
> java-side for some time (but I don't think things have changed much)
>
> Basically packaging a java app is:
> 1. download huge "source" archive
> 2. remove every pre-built jar/war/ear in it
> 3. comb it for private source copies of external components, and
> remove them
> 4. figure how the file layout should be on disk to respect FHS
> 5. figure if the result should be split in subpackages
> 6. try to locate all the deps you've removed in 2. and 3., check
> they're all already packaged and if not recurse packaging on them
> 7. create all the classpathes the app uses at build or run time with
> jpackage routines, add needed builddeps manually
> 8. build
> 9. merge everything fedora & jpp-side so hopefully someone volunteers
> co-maintaining. Merging jpp-side means purging the spec of fedorisms,
> though our conventions are not as invasive as those of other distros
> 10. fix bugs
> 11. re-do the whole dance for new versions
> 12. profit (actually I lie there is no profit stage)
>
> If you manage to do netbeans you'll probably be in a good position to
> update jpackage doc (in jpackage-utils %doc), copy whatever is
> relevant to the Fedora wiki, and comment on the "modules" JSR (which
> is supposed to fix most dependency-building problems in java, except
> I'm not sure anyone reviewed it yet for rpm integration and when it
> ships in java 7 it'll be too late)

Sounds hard to do.. o well i will just give it my best shot soon. i
think i'm gonna wait till fordora 8 is released (within a week or so)
because i don't really want to install a rawhide or 7 at this point.



From rms at 1407.org  Tue Oct 30 09:53:48 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Tue, 30 Oct 2007 09:53:48 +0000
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <6e24a8e80710300215m7142c511x745095c27fff0a02@mail.gmail.com>
References: <57662.192.54.193.51.1193733784.squirrel@rousalka.dyndns.org>
	<6e24a8e80710300215m7142c511x745095c27fff0a02@mail.gmail.com>
Message-ID: <20071030095348.GA7453@roque.1407.org>

On Tue, Oct 30, 2007 at 10:15:32AM +0100, Mark wrote:
> Sounds hard to do.. o well i will just give it my best shot soon. i
> think i'm gonna wait till fordora 8 is released (within a week or so)
> because i don't really want to install a rawhide or 7 at this point.

It's not very hard, it simply has a *lot* of easy things to do. Java
people really need to learn to not make monstruous application that
bring everything they need after them. That's the Proprietary way :)

Rui

-- 
Hail Eris!
Today is Pungenday, the 11st day of The Aftermath in the YOLD 3173
+ 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...?



From nicolas.mailhot at laposte.net  Tue Oct 30 10:11:01 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 30 Oct 2007 11:11:01 +0100 (CET)
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora 
 repo?
Message-ID: <40081.192.54.193.51.1193739061.squirrel@rousalka.dyndns.org>


Le Mar 30 octobre 2007 10:53, Rui Miguel Silva Seabra a ?crit :
> On Tue, Oct 30, 2007 at 10:15:32AM +0100, Mark wrote:
>> Sounds hard to do.. o well i will just give it my best shot soon. i
>> think i'm gonna wait till fordora 8 is released (within a week or
>> so)
>> because i don't really want to install a rawhide or 7 at this point.
>
> It's not very hard, it simply has a *lot* of easy things to do. Java
> people really need to learn to not make monstruous application that
> bring everything they need after them. That's the Proprietary way :)

Well SUN has told Java people "you do not need shared system
components, having private copies of everything your app relies on is
fine". That's the root of this particular mess.

-- 
Nicolas Mailhot



From hun at n-dimensional.de  Tue Oct 30 10:42:25 2007
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Tue, 30 Oct 2007 11:42:25 +0100
Subject: How to generate videoaliases/foo.xinf for hwdata?
Message-ID: <47270A91.7070305@n-dimensional.de>

Hi,

I guess that for proper integration of xorg-x11-drv-radeonhd into Fedora
the package should ship a /usr/share/hwdata/videoaliases/radeonhd.xinf file.

Is the xinf file format documented somewhere? Are there tools to create it?
-- 
Hans Ulrich Niedermann



From buildsys at redhat.com  Tue Oct 30 10:49:02 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 30 Oct 2007 06:49:02 -0400
Subject: rawhide report: 20071030 changes
Message-ID: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>

New package compiz-manager
	A wrapper script to start compiz with proper options


 
Updated Packages:

R-2.6.0-3.fc8
-------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3
- fix multilib conflicts (bz 343061)

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-2
- add R CMD javareconf to post (bz 354541)
- don't pickup bogus perl provides (bz 356071)
- use xdg-open, drop requires for firefox/evince (bz 351841)

* Thu Oct 04 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-1
- bump to 2.6.0

alsa-lib-1.0.15-1.fc8
---------------------
* Mon Oct 29 2007 Martin Stransky <stransky at redhat.com> 1.0.15-1
- updated to 1.0.15 final

alsa-utils-1.0.15-1.fc8
-----------------------
* Mon Oct 29 2007 Martin Stransky <stransky at redhat.com> 1.0.15-1
- updated to 1.0.15 final

bigboard-0.5.26-1.fc8
---------------------
* Fri Oct 26 2007 Colin Walters <walters at redhat.com> - 0.5.26-1
- new upstream

* Fri Oct 26 2007 Colin Walters <walters at redhat.com> - 0.5.25-1
- new upstream

* Thu Oct 25 2007 Colin Walters <walters at redhat.com> - 0.5.24-1
- new upstream

clamav-0.91.2-3.fc8
-------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.91.2-3
- remove RAR decompression code from source tarball because of 
  legal problems (resolves 334371)
- correct license tag

fedora-logos-8.0.2-1.fc8
------------------------
* Mon Oct 29 2007 Matthias Clasen <mclasen at redhat.com> - 8.0.2-1
- Add Infinity splash screens for KDE and Gnome

fedora-release-8-3
------------------
* Mon Oct 29 2007 Jesse Keating <jkeating at redhat.com> - 8-3
- Update the compose configs

* Fri Oct 19 2007 Jesse Keating <jkeating at redhat.com> - 8-2
- Disable development, enable release/updates.

* Fri Oct 19 2007 Jesse Keating <jkeating at redhat.com> - 8-1
- Build for Fedora 8, add release name, update compose configs

generic-logos-8.0.2-1.fc8
-------------------------

gnome-phone-manager-0.30-1.fc8
------------------------------
* Mon Oct 29 2007 - Bastien Nocera <bnocera at redhat.com> - 0.30-1
- Update to 0.30
- Fix sending non-ASCII texts (for real)
- Add debugging improvements

gnome-screensaver-2.20.0-9.fc8
------------------------------
* Mon Oct 29 2007 Warren Togami <wtogami at redhat.com> - 2.20.0-9
- Blank screen by default in order to save power

* Wed Oct 10 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-8
- Require the appropriate artwork (bug 327161)

* Fri Oct 05 2007 Ray Strode <rstrode at redhat.com> - 2.20.0-7
- fix up gamma handling, patch by John Bryant (should fix 290611)

gnucash-2.2.1-4.fc8
-------------------
* Thu Oct 25 2007 Bill Nottingham <notting at redhat.com> - 2.2.1-4
- multilib fixes (#341331, #357161, #246382)
gnucash-docs-2.2.0-2.fc8
------------------------
* Mon Oct 29 2007 Bill Nottingham <notting at redhat.com> - 2.2.0-2
- gnucash multilib fixes (#341331, #357161, #246382)
kde-settings-3.5-34.fc8
-----------------------
* Mon Oct 29 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 3.5-34
- ksplashrc: Theme=FedoraInfinity (thanks to Chitlesh Goorah)

kernel-2.6.23.1-41.fc8
----------------------
* Mon Oct 29 2007 Chuck Ebbert <cebbert at redhat.com>
- Enable hamradio drivers.

* Mon Oct 29 2007 David Woodhouse <dwmw2 at redhat.com>
- Disable PS3 wireless for now (#343901)

* Mon Oct 29 2007 Dave Jones <davej at redhat.com>
- Revert: x86_64: allocate sparsemem memmap above 4G (fixes bz #249174)
  (Much thanks to Martin Ebourne for tracking this down).

libmcrypt-2.5.8-4.fc8
---------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.5.8-4
- multilib fix (bz 342221)

livecd-tools-013-1.fc8
----------------------
* Mon Oct 29 2007 Jeremy Katz <katzj at redhat.com> - 013-1
- Lots of config updates
- Support 'device foo' to say what modules go in the initramfs
- Support multiple kernels being installed
- Allow blacklisting kernel modules on boot with blacklist=foo
- Improve bootloader configs
- Split configs off for f8

ntfs-3g-2:1.1030-1.fc8
----------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1030-1
- bump to 1.1030

online-desktop-0.2.22-1.fc8
---------------------------
* Fri Oct 26 2007 Colin Walters <walters at redhat.com> - 0.2.22-1
- new upstream

* Thu Oct 25 2007 Colin Walters <walters at redhat.com> - 0.2.21-1
- new upstream

* Tue Oct 23 2007 Colin Walters <walters at redhat.com> - 0.2.20-2
- Add some deps (b.redhat.com #348591)

perl-Image-ExifTool-7.00-1.fc8
------------------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 7.00-1
- 7.00

physfs-1.0.1-7.fc8
------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.0.1-7
- fix multilib conficts

pungi-1.1.9-1.fc8
-----------------
* Mon Oct 29 2007 Jesse Keating <jkeating at redhat.com> - 1.1.9-1
- Remove oversized cached packages (fixes reget problem)

rhythmbox-0.11.2-10.fc8
-----------------------
* Mon Oct 29 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-10
- Update patch for #242260, tooltips weren't working
- Add patch to fix problems importing files with spaces in them (#291571)
- Add patch to remove iPod tracks when removed, rather than put them
  in the trash (#330101)

selinux-policy-3.0.8-40.fc8
---------------------------
* Mon Oct 29 2007 Jeremy Katz <katzj at redhat.com> - 3.0.8-40
- fix ps3 disk tyop

* Mon Oct 29 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-39
- Allow unconfined to run crontab

* Sat Oct 27 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-38
- Allow ip to load sys_modules in order to bring up ip6 networks

strigi-0.5.5-2.fc8.2
--------------------
* Mon Oct 29 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.5.5-2.1
- Apply plugin soname patch to actually fix dangling symlink issue
- Move ldconfig calls to -libs subpackage

* Mon Oct 29 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.5.5-2.1
- Rebuild in an attempt to fix dangling symlinks

udunits-1.12.4-12.fc8
---------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-12
- multilib enable

wpa_supplicant-1:0.5.7-15.fc8
-----------------------------
* Sun Oct 28 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-15
- Fix Dynamic WEP associations with mac80211-based drivers

* Sun Oct 28 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-14
- Don't error an association on duplicate CA cert additions

* Wed Oct 24 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-13
- Correctly set the length of blobs added via the D-Bus interface

wvdial-1.60-3.fc8
-----------------
* Mon Oct 29 2007 Bill Nottingham <notting at redhat.com> - 1.60-3
- fix remotename patch (#348831, #344391)

xsupplicant-1.2.8-4.fc8.3
-------------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.2.8-4.3
- fix docs patch

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.2.8-4.2
- multilib fix (bz 228395)

Broken deps for i386
----------------------------------------------------------
	R - 2.6.0-3.fc8.i386 requires perl(Text::DelimMatch)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	R - 2.6.0-3.fc8.x86_64 requires perl(Text::DelimMatch)
	R - 2.6.0-3.fc8.i386 requires perl(Text::DelimMatch)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8



Broken deps for ppc
----------------------------------------------------------
	R - 2.6.0-3.fc8.ppc64 requires perl(Text::DelimMatch)
	R - 2.6.0-3.fc8.ppc requires perl(Text::DelimMatch)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp



Broken deps for ppc64
----------------------------------------------------------
	R - 2.6.0-3.fc8.ppc64 requires perl(Text::DelimMatch)
	kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
	kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8kdump





From martin at bugs.unl.edu.ar  Tue Oct 30 11:19:44 2007
From: martin at bugs.unl.edu.ar (Martin Marques)
Date: Tue, 30 Oct 2007 08:19:44 -0300
Subject: Arial font on OOo
Message-ID: <47271350.1010207@bugs.unl.edu.ar>

How do I get an Arial font on OOo for Fedora 7?



From jkeating at redhat.com  Tue Oct 30 11:19:48 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 07:19:48 -0400
Subject: Might Be A Problem With NM
In-Reply-To: <20071030072038.65f7c7ca@pensja.lam.pl>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
	<1193692618.3927.42.camel@localhost.localdomain>
	<1193712561.16349.3.camel@localhost6.localdomain6>
	<20071030072038.65f7c7ca@pensja.lam.pl>
Message-ID: <20071030071948.15e63764@redhat.com>

On Tue, 30 Oct 2007 07:20:38 +0100
Leszek Matok <Lam at Lam.pl> wrote:

> It did in F8t3 (not only left it alone, but the GNOME applet correctly
> showed which NIC is active), I'd call it a regression. I don't
> use /home over NFS, but it's very annoying having to click the same
> option every time I log in (and sometimes I do it few times a day
> with the devel machine, it's not true that people don't reboot their
> laptops). It really needs to remember some settings (I also want it
> to disable my wireless card, a useless waste of power)

There was a period of time where the auto checkbox was not getting set
in gconf for new connections.  so if you have connections in gconf from
that period of time they won't autoconnect, but new connections added
now would.  You can use gconf-editor to find your connections and set
them to auto.  system -> networking -> connections

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/c43899da/attachment.sig>

From caolanm at redhat.com  Tue Oct 30 12:09:21 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 30 Oct 2007 12:09:21 +0000
Subject: Arial font on OOo
In-Reply-To: <47271350.1010207@bugs.unl.edu.ar>
References: <47271350.1010207@bugs.unl.edu.ar>
Message-ID: <1193746161.31627.48.camel@Jehannum>


On Tue, 2007-10-30 at 08:19 -0300, Martin Marques wrote:
> How do I get an Arial font on OOo for Fedora 7?

You shouldn't really need it, install the liberation fonts, "Liberation
Sans" is supposed to be metrically equivalent to Arial, i.e. effectively
the same size glyphs, spacing, etc. And fontconfig will automatically
suggest "Liberation Sans" as a replacement for anything (e.g. OOo)
requesting a replacement for "Arial" through it.

Otherwise google for "corefonts".

C.



From wolfy at nobugconsulting.ro  Tue Oct 30 11:38:08 2007
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 30 Oct 2007 13:38:08 +0200
Subject: I want to unorphan pam_mysql
In-Reply-To: <20071029231137.GL22312@stingr.net>
References: <20071029231137.GL22312@stingr.net>
Message-ID: <472717A0.3080801@nobugconsulting.ro>

Paul P Komkoff Jr wrote:
> Hi!
>
> I want to unorphan pam_mysql. I already took ownership in pkgdb for
> devel. The package was orphaned for a long time so new bild is
> available for review here:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=21817
>
> I have no intention to assign older releases to myself (they are EOL
> already), but I plan to open F-8 and F-8 branch as soon as I pass the
> review (if any).
>
> Any objections?
>
>
>   
Hi, Paul

Excellent idea!
If you need/want a hand helping you for EPEL, I'll be glad to assist. I 
am using it in Centos anyway.

    manuel




From rodd at clarkson.id.au  Tue Oct 30 11:41:53 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 30 Oct 2007 22:41:53 +1100
Subject: Arial font on OOo
In-Reply-To: <47271350.1010207@bugs.unl.edu.ar>
References: <47271350.1010207@bugs.unl.edu.ar>
Message-ID: <1193744514.3740.3.camel@localhost.localdomain>


On Tue, 2007-10-30 at 08:19 -0300, Martin Marques wrote:
> How do I get an Arial font on OOo for Fedora 7?

Right, for starters, this is certainly not a question that's appropriate
for the fedora-devel-list.  This list if for questions about development
of fedora, and not about how to get a MS font to work in fedora.

That said, you could find a copy of the arail ttf files and then copy
them to ~/.fonts

Please ask these questions in a more suitable forum next time.


R.

> 
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From martin at bugs.unl.edu.ar  Tue Oct 30 12:14:20 2007
From: martin at bugs.unl.edu.ar (Martin Marques)
Date: Tue, 30 Oct 2007 09:14:20 -0300
Subject: Arial font on OOo
In-Reply-To: <1193744514.3740.3.camel@localhost.localdomain>
References: <47271350.1010207@bugs.unl.edu.ar>
	<1193744514.3740.3.camel@localhost.localdomain>
Message-ID: <4727201C.7060503@bugs.unl.edu.ar>

Rodd Clarkson escribi?:
> On Tue, 2007-10-30 at 08:19 -0300, Martin Marques wrote:
>> How do I get an Arial font on OOo for Fedora 7?
> 
> Right, for starters, this is certainly not a question that's appropriate
> for the fedora-devel-list.  This list if for questions about development
> of fedora, and not about how to get a MS font to work in fedora.
> 
> That said, you could find a copy of the arail ttf files and then copy
> them to ~/.fonts
> 
> Please ask these questions in a more suitable forum next time.

Sorry Rodd, just noticed that I sent the mail to the wrong list. Sorry.

Anyway, I installed the ttf fonts from corefonts:

http://corefonts.sourceforge.net/

Sorry again.



From ark.hit at gmail.com  Tue Oct 30 12:42:02 2007
From: ark.hit at gmail.com (karthikeyan Govindarajan)
Date: Tue, 30 Oct 2007 18:12:02 +0530
Subject: fedora-devel-list Digest, Vol 44, Issue 169
In-Reply-To: <20071029123056.6648A72F0E@hormel.redhat.com>
References: <20071029123056.6648A72F0E@hormel.redhat.com>
Message-ID: <65d0b5300710300542t549e92d2xf395a49706ee2529@mail.gmail.com>

i have a problem in installing fedora 7 in my laptop
my laptop configuration is:
 Lenovo 3000 y 500 series
 Intel dual core(TM) T5500
2 GB RAM
Nvidia 7500
While installing all  are going fine. but after  rebooting  the laptop both
touchpad and  keyboard is not working.
i have  tried RHEL 5 and  fedora 6 i got the same result
Karthikeyan.



On 10/29/07, fedora-devel-list-request at redhat.com <
fedora-devel-list-request at redhat.com> wrote:
>
> Send fedora-devel-list mailing list submissions to
>         fedora-devel-list at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.redhat.com/mailman/listinfo/fedora-devel-list
> or, via email, send a message with subject or body 'help' to
>         fedora-devel-list-request at redhat.com
>
> You can reach the person managing the list at
>         fedora-devel-list-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fedora-devel-list digest..."
>
> Today's Topics:
>
>    1. Re: Package XYZ is not signed (Till Maas)
>    2. Re: koji server installation (Oliver Falk)
>    3. Re: koji server installation (Oliver Falk)
>    4. Re: ALSA 1.0.15 update test kernels available - user space
>       packages (Martin Stransky)
>    5. Re: Package XYZ is not signed (Nicolas Mailhot)
>    6. Re: nautilus/GNOME VFS ACL support capabilities? (Tomasz Torcz)
>    7. rawhide report: 20071029 changes (Build System)
>    8. hibernation (Thomas Vander Stichele)
>    9. Re: Possibility of inclusion of a "kde-desktop-effects"
>       version in        compiz (Sebastian Vahl)
>   10. Re: Firefox backspace button action should be "Previous Page"
>       not "Page Up" (Christopher Aillon)
>   11. Re: rawhide report: 20071029 changes (Hans de Goede)
>   12. Re: rawhide report: 20071029 changes (Rahul Sundaram)
>   13. Re: rawhide report: 20071029 changes (dragoran)
>   14. dangling symlinks in rpm packages for Fedora-devel
>       (Florian La Roche)
>
>
> ---------- Forwarded message ----------
> From: Till Maas <opensource at till.name>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 08:27:23 +0100
> Subject: Re: Package XYZ is not signed
> On So Oktober 28 2007, Andrew Farris wrote:
>
> > prevent that either (in rawhide).  Testing rawhide isn't for boxes with
> > corporate sensitive data...
>
> This seems not to be common knowledge, because afaik even Fedora
> Maintainers
> use Rawhide on a system, where they create new packages.
>
> > Actually signing the package from the build system would change very
> little
> > other than insure that the mirror you're downloading from did not bring
> in
> > a new package that doesn't belong.
>
> Imho it is a big benefit, because it is very easy for a mirror maintainer
> to
> change a package. Also someone who breaks into a mirror can easily cause
> heavy damage. And last but not least, the manipulation of the package can
> also happen on the connection to the mirror, e.g. on conferences with
> free/open wifi/internet access.
>
> Regards,
> Till
>
>
> ---------- Forwarded message ----------
> From: Oliver Falk <oliver at linux-kernel.at>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 08:44:54 +0100
> Subject: Re: koji server installation
> On 10/25/2007 07:48 PM, Mike Bonnet wrote:
> > On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
> >> In terms of your other problems, you need to to bootstrap Koji by
> >> importing a bunch of pre-built packages so Koji is able to populate a
> >> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
> >> guide, I'll point you at it when it's posted.
> >
> > I've put up a setup/bootstrapping guide here:
> >
> > https://fedoraproject.org/wiki/Koji/ServerBootstrap
> >
> > and linked it from the bottom of the ServerHowTo.  Give it a try and let
> > me know if you run into problems or have suggestions on how to improve
> > the guide.
>
> Much the same like mine, but more complete and added 'features' like the
> bypass stuff!
>
> Good work!
>
> -of
>
>
>
>
> ---------- Forwarded message ----------
> From: Oliver Falk <oliver at linux-kernel.at>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 08:44:54 +0100
> Subject: Re: koji server installation
> On 10/25/2007 07:48 PM, Mike Bonnet wrote:
> > On Thu, 2007-10-18 at 11:06 -0400, Mike Bonnet wrote:
> >> In terms of your other problems, you need to to bootstrap Koji by
> >> importing a bunch of pre-built packages so Koji is able to populate a
> >> buildroot and satisfy BuildRequires.  I'm writing up a bootstrapping
> >> guide, I'll point you at it when it's posted.
> >
> > I've put up a setup/bootstrapping guide here:
> >
> > https://fedoraproject.org/wiki/Koji/ServerBootstrap
> >
> > and linked it from the bottom of the ServerHowTo.  Give it a try and let
> > me know if you run into problems or have suggestions on how to improve
> > the guide.
>
> Much the same like mine, but more complete and added 'features' like the
> bypass stuff!
>
> Good work!
>
> -of
>
>
>
>
> ---------- Forwarded message ----------
> From: Martin Stransky <stransky at redhat.com>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 08:54:32 +0100
> Subject: Re: ALSA 1.0.15 update test kernels available - user space
> packages
> Jon Masters wrote:
> > On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
> >> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> >> would get us up-to-date with the latest audio drivers and fix many
> >> problems with audio drivers not working, or only partially working.
> >>
> >> Test kernels for i686 and x86_64 are available at:
> >>
> >>   http://people.redhat.com/cebbert/kernels/F8/
> >>
>
> User space packages (alsa 1.0.15) are here:
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22679
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22680
>
> If the updated kernel is included in F8 please add them there, too.
>
> ma.
>
>
>
>
> ---------- Forwarded message ----------
> From: "Nicolas Mailhot" <nicolas.mailhot at laposte.net>
> To: "Development discussions related to Fedora" <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 09:26:01 +0100 (CET)
> Subject: Re: Package XYZ is not signed
>
> Le Lun 29 octobre 2007 08:27, Till Maas a ?crit :
> > On So Oktober 28 2007, Andrew Farris wrote:
> >
> >> prevent that either (in rawhide).  Testing rawhide isn't for boxes
> >> with
> >> corporate sensitive data...
> >
> > This seems not to be common knowledge, because afaik even Fedora
> > Maintainers use Rawhide on a system, where they create new packages.
>
> And it's totally unrealistic because the only people who're going to
> sit before a test box without real data are people paid for testing
> (ie not community contributors).
>
> You can't have it both ways - either you pay people to do testing on
> fake safe data (very expensive), or you have volunteers testing on
> their own systems (with their own data), and you have to work a
> minimum so you only eat this data in very rare cases.
>
> >> Actually signing the package from the build system would change very
> >> little
> >> other than insure that the mirror you're downloading from did not
> >> bring in
> >> a new package that doesn't belong.
> >
> > Imho it is a big benefit,
>
> And even kernel.org does it so anyone who feels autosigning packages
> before uploading to the root mirrors is "unprofessional" can complain
> on LKML and get educated :).
>
> Regards,
>
> --
> Nicolas Mailhot
>
>
>
>
> ---------- Forwarded message ----------
> From: Tomasz Torcz <tomek at crocom.com.pl>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 11:04:31 +0100
> Subject: Re: nautilus/GNOME VFS ACL support capabilities?
> Dnia 25-10-2007, Cz o godzinie 03:42 -0400, Jon Masters napisa?(a):
> > Yo,
> >
> > Rather than sleeping, I was just looking at a few capabilities currently
> > in F8 and thinking about what would be nice in the future.
> >
> > Unless I'm missing something, GNOME's nautilus (GNOME VFS) doesn't seem
> > to understand ACLs. Am I missing something? Heck, I remember 5 or 6
> > years ago patching in the original ACL patches from bestbits and even
> > setting ACLs remotely from a Windows machine using Samba, by right
> > clicking on the export files. Does this not work in nautilus?
>
>   Nautilus in Solaris 10 has ACL support. I don't know if patches were
> submitted upstream.
>
>
> --
> Tomasz Torcz
> Crocom Computer Systems
>
>
>
>
> ---------- Forwarded message ----------
> From: Build System <buildsys at redhat.com>
> To: fedora-devel-list at redhat.com, fedora-test-list at redhat.com
> Date: Mon, 29 Oct 2007 06:20:07 -0400
> Subject: rawhide report: 20071029 changes
>
>
>
> Updated Packages:
>
> anaconda-11.3.0.48-1
> --------------------
> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.48-1
> - Fix docs location (#356021)
> - Live images don't have xfsprogs by default, so look for xfsprogs before
>   allowing xfs as a filesystem (#355351)
> - Don't show bridge devices (#354561)
>
> bluez-utils-3.20-4.fc8
> ----------------------
> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 3.20-4
> - Follow guidelines for scriplets to quiet error (#354531)
>
> compiz-fusion-0.6.0-5.fc8
> -------------------------
> * Sun Oct 28 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-5
> - Rediff patch
>
> * Sun Oct 28 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-4
> - Fix previous patch
>
> * Sat Oct 27 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.6.0-3
> - Apply patch from upstream to fix RH #354601
>
> gnokii-0.6.18-3.fc8
> -------------------
> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
> - Even better multilib fixing (#335161)
>
> libsoup-2.2.103-1.fc8
> ---------------------
> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 2.2.103-1
> - update to 2.2.103 to fix a rhythmbox crasher (#343561)
>
> * Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 2.2.102-1
> - Update to 2.2.102
>
> Broken deps for i386
> ----------------------------------------------------------
>         kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires
> kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8
>         kmod-em8300-PAE - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.i686 requires
> kernel-i686 = 0:2.6.23-0.220.rc9.git2.fc8PAE
>         kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires
> kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
>         kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686requires kernel-i686 = 0:
> 2.6.23-0.142.rc3.git10.fc8PAE
>
>
>
> Broken deps for x86_64
> ----------------------------------------------------------
>         kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.x86_64 requires
> kernel-x86_64 = 0:2.6.23-0.220.rc9.git2.fc8
>         kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires
> kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
>
>
>
> Broken deps for ppc
> ----------------------------------------------------------
>         kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires
> kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8
>         kmod-em8300-smp - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc requires
> kernel-ppc = 0:2.6.23-0.220.rc9.git2.fc8smp
>
>
>
> Broken deps for ppc64
> ----------------------------------------------------------
>         kmod-em8300 - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64 requires
> kernel-ppc64 = 0:2.6.23-0.220.rc9.git2.fc8
>         kmod-em8300-kdump - 0.16.3-5.2.6.23_0.220.rc9.git2.fc8.ppc64requires kernel-ppc64 = 0:
> 2.6.23-0.220.rc9.git2.fc8kdump
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Vander Stichele <thomas at apestaart.org>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 11:42:34 +0100
> Subject: hibernation
> Hi,
>
> is hibernation working for other people currently ?
>
> I installed test3 on my new T61, and am running 2.6.23.1-35.fc8, but
> when I choose "hibernate" from the logout menu, it hibernates just fine,
> and goes to sleep, but on the next boot it just boots the kernel without
> restoring state.  This worked fine in F7.
>
> If it's me and not a general problem, how do I debug it further ? Is
> there some docs on how this is supposed to be working in Fedora ?
>
> Thomas
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Sebastian Vahl <ml at deadbabylon.de>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 11:48:03 +0100
> Subject: Re: Possibility of inclusion of a "kde-desktop-effects" version
> in compiz
> Am Sa 27.Oktober 2007 schrieb Neal Becker:
> > Thanks.  I grabbed compiz-manager.  It needs minor fixes for x86_64.
> >
> > All /usr/lib needs to be /usr/lib64 on x86_64.
>
> This was also an issue in the review process and is fixed now (in the
> latest
> srpm which was approved).
>
> Sebastian
>
>
> ---------- Forwarded message ----------
> From: Christopher Aillon <caillon at redhat.com>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 11:52:53 +0100
> Subject: Re: Firefox backspace button action should be "Previous Page" not
> "Page Up"
> Mark wrote:
> > Hey,
> >
> > i was just wondering why Firefox had page up action bound to the
> > backspace button. and i end up reading this bug report:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=358764
> >
> > Now the default action for Firefox in fedora is "page up" and i think
> > nearly every keyboard in the world _has_ a page up key so please
> > remove that silly default action. A patch for this to give the
> > backspace the "previous page" (or whatever you want to call it) action
> > is very simple:
> >
> > type (in the address bar): about:config
> > find: browser.backspace_action
> > The value is likely to be on: 1. Change that value to 0 and backspace
> > is acting the way it should do.
> >
> > I don't know where firefox is getting the "logic" to make firefox
> > default backspace action "previous page" in windows and "page up" in
> > linux.. just doesn't make sense to me.
> >
> > And could this be patched in the firefox that is in the fedora repo?
> > or (if fedora chooses not to patch it to the "previous page" action)
> > than make it no action at all!! "page up" is just not good.
> >
> > Bigzilla: https://bugzilla.redhat.com/show_bug.cgi?id=355511
> >
> > Posted here because i would like to know the users and developer
> > opinions about this.
> >
>
> Authoritatively, the action for backspace should be to do nothing on
> Linux.  This was discussed with the GNOME usability guy, Sun, Novell,
> and Mozilla a bit ago and was checked in as per the bug you posted.  It
> appears that it is still not in the 2.x branch though other distros such
> have patched it in, with a quick glance.
>
> I guess having had this set in my local preferences for ages, I sort of
> forgot about it in the 2.x branch.  I am okay with turning this pref to
> do nothing even though it will be last minute as this is what upstream
> has decided and will be in future versions of Firefox as it best matches
> the platform convention.
>
>
>
>
> ---------- Forwarded message ----------
> From: Hans de Goede <j.w.r.degoede at hhs.nl>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 11:43:19 +0100
> Subject: Re: rawhide report: 20071029 changes
> Build System wrote:
> >
> >
> >
> > Updated Packages:
> >
> > gnokii-0.6.18-3.fc8
> > -------------------
> > * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
> > - Even better multilib fixing (#335161)
> >
>
> How does this match with us being in freeze?
>
> Regards,
>
> Hans
>
>
>
>
> ---------- Forwarded message ----------
> From: Rahul Sundaram <sundaram at fedoraproject.org>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 16:33:34 +0530
> Subject: Re: rawhide report: 20071029 changes
> Hans de Goede wrote:
> > Build System wrote:
> >>
> >>
> >>
> >> Updated Packages:
> >>
> >> gnokii-0.6.18-3.fc8
> >> -------------------
> >> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
> >> - Even better multilib fixing (#335161)
> >>
> >
> > How does this match with us being in freeze?
>
> The bug in question has been marked as a blocker.
>
> Rahul
>
>
>
>
> ---------- Forwarded message ----------
> From: dragoran <drago01 at gmail.com>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: Mon, 29 Oct 2007 12:06:36 +0100
> Subject: Re: rawhide report: 20071029 changes
> Hans de Goede wrote:
> > Build System wrote:
> >>
> >>
> >>
> >> Updated Packages:
> >>
> >> gnokii-0.6.18-3.fc8
> >> -------------------
> >> * Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 0.6.18-3
> >> - Even better multilib fixing (#335161)
> >>
> >
> > How does this match with us being in freeze?
> >
> that was a blocker:
>
> --------------------------------
>
> * Bug 335161: ASSIGNED - triad (Linus Walleij)
> - multilib file conflicts in gnokii
>
> Fix was incomplete, needs a rebuild. This prevents people from being
> able to yum upgrade from F8Test3 to F8 final.
> ----------------
>
> or are you talking about the "better fix" ?
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Florian La Roche <laroche at redhat.com>
> To: fedora-devel-list at redhat.com
> Date: Mon, 29 Oct 2007 13:30:46 +0100
> Subject: dangling symlinks in rpm packages for Fedora-devel
> Hello all,
>
> here the output of a test script that checks all rpm packages
> for dangling symlinks. It does not look at an installed system,
> but only at files included within rpm packages, so there are
> a few false reports here for files/dirs created within scripts.
>
> Output is against a current Fedora-devel tree. I welcome help to
> review this list, so remaining items can be looked at during the
> F9 devel phase.
>
> regards,
>
> Florian La Roche
>
>
>
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier to
> /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed.ttf
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Courier-Bold
> to /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed-Bold.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Courier-BoldOblique to
> /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Courier-Oblique to
> /usr/share/fonts/dejavu-fonts/DejaVuSerifCondensed-Oblique.ttf
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Helvetica to
> /usr/share/fonts/dejavu-fonts/DejaVuSans.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Helvetica-Bold to
> /usr/share/fonts/dejavu-fonts/DejaVuSans-Bold.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Helvetica-BoldOblique to
> /usr/share/fonts/dejavu-fonts/DejaVuSans.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Helvetica-Oblique to
> /usr/share/fonts/dejavu-fonts/DejaVuSans-Oblique.ttf
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Times-Roman
> to /usr/share/fonts/dejavu-fonts/DejaVuSerif.ttf
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-Bold
> to /usr/share/fonts/dejavu-fonts/DejaVuSerif-Bold.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Utopia-BoldItalic to
> /usr/share/fonts/dejavu-fonts/DejaVuSerif-BoldOblique.ttf
> Inventor has dangling symlink from /usr/share/Inventor/fonts/Utopia-Italic
> to /usr/share/fonts/dejavu-fonts/DejaVuSerif-Oblique.ttf
> Inventor has dangling symlink from
> /usr/share/Inventor/fonts/Utopia-Regular to
> /usr/share/fonts/dejavu-fonts/DejaVuSerif.ttf
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2
> /doc/docbook-xsl.css to /usr/share/doc/asciidoc-8.2.2/stylesheets/docbook-
> xsl.css
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/doc/images
> to /usr/share/doc/asciidoc-8.2.2/images
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/ASCIIMathML.js
> to /usr/share/doc/asciidoc-8.2.2/javascripts/ASCIIMathML.js
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/CHANGELOG.txt
> to /usr/share/doc/asciidoc-8.2.2/CHANGELOG.txt
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/INSTALL.txt
> to /usr/share/doc/asciidoc-8.2.2/INSTALL.txt
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/LaTeXMathML.js
> to /usr/share/doc/asciidoc-8.2.2/javascripts/LaTeXMathML.js
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/README.txt
> to /usr/share/doc/asciidoc-8.2.2/README.txt
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2
> /examples/website/asciidoc-docbook-xsl.txt to /usr/share/doc/asciidoc-
> 8.2.2/docbook-xsl/asciidoc-docbook-xsl.txt
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/images
> to /usr/share/doc/asciidoc-8.2.2/images
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/toc.js
> to /usr/share/doc/asciidoc-8.2.2/javascripts/toc.js
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2
> /examples/website/xhtml11-manpage.css to /usr/share/doc/asciidoc-8.2.2
> /stylesheets/xhtml11-manpage.css
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2
> /examples/website/xhtml11-quirks.css to /usr/share/doc/asciidoc-8.2.2
> /stylesheets/xhtml11-quirks.css
> asciidoc has dangling symlink from /usr/share/doc/asciidoc-8.2.2/examples/website/xhtml11.css
> to /usr/share/doc/asciidoc-8.2.2/stylesheets/xhtml11.css
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/16x16/actions/gtk-ok.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/actions/dialog-
> ok.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/16x16/apps/icon-systemhealth.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/apps/utilities-
> system-monitor.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/16x16/categories/icon-web-browser.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/16x16/categories/applications-
> internet.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/22x22/categories/icon-web-browser.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/22x22/categories/applications-
> internet.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/24x24/actions/gtk-ok.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/24x24/actions/dialog-
> ok.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/24x24/categories/icon-web-browser.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/24x24/categories/applications-
> internet.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/32x32/categories/icon-web-browser.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/32x32/categories/applications-
> internet.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/48x48/actions/gtk-ok.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/48x48/actions/dialog-
> ok.png
> echo-icon-theme has dangling symlink from
> /usr/share/icons/Echo/48x48/categories/icon-web-browser.png to
> /home/luya/Mod?les/git/echo-icon-theme/trunk/Echo/48x48/categories/applications-
> internet.png
> freenx has dangling symlink from
> /var/lib/nxserver/home/.ssh/authorized_keys to
> /etc/nxserver/server.id_dsa.pub.key
> grace has dangling symlink from /etc/X11/fontpath.d/grace-type1 to
> /usr/share/grace/type1
> httpunit-doc has dangling symlink from /usr/share/doc/httpunit-doc-1.6.2/api
> to /usr/share/javadoc/httpunit-1.6.2
> jakarta-commons-dbcp has dangling symlink from
> /usr/share/java/hibernate_jdbc_cache.jar to
> /etc/alternatives/hibernate_jdbc_cache
> kdebluetooth has dangling symlink from
> /usr/share/doc/HTML/ca/kdebluetooth/common to /usr/share/doc/HTML/ca/common
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnadded.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnadded.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnconflicted.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnconflicted.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvndeleted.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvndeleted.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnlocked.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnlocked.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnmodified.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnmodified.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnneedlock.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnneedlock.png
> kdesvn has dangling symlink from /usr/share/doc/HTML/en/kdesvn/hi128-
> filesys-kdesvnupdates.png to /usr/share/doc/HTML/src/pics/hi128-
> filesys-kdesvnupdates.png
> keurocalc has dangling symlink from
> /usr/share/doc/HTML/nb/keurocalc/common to /usr/share/doc/HTML/nb/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/karbon/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kchart/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kexi/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kformula/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kivio/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/koffice/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/koshell/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kplato/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kpresenter/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/krita/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kspread/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kugar/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/kword/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-ca has dangling symlink from
> /usr/share/doc/HTML/ca/thesaurus/common to /usr/share/doc/HTML/ca/common
> koffice-langpack-gl has dangling symlink from
> /usr/share/doc/HTML/gl/karbon/common to /usr/share/doc/HTML/gl/common
> koffice-langpack-gl has dangling symlink from
> /usr/share/doc/HTML/gl/kchart/common to /usr/share/doc/HTML/gl/common
> koffice-langpack-gl has dangling symlink from
> /usr/share/doc/HTML/gl/koffice/common to /usr/share/doc/HTML/gl/common
> koffice-langpack-gl has dangling symlink from
> /usr/share/doc/HTML/gl/koshell/common to /usr/share/doc/HTML/gl/common
> koffice-langpack-gl has dangling symlink from
> /usr/share/doc/HTML/gl/thesaurus/common to /usr/share/doc/HTML/gl/common
> kpowersave has dangling symlink from
> /usr/share/doc/HTML/cs/kpowersave/common to /usr/share/doc/HTML/cs/common
> kpowersave has dangling symlink from
> /usr/share/doc/HTML/fi/kpowersave/common to /usr/share/doc/HTML/fi/common
> kpowersave has dangling symlink from
> /usr/share/doc/HTML/hu/kpowersave/common to /usr/share/doc/HTML/hu/common
> kpowersave has dangling symlink from
> /usr/share/doc/HTML/nb/kpowersave/common to /usr/share/doc/HTML/nb/common
> libextractor-plugins-thumbnailgtk has dangling symlink from
> /usr/lib/libextractor/libextractor-thumbnail.so to
> /usr/lib/libextractor/dummy
> libextractor-plugins-thumbnailqt has dangling symlink from
> /usr/lib/libextractor/libextractor-thumbnail.so to
> /usr/lib/libextractor/dummy
> mantis has dangling symlink from /usr/share/mantis/mantis_offline.php to
> /etc/mantis/mantis_offline.php
> pinentry has dangling symlink from /usr/bin/pinentry to
> /etc/alternatives/pinentry
> pinentry-gtk has dangling symlink from /usr/bin/pinentry to
> /etc/alternatives/pinentry
> pinentry-qt has dangling symlink from /usr/bin/pinentry to
> /etc/alternatives/pinentry
> stellarium has dangling symlink from /usr/bin/stellarium-wrapper to
> /usr/bin/opengl-game-wrapper
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_cpp.so to
> /usr/lib/strigi/strigila_cpp.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_deb.so to
> /usr/lib/strigi/strigila_deb.so.0
> strigi-libs has dangling symlink from
> /usr/lib/strigi/strigila_namespaceharvester.so to
> /usr/lib/strigi/strigila_namespaceharvester.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigila_xpm.so to
> /usr/lib/strigi/strigila_xpm.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_au.so to
> /usr/lib/strigi/strigita_au.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_gif.so to
> /usr/lib/strigi/strigita_gif.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_pcx.so to
> /usr/lib/strigi/strigita_pcx.so.0
> strigi-libs has dangling symlink from /usr/lib/strigi/strigita_xbm.so to
> /usr/lib/strigi/strigita_xbm.so.0
> tetex-fonts-hebrew has dangling symlink from
> /usr/share/texmf/fonts/afm/public/culmus to /usr/share/fonts/hebrew
> tetex-fonts-hebrew has dangling symlink from
> /usr/share/texmf/fonts/type1/public/culmus to /usr/share/fonts/hebrew
> util-vserver has dangling symlink from /etc/vservers/.defaults/vdirbase to
> /vservers
> xorg-x11-fonts-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-ISO8859-1-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-ISO8859-1-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-ISO8859-14-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-ISO8859-14-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-ISO8859-15-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-ISO8859-15-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-ISO8859-2-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-ISO8859-2-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-ISO8859-9-100dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-100dpi:unscaled:pri=30 to
> /usr/share/X11/fonts/100dpi:unscaled
> xorg-x11-fonts-ISO8859-9-75dpi has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 to
> /usr/share/X11/fonts/75dpi:unscaled
> xorg-x11-fonts-misc has dangling symlink from
> /etc/X11/fontpath.d/xorg-x11-fonts-misc:unscaled:pri=10 to
> /usr/share/X11/fonts/misc:unscaled
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/ea9be980/attachment.htm>

From s0238762 at sms.ed.ac.uk  Tue Oct 30 12:50:19 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Tue, 30 Oct 2007 12:50:19 +0000
Subject: b43 in Fedora 7
In-Reply-To: <47260B1D.2070200@redhat.com>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>	<1193577458.2915.45.camel@shinybook.infradead.org>	<4724911F.4050308@sms.ed.ac.uk>	<1193585785.2915.56.camel@shinybook.infradead.org>	<4724C4C0.4020007@sms.ed.ac.uk>
	<47260B1D.2070200@redhat.com>
Message-ID: <4727288B.3020704@sms.ed.ac.uk>

Chuck Ebbert wrote:
> On 10/28/2007 01:20 PM, Ioannis Nousias wrote:
>   
>>>   
>>>       
>> ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for me.
>>
>>     
>
> 2.6.23.1 for Fedora 7 will be pushed as an update soon, it's also here:
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=21666
>
>   
thanks, that's good to know. I can see it has landed in the repos 
already. I'll give it a go when livna updates the nvidia driver package 
as well (which should happen any day now).





From fedora at leemhuis.info  Tue Oct 30 13:01:25 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 30 Oct 2007 14:01:25 +0100
Subject: b43 in Fedora 7
In-Reply-To: <4727288B.3020704@sms.ed.ac.uk>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>	<1193577458.2915.45.camel@shinybook.infradead.org>	<4724911F.4050308@sms.ed.ac.uk>	<1193585785.2915.56.camel@shinybook.infradead.org>	<4724C4C0.4020007@sms.ed.ac.uk>	<47260B1D.2070200@redhat.com>
	<4727288B.3020704@sms.ed.ac.uk>
Message-ID: <47272B25.50609@leemhuis.info>



On 30.10.2007 13:50, Ioannis Nousias wrote:
> Chuck Ebbert wrote:
>> On 10/28/2007 01:20 PM, Ioannis Nousias wrote:
>>   
>>> ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for me.
>> 2.6.23.1 for Fedora 7 will be pushed as an update soon, it's also here:
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=21666
> thanks, that's good to know. I can see it has landed in the repos 
> already. I'll give it a go when livna updates the nvidia driver package 
> as well (which should happen any day now).

Kmods for the latest Nvidia drivers are available for some hours from
livna already; see for example:
http://livna-dl.reloumirrors.net/fedora/7/i386/kmod-nvidia-100.14.19-1.2.6.23.1_10.fc7.i686.rpm

The other kmods except nvidia-96xx and nvidia-legacy are available as
well. The two older nvidia driver should hopefully follow later today,
once the main drivers got updated to the latest version (as only those
builds with 2.6.23).

Cu
knurd



From mike at miketc.com  Tue Oct 30 13:11:44 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 30 Oct 2007 08:11:44 -0500
Subject: RadeonHD driver status
Message-ID: <1193749904.5664.1.camel@scrappy.miketc.com>

Andrew,

How has this driver been coming?  I thought I saw it in rawhide at one
point and then removed?  I had heard this is the newer driver being
worked on for updated ATI cards including R500 and whatever else?  Will
this be (re)included in the near future?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From opensource at till.name  Tue Oct 30 13:34:06 2007
From: opensource at till.name (Till Maas)
Date: Tue, 30 Oct 2007 14:34:06 +0100
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <20071020084230.GA14246@free.fr>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020084230.GA14246@free.fr>
Message-ID: <200710301434.11037.opensource@till.name>

On Sa Oktober 20 2007, Patrice Dumas wrote:
> On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> > Does rpm complain about differing timestamps on files, while the
> > contents is identical?
>
> It doesn't complain but rpm -V shows the differences, it is better if
> the stamps are the same for common files coming from different packages.

Would it be enough to use
%verify(not mtime) /path/to/files
in %files?

Maximum rpm does not really say what this does, except that rpm will not 
verify the mtime then.
http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/ea5978f4/attachment.sig>

From jkeating at redhat.com  Tue Oct 30 13:32:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 09:32:24 -0400
Subject: RadeonHD driver status
In-Reply-To: <1193749904.5664.1.camel@scrappy.miketc.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
Message-ID: <20071030093224.151f1ada@redhat.com>

On Tue, 30 Oct 2007 08:11:44 -0500
Mike Chambers <mike at miketc.com> wrote:

> Andrew,
> 
> How has this driver been coming?  I thought I saw it in rawhide at one
> point and then removed?  I had heard this is the newer driver being
> worked on for updated ATI cards including R500 and whatever else?
> Will this be (re)included in the near future?

radeonhd was pulled from F8 due to it not really working.  It will
reappear in Fedora 9's rawhide.  Already in Fedora 8 is the avivo
driver which is an effort at supporting the same card set that started
before radeonhd.  Avivo is benefiting from ATI opening the
documentation and currently works a slight bit better than radeonhd.
However neither are in a state where we want to enable them by default.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/afeb361d/attachment.sig>

From jkeating at redhat.com  Tue Oct 30 13:29:39 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 09:29:39 -0400
Subject: Last day for bugfixes
Message-ID: <20071030092939.1cdf6c0c@redhat.com>

At the end of today (IE when I fall asleep) we will no longer be
evaluating builds for release that aren't a critical release blocking
bugfix.  We will be using very strict means of determining what a
release blocking issue is.  This is the final stretch, my goals are to
have a complete package set tomorrow morning for doing the final
composes.

Unless something goes horribly wrong, the final kernel build will be
kernel-2.6.23.1-41.fc8 which is currently available in the buildroots.  If you have software that builds against the kernel now would be the time to build it and alert rel-eng at fedoraproject.org so that we can tag those builds for the release.

Thank you all for all your help making Werewolf be an awesome release!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/847da62a/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From j.w.r.degoede at hhs.nl  Tue Oct 30 13:37:00 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 30 Oct 2007 14:37:00 +0100
Subject: rawhide report: 20071030 changes
In-Reply-To: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>
References: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>
Message-ID: <4727337C.1040806@hhs.nl>

Build System wrote:
> New package compiz-manager
> 	A wrapper script to start compiz with proper options
> 
> 
>  
> Updated Packages:
> 

<snip>

And again I see a lot of fix multilib conflicts changelog entries, wasn't this 
supposed to be F-9 material and if they are how does this relate to the freeze?

I've fixed quite a few packages for this too, but all the bug reports I got 
said it would be nice if this were to be fixed for F-9.

Regards,

Hans



From katzj at redhat.com  Tue Oct 30 13:46:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 30 Oct 2007 09:46:27 -0400
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <47270A91.7070305@n-dimensional.de>
References: <47270A91.7070305@n-dimensional.de>
Message-ID: <1193751987.5775.2.camel@localhost.localdomain>

On Tue, 2007-10-30 at 11:42 +0100, Hans Ulrich Niedermann wrote:
> I guess that for proper integration of xorg-x11-drv-radeonhd into Fedora
> the package should ship a /usr/share/hwdata/videoaliases/radeonhd.xinf file.

Only if the driver is at a stability level where giving it to users by
default is the right thing.  It's probably worth coordinating with ajax
on it, also, as having two drivers (avivo and radeonhd) saying they
drive the same hardware is going to lead to less than predictable
results

> Is the xinf file format documented somewhere? Are there tools to create it?

It's the same as the modaliases generated from kernel modules.  No real
documentation of it that I know of other than the module-init-tools
source

Jeremy



From jkeating at redhat.com  Tue Oct 30 13:46:09 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 09:46:09 -0400
Subject: rawhide report: 20071030 changes
In-Reply-To: <4727337C.1040806@hhs.nl>
References: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>
	<4727337C.1040806@hhs.nl>
Message-ID: <20071030094609.5c25fe77@redhat.com>

On Tue, 30 Oct 2007 14:37:00 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> And again I see a lot of fix multilib conflicts changelog entries,
> wasn't this supposed to be F-9 material and if they are how does this
> relate to the freeze?
> 
> I've fixed quite a few packages for this too, but all the bug reports
> I got said it would be nice if this were to be fixed for F-9.

Some overachieving maintainers requested that these be fixed in F-8,
particularly if it would effect yum upgrades from F7 or otherwise part
of a standard package set.  Since we were taking in bugfixes we went
ahead and accepted these requests for inclusion.  However as per my
email just a moment ago today is the last day for such freedom in
requesting bugfixes.  Even today I'm going to give people a harder time
on getting stuff in.

The bugs say F9 because it was completely unreasonable to expect
everybody fix this stuff for F8 (and that would be a lot of churn very
late in the game).  So the deadline is F9.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/9cffa0cc/attachment.sig>

From laroche at redhat.com  Tue Oct 30 13:58:37 2007
From: laroche at redhat.com (Florian La Roche)
Date: Tue, 30 Oct 2007 14:58:37 +0100
Subject: rawhide report: 20071030 changes
In-Reply-To: <4727337C.1040806@hhs.nl>
References: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>
	<4727337C.1040806@hhs.nl>
Message-ID: <20071030135837.GA9679@dudweiler.stuttgart.redhat.com>

On Tue, Oct 30, 2007 at 02:37:00PM +0100, Hans de Goede wrote:
> Build System wrote:
> >New package compiz-manager
> >	A wrapper script to start compiz with proper options
> >
> >
> > 
> >Updated Packages:
> >
> 
> <snip>
> 
> And again I see a lot of fix multilib conflicts changelog entries, wasn't 
> this supposed to be F-9 material and if they are how does this relate to 
> the freeze?
> 
> I've fixed quite a few packages for this too, but all the bug reports I got 
> said it would be nice if this were to be fixed for F-9.


Hello Hans,

I guess if maintainers submit their packages to F8, they are decided
on a case-by-case basis if they are save enough to still go in.
Most multilib fixes are pretty obvious to review.

regards,

Florian La Roche



From myfedora at richip.dhs.org  Tue Oct 30 14:07:19 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 30 Oct 2007 08:07:19 -0600
Subject: Might Be A Problem With NM
In-Reply-To: <20071030072038.65f7c7ca@pensja.lam.pl>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
	<1193692618.3927.42.camel@localhost.localdomain>
	<1193712561.16349.3.camel@localhost6.localdomain6>
	<20071030072038.65f7c7ca@pensja.lam.pl>
Message-ID: <1193753239.26537.8.camel@localhost6.localdomain6>

On Tue, 2007-10-30 at 07:20 +0100, Leszek Matok wrote:

> It did in F8t3 (not only left it alone, but the GNOME applet correctly
> showed which NIC is active), I'd call it a regression.

Do you have a bug number for this?

> Oh, and it looks like it's not NM that's disconnecting my network - it's
> rather the applet giving NM the command upon startup.

In my case, it really disconnects at NM startup. I've disabled NM for
now, but I'm sure that's not the solution we want if we want NM to get
adopted and tested.
--

Richi Plana



From lkundrak at redhat.com  Tue Oct 30 14:13:33 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 30 Oct 2007 15:13:33 +0100
Subject: Lenovo 3000 y 500 keyboard not working [Was: fedora-devel-list
	Digest, Vol 44, Issue 169]
In-Reply-To: <65d0b5300710300542t549e92d2xf395a49706ee2529@mail.gmail.com>
References: <20071029123056.6648A72F0E@hormel.redhat.com>
	<65d0b5300710300542t549e92d2xf395a49706ee2529@mail.gmail.com>
Message-ID: <1193753613.16103.11.camel@localhost.localdomain>

Hi,

On Tue, 2007-10-30 at 18:12 +0530, karthikeyan Govindarajan wrote:
> i have a problem in installing fedora 7 in my laptop
> my laptop configuration is:
>  Lenovo 3000 y 500 series
>  Intel dual core(TM) T5500
> 2 GB RAM
> Nvidia 7500
> While installing all  are going fine. but after  rebooting  the laptop
> both touchpad and  keyboard is not working. 
> i have  tried RHEL 5 and  fedora 6 i got the same result
> Karthikeyan.

Do they work in text console? Did you try attaching an USB mouse and
keyboard? Please open a bugzilla [1] ticket and attach output of dmesg
command.

[1] https://bugzilla.redhat.com/bugzilla/enter_bug.cgi

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From ajackson at redhat.com  Tue Oct 30 13:47:58 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 30 Oct 2007 09:47:58 -0400
Subject: RadeonHD driver status
In-Reply-To: <1193749904.5664.1.camel@scrappy.miketc.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
Message-ID: <1193752079.15341.55.camel@localhost.localdomain>

On Tue, 2007-10-30 at 08:11 -0500, Mike Chambers wrote:
> Andrew,
> 
> How has this driver been coming?  I thought I saw it in rawhide at one
> point and then removed?  I had heard this is the newer driver being
> worked on for updated ATI cards including R500 and whatever else?  Will
> this be (re)included in the near future?

I'll assume this was directed at me.

Hans Niedermann has packaged it, but it's only in rawhide atm.  We'll
figure out what to do with R500+ cards during the F9 cycle.

- ajax



From katzj at redhat.com  Tue Oct 30 14:19:47 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 30 Oct 2007 10:19:47 -0400
Subject: Might Be A Problem With NM
In-Reply-To: <1193753239.26537.8.camel@localhost6.localdomain6>
References: <1193674696.29491.7.camel@localhost6.localdomain6>
	<1193688556.4477.0.camel@optimus>
	<1193692217.26629.9.camel@localhost.localdomain>
	<1193692618.3927.42.camel@localhost.localdomain>
	<1193712561.16349.3.camel@localhost6.localdomain6>
	<20071030072038.65f7c7ca@pensja.lam.pl>
	<1193753239.26537.8.camel@localhost6.localdomain6>
Message-ID: <1193753987.5775.5.camel@localhost.localdomain>

On Tue, 2007-10-30 at 08:07 -0600, Richi Plana wrote:
> On Tue, 2007-10-30 at 07:20 +0100, Leszek Matok wrote:
> 
> > It did in F8t3 (not only left it alone, but the GNOME applet correctly
> > showed which NIC is active), I'd call it a regression.
> 
> Do you have a bug number for this?
> 
> > Oh, and it looks like it's not NM that's disconnecting my network - it's
> > rather the applet giving NM the command upon startup.
> 
> In my case, it really disconnects at NM startup. I've disabled NM for
> now, but I'm sure that's not the solution we want if we want NM to get
> adopted and tested.

Actually, right now, it is what's wanted.

If you want control of networking within the user session,
NetworkManager is what you want.  This is the more expected use case
with those who run and install from the live images and thus it is the
default there.

If you want the network settings to be decided on a system-wide basis,
right now, you use the network service and not NetworkManager.  Work is
underway so that for F9, this group of users moves to using
NetworkManager as well

Jeremy



From myfedora at richip.dhs.org  Tue Oct 30 14:20:46 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 30 Oct 2007 08:20:46 -0600
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the
	fedora	repo?
In-Reply-To: <4726D1E5.8030101@hhs.nl>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<4726D1E5.8030101@hhs.nl>
Message-ID: <1193754046.26537.18.camel@localhost6.localdomain6>

On Tue, 2007-10-30 at 07:40 +0100, Hans de Goede wrote:
> Mark wrote:
> >>> Packaging is not a free thing. It takes time energy and someone who is
> >>> going to deal with it. Most people who have packages are usually
> >>> swamped as it is... so if you see something you would like to get into
> >>> Fedora.. first check to see if someone is already packaging it, and
> >>> then volunteer to do it yourself (or help someone who can). Otherwise
> >>> its not going to happen.
> >> Plus, there's a little fame if not fortune, and usually a few people
> >> willing to help.
> >>
> >> I'd be willing to be that if you can *use* netbeans, you can certainly
> >> learn to *package* netbeans, and as an avid user, you're in excellent
> >> position to make sure the package actually works.  :)
> >>
> >> -Eric
> > 
> > I can't make RPM packages from scratch so therefore i think it's best
> > to leave that to a professional RPM packager. But if noone else is
> > willing to do it than i would like to give it a try.. and i probably
> > need a lot of help along the way.
> > 
> > So is anyone up to this? or is there someone that is willing to help
> > me with this? i have nearly no rpm packaging experience. (i edited
> > specs before and compiled the package but i didn't made a spec from
> > scratch)
> > 
> 
> I think that having netbeans in Fedora would be great, so I'm wlling to help 
> were I can (I already maintain 170+ packages). But my java packaging experience 
> is limited. Are there any jpackage people here who are also willing to help? 
> Nicolas? Ville?
> 
> Also if I were you I would start with trying to get it to compile on F-8 using 
> icedtea, don't worry about packaging yet, first just try to get it to compile 
> and run from the released sources?
> 
> (Are the sources complete?)

Might I refer people to JPackage's packaging guidelines for Java-based
packages (which, I'm hoping, Fedora will officially adopt or, better
yet, officially defer to).

http://www.jpackage.org/develdocs.php

and

http://www.jpackage.org/cgi-bin/viewvc.cgi/*checkout*/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?root=jpackage&content-type=text%2Fhtml

Sidenote: If or when we get around to rediscussing multi-arch packaging,
I vote that Java packages and mono be considered so that packaging
guidelines for them in Fedora can be set in stone. (Or, at least, a page
on the wiki be established that people can be referred to and can
evolve).
--

Richi Plana



From mike.cohler at gmail.com  Tue Oct 30 14:23:57 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 14:23:57 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
Message-ID: <3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>

I posted this to Fedora List but no-one seems able to help? Since this
is a problem that arose with a new version of rpcbind that was just
released into updates for F7, and previously all was working fine for
my nfs server, I am asking if anyone on this list can help, so
apologies for cross-posting.

After the recent rpcbind update in F7 I cannot restart nfs.

Message below:

# service nfs restart
Shutting down NFS mountd:                                  [FAILED]
Shutting down NFS daemon:                                  [FAILED]
Shutting down NFS quotas:                                  [FAILED]
Shutting down NFS services:                                [  OK  ]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas: Cannot register service: RPC: Authentication error; why =
Client credential too weak
rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
                                                           [FAILED]
Starting NFS daemon:                                       [FAILED]

Anyone know how to fix/workaround this?

In /var/log/messages I see as follows:
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(rquotad):
request from unauthorized host
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(rquotad):
request from unauthorized host
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to set(rquotad):
request from unauthorized host
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(nfs): request
from unauthorized host
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion nfsd[4661]: nfssvc: writing fds to kernel failed: errno
13 (Permission denied)
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to set(nfs): request
from unauthorized host
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion nfsd[4661]: nfssvc: writing fds to kernel failed: errno
13 (Permission denied)
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to set(nfs): request
from unauthorized host
Oct 30 10:33:58 pavilion kernel: NFSD: Using /var/lib/nfs/v4recovery as the
NFSv4 state recovery directory
Oct 30 10:33:58 pavilion kernel: NFSD: starting 90-second grace period
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(nlockmgr):
request from unauthorized host
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to set(nlockmgr):
request from unauthorized host
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(nlockmgr):
request from unauthorized host
Oct 30 10:33:58 pavilion rpcbind: connect from 127.0.0.1 to unset(nfs): request
from unauthorized host
Oct 30 10:33:58 pavilion nfsd[4661]: nfssvc: Permission denied
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).
Oct 30 10:33:58 pavilion kernel: nfsd: last server has exited
Oct 30 10:33:58 pavilion kernel: nfsd: unexporting all filesystems
Oct 30 10:33:58 pavilion kernel: call_verify: server localhost requires stronger
authentication.
Oct 30 10:33:58 pavilion kernel: RPC: failed to contact local rpcbind server
(errno 13).

Thanks for any help....
-- 

mike cohler



From ajackson at redhat.com  Tue Oct 30 14:11:38 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 30 Oct 2007 10:11:38 -0400
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <1193751987.5775.2.camel@localhost.localdomain>
References: <47270A91.7070305@n-dimensional.de>
	<1193751987.5775.2.camel@localhost.localdomain>
Message-ID: <1193753498.15341.67.camel@localhost.localdomain>

On Tue, 2007-10-30 at 09:46 -0400, Jeremy Katz wrote:
> On Tue, 2007-10-30 at 11:42 +0100, Hans Ulrich Niedermann wrote:
> > I guess that for proper integration of xorg-x11-drv-radeonhd into Fedora
> > the package should ship a /usr/share/hwdata/videoaliases/radeonhd.xinf file.
> 
> Only if the driver is at a stability level where giving it to users by
> default is the right thing.  It's probably worth coordinating with ajax
> on it, also, as having two drivers (avivo and radeonhd) saying they
> drive the same hardware is going to lead to less than predictable
> results

Not a huge problem, actually, since the avivo driver doesn't ship an
xinf file yet.  But yeah, if you ship one, then kudzu will match devices
with the IDs listed in it to the driver named at the end of the file,
which means you'll be set up at install time with that driver.

Which is, in fact, the reason avivo doesn't have an xinf file.

> > Is the xinf file format documented somewhere? Are there tools to create it?

Not really, no.

An example line would be:

alias pcivideo:v00008086d00007121sv*sd*bc*sc*i* intel   # i810

pcivideo is a tag understood by kudzu to mean that this line describes
an X driver.  The lowercase letters (v, d, sv, sd, bc, sc, i) are the
various PCI ID fields: vendor, device, subvendor, subdevice, base class,
subclass, and ASIC revision.  Normally you only need to use the first
two.  Then the third word is the driver name you want for that chip.
Comments are optional but are greatly appreciated.

The * wildcards are like shell, not like regex.  Numeric values _must_
be in uppercase hexadecimal; don't try to specify nvidia hardware with
000010de or you will be sadly disappointed.  Multiple matches are
possible, last match wins, but it's best if you don't have to rely on
that accidental feature.



From mike at miketc.com  Tue Oct 30 14:55:42 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 30 Oct 2007 09:55:42 -0500
Subject: RadeonHD driver status
In-Reply-To: <1193752079.15341.55.camel@localhost.localdomain>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<1193752079.15341.55.camel@localhost.localdomain>
Message-ID: <1193756142.5664.12.camel@scrappy.miketc.com>


On Tue, 2007-10-30 at 09:47 -0400, Adam Jackson wrote:
> On Tue, 2007-10-30 at 08:11 -0500, Mike Chambers wrote:
> > Andrew,
> > 
> > How has this driver been coming?  I thought I saw it in rawhide at one
> > point and then removed?  I had heard this is the newer driver being
> > worked on for updated ATI cards including R500 and whatever else?  Will
> > this be (re)included in the near future?
> 
> I'll assume this was directed at me.

Heh, hrm, wtf did I get Andrew from?  And yes I meant you, Adam. LOL
> 
> Hans Niedermann has packaged it, but it's only in rawhide atm.  We'll
> figure out what to do with R500+ cards during the F9 cycle.

I'm using rawhide but don't see it as of yet.  Guess you mean the F9
branch?

BTW, the avivo driver that Jesse mentioned doesn't work for my card.
Which is why I am interested in the radeonhd driver in case it does.
Using vesa currently, but having font blurriness problems in middle of
my screen, and except for getting new monitor (which might get new flat
lcd one anyway), trying to help figure out what is the problem.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From mike at miketc.com  Tue Oct 30 14:57:24 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 30 Oct 2007 09:57:24 -0500
Subject: Last day for bugfixes
In-Reply-To: <20071030092939.1cdf6c0c@redhat.com>
References: <20071030092939.1cdf6c0c@redhat.com>
Message-ID: <1193756244.5664.14.camel@scrappy.miketc.com>

On Tue, 2007-10-30 at 09:29 -0400, Jesse Keating wrote:
> At the end of today (IE when I fall asleep) we will no longer be
> evaluating builds for release that aren't a critical release blocking
> bugfix.  We will be using very strict means of determining what a
> release blocking issue is.  This is the final stretch, my goals are to
> have a complete package set tomorrow morning for doing the final
> composes.

So the next couple of days will still be towards F8 until the final spin
bits are spun?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From poelstra at redhat.com  Tue Oct 30 15:06:39 2007
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 30 Oct 2007 08:06:39 -0700
Subject: rawhide report: 20071030 changes
In-Reply-To: <20071030094609.5c25fe77@redhat.com>
References: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>	<4727337C.1040806@hhs.nl>
	<20071030094609.5c25fe77@redhat.com>
Message-ID: <4727487F.1040203@redhat.com>

Jesse Keating wrote:
> On Tue, 30 Oct 2007 14:37:00 +0100
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> And again I see a lot of fix multilib conflicts changelog entries,
>> wasn't this supposed to be F-9 material and if they are how does this
>> relate to the freeze?
>>
>> I've fixed quite a few packages for this too, but all the bug reports
>> I got said it would be nice if this were to be fixed for F-9.
> 
> Some overachieving maintainers requested that these be fixed in F-8,
> particularly if it would effect yum upgrades from F7 or otherwise part
> of a standard package set.  Since we were taking in bugfixes we went
> ahead and accepted these requests for inclusion.  However as per my
> email just a moment ago today is the last day for such freedom in
> requesting bugfixes.  Even today I'm going to give people a harder time
> on getting stuff in.
> 

For those following along at home... which "scheduled milestone" 
reflects the "last day of freedom"?  I don't see anything for October 
30th here
http://fedoraproject.org/wiki/Releases/8/Schedule

John



From jkeating at redhat.com  Tue Oct 30 15:13:23 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 11:13:23 -0400
Subject: rawhide report: 20071030 changes
In-Reply-To: <4727487F.1040203@redhat.com>
References: <200710301049.l9UAn2rv001734@porkchop.devel.redhat.com>
	<4727337C.1040806@hhs.nl> <20071030094609.5c25fe77@redhat.com>
	<4727487F.1040203@redhat.com>
Message-ID: <20071030111323.2c1a6177@redhat.com>

On Tue, 30 Oct 2007 08:06:39 -0700
John Poelstra <poelstra at redhat.com> wrote:

> For those following along at home... which "scheduled milestone" 
> reflects the "last day of freedom"?  I don't see anything for October 
> 30th here
> http://fedoraproject.org/wiki/Releases/8/Schedule

It wasn't necessarily a "scheduled milestone".  It's just the moment
when we think we have all the known blockers fixed, or expect to have
them fixed by the end of the day.  I personally have been shooting for
Tues/Wed to have the final package set to be able to compose Thurs and
hand off to IS to stage the mirrors.  It just wasn't documented (this
time).  Given the experience we had this time we can better document it
for F9, provided FESCo  approves my proposed changes.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/98141d87/attachment.sig>

From jkeating at redhat.com  Tue Oct 30 15:14:21 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 11:14:21 -0400
Subject: Last day for bugfixes
In-Reply-To: <1193756244.5664.14.camel@scrappy.miketc.com>
References: <20071030092939.1cdf6c0c@redhat.com>
	<1193756244.5664.14.camel@scrappy.miketc.com>
Message-ID: <20071030111421.564eda9b@redhat.com>

On Tue, 30 Oct 2007 09:57:24 -0500
Mike Chambers <mike at miketc.com> wrote:

> So the next couple of days will still be towards F8 until the final
> spin bits are spun?

Yes.  We'll alert loudly when rawhide will start picking up F9 builds.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/b82b33f0/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct 30 15:23:18 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 30 Oct 2007 20:53:18 +0530
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the	fedora
 repo?
In-Reply-To: <1193754046.26537.18.camel@localhost6.localdomain6>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>	<1193524190.2269.7.camel@ignacio.lan>	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>	<4723FE94.7030602@redhat.com>	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>	<4726D1E5.8030101@hhs.nl>
	<1193754046.26537.18.camel@localhost6.localdomain6>
Message-ID: <47274C66.6060201@fedoraproject.org>

Richi Plana wrote:

> 
> Might I refer people to JPackage's packaging guidelines for Java-based
> packages (which, I'm hoping, Fedora will officially adopt or, better
> yet, officially defer to).
> 
> http://www.jpackage.org/develdocs.php

Did you look?

http://fedoraproject.org/wiki/Packaging/JPackagePolicy

Rahul




From limb at jcomserv.net  Tue Oct 30 15:24:57 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 10:24:57 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
	<3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
Message-ID: <36853.63.85.68.164.1193757897.squirrel@mail.jcomserv.net>


> I posted this to Fedora List but no-one seems able to help? Since this
> is a problem that arose with a new version of rpcbind that was just
> released into updates for F7, and previously all was working fine for
> my nfs server, I am asking if anyone on this list can help, so
> apologies for cross-posting.
>
> After the recent rpcbind update in F7 I cannot restart nfs.
>
> Message below:

<snip>

Works on my client machines, testing on my NFS server now. . .

Jon

-- 
novus ordo absurdum



From nicolas.mailhot at laposte.net  Tue Oct 30 15:36:15 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 30 Oct 2007 16:36:15 +0100 (CET)
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the	fedora 
 repo?
Message-ID: <1414.192.54.193.51.1193758575.squirrel@rousalka.dyndns.org>


Le Mar 30 octobre 2007 16:23, Rahul Sundaram a ?crit :
> Richi Plana wrote:
>
>>
>> Might I refer people to JPackage's packaging guidelines for
>> Java-based
>> packages (which, I'm hoping, Fedora will officially adopt or, better
>> yet, officially defer to).
>>
>> http://www.jpackage.org/develdocs.php
>
> Did you look?
>
> http://fedoraproject.org/wiki/Packaging/JPackagePolicy

That's only the package naming part

Regards,

-- 
Nicolas Mailhot



From limb at jcomserv.net  Tue Oct 30 15:36:30 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 10:36:30 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <36853.63.85.68.164.1193757897.squirrel@mail.jcomserv.net>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
	<3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
	<36853.63.85.68.164.1193757897.squirrel@mail.jcomserv.net>
Message-ID: <47314.63.85.68.164.1193758590.squirrel@mail.jcomserv.net>


>
>> I posted this to Fedora List but no-one seems able to help? Since this
>> is a problem that arose with a new version of rpcbind that was just
>> released into updates for F7, and previously all was working fine for
>> my nfs server, I am asking if anyone on this list can help, so
>> apologies for cross-posting.
>>
>> After the recent rpcbind update in F7 I cannot restart nfs.
>>
>> Message below:
>
> <snip>
>
> Works on my client machines, testing on my NFS server now. . .

Works on my NFS server, too.  Odd error messages.  What kernel are you
running?

> Jon
>
> --
> novus ordo absurdum
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From davej at redhat.com  Tue Oct 30 15:59:03 2007
From: davej at redhat.com (Dave Jones)
Date: Tue, 30 Oct 2007 11:59:03 -0400
Subject: Last day for bugfixes
In-Reply-To: <20071030092939.1cdf6c0c@redhat.com>
References: <20071030092939.1cdf6c0c@redhat.com>
Message-ID: <20071030155903.GM1650@redhat.com>

On Tue, Oct 30, 2007 at 09:29:39AM -0400, Jesse Keating wrote:

 > Unless something goes horribly wrong, the final kernel build will be
 > kernel-2.6.23.1-41.fc8 which is currently available in the buildroots.

Everyone knows '42' is the one true answer to everything.
Seriously, one more build. Coming soon to a koji near you.

	Dave

-- 
http://www.codemonkey.org.uk



From hun at n-dimensional.de  Tue Oct 30 15:55:40 2007
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Tue, 30 Oct 2007 16:55:40 +0100
Subject: RadeonHD driver status
In-Reply-To: <20071030093224.151f1ada@redhat.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
Message-ID: <472753FC.7060509@n-dimensional.de>

Jesse Keating wrote:
> On Tue, 30 Oct 2007 08:11:44 -0500
> Mike Chambers <mike at miketc.com> wrote:

>> How has this driver been coming?  I thought I saw it in rawhide at one
>> point and then removed?  I had heard this is the newer driver being
>> worked on for updated ATI cards including R500 and whatever else?
>> Will this be (re)included in the near future?
> 
> radeonhd was pulled from F8 due to it not really working.  It will
> reappear in Fedora 9's rawhide.  Already in Fedora 8 is the avivo
> driver which is an effort at supporting the same card set that started
> before radeonhd.  Avivo is benefiting from ATI opening the
> documentation and currently works a slight bit better than radeonhd.
> However neither are in a state where we want to enable them by default.

IMHO, current xorg-x11-drv-radeonhd could be made available via the F8
updates repos. Yes, it has a few issues, but then it does work for many
people, no software is without bugs, and no one is forced to install it.

OK, I do have to admit that I have never run the avivo driver :)

Now follows the part with the issues I had planned to raise after the F8
release has stabilized the koji tag/CVS branch/yum repo mappings -- but
while we're talking about current state of affairs I can't omit them. :)

I have been regularly doing snapshots of the radeonhd driver, but the F8
block seems to have propagated to the dist-f9 tag, so there have not
been any koji builds after 2007-10-17:

    http://koji.fedoraproject.org/koji/packageinfo?packageID=5156
    http://koji.fedoraproject.org/koji/taskinfo?taskID=217665
    BuildError: package xorg-x11-drv-radeonhd is blocked for tag dist-f9

FWIW, Stefan Dirsch at SUSE has been trying to build F7 and FC6 RPMs
using the openSUSE build service. If we can make our own package
available for F7 and FC6, he'd like to stop his efforts on building what
I guess is the openSUSE RPM for Fedora. Having Fedora building Fedora
RPMs sounds like good idea to to me, at least.

-- 
Hans Ulrich Niedermann



From mike.cohler at gmail.com  Tue Oct 30 16:07:16 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 16:07:16 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710300907vb2d728fw230fc8e227bfdf50@mail.gmail.com>

"Jon Ciesla" wrote:

>> Works on my client machines, testing on my NFS server now. . .

>Works on my NFS server, too.  Odd error messages.  What kernel are you
>running?

2.6.23.1-10.fc7

-- 

mike cohler



From jkeating at redhat.com  Tue Oct 30 16:03:56 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 12:03:56 -0400
Subject: RadeonHD driver status
In-Reply-To: <472753FC.7060509@n-dimensional.de>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
Message-ID: <20071030120356.14db5430@redhat.com>

On Tue, 30 Oct 2007 16:55:40 +0100
Hans Ulrich Niedermann <hun at n-dimensional.de> wrote:

>     http://koji.fedoraproject.org/koji/packageinfo?packageID=5156
>     http://koji.fedoraproject.org/koji/taskinfo?taskID=217665
>     BuildError: package xorg-x11-drv-radeonhd is blocked for tag
> dist-f9

Fixed this.  You can now build for F9.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/85682c60/attachment.sig>

From limb at jcomserv.net  Tue Oct 30 16:04:36 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 11:04:36 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710300907vb2d728fw230fc8e227bfdf50@mail.gmail.com>
References: <3dd77c60710300907vb2d728fw230fc8e227bfdf50@mail.gmail.com>
Message-ID: <10783.63.85.68.164.1193760276.squirrel@mail.jcomserv.net>


> "Jon Ciesla" wrote:
>
>>> Works on my client machines, testing on my NFS server now. . .
>
>>Works on my NFS server, too.  Odd error messages.  What kernel are you
>>running?
>
> 2.6.23.1-10.fc7

Hm, I've got that installed, but I'm running on kernel-2.6.22.9-91.fc7. 
I'll be rebooting in a few days, so I might see it then.  Is it feasible
for you to reboot and try it on kernel-2.6.22.9-91.fc7?  I'm curious if
that's the issue.  I'm fully updated, I assume your machine is too?

> --
>
> mike cohler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From mike.cohler at gmail.com  Tue Oct 30 16:18:01 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 16:18:01 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710300918x12f2f40uc9a8ac8530de8ca3@mail.gmail.com>

"Jon Ciesla" wrote:

>Hm, I've got that installed, but I'm running on kernel-2.6.22.9-91.fc7.
>I'll be rebooting in a few days, so I might see it then.  Is it feasible
>for you to reboot and try it on kernel-2.6.22.9-91.fc7?  I'm curious if
>that's the issue.  I'm fully updated, I assume your machine is too?

OK I will reboot to kernel-2.6.22.9-91.fc7 when I get back to the
machine later this evening, and report back. Yes I am fully updated
too.

Mike

-- 

mike cohler



From SteveD at redhat.com  Tue Oct 30 16:43:36 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 30 Oct 2007 12:43:36 -0400
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
	<3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
Message-ID: <47275F38.8030500@RedHat.com>



Mike Cohler wrote:
> I posted this to Fedora List but no-one seems able to help? Since this
> is a problem that arose with a new version of rpcbind that was just
> released into updates for F7, and previously all was working fine for
> my nfs server, I am asking if anyone on this list can help, so
> apologies for cross-posting.
> 
> After the recent rpcbind update in F7 I cannot restart nfs.
> 
> Message below:
> 
> # service nfs restart
> Shutting down NFS mountd:                                  [FAILED]
> Shutting down NFS daemon:                                  [FAILED]
> Shutting down NFS quotas:                                  [FAILED]
> Shutting down NFS services:                                [  OK  ]
> Starting NFS services:                                     [  OK  ]
> Starting NFS quotas: Cannot register service: RPC: Authentication error; why =
> Client credential too weak
> rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
>                                                            [FAILED]
> Starting NFS daemon:                                       [FAILED]
> 
> Anyone know how to fix/workaround this?
Is selinux in the picture? If so try 'setenforce 0'
What does 'service rpcbind status' say?

steved.



From limb at jcomserv.net  Tue Oct 30 16:43:03 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 11:43:03 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <47275F38.8030500@RedHat.com>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
	<3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
	<47275F38.8030500@RedHat.com>
Message-ID: <49315.63.85.68.164.1193762583.squirrel@mail.jcomserv.net>


>
>
> Mike Cohler wrote:
>> I posted this to Fedora List but no-one seems able to help? Since this
>> is a problem that arose with a new version of rpcbind that was just
>> released into updates for F7, and previously all was working fine for
>> my nfs server, I am asking if anyone on this list can help, so
>> apologies for cross-posting.
>>
>> After the recent rpcbind update in F7 I cannot restart nfs.
>>
>> Message below:
>>
>> # service nfs restart
>> Shutting down NFS mountd:                                  [FAILED]
>> Shutting down NFS daemon:                                  [FAILED]
>> Shutting down NFS quotas:                                  [FAILED]
>> Shutting down NFS services:                                [  OK  ]
>> Starting NFS services:                                     [  OK  ]
>> Starting NFS quotas: Cannot register service: RPC: Authentication error;
>> why =
>> Client credential too weak
>> rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
>>                                                            [FAILED]
>> Starting NFS daemon:                                       [FAILED]
>>
>> Anyone know how to fix/workaround this?
> Is selinux in the picture? If so try 'setenforce 0'
> What does 'service rpcbind status' say?

I just thought of that, it's like we're in the same mental room. . .

For reference, my updated working setup is on permissive.

> steved.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From myfedora at richip.dhs.org  Tue Oct 30 16:59:22 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 30 Oct 2007 10:59:22 -0600
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in
	the	fedora	repo?
In-Reply-To: <47274C66.6060201@fedoraproject.org>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<1193524190.2269.7.camel@ignacio.lan>
	<6e24a8e80710271536g3f95a89em35f69c2ae65d6ff6@mail.gmail.com>
	<80d7e4090710271829r2fd2989h142ded4e0d4582fd@mail.gmail.com>
	<4723FE94.7030602@redhat.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<4726D1E5.8030101@hhs.nl>
	<1193754046.26537.18.camel@localhost6.localdomain6>
	<47274C66.6060201@fedoraproject.org>
Message-ID: <1193763562.27742.13.camel@localhost6.localdomain6>

On Tue, 2007-10-30 at 20:53 +0530, Rahul Sundaram wrote:
> Richi Plana wrote:
> 
> > 
> > Might I refer people to JPackage's packaging guidelines for Java-based
> > packages (which, I'm hoping, Fedora will officially adopt or, better
> > yet, officially defer to).
> > 
> > http://www.jpackage.org/develdocs.php
> 
> Did you look?
> 
> http://fedoraproject.org/wiki/Packaging/JPackagePolicy

Yes ... and now that you mentioned it ... The page you mentioned above
is a great start, but only covers package-naming and versioning
policies. In fact, the page above seems more like a guide for
repackaging JPackage RPMs so that they compile with gcj (understandable
since that's what was important to RedHat/Fedora). It doesn't mention
anything regarding 1) Fedora's stance on Java packaging, 2) Fedora's
relationship with JPackage, or 3) Fedora's guidelines for Java
packaging.

I think we'll find that as subsystems grow, Fedora has to have
subbranches in its guidelines that people can look to. Even if it means
deferring to another organization's rules (ie. perl, python, mono and
jpackage).

I mentioned multi-arch before because even if these are "noarch",
they're still an arch in and of itself (ie. java bytecode vs. x86_64
gcj).
--

Richi Plana



From mike.cohler at gmail.com  Tue Oct 30 17:19:22 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 17:19:22 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710301019l3a522f51t9d286f5acef2356a@mail.gmail.com>

Steve Dickson wrote:

>Is selinux in the picture? If so try 'setenforce 0'
>What does 'service rpcbind status' say?

selinux is disabled.
[root at pavilion etc]# sestatus -v
SELinux status:                 disabled


Tests:

1)
[root at pavilion etc]# service rpcbind status
rpcbind (pid 3387) is running...

2)
[root at pavilion etc]# service nfs status
rpc.mountd is stopped
nfsd is stopped
rpc.rquotad is stopped

3) root at pavilion etc]# service nfslock status
rpc.statd dead but pid file exists

4) [root at pavilion etc]# service nfslock restart
Stopping NFS statd:                                        [FAILED]
Starting NFS statd:                                        [FAILED]

5) [root at pavilion etc]# service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas: Cannot register service: RPC: Authentication
error; why = Client credential too weak
rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
                                                           [FAILED]
Starting NFS daemon:                                       [FAILED]


-- 

mike cohler



From rc040203 at freenet.de  Tue Oct 30 17:20:16 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 30 Oct 2007 18:20:16 +0100
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <47275F38.8030500@RedHat.com>
References: <3dd77c60710300352n39887f4eg6a600aae40d86bf0@mail.gmail.com>
	<3dd77c60710300723j8ae1879k421f07362740d154@mail.gmail.com>
	<47275F38.8030500@RedHat.com>
Message-ID: <1193764817.29995.18.camel@mccallum.corsepiu.local>

On Tue, 2007-10-30 at 12:43 -0400, Steve Dickson wrote:
> 
> Mike Cohler wrote:
> > I posted this to Fedora List but no-one seems able to help? Since this
> > is a problem that arose with a new version of rpcbind that was just
> > released into updates for F7, and previously all was working fine for
> > my nfs server, I am asking if anyone on this list can help, so
> > apologies for cross-posting.

> > Anyone know how to fix/workaround this?
> Is selinux in the picture?
FWIW: Since today's yum update, I am facing SELinux alerts related to
nfs/rpc on FC7

c.f.: https://bugzilla.redhat.com/show_bug.cgi?id=357601

No idea if the OP's issues are related to mine, nor do I know what the
causes of my issues are.

Ralf




From rc040203 at freenet.de  Tue Oct 30 17:36:25 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 30 Oct 2007 18:36:25 +0100
Subject: make mockbuild is broken
Message-ID: <1193765785.29995.24.camel@mccallum.corsepiu.local>

Hi,

"make mockbuild" in Fedora's CVS is broken (Fedora 7):

# make mockbuild

mock  -r fedora-8-i386.cfg --resultdir=/home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0_30-1_fc8 /home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0.30-1.fc8.src.rpm
INFO: mock suid wrapper version 0.8.4 
ERROR: Could not find required config file: /etc/mock/fedora-8-i386.cfg.cfg
make: *** [mockbuild] Error 1

Seems to me, as if Makefile.common's settings do not meet mock's
expectations. There is one .cfg too much.

Ralf




From paul at city-fan.org  Tue Oct 30 17:41:14 2007
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 30 Oct 2007 17:41:14 +0000
Subject: make mockbuild is broken
In-Reply-To: <1193765785.29995.24.camel@mccallum.corsepiu.local>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
Message-ID: <47276CBA.8000900@city-fan.org>

Ralf Corsepius wrote:
> Hi,
> 
> "make mockbuild" in Fedora's CVS is broken (Fedora 7):
> 
> # make mockbuild
> 
> mock  -r fedora-8-i386.cfg --resultdir=/home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0_30-1_fc8 /home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0.30-1.fc8.src.rpm
> INFO: mock suid wrapper version 0.8.4 
> ERROR: Could not find required config file: /etc/mock/fedora-8-i386.cfg.cfg
> make: *** [mockbuild] Error 1
> 
> Seems to me, as if Makefile.common's settings do not meet mock's
> expectations. There is one .cfg too much.

It's probably going to need a "rebuild" in front of the SRPM filename too.

Paul.



From rc040203 at freenet.de  Tue Oct 30 17:45:49 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 30 Oct 2007 18:45:49 +0100
Subject: make mockbuild is broken
In-Reply-To: <47276CBA.8000900@city-fan.org>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
	<47276CBA.8000900@city-fan.org>
Message-ID: <1193766349.29995.28.camel@mccallum.corsepiu.local>

On Tue, 2007-10-30 at 17:41 +0000, Paul Howarth wrote:
> Ralf Corsepius wrote:
> > Hi,
> > 
> > "make mockbuild" in Fedora's CVS is broken (Fedora 7):
> > 
> > # make mockbuild
> > 
> > mock  -r fedora-8-i386.cfg --resultdir=/home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0_30-1_fc8 /home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0.30-1.fc8.src.rpm
> > INFO: mock suid wrapper version 0.8.4 
> > ERROR: Could not find required config file: /etc/mock/fedora-8-i386.cfg.cfg
> > make: *** [mockbuild] Error 1
> > 
> > Seems to me, as if Makefile.common's settings do not meet mock's
> > expectations. There is one .cfg too much.
> 
> It's probably going to need a "rebuild" in front of the SRPM filename too.
?!? Do you mean building the srpm? It's there, I just cut too much in
the posting above.

The culprit for the breakdown is mock being passed 
"-r fedora-8-i386.cfg". It (mock-0.8.4-2.fc7) expects fedora-8-i386.

Ralf




From ville.skytta at iki.fi  Tue Oct 30 17:50:07 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 30 Oct 2007 19:50:07 +0200
Subject: Fedorability of dvbcut ?
In-Reply-To: <4726CE64.8040506@iinet.net.au>
References: <47248975.7050901@iinet.net.au> <47257C36.9060607@cs.tu-berlin.de>
	<4726CE64.8040506@iinet.net.au>
Message-ID: <200710301950.07671.ville.skytta@iki.fi>

On Tuesday 30 October 2007, David Timms wrote:

> tzap -c "a channel" would seem to be actually demuxing the mpeg stream
> to the single program id selected within that tuned frequency. That
> would seem to be needing knowledge of the mpeg data ?

The last time I heard about this the verdict was that demuxing/muxing is not a 
problem, see eg. https://bugzilla.redhat.com/191036 comments 12-14.  I 
believe there are quite a few things in Fedora that do that.



From mike.cohler at gmail.com  Tue Oct 30 17:55:28 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 17:55:28 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710301055n1b2f946fha233e6f1513506f1@mail.gmail.com>

Steve Dickson wrote:

>> Anyone know how to fix/workaround this?
>Is selinux in the picture? If so try 'setenforce 0'
>What does 'service rpcbind status' say?

I have just seen
https://bugzilla.redhat.com/show_bug.cgi?id=358621

I tried the suggestion in this bug - i.e. add
ALL: localhost

to /etc/hosts.allow

Then restart the services - nfs now starts properly and everything
seems fine - but what are the security implications of this change I
wonder?

-- 

mike cohler



From rc040203 at freenet.de  Tue Oct 30 17:59:36 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 30 Oct 2007 18:59:36 +0100
Subject: make mockbuild is broken
In-Reply-To: <1193766349.29995.28.camel@mccallum.corsepiu.local>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
	<47276CBA.8000900@city-fan.org>
	<1193766349.29995.28.camel@mccallum.corsepiu.local>
Message-ID: <1193767176.29995.32.camel@mccallum.corsepiu.local>

On Tue, 2007-10-30 at 18:45 +0100, Ralf Corsepius wrote:
> On Tue, 2007-10-30 at 17:41 +0000, Paul Howarth wrote:
> > Ralf Corsepius wrote:
> > > Hi,
> > > 
> > > "make mockbuild" in Fedora's CVS is broken (Fedora 7):
> > > 
> > > # make mockbuild
> > > 
> > > mock  -r fedora-8-i386.cfg --resultdir=/home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0_30-1_fc8 /home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0.30-1.fc8.src.rpm
> > > INFO: mock suid wrapper version 0.8.4 
> > > ERROR: Could not find required config file: /etc/mock/fedora-8-i386.cfg.cfg
> > > make: *** [mockbuild] Error 1
> > > 
> > > Seems to me, as if Makefile.common's settings do not meet mock's
> > > expectations. There is one .cfg too much.
> > 
> > It's probably going to need a "rebuild" in front of the SRPM filename too.
> ?!? Do you mean building the srpm? It's there, I just cut too much in
> the posting above.
OK, now I understand.

The call to mock also lacks a "rebuild", i.e.
mock -r fedora-8-i386 .... rebuild *.src.rpm

Ralf





From jkeating at redhat.com  Tue Oct 30 17:56:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 13:56:42 -0400
Subject: make mockbuild is broken
In-Reply-To: <1193766349.29995.28.camel@mccallum.corsepiu.local>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
	<47276CBA.8000900@city-fan.org>
	<1193766349.29995.28.camel@mccallum.corsepiu.local>
Message-ID: <20071030135642.6b32383b@redhat.com>

On Tue, 30 Oct 2007 18:45:49 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> The culprit for the breakdown is mock being passed 
> "-r fedora-8-i386.cfg". It (mock-0.8.4-2.fc7) expects fedora-8-i386.

Ugh, yes.  new mock, different arguments.  (and you do have to do
rebuild IIRC now, it won't just take the srpm and assume what to do
with it)

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/287aca5b/attachment.sig>

From ville.skytta at iki.fi  Tue Oct 30 18:00:57 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 30 Oct 2007 20:00:57 +0200
Subject: Can Netbeans 6.0 beta 2 or higher make it's way in the fedora
	repo?
In-Reply-To: <4726D1E5.8030101@hhs.nl>
References: <6e24a8e80710271450o4463ce36h7b1037075266054e@mail.gmail.com>
	<6e24a8e80710280521h35be7c04v1ec2baf765d4c18a@mail.gmail.com>
	<4726D1E5.8030101@hhs.nl>
Message-ID: <200710302000.58142.ville.skytta@iki.fi>

On Tuesday 30 October 2007, Hans de Goede wrote:

> I think that having netbeans in Fedora would be great, so I'm wlling to
> help were I can (I already maintain 170+ packages). But my java packaging
> experience is limited. Are there any jpackage people here who are also
> willing to help? Nicolas? Ville?

I'm vaguely interested but I'm afraid only to the extent that I might try out 
using NB sometime, and before that, it's premature to think about 
packaging/maintaining it.  Eclipse has worked well enough for me.



From wtogami at redhat.com  Tue Oct 30 18:09:55 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 30 Oct 2007 14:09:55 -0400
Subject: F8 KVM guest on F8?
Message-ID: <47277373.5030203@redhat.com>

Does anybody have a F8 KVM guest on F8 host?

Could you please test if a nfs mount from guest to host works?  Please 
be sure that both sides are updated to latest rawhide.

Thanks,
Warren Togami
wtogami at redhat.com



From lsof at nodata.co.uk  Tue Oct 30 18:25:04 2007
From: lsof at nodata.co.uk (nodata)
Date: Tue, 30 Oct 2007 19:25:04 +0100
Subject: Package XYZ is not signed
In-Reply-To: <4724F3B9.4010608@lordmorgul.net>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home>  <4724F3B9.4010608@lordmorgul.net>
Message-ID: <1193768704.6165.7.camel@sb-home>

Am Sonntag, den 28.10.2007, 13:40 -0700 schrieb Andrew Farris:
> If you keep an eye on where your packages are coming from, even for rawhide,
> then you can be sure that only authorized maintainers have put them into the
> system (control which mirrors you're pulling them from).  Actually signing the
> package from the build system would change very little other than insure that
> the mirror you're downloading from did not bring in a new package that doesn't
> belong.

It worries me massively, from a security perspective, that someone from
inside Red Hat would say something as wrong as this.

> 
> So as it stands, you have to extend trust to the maintainers, and the mirror.
> You can pick which mirror you trust.
> 



From opensource at till.name  Tue Oct 30 18:25:23 2007
From: opensource at till.name (Till Maas)
Date: Tue, 30 Oct 2007 19:25:23 +0100
Subject: pending Fedora 7 testing updates
Message-ID: <200710301925.28858.opensource@till.name>

Hiyas,

there are many pending Fedora 7 testing updates currently in Bodhi, when will 
they be pushed to the testing repository? The oldest waiting updates seem to 
be 7 days old now.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/69f24250/attachment.sig>

From lsof at nodata.co.uk  Tue Oct 30 18:30:10 2007
From: lsof at nodata.co.uk (nodata)
Date: Tue, 30 Oct 2007 19:30:10 +0100
Subject: Package XYZ is not signed
In-Reply-To: <1193768704.6165.7.camel@sb-home>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home>  <4724F3B9.4010608@lordmorgul.net>
	<1193768704.6165.7.camel@sb-home>
Message-ID: <1193769010.6165.11.camel@sb-home>


Am Dienstag, den 30.10.2007, 19:25 +0100 schrieb nodata:
> Am Sonntag, den 28.10.2007, 13:40 -0700 schrieb Andrew Farris:
> > If you keep an eye on where your packages are coming from, even for rawhide,
> > then you can be sure that only authorized maintainers have put them into the
> > system (control which mirrors you're pulling them from).  Actually signing the
> > package from the build system would change very little other than insure that
> > the mirror you're downloading from did not bring in a new package that doesn't
> > belong.
> 
> It worries me massively, from a security perspective, that someone from
> inside Red Hat would say something as wrong as this.

Oh, you don't work for Red Hat. Sorry. But your statement is still
completely off the field.

> > 
> > So as it stands, you have to extend trust to the maintainers, and the mirror.
> > You can pick which mirror you trust.
> > 
> 



From katzj at redhat.com  Tue Oct 30 18:33:05 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 30 Oct 2007 14:33:05 -0400
Subject: F8 KVM guest on F8?
In-Reply-To: <47277373.5030203@redhat.com>
References: <47277373.5030203@redhat.com>
Message-ID: <1193769185.5775.19.camel@localhost.localdomain>

On Tue, 2007-10-30 at 14:09 -0400, Warren Togami wrote:
> Does anybody have a F8 KVM guest on F8 host?
> 
> Could you please test if a nfs mount from guest to host works?  Please 
> be sure that both sides are updated to latest rawhide.

Works for me.  It does depend on what type of networking you use in the
guest, though.  The usermode networking stack within qemu (which is used
by default if you don't pass any -net options) won't work with NFS due
to some trickery with how it actually does things

Jeremy



From jkeating at redhat.com  Tue Oct 30 18:30:49 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 14:30:49 -0400
Subject: pending Fedora 7 testing updates
In-Reply-To: <200710301925.28858.opensource@till.name>
References: <200710301925.28858.opensource@till.name>
Message-ID: <20071030143049.7b1cb7da@redhat.com>

On Tue, 30 Oct 2007 19:25:23 +0100
Till Maas <opensource at till.name> wrote:

> there are many pending Fedora 7 testing updates currently in Bodhi,
> when will they be pushed to the testing repository? The oldest
> waiting updates seem to be 7 days old now.


We've been having compose issues with the -testing repo. Luke has been
working like a madman on trying to resolve the issues.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/05fedb91/attachment.sig>

From jspaleta at gmail.com  Tue Oct 30 18:58:26 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 30 Oct 2007 10:58:26 -0800
Subject: Package XYZ is not signed
In-Reply-To: <4724CFA1.2050007@gmail.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724CFA1.2050007@gmail.com>
Message-ID: <604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>

On 10/28/07, Toshio Kuratomi <a.badger at gmail.com> wrote:
> We don't have auto-sign yet.  Which is the main reason we don't have
> signed rawhide packages.

I think if we are serious about making rawhide day-to-day friendly to
encourage 'normal' people (aka Norms) to become part of the rawhide
testing process we'll need to autosign..something.  Is there a feature
page for roadmapping rawhide non-toxic?

I think greg's right that bootable usbsticks are a pretty interesting
target as a testing platform for pre-release testing.

We just need to work out a reasonable transition from the usb stick to
gold release upgrade of the main system and we can add some assurance
that the pre-release bits are not being tampered with.

-jef"I want a 4 gig usb stick shaped like the fedora logo that I can
dedicate to rawhide testing"spaleta



From mike at miketc.com  Tue Oct 30 19:00:38 2007
From: mike at miketc.com (Mike Chambers)
Date: Tue, 30 Oct 2007 14:00:38 -0500
Subject: RadeonHD driver status
In-Reply-To: <472753FC.7060509@n-dimensional.de>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
Message-ID: <1193770838.2742.2.camel@scrappy.miketc.com>

On Tue, 2007-10-30 at 16:55 +0100, Hans Ulrich Niedermann wrote:
> IMHO, current xorg-x11-drv-radeonhd could be made available via the F8
> updates repos. Yes, it has a few issues, but then it does work for
> many
> people, no software is without bugs, and no one is forced to install
> it.

I did d/l it and give it a shot.  It gave me a screen at least, more
than avivo ever did.  But the rhgb and the gdm login screen were both
HUGE and had to move the mouse to get them to come back to center, like
it was a 600x400 or bigger resolution.  Anyway, after getting to my
desktop, it was better, with my normal resolution.  But still didn't
look right, so went back to vesa for now.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From bkonrath at redhat.com  Tue Oct 30 19:05:27 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Tue, 30 Oct 2007 15:05:27 -0400
Subject: eclipse-egit orphaned
Message-ID: <1193771127.8105.2.camel@localhost.localdomain>

Hi, 

I just orphaned the eclipse-egit package. Anybody interested is more
than welcome to pick it up.

Thanks, Ben



From jkeating at redhat.com  Tue Oct 30 19:07:51 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 15:07:51 -0400
Subject: Package XYZ is not signed
In-Reply-To: <604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724CFA1.2050007@gmail.com>
	<604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>
Message-ID: <20071030150751.29cd9d81@redhat.com>

On Tue, 30 Oct 2007 10:58:26 -0800
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> I think if we are serious about making rawhide day-to-day friendly to
> encourage 'normal' people (aka Norms) to become part of the rawhide
> testing process we'll need to autosign..something.  Is there a feature
> page for roadmapping rawhide non-toxic?


Not written down, but in my head.

1) write a signing server (work progressing)
2) deploy a signing server human driven
3) wire up a method to let koji request packages be signed for it as
part of the build process.
4) profit.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/f16c66fe/attachment.sig>

From jspaleta at gmail.com  Tue Oct 30 19:15:34 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 30 Oct 2007 11:15:34 -0800
Subject: Package XYZ is not signed
In-Reply-To: <20071030150751.29cd9d81@redhat.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724CFA1.2050007@gmail.com>
	<604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>
	<20071030150751.29cd9d81@redhat.com>
Message-ID: <604aa7910710301215j3ef992dcpb08e6daaf737e4eb@mail.gmail.com>

On 10/30/07, Jesse Keating <jkeating at redhat.com> wrote:
> 1) write a signing server (work progressing)
> 2) deploy a signing server human driven
> 3) wire up a method to let koji request packages be signed for it as
> part of the build process.

Does this parse as koji requests auto-signing? Or is that a request to
put packages in a que for the human driver to deal with?

> 4) profit.

I'd settle for break-even.

-jef



From jkeating at redhat.com  Tue Oct 30 19:21:02 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 15:21:02 -0400
Subject: Package XYZ is not signed
In-Reply-To: <604aa7910710301215j3ef992dcpb08e6daaf737e4eb@mail.gmail.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724CFA1.2050007@gmail.com>
	<604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>
	<20071030150751.29cd9d81@redhat.com>
	<604aa7910710301215j3ef992dcpb08e6daaf737e4eb@mail.gmail.com>
Message-ID: <20071030152102.3cb15a68@redhat.com>

On Tue, 30 Oct 2007 11:15:34 -0800
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> Does this parse as koji requests auto-signing? Or is that a request to
> put packages in a que for the human driver to deal with?

As to not delay rawhide composes, the correct thing is to sign a
package as soon as it's tagged for something that is going to rawhide.
So either koji needs to do it itself, or we need to have some daemon
that listens for tag successes and kicks off a signing request (or a
scheduled "sign all in dist-rawhide" run which can be... slow").

But since that's step 3, I'm not committing to any design until steps
one and two are complete.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/85858f52/attachment.sig>

From green at redhat.com  Tue Oct 30 19:30:26 2007
From: green at redhat.com (Anthony Green)
Date: Tue, 30 Oct 2007 12:30:26 -0700
Subject: eclipse-egit orphaned
In-Reply-To: <1193771127.8105.2.camel@localhost.localdomain>
References: <1193771127.8105.2.camel@localhost.localdomain>
Message-ID: <47278652.1060805@redhat.com>

Ben Konrath wrote:
> Hi, 
> 
> I just orphaned the eclipse-egit package. Anybody interested is more
> than welcome to pick it up.

I just installed it yesterday to try it out.  Are there any inherent 
problems with this package?

Thanks,

AG


-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/a3e26455/attachment.vcf>

From mike.cohler at gmail.com  Tue Oct 30 19:32:32 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 19:32:32 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710301232v2ffb733fgaacdd97d908df116@mail.gmail.com>

"Mike Cohler" wrote:

>I have just seen
>https://bugzilla.redhat.com/show_bug.cgi?id=358621

>I tried the suggestion in this bug - i.e. add
>ALL: localhost

>to /etc/hosts.allow

>Then restart the services - nfs now starts properly and everything
>seems fine - but what are the security implications of this change I
>wonder?

I have now just updated the client machine running which looks at the
nfs share.... it could not see the nfs files unless I made the same
change to the /etc/hosts.allow file on the client - then restarting
allows it to see the NFS share.

So the same problem affects both NFS server and NFS client machines
with updates to version rpcbind-0.1.4-8.fc7

-- 

mike cohler



From lsof at nodata.co.uk  Tue Oct 30 19:36:34 2007
From: lsof at nodata.co.uk (nodata)
Date: Tue, 30 Oct 2007 20:36:34 +0100
Subject: OOo .odt files - open with Java by default
Message-ID: <1193772994.6165.22.camel@sb-home>

Nautilus will open OpenText document files from OpenOffice.org with Java
by default.

Is there a way to change this (for everyone, distro-wide)?



From limb at jcomserv.net  Tue Oct 30 19:29:23 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 14:29:23 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710301232v2ffb733fgaacdd97d908df116@mail.gmail.com>
References: <3dd77c60710301232v2ffb733fgaacdd97d908df116@mail.gmail.com>
Message-ID: <19198.63.85.68.164.1193772563.squirrel@mail.jcomserv.net>


> "Mike Cohler" wrote:
>
>>I have just seen
>>https://bugzilla.redhat.com/show_bug.cgi?id=358621
>
>>I tried the suggestion in this bug - i.e. add
>>ALL: localhost
>
>>to /etc/hosts.allow
>
>>Then restart the services - nfs now starts properly and everything
>>seems fine - but what are the security implications of this change I
>>wonder?
>
> I have now just updated the client machine running which looks at the
> nfs share.... it could not see the nfs files unless I made the same
> change to the /etc/hosts.allow file on the client - then restarting
> allows it to see the NFS share.
>
> So the same problem affects both NFS server and NFS client machines
> with updates to version rpcbind-0.1.4-8.fc7

Except that it works for me with no such effort.

> --
>
> mike cohler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From jspaleta at gmail.com  Tue Oct 30 19:44:16 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 30 Oct 2007 11:44:16 -0800
Subject: Package XYZ is not signed
In-Reply-To: <20071030152102.3cb15a68@redhat.com>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home> <4724CFA1.2050007@gmail.com>
	<604aa7910710301158ud62ca95sba126a1d85114dc4@mail.gmail.com>
	<20071030150751.29cd9d81@redhat.com>
	<604aa7910710301215j3ef992dcpb08e6daaf737e4eb@mail.gmail.com>
	<20071030152102.3cb15a68@redhat.com>
Message-ID: <604aa7910710301244p4427da8dxea22bc18b4739298@mail.gmail.com>

On 10/30/07, Jesse Keating <jkeating at redhat.com> wrote:
> But since that's step 3, I'm not committing to any design until steps
> one and two are complete.

You are absolutely no fun.

-jef



From mike.cohler at gmail.com  Tue Oct 30 19:54:43 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 19:54:43 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710301254n5f3969e5y7b9308ce6e9e4f01@mail.gmail.com>

"Jon Ciesla" wrote:

>Except that it works for me with no such effort.

Maybe we have differences in the various config files that cause the
difference in behaviour?
My setup is pretty much as in
http://optics.csufresno.edu/~kriehn/fedora/fedora_files/f7/howto/nfs.html

Also I note that nfs-utils was also a new version
(nfs-utils-1.1.0-4.fc7) today - this may be a factor too?

-- 

mike cohler



From limb at jcomserv.net  Tue Oct 30 19:50:03 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 14:50:03 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710301254n5f3969e5y7b9308ce6e9e4f01@mail.gmail.com>
References: <3dd77c60710301254n5f3969e5y7b9308ce6e9e4f01@mail.gmail.com>
Message-ID: <37589.63.85.68.164.1193773803.squirrel@mail.jcomserv.net>


> "Jon Ciesla" wrote:
>
>>Except that it works for me with no such effort.
>
> Maybe we have differences in the various config files that cause the
> difference in behaviour?
> My setup is pretty much as in
> http://optics.csufresno.edu/~kriehn/fedora/fedora_files/f7/howto/nfs.html
>
> Also I note that nfs-utils was also a new version
> (nfs-utils-1.1.0-4.fc7) today - this may be a factor too?

Possible, but I doubt it, since it changed for both of us.

My main /etc/exports line is:
/path_of_share/ 
XXX.XXX.XXX.XXX/XXX.XXX.XXX.XXX(insecure,no_root_squash,rw,nohide)

> --
>
> mike cohler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From trever.adams at gmail.com  Tue Oct 30 19:58:57 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 30 Oct 2007 13:58:57 -0600
Subject: RadeonHD driver status
In-Reply-To: <472753FC.7060509@n-dimensional.de>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
Message-ID: <1193774337.3064.1.camel@aragorn>


On Tue, 2007-10-30 at 16:55 +0100, Hans Ulrich Niedermann wrote:
> Jesse Keating wrote:

> IMHO, current xorg-x11-drv-radeonhd could be made available via the F8
> updates repos. Yes, it has a few issues, but then it does work for many
> people, no software is without bugs, and no one is forced to install it.

Avivo doesn't work at 1680x1050, radeonhd does. Avivo locked up and
crashed on me all the time, I haven't had radeonhd do that.

I think whoever says that Avivo works better maybe should try them both
themselves.

Trever
--
"SMOG: Evidence of lack of faith. It is the result of needing to see
what you breath." -- Harl Adams
-------------- 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/20071030/6d9dd2ae/attachment.sig>

From mike.cohler at gmail.com  Tue Oct 30 20:06:10 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Tue, 30 Oct 2007 20:06:10 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710301306i4d25d1bdu5584a651d58386@mail.gmail.com>

"Jon Ciesla" wrote:

My main /etc/exports line is:
/path_of_share/
XXX.XXX.XXX.XXX/XXX.XXX.XXX.XXX(insecure,no_root_squash,rw,nohide)

Mine is
/path-to-share xx.xx.xx.xx(rw,root_squash)

i.e. just one machine as client.
-- 

mike cohler



From s0238762 at sms.ed.ac.uk  Tue Oct 30 20:37:43 2007
From: s0238762 at sms.ed.ac.uk (Ioannis Nousias)
Date: Tue, 30 Oct 2007 20:37:43 +0000
Subject: b43 in Fedora 7
In-Reply-To: <47272B25.50609@leemhuis.info>
References: <4723C7F6.8040709@sms.ed.ac.uk>	<1193573023.2915.42.camel@shinybook.infradead.org>	<47248919.6000505@sms.ed.ac.uk>	<1193577458.2915.45.camel@shinybook.infradead.org>	<4724911F.4050308@sms.ed.ac.uk>	<1193585785.2915.56.camel@shinybook.infradead.org>	<4724C4C0.4020007@sms.ed.ac.uk>	<47260B1D.2070200@redhat.com>	<4727288B.3020704@sms.ed.ac.uk>
	<47272B25.50609@leemhuis.info>
Message-ID: <47279617.8010704@sms.ed.ac.uk>

Thorsten Leemhuis wrote:
> On 30.10.2007 13:50, Ioannis Nousias wrote:
>   
>> Chuck Ebbert wrote:
>>     
>>> On 10/28/2007 01:20 PM, Ioannis Nousias wrote:
>>>   
>>>       
>>>> ok, I'll wait for F8 to come out then. bcm43xx wasn't working well for me.
>>>>         
>>> 2.6.23.1 for Fedora 7 will be pushed as an update soon, it's also here:
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=21666
>>>       
>> thanks, that's good to know. I can see it has landed in the repos 
>> already. I'll give it a go when livna updates the nvidia driver package 
>> as well (which should happen any day now).
>>     
>
> Kmods for the latest Nvidia drivers are available for some hours from
> livna already; see for example:
> http://livna-dl.reloumirrors.net/fedora/7/i386/kmod-nvidia-100.14.19-1.2.6.23.1_10.fc7.i686.rpm
>
> The other kmods except nvidia-96xx and nvidia-legacy are available as
> well. The two older nvidia driver should hopefully follow later today,
> once the main drivers got updated to the latest version (as only those
> builds with 2.6.23).
>
> Cu
> knurd
>
>   
thanks guys. Updated now and it seems to work fine, though it only gives 
me a 1Mbps connection. Hopefully it should be stable now. The bcm43xx 
was dropping the connection all the time.

regards
Ioannis





From Michael_E_Brown at dell.com  Tue Oct 30 20:59:39 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Tue, 30 Oct 2007 15:59:39 -0500
Subject: make mockbuild is broken
In-Reply-To: <1193767176.29995.32.camel@mccallum.corsepiu.local>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
	<47276CBA.8000900@city-fan.org>
	<1193766349.29995.28.camel@mccallum.corsepiu.local>
	<1193767176.29995.32.camel@mccallum.corsepiu.local>
Message-ID: <20071030205937.GB21890@humbolt.us.dell.com>

On Tue, Oct 30, 2007 at 06:59:36PM +0100, Ralf Corsepius wrote:
> On Tue, 2007-10-30 at 18:45 +0100, Ralf Corsepius wrote:
> > On Tue, 2007-10-30 at 17:41 +0000, Paul Howarth wrote:
> > > Ralf Corsepius wrote:
> > > > Hi,
> > > > 
> > > > "make mockbuild" in Fedora's CVS is broken (Fedora 7):
> > > > 
> > > > # make mockbuild
> > > > 
> > > > mock  -r fedora-8-i386.cfg --resultdir=/home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0_30-1_fc8 /home/build/src/fedora/pkgs/rpms/perl-Params-Util/F-8/perl-Params-Util-0.30-1.fc8.src.rpm
> > > > INFO: mock suid wrapper version 0.8.4 
> > > > ERROR: Could not find required config file: /etc/mock/fedora-8-i386.cfg.cfg
> > > > make: *** [mockbuild] Error 1
> > > > 
> > > > Seems to me, as if Makefile.common's settings do not meet mock's
> > > > expectations. There is one .cfg too much.
> > > 
> > > It's probably going to need a "rebuild" in front of the SRPM filename too.
> > ?!? Do you mean building the srpm? It's there, I just cut too much in
> > the posting above.
> OK, now I understand.
> 
> The call to mock also lacks a "rebuild", i.e.
> mock -r fedora-8-i386 .... rebuild *.src.rpm

I've sent a patch to makefile.common to fedora-buildsys-list. Didnt know
about this usage of mock, or would have had this fixed up before I
released mock 0.8.
--
Michael



From pertusus at free.fr  Tue Oct 30 20:59:26 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 30 Oct 2007 21:59:26 +0100
Subject: Multiarch conflicts on devel packages with %doc files
In-Reply-To: <200710301434.11037.opensource@till.name>
References: <d9c612bf0710191502x2a35fee8we4bd53f94515ff0e@mail.gmail.com>
	<1192849643.25729.11.camel@mccallum.corsepiu.local>
	<20071020084230.GA14246@free.fr>
	<200710301434.11037.opensource@till.name>
Message-ID: <20071030205926.GA2753@free.fr>

On Tue, Oct 30, 2007 at 02:34:06PM +0100, Till Maas wrote:
> On Sa Oktober 20 2007, Patrice Dumas wrote:
> > On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> > > Does rpm complain about differing timestamps on files, while the
> > > contents is identical?
> >
> > It doesn't complain but rpm -V shows the differences, it is better if
> > the stamps are the same for common files coming from different packages.
> 
> Would it be enough to use
> %verify(not mtime) /path/to/files
> in %files?

I guess so. For some files it could even make more sense than some
things I propose in the multilib trickes page. But when the timestamp
changes comes from patching or not using -p when copying it makes sense
to set them right.

--
Pat



From ml at deadbabylon.de  Tue Oct 30 20:59:05 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 30 Oct 2007 21:59:05 +0100
Subject: KDE-SIG weekly report (44/2007)
Message-ID: <200710302159.11065.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 44/2007

Time: 2007-10-30 17:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-30

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-10-30?action=AttachFile&do=get&target=fedora-kde-sig-2007-10-30.txt

----------------------------------------------------------------------------------

= Participants =

RexDieter 
KevinKofler 
SebastianVahl 
ArthurPemberton (pembo13_com) 
LaithJuwaidah 
AdelGadllah (drago01) 
SuneVuorela (pusling)

----------------------------------------------------------------------------------

= Agenda = 

* Last preparations for Fedora 8 (main topic) 
* KDE-Bits for the Release Summary 
* Status of inclusion of kde-desktop-effects in f8-final 
* Prepare for the next development cycle (basically KDE 4.0 and 
kdebase-workspace)

= Summary = 

o Last preparations for Fedora 8:
- New ksplash with InfinityTheme was imported into kde-settings 
- Some multilib and upgrade path issues were fixed by RexDieter this morning 
- Also strigi-libs has got some multilib fixes 

o KDE-Bits for the Release Summary: 
- Things that could/should be mentioned or enhanced: 
  - kde-desktop-effects 
  - knetworkmanager and nm-applet 
  - KDE 4 Development Platform

o Status of inclusion of kde-desktop-effects in f8final: 
- compiz-manager was approved by rel-eng for inclusion. 
- during the meeting there was the confirmation that kde-desktop-effects would 
be included into compiz-kde 
- So only compiz-kde needs to be approved by rel-eng to be included in f8final 
- compiz-kde was also added as default to kde-desktop group in comps.xml

o Prepare for the next development cycle (F9, kde4, all that jazz): 
- The next development cycle is almost covered by KDE 4.0 (ETA: Dec, 11 2007) 
- There must be made a decision which bits of KDE3 should be kept (at least 
kdebase3 and kdelibs3) 
- kdegames4 and kdeedu4 are already done 
- importing kdebase(4)-workspace and re-placing the 
Conflicts/Provides/Obsoletes has to be done mostly together 
- Due to the work that Upstream has done to minimize the conflicts, many of 
the current hacks could be removed 
- kdebase3 will need a lot of purging to keep only the stuff which doesn't 
conflict 
- KDE4 should be imported into Rawhide asap

o Open discussion: 
- The now used kdepim-enterprise would be merged into KDE 3.5.9 by upstream 
- There were some discussion (or guessing) if kmail would be shipped with 
kdepim4 by upstream 
- So we have to probably ship kdepim3

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06
-------------- 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/20071030/c8a61713/attachment.sig>

From singularitaet at gmx.net  Tue Oct 30 21:07:57 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Tue, 30 Oct 2007 22:07:57 +0100
Subject: KDE logout options with F8
Message-ID: <200710302208.03091.singularitaet@gmx.net>

Hi,

I installed F8 Test3 some time ago and since then I am on rawhide. I am using 
KDE and ever since the installation I miss the shutdown and hibernation 
options (buttons) in the KDE log out dialog. There is only the end current 
session button which is leading me to back to the login screen from where I 
then can do the shutdown. Of course the shell shutdown and kshutdown both 
work as alternative.

I would really appreciate to get those buttons back. Is it because of the 
rawhide packages or is there something messed up on my notebook? (What could 
I do in the latter case?)

Furthermore I sometimes observe for some seconds the standard gnome gdm login  
screen (the blue one with the yellow flower) appearing after I optioned for 
shutdown at the infinity (kdm?) login - ...

Beside this I must say its really nice how everything works!

Regards
Stefan

-------------- 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/20071030/3280301a/attachment.sig>

From jkeating at redhat.com  Tue Oct 30 21:06:20 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 17:06:20 -0400
Subject: make mockbuild is broken
In-Reply-To: <20071030205937.GB21890@humbolt.us.dell.com>
References: <1193765785.29995.24.camel@mccallum.corsepiu.local>
	<47276CBA.8000900@city-fan.org>
	<1193766349.29995.28.camel@mccallum.corsepiu.local>
	<1193767176.29995.32.camel@mccallum.corsepiu.local>
	<20071030205937.GB21890@humbolt.us.dell.com>
Message-ID: <20071030170620.15d955e5@redhat.com>

On Tue, 30 Oct 2007 15:59:39 -0500
Michael E Brown <Michael_E_Brown at dell.com> wrote:

> I've sent a patch to makefile.common to fedora-buildsys-list. Didnt
> know about this usage of mock, or would have had this fixed up before
> I released mock 0.8.

Patch was applied as well.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/9fbe3502/attachment.sig>

From ml at deadbabylon.de  Tue Oct 30 21:12:50 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 30 Oct 2007 22:12:50 +0100
Subject: KDE logout options with F8
In-Reply-To: <200710302208.03091.singularitaet@gmx.net>
References: <200710302208.03091.singularitaet@gmx.net>
Message-ID: <200710302212.50847.ml@deadbabylon.de>

Am Di 30.Oktober 2007 schrieb Stefan Grosse:
> Hi,
>
> I installed F8 Test3 some time ago and since then I am on rawhide. I am
> using KDE and ever since the installation I miss the shutdown and
> hibernation options (buttons) in the KDE log out dialog. There is only the
> end current session button which is leading me to back to the login screen
> from where I then can do the shutdown. Of course the shell shutdown and
> kshutdown both work as alternative.

To get the buttons to show up you have to use kdm as your loginmanager.

Sebastian
-------------- 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/20071030/555d7f1e/attachment.sig>

From singularitaet at gmx.net  Tue Oct 30 21:26:54 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Tue, 30 Oct 2007 22:26:54 +0100
Subject: Missing perl dependency for R-2.6.0 update
Message-ID: <200710302227.25096.singularitaet@gmx.net>

Hi

updating R with todays update (2.6.0-1 to 2.6.0-3) does not work due to a 
missing perl dependency(?):

# yum update
Loading "refresh-updatesd" plugin
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: perl(File::Copy::Recursive) for package: R
--> Processing Dependency: perl(Text::DelimMatch) for package: R
---> Package R.i386 0:2.6.0-3.fc8 set to be updated
--> Running transaction check
--> Processing Dependency: perl(Text::DelimMatch) for package: R
---> Package perl-File-Copy-Recursive.noarch 0:0.35-1.fc8 set to be updated
--> Finished Dependency Resolution
Error: Missing Dependency: perl(Text::DelimMatch) is needed by package R

Regards
Stefan
-------------- 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/20071030/69bc2608/attachment.sig>

From tcallawa at redhat.com  Tue Oct 30 21:31:03 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 30 Oct 2007 17:31:03 -0400
Subject: Missing perl dependency for R-2.6.0 update
In-Reply-To: <200710302227.25096.singularitaet@gmx.net>
References: <200710302227.25096.singularitaet@gmx.net>
Message-ID: <1193779863.3477.74.camel@localhost.localdomain>


On Tue, 2007-10-30 at 22:26 +0100, Stefan Grosse wrote:
> Hi
> 
> updating R with todays update (2.6.0-1 to 2.6.0-3) does not work due to a 
> missing perl dependency(?):

I fixed it this morning, 2.6.0-3.1 is waiting to be pushed to stable.

My bad, all apologies. :)

~spot



From singularitaet at gmx.net  Tue Oct 30 22:02:13 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Tue, 30 Oct 2007 23:02:13 +0100
Subject: KDE logout options with F8
In-Reply-To: <200710302212.50847.ml@deadbabylon.de>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
Message-ID: <200710302302.19495.singularitaet@gmx.net>

On Tuesday 30 October 2007 10:12:50 pm Sebastian Vahl wrote:
SV> To get the buttons to show up you have to use kdm as your loginmanager.

That could be an explanation. But when I was switching from Fedora 7 to 
rawhide (before the test3 installation) that shutdown option disappeared as 
well. And if I am not mistaken I believe that with Fedora Core 6 and maybe 
with Fedora 7 I also had gdm but the KDE shutdown option was there... 

Anyway: how would I change to kdm then? I found in the wiki I would need to 
alter a file /etc/sysconfig/desktop to set DISPLAYMANAGER="KDE" but there is 
no such file.

Stefan
-------------- 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/20071030/5ae2aead/attachment.sig>

From ml at deadbabylon.de  Tue Oct 30 22:08:41 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 30 Oct 2007 23:08:41 +0100
Subject: KDE logout options with F8
In-Reply-To: <200710302302.19495.singularitaet@gmx.net>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
Message-ID: <200710302308.47617.ml@deadbabylon.de>

Am Di 30.Oktober 2007 schrieb Stefan Grosse:
> Anyway: how would I change to kdm then? I found in the wiki I would need to
> alter a file /etc/sysconfig/desktop to set DISPLAYMANAGER="KDE" but there
> is no such file.

Then you have to create it. For a full KDE:
DESKTOP="KDE"
DISPLAYMANAGER="KDE"

Sebastian

P.S.: This question would have better fit to fedora-test-list or even 
fedora-list, I think.
-------------- 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/20071030/b82242ca/attachment.sig>

From airlied at redhat.com  Tue Oct 30 22:18:15 2007
From: airlied at redhat.com (Dave Airlie)
Date: Wed, 31 Oct 2007 08:18:15 +1000
Subject: RadeonHD driver status
In-Reply-To: <1193774337.3064.1.camel@aragorn>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>
Message-ID: <1193782695.3872.1.camel@optimus>

On Tue, 2007-10-30 at 13:58 -0600, Trever L. Adams wrote:
> On Tue, 2007-10-30 at 16:55 +0100, Hans Ulrich Niedermann wrote:
> > Jesse Keating wrote:
> 
> > IMHO, current xorg-x11-drv-radeonhd could be made available via the F8
> > updates repos. Yes, it has a few issues, but then it does work for many
> > people, no software is without bugs, and no one is forced to install it.
> 
> Avivo doesn't work at 1680x1050, radeonhd does. Avivo locked up and
> crashed on me all the time, I haven't had radeonhd do that.
> 
> I think whoever says that Avivo works better maybe should try them both
> themselves.

Neither of them work good enough yet. One works on some cards the other
on other cards, one support dual-head, the other not so much etc..

So yes your sample set of one is enough for us to base all our future
decisions on.

Thanks,
Dave.



From sundaram at fedoraproject.org  Tue Oct 30 22:31:03 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 04:01:03 +0530
Subject: KDE logout options with F8
In-Reply-To: <200710302308.47617.ml@deadbabylon.de>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
Message-ID: <4727B0A7.9050909@fedoraproject.org>

Sebastian Vahl wrote:
> Am Di 30.Oktober 2007 schrieb Stefan Grosse:
>> Anyway: how would I change to kdm then? I found in the wiki I would need to
>> alter a file /etc/sysconfig/desktop to set DISPLAYMANAGER="KDE" but there
>> is no such file.
> 
> Then you have to create it. For a full KDE:
> DESKTOP="KDE"
> DISPLAYMANAGER="KDE"
> 
> Sebastian
> 
> P.S.: This question would have better fit to fedora-test-list or even 
> fedora-list, I think.

Right but does this point to something that needs to be fixed. Why is 
the Fedora DVD image installing GDM if a user has selected KDE?

Rahul



From trever.adams at gmail.com  Tue Oct 30 22:37:30 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 30 Oct 2007 16:37:30 -0600
Subject: RadeonHD driver status
In-Reply-To: <1193782695.3872.1.camel@optimus>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>  <1193782695.3872.1.camel@optimus>
Message-ID: <1193783850.4670.6.camel@aragorn>

On Wed, 2007-10-31 at 08:18 +1000, Dave Airlie wrote:
> On Tue, 2007-10-30 at 13:58 -0600, Trever L. Adams wrote:
> Neither of them work good enough yet. One works on some cards the other
> on other cards, one support dual-head, the other not so much etc..
> 
> So yes your sample set of one is enough for us to base all our future
> decisions on.
> 
> Thanks,
> Dave.
> 

Actually, sample set of more than one. I have two machines I directly
maintain that use the RadeonHD where Avivo was garbage. Additionally,
there are others I help maintain or advise on.

Also, I don't think Avivo should be discarded yet, though from reading
around, it is going to be a dead end, supposedly. But, RadeonHD
shouldn't be left out either.

Just because I didn't give my sample size (which the above is as close
as you will get as I cannot give specifics, for privacy reasons, of many
machines I work with/on), doesn't mean I am some brain-dead "me too" or
"your dumb" person.

Thank you,
Trever
--
"The hands that help are better far than the lips that pray." -- Robert
G. Ingersoll
-------------- 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/20071030/fa0862de/attachment.sig>

From ml at deadbabylon.de  Tue Oct 30 22:41:31 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 30 Oct 2007 23:41:31 +0100
Subject: KDE logout options with F8
In-Reply-To: <4727B0A7.9050909@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
Message-ID: <200710302341.31541.ml@deadbabylon.de>

Am Di 30.Oktober 2007 schrieb Rahul Sundaram:
> Sebastian Vahl wrote:
> > Am Di 30.Oktober 2007 schrieb Stefan Grosse:
> >> Anyway: how would I change to kdm then? I found in the wiki I would need
> >> to alter a file /etc/sysconfig/desktop to set DISPLAYMANAGER="KDE" but
> >> there is no such file.
> >
> > Then you have to create it. For a full KDE:
> > DESKTOP="KDE"
> > DISPLAYMANAGER="KDE"
> >
> > Sebastian
> >
> > P.S.: This question would have better fit to fedora-test-list or even
> > fedora-list, I think.
>
> Right but does this point to something that needs to be fixed. Why is
> the Fedora DVD image installing GDM if a user has selected KDE?

That is indeed a good question, but I cannot answer this.

Sebastian
-------------- 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/20071030/e35b415a/attachment.sig>

From kevin.kofler at chello.at  Tue Oct 30 22:49:03 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 30 Oct 2007 22:49:03 +0000 (UTC)
Subject: KDE logout options with F8
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
Message-ID: <loom.20071030T224723-163@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> Right but does this point to something that needs to be fixed. Why is 
> the Fedora DVD image installing GDM if a user has selected KDE?

Because this was changed back in RHL 8.0 when RHL was in "desktop unification" 
mode and never changed back. RHL up to 7.3 actually installed KDM by default if 
you selected KDE.

        Kevin Kofler



From sundaram at fedoraproject.org  Tue Oct 30 22:50:50 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 04:20:50 +0530
Subject: KDE logout options with F8
In-Reply-To: <loom.20071030T224723-163@post.gmane.org>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
Message-ID: <4727B54A.4080806@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>> Right but does this point to something that needs to be fixed. Why is 
>> the Fedora DVD image installing GDM if a user has selected KDE?
> 
> Because this was changed back in RHL 8.0 when RHL was in "desktop unification" 
> mode and never changed back. RHL up to 7.3 actually installed KDM by default if 
> you selected KDE.

Yes, I know the history here but there isn't a valid reason to do this 
anymore as far as I know. So let's get fixed now.

Rahul



From cebbert at redhat.com  Tue Oct 30 22:57:42 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Tue, 30 Oct 2007 18:57:42 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071030T224723-163@post.gmane.org>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
Message-ID: <4727B6E6.7040808@redhat.com>

On 10/30/2007 06:49 PM, Kevin Kofler wrote:
> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>> Right but does this point to something that needs to be fixed. Why is 
>> the Fedora DVD image installing GDM if a user has selected KDE?
> 
> Because this was changed back in RHL 8.0 when RHL was in "desktop unification" 
> mode and never changed back.

And now kdm gets almost zero testing because of that.



From caillon at redhat.com  Tue Oct 30 23:00:59 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 00:00:59 +0100
Subject: Firefox backspace button action should be "Previous Page" not
 "Page Up"
In-Reply-To: <6e24a8e80710291631l2e10203n48e1066316a9f556@mail.gmail.com>
References: <6e24a8e80710271534q57994a6o2a575708259ac9b1@mail.gmail.com>	<4725BB85.9000706@redhat.com>
	<6e24a8e80710291631l2e10203n48e1066316a9f556@mail.gmail.com>
Message-ID: <4727B7AB.2030206@redhat.com>

Mark wrote:
> Oke good so it's gonna do nothing in Fedora 8 right?

Correct.



From caolanm at redhat.com  Tue Oct 30 23:37:16 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Tue, 30 Oct 2007 23:37:16 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193772994.6165.22.camel@sb-home>
References: <1193772994.6165.22.camel@sb-home>
Message-ID: <1193787436.31627.60.camel@Jehannum>


On Tue, 2007-10-30 at 20:36 +0100, nodata wrote:
> Nautilus will open OpenText document files from OpenOffice.org with Java
> by default

What could "open with java" mean here, actually attempting to
execute .odt files as java programs ?!, or treating them as .jar files
an unzipping them or something. Here, though with OOo installed of
course, it does does the right thing(tm). 

C.



From airlied at redhat.com  Tue Oct 30 23:12:18 2007
From: airlied at redhat.com (Dave Airlie)
Date: Wed, 31 Oct 2007 09:12:18 +1000
Subject: RadeonHD driver status
In-Reply-To: <1193783850.4670.6.camel@aragorn>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>  <1193782695.3872.1.camel@optimus>
	<1193783850.4670.6.camel@aragorn>
Message-ID: <1193785938.3872.5.camel@optimus>


> Actually, sample set of more than one. I have two machines I directly
> maintain that use the RadeonHD where Avivo was garbage. Additionally,
> there are others I help maintain or advise on.
> 
> Also, I don't think Avivo should be discarded yet, though from reading
> around, it is going to be a dead end, supposedly. But, RadeonHD
> shouldn't be left out either.
> 
> Just because I didn't give my sample size (which the above is as close
> as you will get as I cannot give specifics, for privacy reasons, of many
> machines I work with/on), doesn't mean I am some brain-dead "me too" or
> "your dumb" person.

This is the Internet, it looks like a me too and it smells like a me too
I consider it a me too, providing info on the type/range of cards tested
etc is useful.. saying avivo broken radeonhd not is not useful as we
also have ppl saying the opposite...

Red Hat and Fedora are contemplating the future wrt to AMD r5xx cards,
all options are going to be looked at, there may even be options that
you don't know about yet..

Dave.



From mattdm at mattdm.org  Tue Oct 30 23:22:32 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 30 Oct 2007 19:22:32 -0400
Subject: Ekiga working for anyone?
In-Reply-To: <1192459624.30612.4.camel@localhost.localdomain>
References: <20071015002728.GA3593@jadzia.bu.edu>
	<e71b3daf0710141924s2fab7221xdc5e7a19e9266d1b@mail.gmail.com>
	<4712D472.7050009@redhat.com>
	<20071015135345.GA31484@jadzia.bu.edu>
	<1192459624.30612.4.camel@localhost.localdomain>
Message-ID: <20071030232232.GA25245@jadzia.bu.edu>

On Mon, Oct 15, 2007 at 04:47:04PM +0200, Lubomir Kundrak wrote:
> Could you please file a bug? Also, please install ekiga-debuginfo,
> produce a stack trace and all that to the bug.

I will. The problem is apparently in alsa-libs. I can recreate it by blowing
away the ekiga gconf configuration and going through the config wizard. When
I get to "test" after selecting USB Audio for my input device, I get this:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1386271856 (LWP 26442)]
0x01d9d9c3 in snd_pcm_rate_hw_refine_cchange (pcm=0xad4016f8, 
    params=0xad5f1e40, sparams=0xad5f172c) at pcm_rate.c:189
189                             if ((buffer_size->min / period_size->min) *
period_size->min == buffer_size->min) {

Will file a bug tomorrow.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jonathan.underwood at gmail.com  Tue Oct 30 23:24:15 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 30 Oct 2007 23:24:15 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193787436.31627.60.camel@Jehannum>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
Message-ID: <645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>

On 30/10/2007, Caolan McNamara <caolanm at redhat.com> wrote:
>
> On Tue, 2007-10-30 at 20:36 +0100, nodata wrote:
> > Nautilus will open OpenText document files from OpenOffice.org with Java
> > by default
>
> What could "open with java" mean here, actually attempting to
> execute .odt files as java programs ?!, or treating them as .jar files
> an unzipping them or something. Here, though with OOo installed of
> course, it does does the right thing(tm).

I see the same problem on F-7 as well. The dialogue box reads:

Cannot open 4GLS_article.odt

The filename "4GLS_article.odt" indicates that this file is of type
"ODT document". The contents of the file indicate that the file is of
type "Java Archive". If you open this file, the file might present a
security risk to your system.

Do not open the file unless you created the file yourself, or received
the file from a trusted source. To open the file, rename the file to
the correct extension for "Java Archive", then open the file normally.
Alternatively, use the Open With menu to choose a specific application
for the file.



From trever.adams at gmail.com  Tue Oct 30 23:27:49 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 30 Oct 2007 17:27:49 -0600
Subject: RadeonHD driver status
In-Reply-To: <1193785938.3872.5.camel@optimus>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>  <1193782695.3872.1.camel@optimus>
	<1193783850.4670.6.camel@aragorn>  <1193785938.3872.5.camel@optimus>
Message-ID: <1193786869.4670.15.camel@aragorn>


On Wed, 2007-10-31 at 09:12 +1000, Dave Airlie wrote:
> This is the Internet, it looks like a me too and it smells like a me too
> I consider it a me too, providing info on the type/range of cards tested
> etc is useful.. saying avivo broken radeonhd not is not useful as we
> also have ppl saying the opposite...
> 
> Red Hat and Fedora are contemplating the future wrt to AMD r5xx cards,
> all options are going to be looked at, there may even be options that
> you don't know about yet..
> 
> Dave.
> 
01:00.1 Display controller: ATI Technologies Inc Radeon X1950 Pro
(Secondary) (PCIE)

Are the two machines I can talk about. One works better than the other
with Avivo, neither works well with it.

Both use AL2002W monitors from Acer. Both work very well at 1680x150 w/
this monitor. I may have one more machine I can comment on, but it will
be a few days.

I hope a great solution is found.

Trever
--
"There are two ways to live your life. One is as though nothing is a
miracle. The other is as though everything is a miracle." -- Albert
Einstein
-------------- 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/20071030/9dd6949e/attachment.sig>

From trever.adams at gmail.com  Tue Oct 30 23:31:10 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Tue, 30 Oct 2007 17:31:10 -0600
Subject: RadeonHD driver status
In-Reply-To: <1193786869.4670.15.camel@aragorn>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>  <1193782695.3872.1.camel@optimus>
	<1193783850.4670.6.camel@aragorn>  <1193785938.3872.5.camel@optimus>
	<1193786869.4670.15.camel@aragorn>
Message-ID: <1193787070.4670.19.camel@aragorn>


On Tue, 2007-10-30 at 17:27 -0600, Trever L. Adams wrote:
> 01:00.1 Display controller: ATI Technologies Inc Radeon X1950 Pro
> (Secondary) (PCIE)
> 
> Are the two machines I can talk about. One works better than the other
> with Avivo, neither works well with it.
> 
> Both use AL2002W monitors from Acer. Both work very well at 1680x150
> w/
> this monitor. I may have one more machine I can comment on, but it
> will
> be a few days.
> 
> I hope a great solution is found.
> 
> Trever

Sorry, I left out a few details. Avivo won't autodetect my monitor. I
believe, but am not sure that RadeonHD does. My monitor gives a
"frequency out of range" error w/ Avivo at 1680x1050. At 1440x1050 (I
believe it was) it looks almost like 1680x1050 and may actually be.
RadeonHD doesn't show the option 1440x1050 at all. However, it works
beautifully at 1680x1050.

When switching VTs (console to X and back) Avivo would frequently give
monitor problems that would require reboots. I have had only a few
problems with RadeonHD, and it is solved by turning the monitor off and
back on.

I think that is all the testing details I can give.

Trever
--
"Blessed is the man, who having nothing to say, abstains from giving
wordy evidence of the fact." -- George Eliot 
-------------- 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/20071030/34940925/attachment.sig>

From choeger at cs.tu-berlin.de  Tue Oct 30 23:33:32 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=)
Date: Wed, 31 Oct 2007 00:33:32 +0100
Subject: tomcat5 blank page
Message-ID: <4727BF4C.1050507@cs.tu-berlin.de>

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

hi,

i'm not sure wether this is really devel related, but I actually try
some tomcat5 web devel stuff and tried to set it up on my f7 box.

I recognized that the main page was blank and installed tomcat5-webapps
and tomcat5-webapps-admin and voila: everything looked fine. So I digged
into /etc/tomcat/tomcat-users.xml to add the 'manager' role to see the
axis validation page and from now on I have the blank screen again.
Abslutely no html seems to come from tomcat. Is that normal?
wget even tells me about an 400 error...

regards

christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHJ79LhMBO4cVSGS8RAq8hAKCF8Hyjq6x008pr++vMPv5Ihfqv7gCgs5zd
XclvLOu/V5bEiFALMdCXvi8=
=wvkf
-----END PGP SIGNATURE-----



From ngompa13 at gmail.com  Tue Oct 30 23:47:04 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Tue, 30 Oct 2007 18:47:04 -0500
Subject: OOo .odt files - open with Java by default
In-Reply-To: <645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
Message-ID: <8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>

I have had this problem since Fedora Core 4. Ever since GCJ and OOo 2.0 were
included in Fedora, this specific issue has cropped on my computers all the
time. The strange thing is that only OpenDocument files are considered Java
Archives. None of the other archive-based formats supported by OOo have this
issue as far as I can tell.

On 10/30/07, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
>
> On 30/10/2007, Caolan McNamara <caolanm at redhat.com> wrote:
> >
> > On Tue, 2007-10-30 at 20:36 +0100, nodata wrote:
> > > Nautilus will open OpenText document files from OpenOffice.org with
> Java
> > > by default
> >
> > What could "open with java" mean here, actually attempting to
> > execute .odt files as java programs ?!, or treating them as .jar files
> > an unzipping them or something. Here, though with OOo installed of
> > course, it does does the right thing(tm).
>
> I see the same problem on F-7 as well. The dialogue box reads:
>
> Cannot open 4GLS_article.odt
>
> The filename "4GLS_article.odt" indicates that this file is of type
> "ODT document". The contents of the file indicate that the file is of
> type "Java Archive". If you open this file, the file might present a
> security risk to your system.
>
> Do not open the file unless you created the file yourself, or received
> the file from a trusted source. To open the file, rename the file to
> the correct extension for "Java Archive", then open the file normally.
> Alternatively, use the Open With menu to choose a specific application
> for the file.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/28ddb3fa/attachment.htm>

From ngompa13 at gmail.com  Tue Oct 30 23:53:19 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Tue, 30 Oct 2007 18:53:19 -0500
Subject: Zimbra packages in Fedora
In-Reply-To: <47261CC8.8040507@fedoralinks.org>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
Message-ID: <8278b1b0710301653q506fa33at90c42be406ef89ef@mail.gmail.com>

Do you see any possibilities of methodically cleaning these issues up?

On 10/29/07, Robert 'Bob' Jensen <docs-list at fedoralinks.org> wrote:
>
> King InuYasha wrote:
> > I had noticed how well that Zimbra has been doing, and I was wondering
> > if it would be possible for someone to make packages for Zimbra to be
> > included in Fedora?
> >
>
> Well just my personal opinion... Zimbra might be doing well but the
> deployment system leaves a lot to be desired. Best I can tell (installed
> on CentOS5) the current version available is packaged with a broken
> tomcat server. There are some other things that should or would need to
> be addressed also such as the way zimbra provides things like mysqld,
> postfix, ok everything that makes zimbra work.
>
> Step one disable the firewall, step two disable SElinux, step three run
> the install script that will do a lot of things including install the
> rpms...
>
> Robert 'Bob' Jensen
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/29782b20/attachment.htm>

From notting at redhat.com  Wed Oct 31 00:32:25 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 20:32:25 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727B54A.4080806@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
Message-ID: <20071031003225.GB3972@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> Yes, I know the history here but there isn't a valid reason to do this 
> anymore as far as I know. So let's get fixed now.

gdm is the default login manager in the base X group. It can't
be removed from there.

Bill



From rodd at clarkson.id.au  Wed Oct 31 00:44:00 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 31 Oct 2007 11:44:00 +1100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
Message-ID: <1193791440.2818.2.camel@localhost.localdomain>


On Tue, 2007-10-30 at 18:47 -0500, King InuYasha wrote:
> I have had this problem since Fedora Core 4. Ever since GCJ and OOo
> 2.0 were included in Fedora, this specific issue has cropped on my
> computers all the time. The strange thing is that only OpenDocument
> files are considered Java Archives. None of the other archive-based
> formats supported by OOo have this issue as far as I can tell. 

Try this.

Right click a .odt file on the desktop (or in nautilus) and select
properties.

Select the Open With tab and see what's in there.

I have:

[ ] Archive Manager
[*] Word Processor

The Word Processor option is marked as the default.

I suspect you might have a third option and that this is marked as the
default.  You should be able to remove this third option (since it's
pointless)

R.


-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jonathan.underwood at gmail.com  Wed Oct 31 00:44:54 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 31 Oct 2007 00:44:54 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
Message-ID: <645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>

On 30/10/2007, King InuYasha <ngompa13 at gmail.com> wrote:
> I have had this problem since Fedora Core 4. Ever since GCJ and OOo 2.0 were
> included in Fedora, this specific issue has cropped on my computers all the
> time. The strange thing is that only OpenDocument files are considered Java
> Archives. None of the other archive-based formats supported by OOo have this
> issue as far as I can tell.

Actually, I think it's a nasty side effect of installing the Sun java
stack and java-1.6.0-sun-compat-1.6.0.01-1jpp from jpackage rather
than an OOo problem.



From jonathan.underwood at gmail.com  Wed Oct 31 00:48:39 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 31 Oct 2007 00:48:39 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193791440.2818.2.camel@localhost.localdomain>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<1193791440.2818.2.camel@localhost.localdomain>
Message-ID: <645d17210710301748p2cc55a81tbf6a1519d55c186c@mail.gmail.com>

On 31/10/2007, Rodd Clarkson <rodd at clarkson.id.au> wrote:

> Try this.
>
> Right click a .odt file on the desktop (or in nautilus) and select
> properties.
>
> Select the Open With tab and see what's in there.
>
> I have:
>
> [ ] Archive Manager
> [*] Word Processor
>
> The Word Processor option is marked as the default.
>

I have:
[*] Java
[ ] Archive manager

and no Wordprocessor entry.

> I suspect you might have a third option and that this is marked as the
> default.  You should be able to remove this third option (since it's
> pointless)
>

I think the problem is somehow the Sun java stack stomps on the Mime
type entry for OOo files.


I would be interested to know if the OP has installed Sun's java

J.
> R.
>
>
> --
> "It's a fine line between denial and faith.
>  It's much better on my side"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From sundaram at fedoraproject.org  Wed Oct 31 00:46:21 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 06:16:21 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031003225.GB3972@nostromo.devel.redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
Message-ID: <4727D05D.6060903@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Yes, I know the history here but there isn't a valid reason to do this 
>> anymore as far as I know. So let's get fixed now.
> 
> gdm is the default login manager in the base X group. It can't
> be removed from there.

Are you telling me there is no way we can let people who select KDE get 
KDM by default?

Rahul



From limb at jcomserv.net  Wed Oct 31 00:53:02 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 30 Oct 2007 19:53:02 -0500 (CDT)
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710301306i4d25d1bdu5584a651d58386@mail.gmail.com>
References: <3dd77c60710301306i4d25d1bdu5584a651d58386@mail.gmail.com>
Message-ID: <4519.192.168.0.1.1193791982.squirrel@mail.jcomserv.net>


> "Jon Ciesla" wrote:
>
> My main /etc/exports line is:
> /path_of_share/
> XXX.XXX.XXX.XXX/XXX.XXX.XXX.XXX(insecure,no_root_squash,rw,nohide)
>
> Mine is
> /path-to-share xx.xx.xx.xx(rw,root_squash)
>
> i.e. just one machine as client.

Willing to try re-mounting with different options to see if any help?

> mike cohler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From jkeating at redhat.com  Wed Oct 31 00:58:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 20:58:53 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727D05D.6060903@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
Message-ID: <20071030205853.20716788@redhat.com>

On Wed, 31 Oct 2007 06:16:21 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> > gdm is the default login manager in the base X group. It can't
> > be removed from there.  
> 
> Are you telling me there is no way we can let people who select KDE
> get KDM by default?

"default", which means it can be unchecked.  However 'kdm' doesn't seem
to exist at all in comps.  Is it being pulled in purely through deps?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/e49ca411/attachment.sig>

From notting at redhat.com  Wed Oct 31 01:13:17 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 21:13:17 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727D05D.6060903@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
Message-ID: <20071031011317.GA8370@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> gdm is the default login manager in the base X group. It can't
>> be removed from there.
>
> Are you telling me there is no way we can let people who select KDE get KDM 
> by default?

You said we needed to fix gdm being installed - that can't be done that
way.

Bill



From notting at redhat.com  Wed Oct 31 01:13:32 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 21:13:32 -0400
Subject: KDE logout options with F8
In-Reply-To: <20071030205853.20716788@redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071030205853.20716788@redhat.com>
Message-ID: <20071031011332.GB8370@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> "default", which means it can be unchecked.  However 'kdm' doesn't seem
> to exist at all in comps.  Is it being pulled in purely through deps?

kdm is part of kdebase.

Bill



From cebbert at redhat.com  Wed Oct 31 01:19:43 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Tue, 30 Oct 2007 21:19:43 -0400
Subject: KDE logout options with F8
In-Reply-To: <20071031011317.GA8370@nostromo.devel.redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
Message-ID: <4727D82F.40905@redhat.com>

On 10/30/2007 09:13 PM, Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>> gdm is the default login manager in the base X group. It can't
>>> be removed from there.
>> Are you telling me there is no way we can let people who select KDE get KDM 
>> by default?
> 
> You said we needed to fix gdm being installed - that can't be done that
> way.
> 

It's kind of annoying that I get gdm as the configured display manager even
after unchecking Gnome when I install.



From sundaram at fedoraproject.org  Wed Oct 31 01:29:23 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 06:59:23 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031011317.GA8370@nostromo.devel.redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
Message-ID: <4727DA73.1070908@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>> gdm is the default login manager in the base X group. It can't
>>> be removed from there.
>> Are you telling me there is no way we can let people who select KDE get KDM 
>> by default?
> 
> You said we needed to fix gdm being installed - that can't be done that
> way.

I only mentioned that KDM should be selected by default if users choose 
to select KDE. This really has nothing specific to do with KDE either. 
It is just logical that a display manager associated with any desktop 
environment should  be installed by default along with the desktop 
environment. I haven't described anything about GDM or how exactly that 
should be done. I don't see why GDM is in the x-group instead of the 
GNOME group either.

Rahul



From mclasen at redhat.com  Wed Oct 31 01:33:17 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 21:33:17 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727DA73.1070908@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
Message-ID: <1193794397.11243.1.camel@localhost.localdomain>


On Wed, 2007-10-31 at 06:59 +0530, Rahul Sundaram wrote:

> I only mentioned that KDM should be selected by default if users choose 
> to select KDE. This really has nothing specific to do with KDE either. 
> It is just logical that a display manager associated with any desktop 
> environment should  be installed by default along with the desktop 
> environment. I haven't described anything about GDM or how exactly that 
> should be done. I don't see why GDM is in the x-group instead of the 
> GNOME group either.

It is not very logical to associate a display manager with a desktop
environment in the first place. 



From sundaram at fedoraproject.org  Wed Oct 31 01:41:13 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 07:11:13 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193794397.11243.1.camel@localhost.localdomain>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>
	<1193794397.11243.1.camel@localhost.localdomain>
Message-ID: <4727DD39.5070900@fedoraproject.org>

Matthias Clasen wrote:
> On Wed, 2007-10-31 at 06:59 +0530, Rahul Sundaram wrote:
> 
>> I only mentioned that KDM should be selected by default if users choose 
>> to select KDE. This really has nothing specific to do with KDE either. 
>> It is just logical that a display manager associated with any desktop 
>> environment should  be installed by default along with the desktop 
>> environment. I haven't described anything about GDM or how exactly that 
>> should be done. I don't see why GDM is in the x-group instead of the 
>> GNOME group either.
> 
> It is not very logical to associate a display manager with a desktop
> environment in the first place. 

GNOME display manager is not logically associated with GNOME Desktop 
Environment? If that's the case, it makes it even more illogical that 
GNOME display manager is default for KDE Desktop Environment. Either we 
have a neutral display manager that works well for them both (it doesn't 
in this case since there is a regression in functionality inflicted by 
our defaults) or we install whatever display manager goes well with the 
desktop environment.

Rahul



From notting at redhat.com  Wed Oct 31 01:48:11 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 21:48:11 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727DA73.1070908@fedoraproject.org>
References: <200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
Message-ID: <20071031014811.GA13676@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> haven't described anything about GDM or how exactly that should be done. I 
> don't see why GDM is in the x-group instead of the GNOME group either.

A display manager is needed. Inflicting XDM on users is cruel and
unusual punishment.

Bill



From sundaram at fedoraproject.org  Wed Oct 31 01:49:02 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 07:19:02 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031014811.GA13676@nostromo.devel.redhat.com>
References: <200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
Message-ID: <4727DF0E.7090308@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> haven't described anything about GDM or how exactly that should be done. I 
>> don't see why GDM is in the x-group instead of the GNOME group either.
> 
> A display manager is needed. Inflicting XDM on users is cruel and
> unusual punishment.

Here is how it should work:

  * Default X group installs XDM
  * If you select GNOME, you get GDM
  * If you select KDE, you get KDM

Can we get this done?

Rahul



From mclasen at redhat.com  Wed Oct 31 01:52:18 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 21:52:18 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727DF0E.7090308@fedoraproject.org>
References: <200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
Message-ID: <1193795538.11243.3.camel@localhost.localdomain>


On Wed, 2007-10-31 at 07:19 +0530, Rahul Sundaram wrote:
> Bill Nottingham wrote:
> > Rahul Sundaram (sundaram at fedoraproject.org) said: 
> >> haven't described anything about GDM or how exactly that should be done. I 
> >> don't see why GDM is in the x-group instead of the GNOME group either.
> > 
> > A display manager is needed. Inflicting XDM on users is cruel and
> > unusual punishment.
> 
> Here is how it should work:
> 
>   * Default X group installs XDM
>   * If you select GNOME, you get GDM
>   * If you select KDE, you get KDM
> 
> Can we get this done?
> 

No. As Bill said, xdm is not an option.



From sundaram at fedoraproject.org  Wed Oct 31 01:59:59 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 07:29:59 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193795538.11243.3.camel@localhost.localdomain>
References: <200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
Message-ID: <4727E19F.1010405@fedoraproject.org>

Matthias Clasen wrote:
> On Wed, 2007-10-31 at 07:19 +0530, Rahul Sundaram wrote:
>> Bill Nottingham wrote:
>>> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>>> haven't described anything about GDM or how exactly that should be done. I 
>>>> don't see why GDM is in the x-group instead of the GNOME group either.
>>> A display manager is needed. Inflicting XDM on users is cruel and
>>> unusual punishment.
>> Here is how it should work:
>>
>>   * Default X group installs XDM
>>   * If you select GNOME, you get GDM
>>   * If you select KDE, you get KDM
>>
>> Can we get this done?
>>
> 
> No. As Bill said, xdm is not an option.

It sure is since xorg-x11-xdm is available in the repository but 
assuming this is true, what about getting KDM by default when users 
explicitly select KDE?

Rahul



From notting at redhat.com  Wed Oct 31 02:07:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 22:07:15 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E19F.1010405@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
Message-ID: <20071031020715.GA14902@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> It sure is since xorg-x11-xdm is available in the repository

Thanks for dismissing my argument without even reading the context of it!
You're swell.

tcsh is available in the repo too! Let's drop users to that!

Bill



From sundaram at fedoraproject.org  Wed Oct 31 02:14:41 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 07:44:41 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031020715.GA14902@nostromo.devel.redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
Message-ID: <4727E511.9000504@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> It sure is since xorg-x11-xdm is available in the repository
> 
> Thanks for dismissing my argument without even reading the context of it!
> You're swell.

I didn't see any context since you just said inflicting XDM is cruel 
without specifying why. If someone installs just Xorg without any 
desktop environment, I don't see why the default Xorg display manager 
would be a bad choice. The only users who are going to install just Xorg 
are power users and we don't have to worry about them too much since 
this is a corner case.

Besides my point was that if users select GNOME they should get GDM and 
if users select KDE, they should get KDM. Is anyone willing to respond 
to that?

Rahul



From mclasen at redhat.com  Wed Oct 31 02:21:34 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 22:21:34 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E511.9000504@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
Message-ID: <1193797294.11243.7.camel@localhost.localdomain>


On Wed, 2007-10-31 at 07:44 +0530, Rahul Sundaram wrote:

> Besides my point was that if users select GNOME they should get GDM and 
> if users select KDE, they should get KDM. Is anyone willing to respond 
> to that?

Sure, here you go: a display manager is a security sensitive piece of
code. Shipping multiple just because their names start with a letter you
don't like is not a smart move, because you end up doing twice the
security errata. 



From jkeating at redhat.com  Wed Oct 31 02:24:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 22:24:14 -0400
Subject: KDE logout options with F8
In-Reply-To: <1193797294.11243.7.camel@localhost.localdomain>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
Message-ID: <20071030222414.3fb693ea@redhat.com>

On Tue, 30 Oct 2007 22:21:34 -0400
Matthias Clasen <mclasen at redhat.com> wrote:

> Sure, here you go: a display manager is a security sensitive piece of
> code. Shipping multiple just because their names start with a letter
> you don't like is not a smart move, because you end up doing twice the
> security errata. 

And doing every feature twice (face browser, etc..) or having different
feature sets that confuse and anger users.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/6d6466c3/attachment.sig>

From notting at redhat.com  Wed Oct 31 02:28:13 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 22:28:13 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E511.9000504@fedoraproject.org>
References: <20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
Message-ID: <20071031022813.GA15904@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Thanks for dismissing my argument without even reading the context of it!
>> You're swell.
>
> I didn't see any context since you just said inflicting XDM is cruel 
> without specifying why.

Let's see...

- it's ugly
- it's ancient
- it's veritably unmaintained
- it's lacking in features

> If someone installs just Xorg without any desktop 
> environment, I don't see why the default Xorg display manager would be a 
> bad choice. The only users who are going to install just Xorg are power 
> users and we don't have to worry about them too much since this is a corner 
> case.

Right! If they happened to choose this group before, let's change the
defaults now so they get something worse!

> Besides my point was that if users select GNOME they should get GDM and if 
> users select KDE, they should get KDM. Is anyone willing to respond to 
> that?

Perhaps I wasn't clear enough. gdm is installed as part of base-x. So
you can't change this just via package installation.

Bill



From sundaram at fedoraproject.org  Wed Oct 31 02:27:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 07:57:36 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193797294.11243.7.camel@localhost.localdomain>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
Message-ID: <4727E818.8020202@fedoraproject.org>

Matthias Clasen wrote:
> On Wed, 2007-10-31 at 07:44 +0530, Rahul Sundaram wrote:
> 
>> Besides my point was that if users select GNOME they should get GDM and 
>> if users select KDE, they should get KDM. Is anyone willing to respond 
>> to that?
> 
> Sure, here you go: a display manager is a security sensitive piece of
> code. Shipping multiple just because their names start with a letter you
> don't like is not a smart move, because you end up doing twice the
> security errata. 

We are already shipping multiple display managers in our repository and 
KDM is already the default if you use KDE spin of Fedora. Only in the 
Fedora DVD, is GDM the default. The security argument only applies if we 
aren't shipping the package in the repository at all. As it stands, we 
have to provide a security errata if there are security issues in KDM 
anyway. So what matters here is only what is the default.

If you read why this thread started, it is because there is a regression 
in functionality if GDM is the default in KDE (ie) users lose the 
shutdown, hibernation buttons etc. Dismissing that regression by saying 
that it merely because of a letter is ignoring a actual problem.

Rahul



From sundaram at fedoraproject.org  Wed Oct 31 02:30:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:00:36 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071030222414.3fb693ea@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<20071030222414.3fb693ea@redhat.com>
Message-ID: <4727E8CC.403@fedoraproject.org>

Jesse Keating wrote:
> On Tue, 30 Oct 2007 22:21:34 -0400
> Matthias Clasen <mclasen at redhat.com> wrote:
> 
>> Sure, here you go: a display manager is a security sensitive piece of
>> code. Shipping multiple just because their names start with a letter
>> you don't like is not a smart move, because you end up doing twice the
>> security errata. 
> 
> And doing every feature twice (face browser, etc..) or having different
> feature sets that confuse and anger users.

Face browser feature already exists in KDE and since upstream is doing 
the work, it isn't a additional burden for us and users are already 
pissed off about losing basic functionality like a shutdown button.

Like I said, KDE spin already has KDM as the default. If someone is 
explicitly selecting KDE in the Fedora DVD image, it is safe to assume 
they are aware of the differences and provide them the display manager 
that matches their desktop environment better.

Rahul



From notting at redhat.com  Wed Oct 31 02:32:10 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 22:32:10 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E818.8020202@fedoraproject.org>
References: <20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
Message-ID: <20071031023210.GB15904@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> If you read why this thread started, it is because there is a regression in 
> functionality if GDM is the default in KDE (ie) users lose the shutdown, 
> hibernation buttons etc. Dismissing that regression by saying that it 
> merely because of a letter is ignoring a actual problem.

Then perhaps instead of suggesting we change many years of established
behavior ON THE NIGHT OF THE FINAL FREEZE (in ways that don't work, even)
you may want to work on investigating the actual bug?

Bill



From mclasen at redhat.com  Wed Oct 31 02:32:59 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 22:32:59 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E818.8020202@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
Message-ID: <1193797979.11243.11.camel@localhost.localdomain>


On Wed, 2007-10-31 at 07:57 +0530, Rahul Sundaram wrote:
> Matthias Clasen wrote:
> > On Wed, 2007-10-31 at 07:44 +0530, Rahul Sundaram wrote:
> > 
> >> Besides my point was that if users select GNOME they should get GDM and 
> >> if users select KDE, they should get KDM. Is anyone willing to respond 
> >> to that?
> > 
> > Sure, here you go: a display manager is a security sensitive piece of
> > code. Shipping multiple just because their names start with a letter you
> > don't like is not a smart move, because you end up doing twice the
> > security errata. 
> 
> We are already shipping multiple display managers in our repository and 
> KDM is already the default if you use KDE spin of Fedora. Only in the 
> Fedora DVD, is GDM the default. The security argument only applies if we 
> aren't shipping the package in the repository at all. As it stands, we 
> have to provide a security errata if there are security issues in KDM 
> anyway. So what matters here is only what is the default.

Well, it still applies, as an argument for not shipping it in the
repository at all...

> If you read why this thread started, it is because there is a regression 
> in functionality if GDM is the default in KDE (ie) users lose the 
> shutdown, hibernation buttons etc. Dismissing that regression by saying 
> that it merely because of a letter is ignoring a actual problem.

Yeah, and if you read earlier in this thread, somebody said that the
functionality used to work with gdm and kde in earlier releases, so we
are looking at a bug in either gdm or kde or both. Why not just fix that
bug ? 

How exactly did we get from "there is a bug in the interaction between
gdm and kde" to "omg kde uses a program that starts with g, that can't
be correct" ?



From sundaram at fedoraproject.org  Wed Oct 31 02:34:41 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:04:41 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031023210.GB15904@nostromo.devel.redhat.com>
References: <20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
Message-ID: <4727E9C1.6010906@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> If you read why this thread started, it is because there is a regression in 
>> functionality if GDM is the default in KDE (ie) users lose the shutdown, 
>> hibernation buttons etc. Dismissing that regression by saying that it 
>> merely because of a letter is ignoring a actual problem.
> 
> Then perhaps instead of suggesting we change many years of established
> behavior ON THE NIGHT OF THE FINAL FREEZE (in ways that don't work, even)
> you may want to work on investigating the actual bug?

I already discussed in a bug report in Red Hat bugzilla many months back 
IIRC that was ignored and I never suggested that we change this 
immediately for Fedora 8. Since KDE spin already has KDM as the default, 
  there isn't much of a chance for a regression but we can do this in 
the Fedora 9 branch just to be safe if that is a problem.

Rahul



From floss at lex.hider.name  Wed Oct 31 02:38:42 2007
From: floss at lex.hider.name (lexual)
Date: Wed, 31 Oct 2007 13:38:42 +1100
Subject: KDE logout options with F8
In-Reply-To: <4727E818.8020202@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
Message-ID: <4727EAB2.2070105@lex.hider.name>

Rahul Sundaram wrote:
> Matthias Clasen wrote:
>> On Wed, 2007-10-31 at 07:44 +0530, Rahul Sundaram wrote:
>>
>>> Besides my point was that if users select GNOME they should get GDM 
>>> and if users select KDE, they should get KDM. Is anyone willing to 
>>> respond to that?
>>
>> Sure, here you go: a display manager is a security sensitive piece of
>> code. Shipping multiple just because their names start with a letter you
>> don't like is not a smart move, because you end up doing twice the
>> security errata. 
>
> We are already shipping multiple display managers in our repository 
> and KDM is already the default if you use KDE spin of Fedora. Only in 
> the Fedora DVD, is GDM the default. The security argument only applies 
> if we aren't shipping the package in the repository at all. As it 
> stands, we have to provide a security errata if there are security 
> issues in KDM anyway. So what matters here is only what is the default.
>
> If you read why this thread started, it is because there is a 
> regression in functionality if GDM is the default in KDE (ie) users 
> lose the shutdown, hibernation buttons etc. Dismissing that regression 
> by saying that it merely because of a letter is ignoring a actual 
> problem.
>
> Rahul
>
My 2 cents.

1) Isn't it a bug that shutdown/hibernate options aren't available in 
kde using gdm?
2) Isn't the issue not whether gdm or kdm gets installed (kdm will also 
be installed with kde desktop group), but which one is set to run on 
booting.
3) I agree that avoiding xdm is a good idea.
4) If we change so that user ticking kde group install get kdm on boot, 
what happens if user has ticked both gnome and kde. It's perfectly 
legitimate to have a computer where different users use gnome, kde, 
xfce, etc. So GNOME/KDE desktop installation isn't always an either or 
option. They're not mutually exclusive.

Is it a kdebase or gdm bug that the shutdown options aren't available 
from a kde session with gdm as manager?

Lex.



From sundaram at fedoraproject.org  Wed Oct 31 02:43:57 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:13:57 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193797979.11243.11.camel@localhost.localdomain>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
Message-ID: <4727EBED.4020909@fedoraproject.org>

Matthias Clasen wrote:
> On Wed, 2007-10-31 at 07:57 +0530, Rahul Sundaram wrote:
>> Matthias Clasen wrote:
>>> On Wed, 2007-10-31 at 07:44 +0530, Rahul Sundaram wrote:
>>>
>>>> Besides my point was that if users select GNOME they should get GDM and 
>>>> if users select KDE, they should get KDM. Is anyone willing to respond 
>>>> to that?
>>> Sure, here you go: a display manager is a security sensitive piece of
>>> code. Shipping multiple just because their names start with a letter you
>>> don't like is not a smart move, because you end up doing twice the
>>> security errata. 
>> We are already shipping multiple display managers in our repository and 
>> KDM is already the default if you use KDE spin of Fedora. Only in the 
>> Fedora DVD, is GDM the default. The security argument only applies if we 
>> aren't shipping the package in the repository at all. As it stands, we 
>> have to provide a security errata if there are security issues in KDM 
>> anyway. So what matters here is only what is the default.
> 
> Well, it still applies, as an argument for not shipping it in the
> repository at all...

Please be realistic. I doubt if you would agree to KDM be the default 
display manager for both desktop environments and dropping GDM instead. 
What you are suggesting is never going to happen. KDM is going to be in 
the repository and we are going to be doing security erratas anyway. 
Hence the security argument is completely irrelevant for what should be 
the default.

> Yeah, and if you read earlier in this thread, somebody said that the
> functionality used to work with gdm and kde in earlier releases, so we
> are looking at a bug in either gdm or kde or both. Why not just fix that
> bug ? 

I didn't see anyone claim that the buttons used to work with GDM by 
default. Can anyone recall if that claim if it happened was true? 
Besides there are more differences in between KDM and GDM than merely this.

> How exactly did we get from "there is a bug in the interaction between
> gdm and kde" to "omg kde uses a program that starts with g, that can't
> be correct" ?

Like I said, the letter or name is not a problem. You are bringing up a 
false argument repeatedly. There is a actual regression in functionality 
and there is inconsistent behavior between the Fedora DVD image and the 
KDE spin too.

Rahul



From sundaram at fedoraproject.org  Wed Oct 31 02:47:18 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:17:18 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031022813.GA15904@nostromo.devel.redhat.com>
References: <20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>
	<20071031022813.GA15904@nostromo.devel.redhat.com>
Message-ID: <4727ECB6.1080002@fedoraproject.org>

Bill Nottingham wrote:

> 
>> If someone installs just Xorg without any desktop 
>> environment, I don't see why the default Xorg display manager would be a 
>> bad choice. The only users who are going to install just Xorg are power 
>> users and we don't have to worry about them too much since this is a corner 
>> case.
> 
> Right! If they happened to choose this group before, let's change the
> defaults now so they get something worse!

We worry about this corner case of users choosing just Xorg and then 
inflict worse choices on a much more common scenario of users using KDE. 
That doesn't make much sense to me.
> 
> Perhaps I wasn't clear enough. gdm is installed as part of base-x. So
> you can't change this just via package installation.

So the question is, is there any way at all to get KDM by default when 
users select KDE during installation or is there none?

Rahul



From notting at redhat.com  Wed Oct 31 02:49:44 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 22:49:44 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727E9C1.6010906@fedoraproject.org>
References: <20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
Message-ID: <20071031024944.GA22292@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Then perhaps instead of suggesting we change many years of established
>> behavior ON THE NIGHT OF THE FINAL FREEZE (in ways that don't work, even)
>> you may want to work on investigating the actual bug?
>
> I already discussed in a bug report in Red Hat bugzilla many months back 
> IIRC that was ignored and I never suggested that we change this immediately 
> for Fedora 8. Since KDE spin already has KDM as the default,  there isn't 
> much of a chance for a regression but we can do this in the Fedora 9 branch 
> just to be safe if that is a problem.

*sigh*

Or, you know, you could investigate the actual bug. Which is easily found
in both the KDE and GNOME bugzillas, where you can find out that it's 
because kdebase is pointing to the wrong location for the GDM fifo, and
note the one line patch in the KDE bugzilla that fixes it, apply it to
CVS, and build it.

HTH. HAND.

Bill



From mclasen at redhat.com  Wed Oct 31 02:56:24 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 22:56:24 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727EBED.4020909@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
Message-ID: <1193799384.11243.21.camel@localhost.localdomain>


On Wed, 2007-10-31 at 08:13 +0530, Rahul Sundaram wrote:

> > Well, it still applies, as an argument for not shipping it in the
> > repository at all...
> 
> Please be realistic. I doubt if you would agree to KDM be the default 
> display manager for both desktop environments and dropping GDM instead. 
> What you are suggesting is never going to happen. KDM is going to be in 
> the repository and we are going to be doing security erratas anyway. 
> Hence the security argument is completely irrelevant for what should be 
> the default.

I didn't say that it applies only to kdm. We could for instance, apply
it to xdm...

> I didn't see anyone claim that the buttons used to work with GDM by 
> default. Can anyone recall if that claim if it happened was true? 
> Besides there are more differences in between KDM and GDM than merely this.
> 
> > How exactly did we get from "there is a bug in the interaction between
> > gdm and kde" to "omg kde uses a program that starts with g, that can't
> > be correct" ?
> 
> Like I said, the letter or name is not a problem. You are bringing up a 
> false argument repeatedly. There is a actual regression in functionality 
> and there is inconsistent behavior between the Fedora DVD image and the 
> KDE spin too.

Make up your mind, please. If you don't believe that it used to work,
then it is not a regression. 

It is still a bug, and should be fixed, of course. Just like the
corresponding bugs in the interaction between kdm and gnome, since, as
Jesse pointed out, relying on kde working with kdm and gnome working
with gdm doesn't buy you anything on systems which have both kde and
gnome users. 



 



From sundaram at fedoraproject.org  Wed Oct 31 02:56:13 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:26:13 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031024944.GA22292@nostromo.devel.redhat.com>
References: <20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<20071031023210.GB15904@nostromo.devel.redhat.com>	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
Message-ID: <4727EECD.2080808@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>> Then perhaps instead of suggesting we change many years of established
>>> behavior ON THE NIGHT OF THE FINAL FREEZE (in ways that don't work, even)
>>> you may want to work on investigating the actual bug?
>> I already discussed in a bug report in Red Hat bugzilla many months back 
>> IIRC that was ignored and I never suggested that we change this immediately 
>> for Fedora 8. Since KDE spin already has KDM as the default,  there isn't 
>> much of a chance for a regression but we can do this in the Fedora 9 branch 
>> just to be safe if that is a problem.
> 
> *sigh*
> 
> Or, you know, you could investigate the actual bug. Which is easily found
> in both the KDE and GNOME bugzillas, where you can find out that it's 
> because kdebase is pointing to the wrong location for the GDM fifo, and
> note the one line patch in the KDE bugzilla that fixes it, apply it to
> CVS, and build it.

Let me repeat. I discussed this in bugzilla before and it was ignored 
despite being a long standing issue and there are more differences in 
between KDM and GDM than merely this and KDM is always going to work 
better with KDE and similarly, GDM with GNOME. You are forcing GDM to be 
the default for KDE unnecessarily even though, this is not the case for 
the KDE spin.

Rahul



From sundaram at fedoraproject.org  Wed Oct 31 03:01:06 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:31:06 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193799384.11243.21.camel@localhost.localdomain>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
Message-ID: <4727EFF2.6050505@fedoraproject.org>

Matthias Clasen wrote:

> I didn't say that it applies only to kdm. We could for instance, apply
> it to xdm...

None of the packages are going to be dropped for the security argument. 
Duplication is not a problem for for any package submitted in the 
repository. If there are people interested in maintaining KDM, XDM etc, 
they will.

> Make up your mind, please. If you don't believe that it used to work,
> then it is not a regression. 

It is a regression compared to the KDE spin.

Rahul



From mclasen at redhat.com  Wed Oct 31 03:04:57 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 30 Oct 2007 23:04:57 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727EFF2.6050505@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
Message-ID: <1193799897.11243.24.camel@localhost.localdomain>


On Wed, 2007-10-31 at 08:31 +0530, Rahul Sundaram wrote:
> Matthias Clasen wrote:
> 
> > I didn't say that it applies only to kdm. We could for instance, apply
> > it to xdm...
> 
> None of the packages are going to be dropped for the security argument. 
> Duplication is not a problem for for any package submitted in the 
> repository. If there are people interested in maintaining KDM, XDM etc, 
> they will.

Sure it is a problem. Saying it is not does not make it go away.

> > Make up your mind, please. If you don't believe that it used to work,
> > then it is not a regression. 
> 
> It is a regression compared to the KDE spin.
> 

Thats a creative use of the term regression. 



From notting at redhat.com  Wed Oct 31 03:07:43 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 23:07:43 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727EECD.2080808@fedoraproject.org>
References: <1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
	<4727EECD.2080808@fedoraproject.org>
Message-ID: <20071031030743.GA23453@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Or, you know, you could investigate the actual bug. Which is easily found
>> in both the KDE and GNOME bugzillas, where you can find out that it's 
>> because kdebase is pointing to the wrong location for the GDM fifo, and
>> note the one line patch in the KDE bugzilla that fixes it, apply it to
>> CVS, and build it.
>
> Let me repeat. I discussed this in bugzilla before and it was ignored 
> despite being a long standing issue

Bug number?

Bill



From jkeating at redhat.com  Wed Oct 31 03:07:07 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 23:07:07 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727ECB6.1080002@fedoraproject.org>
References: <20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<20071031022813.GA15904@nostromo.devel.redhat.com>
	<4727ECB6.1080002@fedoraproject.org>
Message-ID: <20071030230707.13c5662b@redhat.com>

On Wed, 31 Oct 2007 08:17:18 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> So the question is, is there any way at all to get KDM by default
> when users select KDE during installation or is there none?

Sure, in release notes for KDE you tell them to uncheck gdm.  Seriously
this is the choose your own adventure install type we're talking
about.  There is a reason it's marked as a default and not a
mandatory.  They can opt out of gdm and then the kdm which comes in
kdebase will be the only one left to use.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/9b5d9921/attachment.sig>

From sundaram at fedoraproject.org  Wed Oct 31 03:07:41 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:37:41 +0530
Subject: KDE logout options with F8
In-Reply-To: <1193799897.11243.24.camel@localhost.localdomain>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
Message-ID: <4727F17D.2090305@fedoraproject.org>

Matthias Clasen wrote:
> On Wed, 2007-10-31 at 08:31 +0530, Rahul Sundaram wrote:
>> Matthias Clasen wrote:
>>
>>> I didn't say that it applies only to kdm. We could for instance, apply
>>> it to xdm...
>> None of the packages are going to be dropped for the security argument. 
>> Duplication is not a problem for for any package submitted in the 
>> repository. If there are people interested in maintaining KDM, XDM etc, 
>> they will.
> 
> Sure it is a problem. Saying it is not does not make it go away.

If it is going to be a problem, the problem would be there regardless of 
whether GDM or KDM is the default.

>>> Make up your mind, please. If you don't believe that it used to work,
>>> then it is not a regression. 
>> It is a regression compared to the KDE spin.
>>
> 
> Thats a creative use of the term regression. 

Maybe it is. Not a native speaker.

Rahul



From notting at redhat.com  Wed Oct 31 03:09:41 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 23:09:41 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727EFF2.6050505@fedoraproject.org>
References: <1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
Message-ID: <20071031030941.GB23453@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Make up your mind, please. If you don't believe that it used to work,
>> then it is not a regression. 
>
> It is a regression compared to the KDE spin.

You keep using that word. I do not think it means what you think it means.

Bill



From sundaram at fedoraproject.org  Wed Oct 31 03:08:35 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:38:35 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031030743.GA23453@nostromo.devel.redhat.com>
References: <1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<20071031023210.GB15904@nostromo.devel.redhat.com>	<4727E9C1.6010906@fedoraproject.org>	<20071031024944.GA22292@nostromo.devel.redhat.com>	<4727EECD.2080808@fedoraproject.org>
	<20071031030743.GA23453@nostromo.devel.redhat.com>
Message-ID: <4727F1B3.80700@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>> Or, you know, you could investigate the actual bug. Which is easily found
>>> in both the KDE and GNOME bugzillas, where you can find out that it's 
>>> because kdebase is pointing to the wrong location for the GDM fifo, and
>>> note the one line patch in the KDE bugzilla that fixes it, apply it to
>>> CVS, and build it.
>> Let me repeat. I discussed this in bugzilla before and it was ignored 
>> despite being a long standing issue
> 
> Bug number?

Don't have it handy. This was many months (or years) back.

Rahul



From notting at redhat.com  Wed Oct 31 03:13:01 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Oct 2007 23:13:01 -0400
Subject: KDE logout options with F8
In-Reply-To: <4727F1B3.80700@fedoraproject.org>
References: <20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
	<4727EECD.2080808@fedoraproject.org>
	<20071031030743.GA23453@nostromo.devel.redhat.com>
	<4727F1B3.80700@fedoraproject.org>
Message-ID: <20071031031301.GA23887@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>> Let me repeat. I discussed this in bugzilla before and it was ignored 
>>> despite being a long standing issue
>> Bug number?
>
> Don't have it handy. This was many months (or years) back.

OK, let me recap:

- You're uninterested in solving the current bug
- You're interested in pushing a different agenda
- You're supporting it with anecdotal evidence you can't verify

Give me a break. We're trying to do useful work here.

Bill



From sundaram at fedoraproject.org  Wed Oct 31 03:24:37 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 08:54:37 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031031301.GA23887@nostromo.devel.redhat.com>
References: <20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<20071031023210.GB15904@nostromo.devel.redhat.com>	<4727E9C1.6010906@fedoraproject.org>	<20071031024944.GA22292@nostromo.devel.redhat.com>	<4727EECD.2080808@fedoraproject.org>	<20071031030743.GA23453@nostromo.devel.redhat.com>	<4727F1B3.80700@fedoraproject.org>
	<20071031031301.GA23887@nostromo.devel.redhat.com>
Message-ID: <4727F575.6020400@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>>>> Let me repeat. I discussed this in bugzilla before and it was ignored 
>>>> despite being a long standing issue
>>> Bug number?
>> Don't have it handy. This was many months (or years) back.
> 
> OK, let me recap:
> 
> - You're uninterested in solving the current bug

If that would be the case, why would I have discussed the bug in the 
first place?

> - You're interested in pushing a different agenda

You shouldn't accuse people of pushing agendas without specifying what 
agenda it is. I could do the same and we wouldn't have progressed anywhere.

> - You're supporting it with anecdotal evidence you can't verify

I could spend sometime digging it out possibly but I don't see the point 
since I get personally accused of pushing unknown agendas instead. End 
of discussion.

Rahul



From ngompa13 at gmail.com  Wed Oct 31 03:48:09 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Tue, 30 Oct 2007 22:48:09 -0500
Subject: OOo .odt files - open with Java by default
In-Reply-To: <645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
Message-ID: <8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>

I never install Sun Java. These problems crop up in a default Fedora install
for me.

On 10/30/07, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
>
> On 30/10/2007, King InuYasha <ngompa13 at gmail.com> wrote:
> > I have had this problem since Fedora Core 4. Ever since GCJ and OOo 2.0were
> > included in Fedora, this specific issue has cropped on my computers all
> the
> > time. The strange thing is that only OpenDocument files are considered
> Java
> > Archives. None of the other archive-based formats supported by OOo have
> this
> > issue as far as I can tell.
>
> Actually, I think it's a nasty side effect of installing the Sun java
> stack and java-1.6.0-sun-compat-1.6.0.01-1jpp from jpackage rather
> than an OOo problem.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071030/ab498b47/attachment.htm>

From kevin.kofler at chello.at  Wed Oct 31 04:13:31 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:13:31 +0000 (UTC)
Subject: KDE logout options with F8
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<1193794397.11243.1.camel@localhost.localdomain>
Message-ID: <loom.20071031T041256-353@post.gmane.org>

Matthias Clasen <mclasen <at> redhat.com> writes:
> It is not very logical to associate a display manager with a desktop
> environment in the first place. 

But it is how things work in the real world.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:19:37 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:19:37 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
Message-ID: <loom.20071031T041649-185@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> tcsh is available in the repo too! Let's drop users to that!

tcsh is a perfectly usable shell and there are users who love it. So it 
wouldn't be that insane. Of course you'd need a POSIX-compliant /bin/sh anyway, 
but defaulting to tcsh as an interactive shell would still be a valid choice, 
so this is a bad comparison. (I'd switch the shell back to bash immediately, as 
would most people on this list, I guess, but not everyone grew up in a 
GNU/Linux/bash world. ;-) )

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:16:20 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:16:20 +0000 (UTC)
Subject: KDE logout options with F8
References: <200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
Message-ID: <loom.20071031T041407-306@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> Here is how it should work:
> 
>   * Default X group installs XDM
>   * If you select GNOME, you get GDM
>   * If you select KDE, you get KDM

I agree with that. The base X group also has TWM, how is XDM not of the same 
kind (usable, but very basic and old)? Base X should really be the minimal X 
and not include random parts of an arbitrary desktop environment, exactly 
because there are two (actually more than two).

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:32:04 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:32:04 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
Message-ID: <loom.20071031T041957-355@post.gmane.org>

Matthias Clasen <mclasen <at> redhat.com> writes:
> Sure, here you go: a display manager is a security sensitive piece of
> code. Shipping multiple just because their names start with a letter you
> don't like is not a smart move, because you end up doing twice the
> security errata. 

Please don't make up excuses to fight the desires of the KDE SIG. The fact is:
* The KDE spin already defaults to KDM. This is not a mistake, but an 
intentional decision.
* As far as I know, the KDE SIG members who expressed an opinion on this issue 
all want KDM as the default for KDE on the DVD too.
* I'm definitely one of these.
* Rex Dieter, who started that whole KDE SIG, wants that, too. See the October 
9 meeting log: http://repo.calcforge.org/temp/fedora-kde-sig-2007-10-09.txt

Now how to implement this technically is another issue (I don't see what's the 
big problem with having XDM in Base X and GDM/KDM in the respective desktop 
environment groups, but there's surely other solutions too!), but saying KDM is 
not desirable at all is something we don't agree to.

As for the security errata in KDM, this is our (KDE SIG) responsibility and we 
always take care of those errata, so I don't see how that would be a burden on 
the distro.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:37:09 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:37:09 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<20071030222414.3fb693ea@redhat.com>
Message-ID: <loom.20071031T043323-852@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> And doing every feature twice (face browser, etc..) or having different
> feature sets that confuse and anger users.

Different software has different features, duh... It's funny that you mention 
the face browser, because KDM actually supported that first as far as I know. 
If all choices had the exact same features, people wouldn't have a preference 
in the first place. And there are several features KDE has and GNOME doesn't 
have. There will be even more with KDE 4.x. To follow your logic, we should 
drop GNOME. ;-)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:42:30 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:42:30 +0000 (UTC)
Subject: KDE logout options with F8
References: <20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
Message-ID: <loom.20071031T043839-587@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> Or, you know, you could investigate the actual bug. Which is easily found
> in both the KDE and GNOME bugzillas, where you can find out that it's 
> because kdebase is pointing to the wrong location for the GDM fifo, and
> note the one line patch in the KDE bugzilla that fixes it, apply it to
> CVS, and build it.

Thanks for the fix. KDE working properly with GDM is a good thing.

However, this doesn't mean defaulting to KDM when the user chooses KDE 
shouldn't be done anyway. I agree it's late for F8, but for F9?

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:47:16 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:47:16 +0000 (UTC)
Subject: KDE logout options with F8
References: <20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
	<4727EECD.2080808@fedoraproject.org>
	<20071031030743.GA23453@nostromo.devel.redhat.com>
	<4727F1B3.80700@fedoraproject.org>
	<20071031031301.GA23887@nostromo.devel.redhat.com>
Message-ID: <loom.20071031T044300-453@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> - You're interested in pushing a different agenda

The "agenda" he is "pushing" is the position of several KDE SIG members and the 
closest thing to an official KDE SIG position you'll get unless you want us to 
hold a vote.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 04:54:32 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 04:54:32 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
Message-ID: <loom.20071031T044800-64@post.gmane.org>

Matthias Clasen <mclasen <at> redhat.com> writes:
> Well, it still applies, as an argument for not shipping it in the
> repository at all...

You can pry KDM from my cold, dead hands. Removing KDM is not going to happen.

> How exactly did we get from "there is a bug in the interaction between
> gdm and kde" to "omg kde uses a program that starts with g, that can't
> be correct" ?

Because the topic happened to come up here now, just a few days after we 
discussed this exact issue in the KDE SIG meeting (October 9).

And the problem isn't that it "starts with g", but that it's part of GNOME, 
whereas KDM is part of KDE. They also use the respective widget toolkits.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 05:02:41 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 05:02:41 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<4727EAB2.2070105@lex.hider.name>
Message-ID: <loom.20071031T045526-872@post.gmane.org>

lexual <floss <at> lex.hider.name> writes:
> 1) Isn't it a bug that shutdown/hibernate options aren't available in 
> kde using gdm?

It is, it has been fixed now.

> 2) Isn't the issue not whether gdm or kdm gets installed (kdm will also 
> be installed with kde desktop group), but which one is set to run on 
> booting.

Yes. But not installing GDM in the first place would make booting do the right 
thing automatically, so that would be one way to do it.

> 3) I agree that avoiding xdm is a good idea.

Are you suggesting throwing out all the lightweight WMs too? How's XDM any 
different?

> 4) If we change so that user ticking kde group install get kdm on boot, 
> what happens if user has ticked both gnome and kde. It's perfectly 
> legitimate to have a computer where different users use gnome, kde, 
> xfce, etc. So GNOME/KDE desktop installation isn't always an either or 
> option. They're not mutually exclusive.

Then they get a global default, probably GDM. (It's what happens now if both 
GDM and KDM are installed, which is part of what causes this issue, the other 
part being that GDM is always installed by default.)

> Is it a kdebase or gdm bug that the shutdown options aren't available 
> from a kde session with gdm as manager?

GDM made a change which broke KDE, Bill Nottingham has patched kdebase to match 
the new GDM now.

        Kevin Kofler



From floss at lex.hider.name  Wed Oct 31 05:03:51 2007
From: floss at lex.hider.name (lexual)
Date: Wed, 31 Oct 2007 16:03:51 +1100
Subject: KDE logout options with F8
In-Reply-To: <20071031024944.GA22292@nostromo.devel.redhat.com>
References: <20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<20071031023210.GB15904@nostromo.devel.redhat.com>	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
Message-ID: <47280CB7.5030400@lex.hider.name>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>   
>>> Then perhaps instead of suggesting we change many years of established
>>> behavior ON THE NIGHT OF THE FINAL FREEZE (in ways that don't work, even)
>>> you may want to work on investigating the actual bug?
>>>       
>> I already discussed in a bug report in Red Hat bugzilla many months back 
>> IIRC that was ignored and I never suggested that we change this immediately 
>> for Fedora 8. Since KDE spin already has KDM as the default,  there isn't 
>> much of a chance for a regression but we can do this in the Fedora 9 branch 
>> just to be safe if that is a problem.
>>     
>
> *sigh*
>
> Or, you know, you could investigate the actual bug. Which is easily found
> in both the KDE and GNOME bugzillas, where you can find out that it's 
> because kdebase is pointing to the wrong location for the GDM fifo, and
> note the one line patch in the KDE bugzilla that fixes it, apply it to
> CVS, and build it.
>
> HTH. HAND.
>
> Bill
>
>   

Kubuntu guys may have a patch?
https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/64695

Do you have link to KDE bug, because I couldn't find any gdm mentions in 
kde bugzilla.




From kevin.kofler at chello.at  Wed Oct 31 05:07:53 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 05:07:53 +0000 (UTC)
Subject: KDE logout options with F8
References: <20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>
	<20071031022813.GA15904@nostromo.devel.redhat.com>
	<4727ECB6.1080002@fedoraproject.org>
Message-ID: <loom.20071031T050315-991@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> So the question is, is there any way at all to get KDM by default when 
> users select KDE during installation or is there none?

Here's one: reverse the fallback preferences so KDM is preferred over GDM. That 
way, people who only select GNOME (or Base X) will still get GDM (because KDM 
is in kdebase - we could even split it out to a kdebase-kdm subpackage and put 
that in as default in the KDE group so we don't end up with KDM pulled in 
accidentally when a GNOME user installs some KDE app which happens to require 
kdebase), people who select KDE will get KDM as they expect. It would change 
the default for those having both GNOME and KDE though.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 05:09:30 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 05:09:30 +0000 (UTC)
Subject: KDE logout options with F8
References: <20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<20071031022813.GA15904@nostromo.devel.redhat.com>
	<4727ECB6.1080002@fedoraproject.org>
	<20071030230707.13c5662b@redhat.com>
Message-ID: <loom.20071031T050837-944@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> Sure, in release notes for KDE you tell them to uncheck gdm.  Seriously
> this is the choose your own adventure install type we're talking
> about.  There is a reason it's marked as a default and not a
> mandatory.  They can opt out of gdm and then the kdm which comes in
> kdebase will be the only one left to use.

Good to know, that's better than nothing, but it's very manual and not a real 
solution.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 31 05:11:32 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 05:11:32 +0000 (UTC)
Subject: KDE logout options with F8
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B6E6.7040808@redhat.com>
Message-ID: <loom.20071031T050940-639@post.gmane.org>

Chuck Ebbert <cebbert <at> redhat.com> writes:
> And now kdm gets almost zero testing because of that.

KDM is the default in the KDE-Live spin, so it has been getting testing at 
least since Fedora 7. And there's plenty of KDE users who selected KDM manually 
too (e.g. me).

        Kevin Kofler



From floss at lex.hider.name  Wed Oct 31 05:32:32 2007
From: floss at lex.hider.name (lexual)
Date: Wed, 31 Oct 2007 16:32:32 +1100
Subject: KDE logout options with F8
In-Reply-To: <loom.20071031T045526-872@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<4727EAB2.2070105@lex.hider.name>
	<loom.20071031T045526-872@post.gmane.org>
Message-ID: <47281370.4060507@lex.hider.name>

Kevin Kofler wrote:
> lexual <floss <at> lex.hider.name> writes:
>   
>> 1) Isn't it a bug that shutdown/hibernate options aren't available in 
>> kde using gdm?
>>     
>
> It is, it has been fixed now.
>
>   
<monty burns>Excellllent!</monty burns>
>> 2) Isn't the issue not whether gdm or kdm gets installed (kdm will also 
>> be installed with kde desktop group), but which one is set to run on 
>> booting.
>>     
>
> Yes. But not installing GDM in the first place would make booting do the right 
> thing automatically, so that would be one way to do it.
>
>   
>> 3) I agree that avoiding xdm is a good idea.
>>     
>
> Are you suggesting throwing out all the lightweight WMs too? How's XDM any 
> different?
>
>   
No. There is a difference between kicking something out of the archive, 
and installing it by default.
>> 4) If we change so that user ticking kde group install get kdm on boot, 
>> what happens if user has ticked both gnome and kde. It's perfectly 
>> legitimate to have a computer where different users use gnome, kde, 
>> xfce, etc. So GNOME/KDE desktop installation isn't always an either or 
>> option. They're not mutually exclusive.
>>     
>
> Then they get a global default, probably GDM. (It's what happens now if both 
> GDM and KDM are installed, which is part of what causes this issue, the other 
> part being that GDM is always installed by default.)
>
>   
Disclaimer: I'm a Fedora newbie, and clueless to how much of it works.
Here's my idea.

Could this be fixed in comps.xml ?
e.g. the british language support group has conditional requires like 
the following:

<packagelist>
      <packagereq type="conditional" 
requires="kdelibs">kde-i18n-British</packag
ereq>
      <packagereq type="conditional" 
requires="koffice-core">koffice-langpack-en
_GB</packagereq>
    </packagelist>

I think I'm right in writing that the only desktop option on DVD are 
gnome & kde (don't think xfce is on there).
So could the gdm dependency in base-x group be a conditional one on 
having gnome installed?
>> Is it a kdebase or gdm bug that the shutdown options aren't available 
>> from a kde session with gdm as manager?
>>     
>
> GDM made a change which broke KDE, Bill Nottingham has patched kdebase to match 
> the new GDM now.
>
>         Kevin Kofler
>
>   



From vikigoyal at gmail.com  Wed Oct 31 05:47:14 2007
From: vikigoyal at gmail.com (Vikram Goyal)
Date: Wed, 31 Oct 2007 11:17:14 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071030222414.3fb693ea@redhat.com>
References: <20071030222414.3fb693ea@redhat.com>
Message-ID: <20071031054714.GA16711@holycow.viki.com>

On Tue, Oct 30, 2007 at 10:24:14PM -0400, Jesse Keating wrote:
> On Tue, 30 Oct 2007 22:21:34 -0400
> Matthias Clasen <mclasen at redhat.com> wrote:
> 
> > Sure, here you go: a display manager is a security sensitive piece of
> > code. Shipping multiple just because their names start with a letter
> > you don't like is not a smart move, because you end up doing twice the
> > security errata. 
> 
> And doing every feature twice (face browser, etc..) or having different
> feature sets that confuse and anger users.
> 

Yes, absolutely logical and clear message. We should have only one
display manager and only one desktop environment. What the other are
doing but giving the same functionality. On the same lines:

There should be only one shell
There should be only one image viewer
There should be only one file browser
There should be only one internet browser
There should be only one mail client

On top of that 'WE should have only one distro'

Things remain simple that way.

Whoops! goes the fedora KDE integration.

Really nice direction. Things became a bit clear today. Thanks...

Cheers!
-- 
vikram...
         ||||||||
         ||||||||
^^'''''^^||root||^^^'''''''^^
        // \\   ))
       //(( \\// \\
      // /\\ ||   \\
     || / )) ((    \\
-- 
The state law of Pennsylvania prohibits singing in the bathtub.
-- 
 .
~|~
 =



From cjdahlin at ncsu.edu  Wed Oct 31 06:09:59 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Wed, 31 Oct 2007 02:09:59 -0400
Subject: Any LSB init scripts?
Message-ID: <47281C37.5050802@ncsu.edu>

I've been working on a rewrite of prcsys for Fedora, and I've been 
looking for some LSB compliant init scripts to test against. Does anyone 
know if there are a substantial number of packages that already provide 
the LSB headers, or does anyone happen to have the headers hacked into 
some of their own scripts? I just need a handful to saturate the 
interesting cases.

Thanks!

--CJD



From harald at redhat.com  Wed Oct 31 06:22:10 2007
From: harald at redhat.com (Harald Hoyer)
Date: Wed, 31 Oct 2007 07:22:10 +0100
Subject: Any LSB init scripts?
In-Reply-To: <47281C37.5050802@ncsu.edu>
References: <47281C37.5050802@ncsu.edu>
Message-ID: <47281F12.8070302@redhat.com>

Casey Dahlin wrote:
> I've been working on a rewrite of prcsys for Fedora, and I've been 
> looking for some LSB compliant init scripts to test against. Does anyone 
> know if there are a substantial number of packages that already provide 
> the LSB headers, or does anyone happen to have the headers hacked into 
> some of their own scripts? I just need a handful to saturate the 
> interesting cases.
> 
> Thanks!
> 
> --CJD

Best to try it with Fedora 8.

https://bugzilla.redhat.com/showdependencytree.cgi?id=246824
"view as bug list"

$ grep -l 'BEGIN INIT' /etc/init.d/*

Some dependencies may be missing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3623 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/4d1ce27a/attachment.bin>

From spng.yang at gmail.com  Wed Oct 31 06:56:59 2007
From: spng.yang at gmail.com (Ken YANG)
Date: Wed, 31 Oct 2007 14:56:59 +0800
Subject: What difference between compiz-manager and compiz-tray-icon
Message-ID: <4728273B.4080201@gmail.com>


hi all,

i notice there are new packages named compiz-manager,
which is a script wrapper.

i wonder what the difference between it and compiz-tray-icon?




From caolanm at redhat.com  Wed Oct 31 08:26:45 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 31 Oct 2007 08:26:45 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
	<8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>
Message-ID: <1193819205.31627.63.camel@Jehannum>


On Tue, 2007-10-30 at 22:48 -0500, King InuYasha wrote:
> I never install Sun Java. These problems crop up in a default Fedora
> install for me.

Where as I have never ever ever seen it. Do you get the same error
message of "if you open this file, the file might present a security
risk to your system"

C.



From caolanm at redhat.com  Wed Oct 31 08:30:41 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 31 Oct 2007 08:30:41 +0000
Subject: OOo .odt files - open with Java by default
In-Reply-To: <645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
Message-ID: <1193819441.31627.68.camel@Jehannum>


On Wed, 2007-10-31 at 00:44 +0000, Jonathan Underwood wrote:
> On 30/10/2007, King InuYasha <ngompa13 at gmail.com> wrote:
> > I have had this problem since Fedora Core 4. Ever since GCJ and OOo 2.0 were
> > included in Fedora, this specific issue has cropped on my computers all the
> > time. The strange thing is that only OpenDocument files are considered Java
> > Archives. None of the other archive-based formats supported by OOo have this
> > issue as far as I can tell.
> 
> Actually, I think it's a nasty side effect of installing the Sun java
> stack and java-1.6.0-sun-compat-1.6.0.01-1jpp from jpackage rather
> than an OOo problem.

Yeah, sounds plausible, e.g.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6510610

C.



From dtimms at iinet.net.au  Wed Oct 31 08:15:25 2007
From: dtimms at iinet.net.au (David Timms)
Date: Wed, 31 Oct 2007 19:15:25 +1100
Subject: Fedorability of dvbcut = not
In-Reply-To: <200710301950.07671.ville.skytta@iki.fi>
References: <47248975.7050901@iinet.net.au>
	<47257C36.9060607@cs.tu-berlin.de>	<4726CE64.8040506@iinet.net.au>
	<200710301950.07671.ville.skytta@iki.fi>
Message-ID: <4728399D.2010407@iinet.net.au>

Ville Skytt? wrote:
> On Tuesday 30 October 2007, David Timms wrote:
> 
>> tzap -c "a channel" would seem to be actually demuxing the mpeg stream
>> to the single program id selected within that tuned frequency. That
>> would seem to be needing knowledge of the mpeg data ?
> 
> The last time I heard about this the verdict was that demuxing/muxing is not a 
> problem, see eg. https://bugzilla.redhat.com/191036 comments 12-14.  I 
> believe there are quite a few things in Fedora that do that.
OK, that provides a clearer position, thanks.

DaveT.



From harald at redhat.com  Wed Oct 31 08:15:08 2007
From: harald at redhat.com (Harald Hoyer)
Date: Wed, 31 Oct 2007 09:15:08 +0100
Subject: KDE logout options with F8
In-Reply-To: <4727EBED.4020909@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
Message-ID: <fg9dic$8a9$1@ger.gmane.org>

For me the main argument is:

Why should diskspace and time be spent on bootup to load gnome/gtk/glib libraries/font caches/icon caches, 
etc., if later on gnome/gtk is not used b/c gnome is not installed anyway (besides gdm and its deps)?



From mike.cohler at gmail.com  Wed Oct 31 08:19:38 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Wed, 31 Oct 2007 08:19:38 +0000
Subject: NFS problem after update to
	rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710310119h9348ed0k2f353825d312a189@mail.gmail.com>

"Jon Ciesla" wrote:

>Willing to try re-mounting with different options to see if any help?

I guess it is possible that using the same /etc/exports options as I
did (i.e. make the root_squash the same and also remove the
"insecure") may be able to reproduce what I had?

I don't know if the exports file of the bug reporter at
https://bugzilla.redhat.com/show_bug.cgi?id=358621
used a similar set-up to me as no detail was mentioned that report.
Clearly he was also seeing similar issues.

I wonder if this may also affect rawhide and/or F8 being made ready
for release? If anyone is running rawhide it would be worth checking?

-- 

mike cohler



From david at lovesunix.net  Wed Oct 31 08:30:00 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 31 Oct 2007 09:30:00 +0100
Subject: RadeonHD driver status
In-Reply-To: <20071030120356.14db5430@redhat.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<20071030120356.14db5430@redhat.com>
Message-ID: <1193819400.2750.3.camel@dawkins>


tir, 30 10 2007 kl. 12:03 -0400, skrev Jesse Keating:
> On Tue, 30 Oct 2007 16:55:40 +0100
> Hans Ulrich Niedermann <hun at n-dimensional.de> wrote:
> 
> >     http://koji.fedoraproject.org/koji/packageinfo?packageID=5156
> >     http://koji.fedoraproject.org/koji/taskinfo?taskID=217665
> >     BuildError: package xorg-x11-drv-radeonhd is blocked for tag
> > dist-f9
> 
> Fixed this.  You can now build for F9.

I'm getting the same for ndesk-dbus, 3 emails to releng have gone
unanswered so far. Seriously I'll take get lost you filthy hippie over
no reply, pretty please.

Could you dust a bit of magic on my build capabilities?

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/42378302/attachment.sig>

From seg at haxxed.com  Wed Oct 31 09:04:40 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 31 Oct 2007 04:04:40 -0500
Subject: Mesa license issue?
Message-ID: <1193821480.5825.29.camel@localhost>

Okay, so there's a Second Life bug open pointing out what appears to be
a license problem with some OpenGL headers:

http://jira.secondlife.com/browse/VWR-2881

There is indeed a bunch of headers with "SGI Free Software License B"
boilerplate in them:

$ grep -l "SGI Free" /usr/include/GL/*
/usr/include/GL/glext.h
/usr/include/GL/glu.h
/usr/include/GL/glxext.h
/usr/include/GL/glxmd.h
/usr/include/GL/glxproto.h
/usr/include/GL/glxtokens.h

$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qf|sort|uniq
mesa-libGL-devel-6.5.2-13.fc7.i386
mesa-libGL-devel-6.5.2-13.fc7.x86_64
mesa-libGLU-devel-6.5.2-13.fc7.i386
mesa-libGLU-devel-6.5.2-13.fc7.x86_64
xorg-x11-proto-devel-7.2-9.fc7.x86_64

The devel packages say they're all MIT license:

$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qfi|grep License|
sort|uniq
Size        : 1393741                          License: MIT
Size        : 82501                            License: MIT
Size        : 872295                           License: MIT

"SGI Free Software License B" is explicitly not acceptable in Fedora:

http://fedoraproject.org/wiki/Licensing#head-d8cc605dd386091c8b6be97b8a43fb6a5d624ae1

I've googled up and down and I haven't found an explanation as to what
is going on. Mesa's merge review is untouched:

http://bugzilla.redhat.com/show_bug.cgi?id=226136

Is there a reason these files don't fall under the SGI license? There's
a provision for "an alternative license" but I'm not even going to
pretend to understand the mechanics. If so, could the headers be
clarified, and an explanation made in Mesa's review? And a reply made
here? And Mesa's home page fixed? ;P

http://www.mesa3d.org/license.html

GLEW apparently had the same problem, fixed by taking headers from Mesa,
so I'm very confused as to what is going on:

http://bugzilla.redhat.com/show_bug.cgi?id=251191


-------------- 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/20071031/93f9771b/attachment.sig>

From lemenkov at gmail.com  Wed Oct 31 09:16:24 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 31 Oct 2007 12:16:24 +0300
Subject: Mesa license issue?
In-Reply-To: <1193821480.5825.29.camel@localhost>
References: <1193821480.5825.29.camel@localhost>
Message-ID: <adf480660710310216y53c40ed0k929ee4553ffa4226@mail.gmail.com>

2007/10/31, Callum Lerwick <seg at haxxed.com>:
> Okay, so there's a Second Life bug open pointing out what appears to be
> a license problem with some OpenGL headers:
>
> http://jira.secondlife.com/browse/VWR-2881

> $ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qfi|grep License|
> sort|uniq
> Size        : 1393741                          License: MIT
> Size        : 82501                            License: MIT
> Size        : 872295                           License: MIT
>
> "SGI Free Software License B" is explicitly not acceptable in Fedora:

Yeah! It's time to drop Mesa support from Fedora as it was already did
with openmotif!

-- 
With best regards!



From jfrieben at gmx.de  Wed Oct 31 09:19:02 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Wed, 31 Oct 2007 10:19:02 +0100
Subject: KDE logout options with F8
In-Reply-To: <20071031003225.GB3972@nostromo.devel.redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
Message-ID: <20071031091902.101120@gmx.net>

> gdm is the default login manager in the base X group. It can't
> be removed from there.
> 
> Bill

Rahul's position on this seems to be more coherent. When you want a plain X environment without GNOME nor KDE [and haven't selected any of both at install and -only- then], you simply don't want to get bothered by any of overloaded GDM and KDM with face browser stuff and the like and pulling in tons of additional packages you don't want to have installed either.
XDM is a perfectly valuable and lightweight login manager. Why wouldn't it be a valid choice when it's even shipped by upstream Xorg?
The suggestion to make XDM the default login manager of the X base group and GDM/KDM the default login manager of their respective desktop environments appears to be the most compelling choice.
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser



From j.w.r.degoede at hhs.nl  Wed Oct 31 09:02:14 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 31 Oct 2007 10:02:14 +0100
Subject: Mesa license issue?
In-Reply-To: <1193821480.5825.29.camel@localhost>
References: <1193821480.5825.29.camel@localhost>
Message-ID: <47284496.6040204@hhs.nl>

Callum Lerwick wrote:
> Okay, so there's a Second Life bug open pointing out what appears to be
> a license problem with some OpenGL headers:
> 
> http://jira.secondlife.com/browse/VWR-2881
> 
> There is indeed a bunch of headers with "SGI Free Software License B"
> boilerplate in them:
> 
> $ grep -l "SGI Free" /usr/include/GL/*
> /usr/include/GL/glext.h
> /usr/include/GL/glu.h
> /usr/include/GL/glxext.h
> /usr/include/GL/glxmd.h
> /usr/include/GL/glxproto.h
> /usr/include/GL/glxtokens.h
>

<snip>

> I've googled up and down and I haven't found an explanation as to what
> is going on. Mesa's merge review is untouched:
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=226136
> 
> Is there a reason these files don't fall under the SGI license? There's
> a provision for "an alternative license" but I'm not even going to
> pretend to understand the mechanics. If so, could the headers be
> clarified, and an explanation made in Mesa's review? And a reply made
> here? And Mesa's home page fixed? ;P
> 
> http://www.mesa3d.org/license.html
> 

This is all very much AFAIK:

These files are indeed a problem, there have been talks with SGI about freeing 
them but those have stagnated, since Mesa is a crucial piece of infrastructure, 
the current situation is being allowed as an exception to the licensing guidelines.

> GLEW apparently had the same problem, fixed by taking headers from Mesa,
> so I'm very confused as to what is going on:
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=251191
> 

GLEW contained bits of "code" in some header files copy and pasted from the 
OpenGL reference implementation. I've replaced these with "code" from 
/usr/include/GL/gl.h and /usr/include/GL/glx.h, which are not under the
"SGI Free Software License B" / "GLX Public License" but fall for 100% under 
Mesa's MIT license and thus are ok.

I did this because glew would not be allowed as is, the "SGI Free Software 
License B" / "GLX Public License" exception is only for Mesa and we do not want 
to add any other software under this license to the repo.

On the contrary, we really should start working on removing/replacing the 
troublesome Mesa bits.

Regards,

Hans



From dtimms at iinet.net.au  Wed Oct 31 09:24:04 2007
From: dtimms at iinet.net.au (David Timms)
Date: Wed, 31 Oct 2007 20:24:04 +1100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193819205.31627.63.camel@Jehannum>
References: <1193772994.6165.22.camel@sb-home>	<1193787436.31627.60.camel@Jehannum>	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>	<8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>
	<1193819205.31627.63.camel@Jehannum>
Message-ID: <472849B4.3060303@iinet.net.au>

Caolan McNamara wrote:
> On Tue, 2007-10-30 at 22:48 -0500, King InuYasha wrote:
>> I never install Sun Java. These problems crop up in a default Fedora
>> install for me.
> 
> Where as I have never ever ever seen it. Do you get the same error
> message of "if you open this file, the file might present a security
> risk to your system"

Since I've had this happening for some time , I think I worked out how 
to cause it:
F7 updated.
nautilus --browser  {actually I change the defaults to view list and 
open in browser windows}.

The list shows:
ootexticon   whatever.odt   type=ODT document
If you left click the .odt etc, open office writer is spawned, and "it 
is good".

However, if you actually put the cursor on the file by eg down-down-down 
in the file list, or by right clicking on the file, the type changes so 
that it now says:
javaicon     whatever.odt   type=Java Archive

Once this is the case, a left click now generates the warning dialog:
"The filename "the_tint_shop (copy).12149.odt" indicates that this file 
is of type "ODT document". The contents of the file indicate that the 
file is of type "Java Archive". If you open this file, the file might 
present a security risk to your system.

Do not open the file unless you created the file yourself, or received 
the file from a trusted source. To open the file, rename the file to the 
correct extension for "Java Archive", then open the file normally. 
Alternatively, use the Open With menu to choose a specific application 
for the file. "

Same with a zip file:
archiveicon   whatever.zip   ZIP archive

after cursor on the file:
javaicon     whatever.zip   type=Java Archive


I also see similar for asf file that changes to wmf {or reverse, I forget}.

My explanation {no evidence} is that when you click the file - the file 
command is run to determine the content type regardless of extension. So 
it would be this that is badly interpreting it ? That doesn't seem to be 
the actual case if I run: file  on the commands it gives the correct 
answers.

DaveT.



From dtimms at iinet.net.au  Wed Oct 31 09:28:09 2007
From: dtimms at iinet.net.au (David Timms)
Date: Wed, 31 Oct 2007 20:28:09 +1100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <472849B4.3060303@iinet.net.au>
References: <1193772994.6165.22.camel@sb-home>	<1193787436.31627.60.camel@Jehannum>	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>	<8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>	<1193819205.31627.63.camel@Jehannum>
	<472849B4.3060303@iinet.net.au>
Message-ID: <47284AA9.3060001@iinet.net.au>

David Timms wrote:
> Caolan McNamara wrote:
>> On Tue, 2007-10-30 at 22:48 -0500, King InuYasha wrote:
>>> I never install Sun Java. These problems crop up in a default Fedora
>>> install for me.
And I do have:
java-1.5.0-gcj-1.5.0.0-14.fc7
jdk-1.6.0_01-fcs

DaveT.



From singularitaet at gmx.net  Wed Oct 31 09:36:30 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Wed, 31 Oct 2007 10:36:30 +0100
Subject: KDE logout options with F8
In-Reply-To: <4727E511.9000504@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
Message-ID: <200710311036.36288.singularitaet@gmx.net>

Hi,
On Wednesday 31 October 2007 03:14:41 am Rahul Sundaram wrote:
RS> Besides my point was that if users select GNOME they should get GDM and
RS> if users select KDE, they should get KDM. Is anyone willing to respond
RS> to that?

From my (user) point of view there should be an easy end user option of choice 
which of either gdm or kdm one wants to use (and not manipulating or creating 
a file somewhere) maybe during installation or better even always having the 
choice. 

Beside this I think that even more preferable would be that gdm would also 
work perfectly together with KDE which seems according to Sebastian Vahl not 
really be the case:

SV>To get the buttons to show up you have to use kdm as your loginmanager.

(what if I prefer gdm because its more beautiful?)

Stefan


-------------- 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/20071031/a0f65523/attachment.sig>

From seg at haxxed.com  Wed Oct 31 09:38:20 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 31 Oct 2007 04:38:20 -0500
Subject: Mesa license issue?
In-Reply-To: <1193821480.5825.29.camel@localhost>
References: <1193821480.5825.29.camel@localhost>
Message-ID: <1193823500.5825.33.camel@localhost>

Update: I found this commit in Mesa's git:

http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=344c3f7379ab4db749e7e8513be9be8fbb9f126c

It appears this is fixed in Mesa 7, which is in F8, but I don't know
where this leaves F7 and whatnot, which are still shipping Mesa 6.5.x.
-------------- 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/20071031/182ebf2e/attachment.sig>

From andrewparker at bigfoot.com  Wed Oct 31 09:54:53 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Wed, 31 Oct 2007 05:54:53 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071031T041407-306@post.gmane.org>
References: <200710302212.50847.ml@deadbabylon.de>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<loom.20071031T041407-306@post.gmane.org>
Message-ID: <6c3f5e6c0710310254q25fa7b70ga4b18abf5bb397f@mail.gmail.com>

On 10/31/07, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> > Here is how it should work:
> >
> >   * Default X group installs XDM
> >   * If you select GNOME, you get GDM
> >   * If you select KDE, you get KDM
>
> I agree with that. The base X group also has TWM, how is XDM not of the same
> kind (usable, but very basic and old)? Base X should really be the minimal X
> and not include random parts of an arbitrary desktop environment, exactly
> because there are two (actually more than two).

I like it too, but what if I install KDE later*, or what if I install
KDE at the beginning, then uninstall it too.  Does it get downgraded
to GDM or XDM even if GNOME has been uninstalled.

* - I already do.  Install 300+ rpms post-install because it is so
much easier to do it that way than at install time.



From dtimms at iinet.net.au  Wed Oct 31 10:06:37 2007
From: dtimms at iinet.net.au (David Timms)
Date: Wed, 31 Oct 2007 21:06:37 +1100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <47284AA9.3060001@iinet.net.au>
References: <1193772994.6165.22.camel@sb-home>	<1193787436.31627.60.camel@Jehannum>	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>	<8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>	<1193819205.31627.63.camel@Jehannum>	<472849B4.3060303@iinet.net.au>
	<47284AA9.3060001@iinet.net.au>
Message-ID: <472853AD.9050904@iinet.net.au>

David Timms wrote:
> David Timms wrote:
>> Caolan McNamara wrote:
>>> On Tue, 2007-10-30 at 22:48 -0500, King InuYasha wrote:
>>>> I never install Sun Java. These problems crop up in a default Fedora
>>>> install for me.
> And I do have the the problem with:
> java-1.5.0-gcj-1.5.0.0-14.fc7
> jdk-1.6.0_01-fcs

And after installing jdk 6u3, seems the issue no longer occurs {for java 
at least}. {alternatives are pointing to sun jdk}.

DaveT.



From giallu at gmail.com  Wed Oct 31 10:07:43 2007
From: giallu at gmail.com (Gianluca Sforna)
Date: Wed, 31 Oct 2007 11:07:43 +0100
Subject: Rebuild sysprof-kmod for final kernel
Message-ID: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>

I tried to rebuild sysprof-kmod for the f8 release, but it failed with:

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/sysprof-kmod-1.0.8-1.2.6.23.1_41.fc8-root-kojibuilder
error: Installed (but unpackaged) file(s) found:
   /lib/modules/2.6.23.1-41.fc8/modules.alias
   /lib/modules/2.6.23.1-41.fc8/modules.ccwmap
   /lib/modules/2.6.23.1-41.fc8/modules.dep
   /lib/modules/2.6.23.1-41.fc8/modules.ieee1394map
   /lib/modules/2.6.23.1-41.fc8/modules.inputmap
   /lib/modules/2.6.23.1-41.fc8/modules.isapnpmap
   /lib/modules/2.6.23.1-41.fc8/modules.ofmap
   /lib/modules/2.6.23.1-41.fc8/modules.pcimap
   /lib/modules/2.6.23.1-41.fc8/modules.seriomap
   /lib/modules/2.6.23.1-41.fc8/modules.symbols
   /lib/modules/2.6.23.1-41.fc8/modules.usbmap

These was not created before, so I'm not sure if they have to be
packaged, removed, ghosted or...

The build log is here:
http://koji.fedoraproject.org/koji/getfile?taskID=220489&name=build.log
and yes, I know -41 was not _the_ one...

any help appreciated.



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 31 10:26:28 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 31 Oct 2007 11:26:28 +0100
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
In-Reply-To: <3dd77c60710301232v2ffb733fgaacdd97d908df116@mail.gmail.com>
References: <3dd77c60710301232v2ffb733fgaacdd97d908df116@mail.gmail.com>
Message-ID: <20071031112628.7fa4477a.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 30 Oct 2007 19:32:32 +0000, Mike Cohler wrote:

> "Mike Cohler" wrote:
> 
> >I have just seen
> >https://bugzilla.redhat.com/show_bug.cgi?id=358621
> 
> >I tried the suggestion in this bug - i.e. add
> >ALL: localhost
> 
> >to /etc/hosts.allow
> 
> >Then restart the services - nfs now starts properly and everything
> >seems fine - but what are the security implications of this change I
> >wonder?

Just out of interest, what does your /etc/hosts.deny contain?
And what is in your /etc/hosts?

The rpcbind package changelog mentions tcp_wrappers related changes
in rpcbind-0.1.4-8.fc8, but your problem is not reproducible here.

$ rpm -q rpcbind nfs-utils
rpcbind-0.1.4-11.fc8
nfs-utils-1.1.0-6.fc8



From caillon at redhat.com  Wed Oct 31 11:30:02 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 12:30:02 +0100
Subject: KDE logout options with F8
In-Reply-To: <4727DD39.5070900@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>
	<4727DD39.5070900@fedoraproject.org>
Message-ID: <4728673A.9050502@redhat.com>

Rahul Sundaram wrote:
> GNOME display manager is not logically associated with GNOME Desktop 
> Environment? If that's the case, it makes it even more illogical that 
> GNOME display manager is default for KDE Desktop Environment. Either we 
> have a neutral display manager that works well for them both (it doesn't 
> in this case since there is a regression in functionality inflicted by 
> our defaults) or we install whatever display manager goes well with the 
> desktop environment.


GDM is getting a massive face lift to be more generic.  The original 
intent was to get KDE on board as well such that all you'd do is swap 
toolkits and use the same backend.  We've been trying to convince KDM 
upstream to participate but I've heard there's been pushback because of 
something dumb like we need to be bug for bug compatible with the 
existing KDM, which is just not going to happen.



From buildsys at redhat.com  Wed Oct 31 11:34:00 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 31 Oct 2007 07:34:00 -0400
Subject: rawhide report: 20071031 changes
Message-ID: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>

New package mknbi
	Utility for creating network bootable images


 
Updated Packages:

NetworkManager-openvpn-1:0.7.0-2.svn3047.fc8
--------------------------------------------
* Wed Oct 31 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-2.svn3047.fc8
- BuildRequire gettext

* Tue Oct 30 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-1.svn3047.fc8
- Upgrade to trunk, needed to be compatible with NM 0.7.0, rebuild for F-8

OpenEXR-1.6.0-5.fc8
-------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-5
- multiarch conflicts in OpenEXR (#342781)
- don't own %_includedir/OpenEXR (leave that to ilmbase)

QuantLib-0.8.1-4.fc8
--------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.8.1-4
- fix more conflicting manpages (bz 322201)
- fix multilib conflict (bz 343041)

R-2.6.0-3.fc8.1
---------------
* Tue Oct 30 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3.1
- fix missing perl requires

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3
- fix multilib conflicts (bz 343061)

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-2
- add R CMD javareconf to post (bz 354541)
- don't pickup bogus perl provides (bz 356071)
- use xdg-open, drop requires for firefox/evince (bz 351841)

SDL_mixer-1.2.8-4.fc8
---------------------
* Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
- SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
  avoids applications from locking up

anaconda-11.3.0.50-1
--------------------
* Wed Oct 31 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.50-1
- Fix creating users in kickstart (#358901)

* Tue Oct 30 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.49-1
- Fix language display (#358411)
- Avoid dmraid traceback with live installs over previously existing 
  install (#357401)

apollon-1.0.1-12.fc8
--------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.1-12
- -libs subpkg, multiarch conflicts in apollon (#340661)

compiz-0.6.2-3.fc8
------------------
* Thu Oct 25 2007 Sebastian Vahl <fedora at deadbabylon.de> - 0.6.2-3
- Include kde-desktop-effects in kde subpackage
coreutils-6.9-9.fc8
-------------------
* Tue Oct 30 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-9
- applied upstream patch for runuser to coreutils-selinux.patch(#232652)
- modified coreutils-i18n.patch because of sort -R in
  a non C locales(fix by Andreas Schwab) (#249315)
- allow cp -a to rewrite file on different filesystem(#219900)
  (based on upstream patch)
- License tag to GPLv2+

* Thu Oct 25 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-8
- applied upstream patch for cp and mv(#248591)

* Thu Aug 23 2007 Pete Graner <pgraner at redhat.com> - 6.9-7
- Fix typo in spec file. (CVS merge conflict leftovers)

dmraid-1.0.0.rc14-4.fc8
-----------------------
* Tue Oct 30 2007 Alasdair Kergon <agk at redhat.com> - 1.0.0.rc14-4
- Fix SEGV on "dmraid -r -E" (bz 236891).

* Wed Apr 18 2007 Peter Jones <pjones at redhat.com> - 1.0.0.rc14-3
- Fix jmicron name parsing (#219058)

eclipse-1:3.3.0-30.fc8
----------------------
* Tue Oct 30 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-30
- Actually apply permgen patch.  Ugh.

* Tue Oct 30 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-29
- Move popd at end of %install to allow aot-compile-rpm to allow it to
  use the current directory for its temp directory.

* Mon Oct 29 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-28
- Add patch for memory issues with IcedTea.

em8300-kmod-0.16.3-6.2.6.23.1_42.fc8
------------------------------------
* Wed Oct 31 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.16.3-6
- Don't run depmod during build even if System.map is available.
- Run "make install" in verbose mode.
- Build for kernel 2.6.23.1-42.fc8.

* Thu Oct 18 2007 Ville Skytt?? <ville.skytta at iki.fi>
- Rebuild for kernel 2.6.23.1-23.fc8.

fedora-release-notes-8.0.0-3
----------------------------
* Tue Oct 30 2007 Paul W. Frields <stickster at gmail.com> - 8.0.0-3
- Fix release number in description

firefox-2.0.0.8-2.fc8
---------------------
* Tue Oct 30 2007 Christopher Aillon <caillon at redhat.com> 2.0.0.8-2
- Tweak the default backspace behavior to be more in line with
  GNOME convention, Mozilla upstream, and other distros

gparted-0.3.3-13.fc8
--------------------
* Tue Oct 30 2007 Deji Akingunola <dakingun at gmail.com> - 0.3.3-13
- Fix crash after refresh bug (Bug #309251, patch by Jim Hayward)
- Fix to use realpath properly (Bug #313281, patch by Jim Hayward)

gtk-nodoka-engine-0.6-5.fc8
---------------------------
* Mon Oct 29 2007 Martin Sourada <martin.sourada at seznam.cz> - 0.6-5
- fix gimp crashing in some dialogs when using Small theme
 - rhbz #291121 and rhbz #355931

hal-info-20071030-1.fc8
-----------------------
* Tue Oct 30 2007 David Zeuthen <davidz at redhat.com> - 20071030-1.fc8
- Update to latest upstream release

kaffeine-0.8.5-5.fc8
--------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.8.5-5
- multiarch conflicts in kaffeine (#341681)

* Wed Sep 19 2007 Ville Skytt?? <ville.skytta at iki.fi> 0.8.5-4
- Avoid autotools re-run after configure (unclean upstream tarball?)

kdebase-6:3.5.8-5.fc8
---------------------
* Tue Oct 30 2007 Bill Nottingham <notting at redhat.com> - 6:3.5.8-5
- use correct path for gdm socket, so you get proper options on logout
  (http://bugs.kde.org/show_bug.cgi?id=149045)

* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -libs conditional (f8+)

* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3
- respin (for openexr-1.6.0)
- -libs: %post/%postun /sbin/ldconfig

kdegraphics-7:3.5.8-5.fc8
-------------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-5
- -libs; Requires: %name (multilib upgrades again)
- scriptlets fixes

kdemultimedia-6:3.5.8-8.fc8
---------------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-8
- -libs: Requires: %name (multilib upgrades again)
- scriptlet fixes

kdenetwork-7:3.5.8-4.fc8
------------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-4
- libs: Requires: %{name}... (multilib upgrades)
- fixup scriptlets

kdevelop-9:3.5.0-4.fc8
----------------------
* Wed Oct 31 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-4
- %post/%postun libs -p /sbin/ldconfig

* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-3
- -devel, -libs subpkgs, multiarch conflicts (#341791)

kernel-2.6.23.1-42.fc8
----------------------
* Tue Oct 30 2007 Dave Jones <davej at redhat.com>
- Disable PCI MMCONFIG by default. (Boot with pci=msi if you need it)
  Works around bz 329241 amongst others.

libglade-1:0.17-20.fc8
----------------------
* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:0.17-20
- clarify license as LGPL version 2 or later
- remove bundled libintl (GPL) in %prep to be absolutely sure that it isn't
  used
- patch libglade-config to generate cflags/libs values at runtime instead of
  build-time and hence be multiarch compatible (#342131); we can get away with
  this because the entire (legacy) library stack is stable and isn't going to
  change in any significant way
- enumerate more of the %files list to narrow scope of wildcards
- re-encode ChangeLog as UTF-8
- preserve timestamps for files copied from source to installed package

* Mon Oct 02 2006 Paul Howarth <paul at city-fan.org> 1:0.17-19
- add new buildreq libtool and use the system libtool instead of the bundled
  one to avoid /usr/lib64 rpaths
- add patch to fix non-weak-symbols issues in libglade-gnome.so
- include epoch in versioned gnome-libs-devel dependencies

* Sat Aug 26 2006 Paul Howarth <paul at city-fan.org> 1:0.17-18
- include epoch in versioned libxml-devel dependencies

libuser-0.56.6-2
----------------
* Wed Oct 31 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.6-2
- Fix uninitialized memory usage when SELinux is disabled

mcstrans-0.2.7-1.fc8
--------------------
* Tue Oct 30 2007 Steve Conklin <sconklin at redhat.com> 0.2.7-1
- Fixed a compile error and added compliant init script

* Thu Sep 13 2007 Dan Walsh <dwalsh at redhat.com> 0.2.6-1
- Check for max_categories and error out

mkinitrd-6.0.19-4.fc8
---------------------
* Tue Oct 30 2007 Peter Jones <pjones at redhat.com> - 6.0.19-4
- Work around dmraid dependency detection after livecd install.
- Fix "ide-disk.ko" detection.

nautilus-2.20.0-6.fc8
---------------------
* Tue Oct 30 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-6
- Fix audio preview command-line to use decodebin so playbin doesn't
  pop up a window for videos detected as audio

* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-5
- Add patch from upstream to get audio preview working again
  (#332251)

* Wed Oct 03 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Move /usr/lib/nautilus/extensions-1.0 to the extensions package

pulseaudio-0.9.7-0.17.svn20071017.fc8
-------------------------------------
* Tue Oct 30 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.7-0.17.svn20071017
- fix #322481

python-2.5.1-15.fc8
-------------------
* Tue Oct 30 2007 James Antill <jantill at redhat.com> - 2.5.1-15
- Do codec lowercase in C Locale.
- Resolves: 207134 191096
- Fix stupid namespacing in pysqlite, minimal upgrade to 2.3.3 pysqlite
- Resolves: 263221

* Wed Oct 24 2007 James Antill <jantill at redhat.com> - 2.5.1-14
- Remove bintuils dep. for live CD ... add work around for ctypes

* Mon Oct 22 2007 James Antill <jantill at redhat.com> - 2.5.1-13
- Add tix buildprereq
- Add tkinter patch
- Resolves: #281751
- Fix ctypes loading of libraries, add requires on binutils
- Resolves: #307221
- Possible fix for CVE-2007-4965 possible exploitable integer overflow
- Resolves: #295971

rhgb-8.0.2-1.fc8
----------------
* Mon Oct 29 2007 Ray Strode <rstrode at redhat.com> 8.0.2-1
- update to 8.0.2
- Adds some debugging infrastructure
- Fixes a potential race condition

selinux-policy-3.0.8-42.fc8
---------------------------
* Tue Oct 30 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-42
- Make tcbdomain 
- Allow domain domain:fd use
- Dontaudit rpm_rw_pipes

* Mon Oct 29 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-41
- Fix labeling on /var/run/bluetoothd_address 
- Allow tmpreaper to search logs directory

synce-gnomevfs-0.9.0-6.fc8
--------------------------
* Tue Oct 30 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.0-6
- fix BR

system-config-date-1.9.16-1.fc8
-------------------------------
* Tue Oct 30 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.16-1
- use warning dialog, exit gracefully if hwclock fails to allow operation in a
  XEN guest (#357311)

xapian-core-1.0.2-6.fc8
-----------------------
* Thu Oct 25 2007 Adel Gadllah <adel.gadllah at gmail.com> 1.0.2-6
- Fix multilib conflict in devel package (RH #343471)

Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From lkundrak at redhat.com  Wed Oct 31 11:43:01 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 31 Oct 2007 12:43:01 +0100
Subject: Rebuild sysprof-kmod for final kernel
In-Reply-To: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>
References: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>
Message-ID: <1193830981.9762.4.camel@localhost.localdomain>

Hi,

On Wed, 2007-10-31 at 11:07 +0100, Gianluca Sforna wrote:
> I tried to rebuild sysprof-kmod for the f8 release, but it failed with:
> 
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /var/tmp/sysprof-kmod-1.0.8-1.2.6.23.1_41.fc8-root-kojibuilder
> error: Installed (but unpackaged) file(s) found:
>    /lib/modules/2.6.23.1-41.fc8/modules.alias
>    /lib/modules/2.6.23.1-41.fc8/modules.ccwmap
>    /lib/modules/2.6.23.1-41.fc8/modules.dep
>    /lib/modules/2.6.23.1-41.fc8/modules.ieee1394map
>    /lib/modules/2.6.23.1-41.fc8/modules.inputmap
>    /lib/modules/2.6.23.1-41.fc8/modules.isapnpmap
>    /lib/modules/2.6.23.1-41.fc8/modules.ofmap
>    /lib/modules/2.6.23.1-41.fc8/modules.pcimap
>    /lib/modules/2.6.23.1-41.fc8/modules.seriomap
>    /lib/modules/2.6.23.1-41.fc8/modules.symbols
>    /lib/modules/2.6.23.1-41.fc8/modules.usbmap
> 
> These was not created before, so I'm not sure if they have to be
> packaged, removed, ghosted or...

I'd remove them, possibly with %exclude. It is the responsibility of
scriptlets added by kmodtool to calculate the module dependencies, these
files are unusable anyways.

> 
> The build log is here:
> http://koji.fedoraproject.org/koji/getfile?taskID=220489&name=build.log
> and yes, I know -41 was not _the_ one...
> 
> any help appreciated.
> 
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From dcbw at redhat.com  Wed Oct 31 11:44:26 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 31 Oct 2007 07:44:26 -0400
Subject: RadeonHD driver status
In-Reply-To: <1193786869.4670.15.camel@aragorn>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193774337.3064.1.camel@aragorn>  <1193782695.3872.1.camel@optimus>
	<1193783850.4670.6.camel@aragorn>  <1193785938.3872.5.camel@optimus>
	<1193786869.4670.15.camel@aragorn>
Message-ID: <1193831066.23775.17.camel@localhost.localdomain>

On Tue, 2007-10-30 at 17:27 -0600, Trever L. Adams wrote:
> On Wed, 2007-10-31 at 09:12 +1000, Dave Airlie wrote:
> > This is the Internet, it looks like a me too and it smells like a me too
> > I consider it a me too, providing info on the type/range of cards tested
> > etc is useful.. saying avivo broken radeonhd not is not useful as we
> > also have ppl saying the opposite...
> > 
> > Red Hat and Fedora are contemplating the future wrt to AMD r5xx cards,
> > all options are going to be looked at, there may even be options that
> > you don't know about yet..
> > 
> > Dave.
> > 
> 01:00.1 Display controller: ATI Technologies Inc Radeon X1950 Pro
> (Secondary) (PCIE)

Avivo works fine on the X2300 in my HP laptop... but that doesn't mean
anything.  They both still suck.

Dan

> Are the two machines I can talk about. One works better than the other
> with Avivo, neither works well with it.
> 
> Both use AL2002W monitors from Acer. Both work very well at 1680x150 w/
> this monitor. I may have one more machine I can comment on, but it will
> be a few days.
> 
> I hope a great solution is found.
> 
> Trever
> --
> "There are two ways to live your life. One is as though nothing is a
> miracle. The other is as though everything is a miracle." -- Albert
> Einstein
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From sundaram at fedoraproject.org  Wed Oct 31 11:49:34 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 17:19:34 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728673A.9050502@redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>
	<4728673A.9050502@redhat.com>
Message-ID: <47286BCE.2070208@fedoraproject.org>

Christopher Aillon wrote:
> Rahul Sundaram wrote:
>> GNOME display manager is not logically associated with GNOME Desktop 
>> Environment? If that's the case, it makes it even more illogical that 
>> GNOME display manager is default for KDE Desktop Environment. Either 
>> we have a neutral display manager that works well for them both (it 
>> doesn't in this case since there is a regression in functionality 
>> inflicted by our defaults) or we install whatever display manager goes 
>> well with the desktop environment.
> 
> 
> GDM is getting a massive face lift to be more generic.  The original 
> intent was to get KDE on board as well such that all you'd do is swap 
> toolkits and use the same backend.  We've been trying to convince KDM 
> upstream to participate but I've heard there's been pushback because of 
> something dumb like we need to be bug for bug compatible with the 
> existing KDM, which is just not going to happen.

It would be fantastic if the backend was more neutral like you said 
since there are people who might want to run any display manager with 
any desktop environment. Meanwhile, throwing around accusations instead 
of looking at what KDE maintainers as well as users want in Fedora is 
counter productive. Just a while back I was accused of having an agenda 
against KDE [1]. Now I get accused of having an agenda towards KDE [2]. 
I guess, the next one to follow would be XFCE [3]. Others would accuse 
Red Hat of crippling KDE and the routine will continue.  Next time, 
don't wonder why.

Rahul

[1]https://www.redhat.com/archives/fedora-games-list/2007-September/msg00047.html

[2]https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02680.html

[3]http://fedoraproject.org/wiki/RahulSundaram/XfceLive



From caillon at redhat.com  Wed Oct 31 11:53:50 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 12:53:50 +0100
Subject: KDE logout options with F8
In-Reply-To: <loom.20071031T041957-355@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
Message-ID: <47286CCE.9020401@redhat.com>

Kevin Kofler wrote:
> Matthias Clasen <mclasen <at> redhat.com> writes:
>> Sure, here you go: a display manager is a security sensitive piece of
>> code. Shipping multiple just because their names start with a letter you
>> don't like is not a smart move, because you end up doing twice the
>> security errata. 
> 
> Please don't make up excuses to fight the desires of the KDE SIG. The fact is:
> * The KDE spin already defaults to KDM. This is not a mistake, but an 
> intentional decision.
> * As far as I know, the KDE SIG members who expressed an opinion on this issue 
> all want KDM as the default for KDE on the DVD too.
> * I'm definitely one of these.
> * Rex Dieter, who started that whole KDE SIG, wants that, too. See the October 
> 9 meeting log: http://repo.calcforge.org/temp/fedora-kde-sig-2007-10-09.txt
> 
> Now how to implement this technically is another issue (I don't see what's the 
> big problem with having XDM in Base X and GDM/KDM in the respective desktop 
> environment groups, but there's surely other solutions too!), but saying KDM is 
> not desirable at all is something we don't agree to.

We should get to the point where we have one login manager, and just 
swap out the toolkits/UI.  Logging in is something that we seriously 
should not have multiple packages for.

See the work that William Jon Mcann is doing upstream right now to help 
get to the goal of a more generic login manager.  However, because we 
aren't aiming to be bug for bug compatible with KDM (we're not even 
aiming to be bug for bug compat with GDM), the KDM upstream guys are not 
interested in participating.  Maybe instead of fighting within Fedora, 
we can redirect the discussion to convince the KDM guys that this is a 
good idea.




From green at redhat.com  Wed Oct 31 12:13:08 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 31 Oct 2007 05:13:08 -0700
Subject: Mesa license issue?
In-Reply-To: <1193821480.5825.29.camel@localhost>
References: <1193821480.5825.29.camel@localhost>
Message-ID: <47287154.7060101@redhat.com>

Callum Lerwick wrote:
> "SGI Free Software License B" is explicitly not acceptable in Fedora:
> 
> http://fedoraproject.org/wiki/Licensing#head-d8cc605dd386091c8b6be97b8a43fb6a5d624ae1
> 

Parts of jogl are licensed under this license.  I don't believe anything 
depends on jogl. I've just retired this package.

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/46141d6d/attachment.vcf>

From triad at df.lth.se  Wed Oct 31 12:27:06 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 31 Oct 2007 13:27:06 +0100 (CET)
Subject: RadeonHD driver status
In-Reply-To: <1193749904.5664.1.camel@scrappy.miketc.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
Message-ID: <Pine.GSO.4.60.0710311324230.21669@igloo.df.lth.se>

On Tue, 30 Oct 2007, Mike Chambers wrote:

> How has this driver been coming?

I'm running that driver, it improved a lot recently. Incidentally, Avivo 
won't work on my machine, whereas radeonhd does work. It drives the 
graphics, but not much more, no acceleration, no Xvideo, and absolutely no 
DRI. But it atleast enables me to use this machine with this monitor which 
is good, previously I could only use VESA mode which was REAL bad and 
blurry since it does not support 1440x900 properly.

My Euro 0.01

Linus



From triad at df.lth.se  Wed Oct 31 12:28:29 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 31 Oct 2007 13:28:29 +0100 (CET)
Subject: RadeonHD driver status
In-Reply-To: <1193756142.5664.12.camel@scrappy.miketc.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<1193752079.15341.55.camel@localhost.localdomain>
	<1193756142.5664.12.camel@scrappy.miketc.com>
Message-ID: <Pine.GSO.4.60.0710311328050.21669@igloo.df.lth.se>

On Tue, 30 Oct 2007, Mike Chambers wrote:

> BTW, the avivo driver that Jesse mentioned doesn't work for my card.
> Which is why I am interested in the radeonhd driver in case it does.
> Using vesa currently, but having font blurriness problems in middle of
> my screen, and except for getting new monitor (which might get new flat
> lcd one anyway), trying to help figure out what is the problem.

Same problem as me. Radeonhd solved my problem.

Linus



From triad at df.lth.se  Wed Oct 31 12:30:48 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 31 Oct 2007 13:30:48 +0100 (CET)
Subject: RadeonHD driver status
In-Reply-To: <1193770838.2742.2.camel@scrappy.miketc.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<1193770838.2742.2.camel@scrappy.miketc.com>
Message-ID: <Pine.GSO.4.60.0710311330070.21669@igloo.df.lth.se>

On Tue, 30 Oct 2007, Mike Chambers wrote:

> I did d/l it and give it a shot.  It gave me a screen at least, more
> than avivo ever did.  But the rhgb and the gdm login screen were both
> HUGE and had to move the mouse to get them to come back to center, like
> it was a 600x400 or bigger resolution.

Do you have a "Monitor" section in /etc/X11/xorg.conf?

Remove it. Or #comment it out.

Linus



From chris.stone at gmail.com  Wed Oct 31 12:31:03 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 31 Oct 2007 05:31:03 -0700
Subject: KDE logout options with F8
In-Reply-To: <47286BCE.2070208@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<1193794397.11243.1.camel@localhost.localdomain>
	<4727DD39.5070900@fedoraproject.org> <4728673A.9050502@redhat.com>
	<47286BCE.2070208@fedoraproject.org>
Message-ID: <d9c612bf0710310531k4691e8a2w1cde9e3ab31b22df@mail.gmail.com>

On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> It would be fantastic if the backend was more neutral like you said
> since there are people who might want to run any display manager with
> any desktop environment. Meanwhile, throwing around accusations instead
> of looking at what KDE maintainers as well as users want in Fedora is
> counter productive. Just a while back I was accused of having an agenda
> against KDE [1]. Now I get accused of having an agenda towards KDE [2].
> I guess, the next one to follow would be XFCE [3]. Others would accuse
> Red Hat of crippling KDE and the routine will continue.  Next time,
> don't wonder why.
>
> Rahul
>
> [1]https://www.redhat.com/archives/fedora-games-list/2007-September/msg00047.html
>
> [2]https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02680.html
>
> [3]http://fedoraproject.org/wiki/RahulSundaram/XfceLive

While I agree with what you have said in this thread, I certainly got
the impression you were doing everything within your means to avoid
having any kde games in the games spin.  I really don't know why you
brought that up here, if you want to continue the discussion about the
games spin, please add to the thread on the games list or in private
with me.  Thank you.  Sheesh.



From rdieter at math.unl.edu  Wed Oct 31 12:31:42 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 31 Oct 2007 07:31:42 -0500
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
Message-ID: <fg9sjf$p80$1@ger.gmane.org>

Christopher Aillon wrote:

> See the work that William Jon Mcann is doing upstream right now to help
> get to the goal of a more generic login manager.  However, because we
> aren't aiming to be bug for bug compatible with KDM (we're not even
> aiming to be bug for bug compat with GDM), the KDM upstream guys are not
> interested in participating.  Maybe instead of fighting within Fedora,
> we can redirect the discussion to convince the KDM guys that this is a
> good idea.

Any references, pointers, mailing lists for the aforementioned work would be
appreciated.  

fwiw, kde's kdm mainainer can be a bit... um... stubborn, but I'm certain
his heart is in the right place.  I'll do what I can to push, pull, nudge
things in the right direction.

-- Rex



From jkeating at redhat.com  Wed Oct 31 12:29:01 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 08:29:01 -0400
Subject: RadeonHD driver status
In-Reply-To: <1193819400.2750.3.camel@dawkins>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<20071030120356.14db5430@redhat.com>
	<1193819400.2750.3.camel@dawkins>
Message-ID: <20071031082901.5085bbfc@redhat.com>

On Wed, 31 Oct 2007 09:30:00 +0100
David Nielsen <david at lovesunix.net> wrote:

> I'm getting the same for ndesk-dbus, 3 emails to releng have gone
> unanswered so far. Seriously I'll take get lost you filthy hippie over
> no reply, pretty please.
> 
> Could you dust a bit of magic on my build capabilities?

3 emails?  Seriously?  "rel-eng at fedoraproject.org" right?  What was the
subject line?  I haven't gotten anything with 'ndesk' in the name.

You just need to be able to build this for f9 and above right?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/97ad4c28/attachment.sig>

From jkeating at redhat.com  Wed Oct 31 12:33:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 08:33:12 -0400
Subject: KDE logout options with F8
In-Reply-To: <20071031054714.GA16711@holycow.viki.com>
References: <20071030222414.3fb693ea@redhat.com>
	<20071031054714.GA16711@holycow.viki.com>
Message-ID: <20071031083312.5fa83aa2@redhat.com>

On Wed, 31 Oct 2007 11:17:14 +0530
Vikram Goyal <vikigoyal at gmail.com> wrote:

> Whoops! goes the fedora KDE integration.

Why does "KDE integration" have to mean throw out all things that don't
start with K?  Why can't it mean integrate with various bits and pieces
that should be system standard and DE agnostic (like a display manager
that can select which session to load)?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/8f78a5d8/attachment.sig>

From tcallawa at redhat.com  Wed Oct 31 12:39:04 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 31 Oct 2007 08:39:04 -0400
Subject: Mesa license issue?
In-Reply-To: <1193823500.5825.33.camel@localhost>
References: <1193821480.5825.29.camel@localhost>
	<1193823500.5825.33.camel@localhost>
Message-ID: <1193834344.21765.18.camel@localhost.localdomain>


On Wed, 2007-10-31 at 04:38 -0500, Callum Lerwick wrote:
> Update: I found this commit in Mesa's git:
> 
> http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=344c3f7379ab4db749e7e8513be9be8fbb9f126c
> 
> It appears this is fixed in Mesa 7, which is in F8, but I don't know
> where this leaves F7 and whatnot, which are still shipping Mesa 6.5.x.

I'm not sure that's even remotely legal for Mesa to have committed. The
SGI Free B license doesn't permit arbitrary relicensing, and without any
code changes, that amounts to simply stripping the copyright and license
off the old files.

Adam, do you know the details behind that commit?

~spot




From j.w.r.degoede at hhs.nl  Wed Oct 31 12:25:02 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 31 Oct 2007 13:25:02 +0100
Subject: rawhide report: 20071031 changes
In-Reply-To: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>
References: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>
Message-ID: <4728741E.1010002@hhs.nl>

Build System wrote:
> SDL_mixer-1.2.8-4.fc8
> ---------------------
> * Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
> - SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
>   avoids applications from locking up
> 

Is there a bugzilla ID for this? If this is a problem, shouldn't this be 
handled at the SDL level?

Regards,

Hans



From tcallawa at redhat.com  Wed Oct 31 12:44:33 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 31 Oct 2007 08:44:33 -0400
Subject: Mesa license issue?
In-Reply-To: <1193834344.21765.18.camel@localhost.localdomain>
References: <1193821480.5825.29.camel@localhost>
	<1193823500.5825.33.camel@localhost>
	<1193834344.21765.18.camel@localhost.localdomain>
Message-ID: <1193834673.21765.20.camel@localhost.localdomain>


On Wed, 2007-10-31 at 08:39 -0400, Tom "spot" Callaway wrote:
> On Wed, 2007-10-31 at 04:38 -0500, Callum Lerwick wrote:
> > Update: I found this commit in Mesa's git:
> > 
> > http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=344c3f7379ab4db749e7e8513be9be8fbb9f126c
> > 
> > It appears this is fixed in Mesa 7, which is in F8, but I don't know
> > where this leaves F7 and whatnot, which are still shipping Mesa 6.5.x.
> 
> I'm not sure that's even remotely legal for Mesa to have committed. The
> SGI Free B license doesn't permit arbitrary relicensing, and without any
> code changes, that amounts to simply stripping the copyright and license
> off the old files.
> 
> Adam, do you know the details behind that commit?

NM, it looks like SGI signed off on that change upstream when they moved
to hosting those files at Khronos.

~spot



From j.w.r.degoede at hhs.nl  Wed Oct 31 12:32:42 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 31 Oct 2007 13:32:42 +0100
Subject: Mesa license issue?
In-Reply-To: <1193834344.21765.18.camel@localhost.localdomain>
References: <1193821480.5825.29.camel@localhost>	<1193823500.5825.33.camel@localhost>
	<1193834344.21765.18.camel@localhost.localdomain>
Message-ID: <472875EA.4080508@hhs.nl>

Tom "spot" Callaway wrote:
> On Wed, 2007-10-31 at 04:38 -0500, Callum Lerwick wrote:
>> Update: I found this commit in Mesa's git:
>>
>> http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=344c3f7379ab4db749e7e8513be9be8fbb9f126c
>>
>> It appears this is fixed in Mesa 7, which is in F8, but I don't know
>> where this leaves F7 and whatnot, which are still shipping Mesa 6.5.x.
> 
> I'm not sure that's even remotely legal for Mesa to have committed. The
> SGI Free B license doesn't permit arbitrary relicensing, and without any
> code changes, that amounts to simply stripping the copyright and license
> off the old files.
> 
> Adam, do you know the details behind that commit?
> 

I've done some research on this, the OpenGL standard has been given in the 
hands of an organization called "The Khronos Group Inc":
http://www.khronos.org/

They are now the owners of:
http://www.opengl.org/

Where the host atleast some of the involved header files:
http://www.opengl.org/registry/api/glext.h
http://www.opengl.org/registry/api/glxext.h
http://www.opengl.org/registry/api/wglext.h

With a new Khronos copyright header, these are the only files changed by the 
commit, so yes this is legit. Unfortunately, it doesn't solve the whole problem.

Regards,

Hans



From tcallawa at redhat.com  Wed Oct 31 12:51:31 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 31 Oct 2007 08:51:31 -0400
Subject: Mesa license issue?
In-Reply-To: <472875EA.4080508@hhs.nl>
References: <1193821480.5825.29.camel@localhost>
	<1193823500.5825.33.camel@localhost>
	<1193834344.21765.18.camel@localhost.localdomain>
	<472875EA.4080508@hhs.nl>
Message-ID: <1193835091.21765.22.camel@localhost.localdomain>


On Wed, 2007-10-31 at 13:32 +0100, Hans de Goede wrote:

> With a new Khronos copyright header, these are the only files changed by the 
> commit, so yes this is legit. Unfortunately, it doesn't solve the whole problem.

Nope, it doesn't.

~spot



From j.w.r.degoede at hhs.nl  Wed Oct 31 12:39:26 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 31 Oct 2007 13:39:26 +0100
Subject: Mesa license issue?
In-Reply-To: <47287154.7060101@redhat.com>
References: <1193821480.5825.29.camel@localhost> <47287154.7060101@redhat.com>
Message-ID: <4728777E.9010009@hhs.nl>

Anthony Green wrote:
> Callum Lerwick wrote:
>> "SGI Free Software License B" is explicitly not acceptable in Fedora:
>>
>> http://fedoraproject.org/wiki/Licensing#head-d8cc605dd386091c8b6be97b8a43fb6a5d624ae1 
>>
>>
> 
> Parts of jogl are licensed under this license.  I don't believe anything 
> depends on jogl. I've just retired this package.
> 

We might want to have jogl in the future, assuming it just includes some SGI 
licensed OpenGL header files, we might be able to replaced the encumbered parts 
like I did with glew.

Regards,

Hans



From green at redhat.com  Wed Oct 31 13:04:39 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 31 Oct 2007 06:04:39 -0700
Subject: Mesa license issue?
In-Reply-To: <4728777E.9010009@hhs.nl>
References: <1193821480.5825.29.camel@localhost> <47287154.7060101@redhat.com>
	<4728777E.9010009@hhs.nl>
Message-ID: <47287D67.6020200@redhat.com>

Hans de Goede wrote:
> We might want to have jogl in the future, assuming it just includes some 
> SGI licensed OpenGL header files, we might be able to replaced the 
> encumbered parts like I did with glew.

I think it is more than just headers.  I'm going to talk to upstream 
about it.  I hope we can sort it out because there are some nice apps 
written on top of jogl these days (cf. 
http://code.google.com/p/worldwindrcp/ )

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/f0145b01/attachment.vcf>

From drago01 at gmail.com  Wed Oct 31 12:10:31 2007
From: drago01 at gmail.com (dragoran)
Date: Wed, 31 Oct 2007 13:10:31 +0100
Subject: rawhide report: 20071031 changes
In-Reply-To: <4728741E.1010002@hhs.nl>
References: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>
	<4728741E.1010002@hhs.nl>
Message-ID: <472870B7.40306@gmail.com>

Hans de Goede wrote:
> Build System wrote:
>> SDL_mixer-1.2.8-4.fc8
>> ---------------------
>> * Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
>> - SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio 
>> directly
>>   avoids applications from locking up
>>
>
> Is there a bugzilla ID for this? If this is a problem, shouldn't this 
> be handled at the SDL level?
>
https://bugzilla.redhat.com/show_bug.cgi?id=358341




From sundaram at fedoraproject.org  Wed Oct 31 13:21:31 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 18:51:31 +0530
Subject: KDE logout options with F8
In-Reply-To: <d9c612bf0710310531k4691e8a2w1cde9e3ab31b22df@mail.gmail.com>
References: <200710302208.03091.singularitaet@gmx.net>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>
	<4728673A.9050502@redhat.com>	<47286BCE.2070208@fedoraproject.org>
	<d9c612bf0710310531k4691e8a2w1cde9e3ab31b22df@mail.gmail.com>
Message-ID: <4728815B.9010209@fedoraproject.org>

Christopher Stone wrote:
> On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>> It would be fantastic if the backend was more neutral like you said
>> since there are people who might want to run any display manager with
>> any desktop environment. Meanwhile, throwing around accusations instead
>> of looking at what KDE maintainers as well as users want in Fedora is
>> counter productive. Just a while back I was accused of having an agenda
>> against KDE [1]. Now I get accused of having an agenda towards KDE [2].
>> I guess, the next one to follow would be XFCE [3]. Others would accuse
>> Red Hat of crippling KDE and the routine will continue.  Next time,
>> don't wonder why.
>>
>> Rahul
>>
>> [1]https://www.redhat.com/archives/fedora-games-list/2007-September/msg00047.html
>>
>> [2]https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02680.html
>>
>> [3]http://fedoraproject.org/wiki/RahulSundaram/XfceLive
> 
> While I agree with what you have said in this thread, I certainly got
> the impression you were doing everything within your means to avoid
> having any kde games in the games spin.  I really don't know why you
> brought that up here, if you want to continue the discussion about the
> games spin, please add to the thread on the games list or in private
> with me.  Thank you.  Sheesh.

I am uninterested in that discussion again. Generally people could be 
more courteous instead of throwing around accusations of bias without 
understanding the factors involved. We can do better.

Rahul



From doug at nostar.net  Wed Oct 31 13:28:39 2007
From: doug at nostar.net (Doug McLain)
Date: Wed, 31 Oct 2007 09:28:39 -0400
Subject: linux1394 and f8
Message-ID: <47288307.7060306@nostar.net>

I am running 7.92, and I see that the new firewire stack is in place. 
There is a page at the linux1394 wiki that suggests that kernel 
packagers build the old stack into the kernel for the time being:

http://wiki.linux1394.org/JujuMigration

Any chance of this happenign for Fedora 8?

Doug



From pbrobinson at gmail.com  Wed Oct 31 13:46:57 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 31 Oct 2007 13:46:57 +0000
Subject: linux1394 and f8
In-Reply-To: <47288307.7060306@nostar.net>
References: <47288307.7060306@nostar.net>
Message-ID: <5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>

> I am running 7.92, and I see that the new firewire stack is in place.
> There is a page at the linux1394 wiki that suggests that kernel
> packagers build the old stack into the kernel for the time being:
>
> http://wiki.linux1394.org/JujuMigration
>
> Any chance of this happenign for Fedora 8?

Right below where it says the best advise is to use the old drivers it
also says :

Building the new drivers is only for advanced users (who for example
want the better speed of firewire-sbp2 relative to sbp2, on the
hardware on which the new drivers already work) - and for distributors
who know what is required in userspace to make use of the new drivers
(i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
and config files etc.).

I suspect "distributors who know what is required in userspace" covers
Fedora and hence the required patches are probably all there.

I believe also it makes firewire generally a lot more stable even
though there are a few regressions.

Peter



From gemi at bluewin.ch  Wed Oct 31 14:05:38 2007
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Wed, 31 Oct 2007 15:05:38 +0100
Subject: linux1394 and f8
In-Reply-To: <5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
References: <47288307.7060306@nostar.net>
	<5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
Message-ID: <1193839538.11477.2.camel@localhost.localdomain>

On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
> I believe also it makes firewire generally a lot more stable even
> though there are a few regressions.
The regression is that on FW interfaces which support OHCI 1.0 instead
of OHCI 1.1, dv grabbing is not possible. It appears that most FW cards
are still OHCI 1.0. Work seems to be underway to support the older ones
too, but until then I think the only possibility is to buy a new card.
BTW the new stack is already in F7.
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From davej at redhat.com  Wed Oct 31 14:08:35 2007
From: davej at redhat.com (Dave Jones)
Date: Wed, 31 Oct 2007 10:08:35 -0400
Subject: kernel-2.6.23.1-30.fc8 problem with symbios scsi controllers.
In-Reply-To: <471F7D7C.2070003@cohtech.com>
References: <471F7D7C.2070003@cohtech.com>
Message-ID: <20071031140835.GB28715@redhat.com>

On Wed, Oct 24, 2007 at 06:14:36PM +0100, Howard Wilkinson wrote:

 > PCI quirk: region 0c00-0c3f claimed by PIIX4 ACPI
 > PCI quirk: region 0cc0-0ccf claimed by PIIX4 SMB
 > PIIX4 devres B PIO at 0ca2-0ca3
 > PIIX4 devres C PIO at 0ca0-0ca1
 > PCI: Searching for i450NX host bridges on 0000:00:10.0
 > ACPI: PCI Root Bridge [PCI1] (0000:01)
 > ACPI: Bus 0000:01 not present in PCI namespace
 > ACPI: PCI Interrupt Link [IT00] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT01] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT02] (IRQs 3 4 5 7 *10 11 12 14 15)
 > ACPI: PCI Interrupt Link [IT10] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT11] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT12] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT20] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT21] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT22] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT30] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT31] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT32] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT42] (IRQs 3 4 5 7 10 *11 12 14 15)
 > ACPI: PCI Interrupt Link [IT38] (IRQs 3 4 5 7 10 11 12 14 *15)
 > ACPI: PCI Interrupt Link [IT39] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT03] (IRQs 3 4 *5 7 10 11 12 14 15)
 > ACPI: PCI Interrupt Link [IT04] (IRQs 3 5 7 10 *11 15)
 > ACPI: PCI Interrupt Link [IT05] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT06] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT13] (IRQs 3 4 5 7 10 *11 12 14 15)
 > ACPI: PCI Interrupt Link [IT14] (IRQs 3 4 5 7 10 *11 12 14 15)
 > ACPI: PCI Interrupt Link [IT15] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT16] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT23] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT24] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT25] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT26] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT33] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT34] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT35] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT36] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
 > ACPI: PCI Interrupt Link [IT41] (IRQs 3 4 5 7 10 *11 12 14 15)
 > ACPI: PCI Interrupt Link [IT40] (IRQs 3 4 5 7 10 *11 12 14 15)

On the kernel that works, is anything in the above section different?

 > PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a 
 > report

Worth a shot.  Also give pci=noacpi a try if that still doesn't fix it.

 > ACPI: Unable to derive IRQ for device 0000:01:03.0
 > ACPI: PCI Interrupt 0000:01:03.0[A]: no GSI - using IRQ 11
 > sym0: <896> rev 0x1 at pci 0000:01:03.0 irq 11
 > sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
 > sym0: SCSI BUS has been reset.
 > scsi0 : sym-2.2.3
 > ACPI: Unable to derive IRQ for device 0000:01:03.1
 > ACPI: PCI Interrupt 0000:01:03.1[B]: no GSI - using IRQ 11
 > sym1: <896> rev 0x1 at pci 0000:01:03.1 irq 11
 > sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking
 > sym1: SCSI BUS has been reset.
 > scsi1 : sym-2.2.3
 > ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 58 (level, low) -> IRQ 17
 > sym2: <810a> rev 0x23 at pci 0000:00:08.0 irq 17
 > sym2: No NVRAM, ID 7, Fast-10, SE, parity checking
 > sym2: SCSI BUS has been reset.

On the face of things, interrupt routing is screwed up somehow, and
everything goes south shortly after initialisation.
Give those boot params a try, and see if that helps any.
Sadly, this isn't going to get fixed in time for F8 now, so we're
in the "hope there are workarounds" area for this.

(Final big hammer to try if all else fails - acpi=off)

	Dave

-- 
http://www.codemonkey.org.uk



From wwoods at redhat.com  Wed Oct 31 14:27:19 2007
From: wwoods at redhat.com (Will Woods)
Date: Wed, 31 Oct 2007 10:27:19 -0400
Subject: linux1394 and f8
In-Reply-To: <5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
References: <47288307.7060306@nostar.net>
	<5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
Message-ID: <1193840839.14742.18.camel@localhost.localdomain>


On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
> > I am running 7.92, and I see that the new firewire stack is in place.
> > There is a page at the linux1394 wiki that suggests that kernel
> > packagers build the old stack into the kernel for the time being:
> >
> > http://wiki.linux1394.org/JujuMigration
> >
> > Any chance of this happenign for Fedora 8?

Short answer: No. We've been using the Juju stack since F7 and we're not
moving back, 'cuz Cutting Edge is what we're all about. But see below. 

> Right below where it says the best advise is to use the old drivers it
> also says :
> 
> Building the new drivers is only for advanced users (who for example
> want the better speed of firewire-sbp2 relative to sbp2, on the
> hardware on which the new drivers already work) - and for distributors
> who know what is required in userspace to make use of the new drivers
> (i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
> and config files etc.).
> 
> I suspect "distributors who know what is required in userspace" covers
> Fedora and hence the required patches are probably all there.

Right. Kristian H?gsberg is the primary author of the Juju stack - he's
a Red Hat employee and Fedora contributor. He got all the Juju bits into
F7 - the "new firewire stack" has been in place since then.

So nothing's really new for firewire in F8. The only noticeable changes
since F7 are some bugfixes, and some changes relating to dvgrab,
libraw1394 and isochronous devices (basically cameras and other
audio/video devices). 

Iso devices should work everywhere *except* machines with OHCI 1.0
controllers. Otherwise you get this message in dmesg:

firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
firewire_ohci:     Isochronous I/O is not yet implemented for OHCI 1.0
chips.
firewire_ohci:     Cameras, audio devices etc. won't work on this
controller with this driver version.

Unfortunately, these turn out to be more common than previously thought.
But people are actively working on this problem - see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0

It's possible this will be fixed in an F8 update. It's quite likely to
be fixed for Fedora 9. If that's not soon enough, I'm told there's some
third-party repositories out there that package up the older stack.

-w
-------------- 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/20071031/17199101/attachment.sig>

From chris.stone at gmail.com  Wed Oct 31 14:33:17 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 31 Oct 2007 07:33:17 -0700
Subject: KDE logout options with F8
In-Reply-To: <4728815B.9010209@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<1193794397.11243.1.camel@localhost.localdomain>
	<4727DD39.5070900@fedoraproject.org> <4728673A.9050502@redhat.com>
	<47286BCE.2070208@fedoraproject.org>
	<d9c612bf0710310531k4691e8a2w1cde9e3ab31b22df@mail.gmail.com>
	<4728815B.9010209@fedoraproject.org>
Message-ID: <d9c612bf0710310733n37ee6ba8oa5bd331d4eb89edc@mail.gmail.com>

On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Christopher Stone wrote:
> > On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> >> It would be fantastic if the backend was more neutral like you said
> >> since there are people who might want to run any display manager with
> >> any desktop environment. Meanwhile, throwing around accusations instead
> >> of looking at what KDE maintainers as well as users want in Fedora is
> >> counter productive. Just a while back I was accused of having an agenda
> >> against KDE [1]. Now I get accused of having an agenda towards KDE [2].
> >> I guess, the next one to follow would be XFCE [3]. Others would accuse
> >> Red Hat of crippling KDE and the routine will continue.  Next time,
> >> don't wonder why.
> >>
> >> Rahul
> >>
> >> [1]https://www.redhat.com/archives/fedora-games-list/2007-September/msg00047.html
> >>
> >> [2]https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02680.html
> >>
> >> [3]http://fedoraproject.org/wiki/RahulSundaram/XfceLive
> >
> > While I agree with what you have said in this thread, I certainly got
> > the impression you were doing everything within your means to avoid
> > having any kde games in the games spin.  I really don't know why you
> > brought that up here, if you want to continue the discussion about the
> > games spin, please add to the thread on the games list or in private
> > with me.  Thank you.  Sheesh.
>
> I am uninterested in that discussion again. Generally people could be
> more courteous instead of throwing around accusations of bias without
> understanding the factors involved. We can do better.

I still do not understand why you brought it up again in this thread
especially in light of the fact that you are not interested in it.

I guess you want everyone on the fedora devel list to analyze the
games thread and try and determine if my accusations of bias were
unjustified (which they were not).

Did I not clearly ask that you send this to me either in private or
start up the thread again on the games list?



From mike.cohler at gmail.com  Wed Oct 31 14:33:15 2007
From: mike.cohler at gmail.com (Mike Cohler)
Date: Wed, 31 Oct 2007 14:33:15 +0000
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7
Message-ID: <3dd77c60710310733v5e445dbcked55759514b50cc7@mail.gmail.com>

Michael Schwendt wrote:

>Just out of interest, what does your /etc/hosts.deny contain?
>And what is in your /etc/hosts?

>The rpcbind package changelog mentions tcp_wrappers related changes
>in rpcbind-0.1.4-8.fc8, but your problem is not reproducible here.

>$ rpm -q rpcbind nfs-utils
>rpcbind-0.1.4-11.fc8
>nfs-utils-1.1.0-6.fc8


In my case the file
/etc/hosts.deny
has
#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
lockd:ALL
mountd:ALL
rpcbind:ALL
rquotad:ALL
statd:ALL

and
/etc/hosts
has
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
::1             localhost.localdomain localhost
xxx.xxx.xxx.xxx     mymachine mymachine.localnetwork.com

Of course you are quoting for F8 whereas this is seen in F7 here.
-- 

mike cohler



From sundaram at fedoraproject.org  Wed Oct 31 14:34:32 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 20:04:32 +0530
Subject: KDE logout options with F8
In-Reply-To: <d9c612bf0710310733n37ee6ba8oa5bd331d4eb89edc@mail.gmail.com>
References: <200710302208.03091.singularitaet@gmx.net>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>
	<4728673A.9050502@redhat.com>	<47286BCE.2070208@fedoraproject.org>	<d9c612bf0710310531k4691e8a2w1cde9e3ab31b22df@mail.gmail.com>	<4728815B.9010209@fedoraproject.org>
	<d9c612bf0710310733n37ee6ba8oa5bd331d4eb89edc@mail.gmail.com>
Message-ID: <47289278.5020703@fedoraproject.org>

Christopher Stone wrote:
> On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>> Christopher Stone wrote:
>>> On 10/31/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>>>> It would be fantastic if the backend was more neutral like you said
>>>> since there are people who might want to run any display manager with
>>>> any desktop environment. Meanwhile, throwing around accusations instead
>>>> of looking at what KDE maintainers as well as users want in Fedora is
>>>> counter productive. Just a while back I was accused of having an agenda
>>>> against KDE [1]. Now I get accused of having an agenda towards KDE [2].
>>>> I guess, the next one to follow would be XFCE [3]. Others would accuse
>>>> Red Hat of crippling KDE and the routine will continue.  Next time,
>>>> don't wonder why.
>>>>
>>>> Rahul
>>>>
>>>> [1]https://www.redhat.com/archives/fedora-games-list/2007-September/msg00047.html
>>>>
>>>> [2]https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02680.html
>>>>
>>>> [3]http://fedoraproject.org/wiki/RahulSundaram/XfceLive
>>> While I agree with what you have said in this thread, I certainly got
>>> the impression you were doing everything within your means to avoid
>>> having any kde games in the games spin.  I really don't know why you
>>> brought that up here, if you want to continue the discussion about the
>>> games spin, please add to the thread on the games list or in private
>>> with me.  Thank you.  Sheesh.
>> I am uninterested in that discussion again. Generally people could be
>> more courteous instead of throwing around accusations of bias without
>> understanding the factors involved. We can do better.
> 
> I still do not understand why you brought it up again in this thread
> especially in light of the fact that you are not interested in it.

To make another related point. Nothing personal with you.

Rahul



From david at lovesunix.net  Wed Oct 31 14:51:16 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 31 Oct 2007 15:51:16 +0100
Subject: RadeonHD driver status
In-Reply-To: <20071031082901.5085bbfc@redhat.com>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<20071030120356.14db5430@redhat.com> <1193819400.2750.3.camel@dawkins>
	<20071031082901.5085bbfc@redhat.com>
Message-ID: <1193842276.3048.7.camel@dawkins>


ons, 31 10 2007 kl. 08:29 -0400, skrev Jesse Keating:
> On Wed, 31 Oct 2007 09:30:00 +0100
> David Nielsen <david at lovesunix.net> wrote:
> 
> > I'm getting the same for ndesk-dbus, 3 emails to releng have gone
> > unanswered so far. Seriously I'll take get lost you filthy hippie over
> > no reply, pretty please.
> > 
> > Could you dust a bit of magic on my build capabilities?
> 
> 3 emails?  Seriously?  "rel-eng at fedoraproject.org" right?  What was the
> subject line?  I haven't gotten anything with 'ndesk' in the name.
> 
> You just need to be able to build this for f9 and above right?

3 emails. Subject "ndesk-dbus is blocked for tag dist-f9"

Kevin told me to mail releng at fedoraproject.org, I took his authority
without double checking so there seems to be the cause of the problem.
Strangely I got not failure message either though I would have expected
that if I send it to a non-existing addy.

Regardless if I could just get f9 for now that would be great, there we
can live with a tiny bit of disruption should it happen. 

Implementation plan goes as follows:
Build ndesk-dbus
Get ndesk-dbus-glib through review
Convert builds in F9 to use system ndesk-dbus

When all builds work, we can coordinate a push to F8 and F7. Ndesk-dbus
will be required to build podsleuth which is a dependency for the
upcoming Banshee so I'll work as fast as possible to not disrupt chris'
work.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/f472783f/attachment.sig>

From howard at cohtech.com  Wed Oct 31 14:54:20 2007
From: howard at cohtech.com (Howard Wilkinson)
Date: Wed, 31 Oct 2007 14:54:20 +0000
Subject: kernel-2.6.23.1-30.fc8 problem with symbios scsi controllers.
In-Reply-To: <20071031140835.GB28715@redhat.com>
References: <471F7D7C.2070003@cohtech.com> <20071031140835.GB28715@redhat.com>
Message-ID: <4728971C.4030909@cohtech.com>

Dave Jones wrote:
> On Wed, Oct 24, 2007 at 06:14:36PM +0100, Howard Wilkinson wrote:
>
>
> On the kernel that works, is anything in the above section different?
>   
Yes the kernel saw some data about the bridges! I do not have a dump to 
hand but may be able to reproduce if needed
>  > PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a 
>  > report
>
> Worth a shot.  Also give pci=noacpi a try if that still doesn't fix it.
>   
pci=routeirq fails with same problem
pci=noacpi works in that it sees the disc but the network will not start 
the loopback device - probably unrelated as I have seen something 
similar elsewhere.
>
> On the face of things, interrupt routing is screwed up somehow, and
> everything goes south shortly after initialisation.
> Give those boot params a try, and see if that helps any.
> Sadly, this isn't going to get fixed in time for F8 now, so we're
> in the "hope there are workarounds" area for this.
>
> (Final big hammer to try if all else fails - acpi=off)
>   
This worked and will do me for now. But how do we go about getting this 
fixed, there are a LARGE number of these boxes in the field!
> 	Dave
>
>   
Howard.

-- 

Howard Wilkinson

	

Phone:

	

+44(20)76907075

Coherent Technology Limited

	

Fax:

	

 

23 Northampton Square,

	

Mobile:

	

+44(7980)639379

United Kingdom, EC1V 0HL

	

Email:

	

howard at cohtech.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/7ffb079a/attachment.htm>

From bpepple at fedoraproject.org  Wed Oct 31 14:56:43 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 31 Oct 2007 10:56:43 -0400
Subject: Plan for tomorrows (20071101) FESCO meeting
Message-ID: <1193842603.2599.4.camel@nixon>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic Misc - Proposed Development Changes -
http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal - f13

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, but we'll most likely will if we don't run out of time).
You can also propose topics in the meeting while it is in the "Free
discussion around Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- 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/20071031/a77ffe95/attachment.sig>

From j.w.r.degoede at hhs.nl  Wed Oct 31 14:45:51 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 31 Oct 2007 15:45:51 +0100
Subject: linux1394 and f8
In-Reply-To: <1193840839.14742.18.camel@localhost.localdomain>
References: <47288307.7060306@nostar.net>	<5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
	<1193840839.14742.18.camel@localhost.localdomain>
Message-ID: <4728951F.6080007@hhs.nl>

Will Woods wrote:
> On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
>>> I am running 7.92, and I see that the new firewire stack is in place.
>>> There is a page at the linux1394 wiki that suggests that kernel
>>> packagers build the old stack into the kernel for the time being:
>>>
>>> http://wiki.linux1394.org/JujuMigration
>>>
>>> Any chance of this happenign for Fedora 8?
> 
> Short answer: No. We've been using the Juju stack since F7 and we're not
> moving back, 'cuz Cutting Edge is what we're all about. But see below. 
> 
>> Right below where it says the best advise is to use the old drivers it
>> also says :
>>
>> Building the new drivers is only for advanced users (who for example
>> want the better speed of firewire-sbp2 relative to sbp2, on the
>> hardware on which the new drivers already work) - and for distributors
>> who know what is required in userspace to make use of the new drivers
>> (i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
>> and config files etc.).
>>
>> I suspect "distributors who know what is required in userspace" covers
>> Fedora and hence the required patches are probably all there.
> 
> Right. Kristian H?gsberg is the primary author of the Juju stack - he's
> a Red Hat employee and Fedora contributor. He got all the Juju bits into
> F7 - the "new firewire stack" has been in place since then.
> 
> So nothing's really new for firewire in F8. The only noticeable changes
> since F7 are some bugfixes, and some changes relating to dvgrab,
> libraw1394 and isochronous devices (basically cameras and other
> audio/video devices). 
> 
> Iso devices should work everywhere *except* machines with OHCI 1.0
> controllers. Otherwise you get this message in dmesg:
> 
> firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
> firewire_ohci:     Isochronous I/O is not yet implemented for OHCI 1.0
> chips.
> firewire_ohci:     Cameras, audio devices etc. won't work on this
> controller with this driver version.
> 
> Unfortunately, these turn out to be more common than previously thought.
> But people are actively working on this problem - see this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0
> 
> It's possible this will be fixed in an F8 update. It's quite likely to
> be fixed for Fedora 9. If that's not soon enough, I'm told there's some
> third-party repositories out there that package up the older stack.
> 

Correct, most notably planet ccrma (AFAIK)

Regards,

Hans




From jkeating at redhat.com  Wed Oct 31 15:12:46 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 11:12:46 -0400
Subject: RadeonHD driver status
In-Reply-To: <1193842276.3048.7.camel@dawkins>
References: <1193749904.5664.1.camel@scrappy.miketc.com>
	<20071030093224.151f1ada@redhat.com>
	<472753FC.7060509@n-dimensional.de>
	<20071030120356.14db5430@redhat.com>
	<1193819400.2750.3.camel@dawkins>
	<20071031082901.5085bbfc@redhat.com>
	<1193842276.3048.7.camel@dawkins>
Message-ID: <20071031111246.25901dfc@redhat.com>

On Wed, 31 Oct 2007 15:51:16 +0100
David Nielsen <david at lovesunix.net> wrote:

> Regardless if I could just get f9 for now that would be great, there
> we can live with a tiny bit of disruption should it happen. 

Unblocked.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/761d6b4b/attachment.sig>

From vikigoyal at gmail.com  Wed Oct 31 15:22:30 2007
From: vikigoyal at gmail.com (Vikram Goyal)
Date: Wed, 31 Oct 2007 20:52:30 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031083312.5fa83aa2@redhat.com>
References: <20071031083312.5fa83aa2@redhat.com>
Message-ID: <20071031152230.GA6811@holycow.viki.com>

On Wed, Oct 31, 2007 at 08:33:12AM -0400, Jesse Keating wrote:
> On Wed, 31 Oct 2007 11:17:14 +0530
> Vikram Goyal <vikigoyal at gmail.com> wrote:
> 
> > Whoops! goes the fedora KDE integration.
> 
> Why does "KDE integration" have to mean throw out all things that don't
> start with K?  Why can't it mean integrate with various bits and pieces
> that should be system standard and DE agnostic (like a display manager
> that can select which session to load)?
> 

That's what we all are saying. Why Not.

But if you go up the thread, there's all kind rubbish without any
logical, meaningful reply, as if OP touched a really raw nerve and all
knee jerk reactions came to surface.

This is about kdm, but the arguments can go about for anything in KDE
to chop it off or atleast make it difficult to use to the point of
dormancy.

If this is called integration then as I said.

<QuotesON>
Really nice direction. Things became a bit clear today. Thanks...
<QuotesOff>

By the way I turned on kdm just now after reading the magical words in
one of the previous reply and found two selinux denied avcs and filed
the bug. The avcs it shows could have been fixed but since people could
not use kdm, they never came to filing bugs.

Thanks!
-- 
vikram...
         ||||||||
         ||||||||
^^'''''^^||root||^^^'''''''^^
        // \\   ))
       //(( \\// \\
      // /\\ ||   \\
     || / )) ((    \\
-- 
printk(KERN_ERR "happy meal: Fry guys.");
        linux-2.6.6/drivers/net/sunhme.c
-- 
 #
~|~
 =



From mcepl at redhat.com  Wed Oct 31 15:15:47 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 31 Oct 2007 16:15:47 +0100
Subject: Arial font on OOo
References: <47271350.1010207@bugs.unl.edu.ar>
	<1193744514.3740.3.camel@localhost.localdomain>
	<4727201C.7060503@bugs.unl.edu.ar>
Message-ID: <slrnfih713.q4j.mcepl@hubmaier.ceplovi.cz>

On 2007-10-30, 12:14 GMT, Martin Marques wrote:
> Anyway, I installed the ttf fonts from corefonts:
>
> http://corefonts.sourceforge.net/
>
> Sorry again.

Be even more sorry for installing proprietary fonts when the free 
100% functional equivalent exists.

Mat?j



From myfedora at richip.dhs.org  Wed Oct 31 15:24:43 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 31 Oct 2007 09:24:43 -0600
Subject: linux1394 and f8
In-Reply-To: <47288307.7060306@nostar.net>
References: <47288307.7060306@nostar.net>
Message-ID: <1193844283.10224.7.camel@localhost6.localdomain6>

On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
> I am running 7.92, and I see that the new firewire stack is in place. 
> There is a page at the linux1394 wiki that suggests that kernel 
> packagers build the old stack into the kernel for the time being:
> 
> http://wiki.linux1394.org/JujuMigration
> 
> Any chance of this happenign for Fedora 8?

Axel Thimms (of ATRPMS fame) is distributing an ieee1394-kmdl package
which, I think, is compiled to use the old stack. They are doing it
because MythTV is incompatible (read: doesn't work) with the new
firewire stack. The only unfortunate thing is that he is distributing a
"libraw1394" package (which collides with a package on Fedora) in order
to provide support for the kernel module. I have suggested using a
different name for the package and placing the library in a different
directory (to be loaded by mythtv with LD_LIBRARY_PATH), and hopefully
that will fix any conflicts with Fedora.

(I just checked and they don't seem to be doing it for F8 but you could
probably grab the src.rpm and compile it and update it for your kernel.)
--

Richi Plana



From jkeating at redhat.com  Wed Oct 31 15:30:07 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 11:30:07 -0400
Subject: KDE logout options with F8
In-Reply-To: <20071031152230.GA6811@holycow.viki.com>
References: <20071031083312.5fa83aa2@redhat.com>
	<20071031152230.GA6811@holycow.viki.com>
Message-ID: <20071031113007.08137c1c@redhat.com>

On Wed, 31 Oct 2007 20:52:30 +0530
Vikram Goyal <vikigoyal at gmail.com> wrote:

> By the way I turned on kdm just now after reading the magical words in
> one of the previous reply and found two selinux denied avcs and filed
> the bug. The avcs it shows could have been fixed but since people
> could not use kdm, they never came to filing bugs.

What is the bug number, and as stated in this thread there are plenty
of people using kdm.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/45c3912c/attachment.sig>

From overholt at redhat.com  Wed Oct 31 15:31:37 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 31 Oct 2007 11:31:37 -0400
Subject: eclipse-egit orphaned
In-Reply-To: <47278652.1060805@redhat.com>
References: <1193771127.8105.2.camel@localhost.localdomain>
	<47278652.1060805@redhat.com>
Message-ID: <20071031153137.GB20269@redhat.com>

* Anthony Green <green at redhat.com> [2007-10-30 15:30]:
> Ben Konrath wrote:
>> Hi, I just orphaned the eclipse-egit package. Anybody interested is more
>> than welcome to pick it up.
>
> I just installed it yesterday to try it out.  Are there any inherent 
> problems with this package?

Ben was telling me last week that it's still very much in development.
There aren't a whole lot of GUI operations but one can import from a
command line-checked out repository.  I really don't know much about it,
though.

Andrew
-------------- 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/20071031/4729b4f0/attachment.sig>

From caillon at redhat.com  Wed Oct 31 15:41:10 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 16:41:10 +0100
Subject: KDE logout options with F8
In-Reply-To: <fg9sjf$p80$1@ger.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<fg9sjf$p80$1@ger.gmane.org>
Message-ID: <4728A216.3020700@redhat.com>

Rex Dieter wrote:
> Christopher Aillon wrote:
> 
>> See the work that William Jon Mcann is doing upstream right now to help
>> get to the goal of a more generic login manager.  However, because we
>> aren't aiming to be bug for bug compatible with KDM (we're not even
>> aiming to be bug for bug compat with GDM), the KDM upstream guys are not
>> interested in participating.  Maybe instead of fighting within Fedora,
>> we can redirect the discussion to convince the KDM guys that this is a
>> good idea.
> 
> Any references, pointers, mailing lists for the aforementioned work would be
> appreciated.  

I don't know precisely where, I'm only aware of it happening.  I believe 
that there's some code checked into gdm HEAD right now.  That might be a 
good starting point.  mclasen or halfline probably know more about this.

> fwiw, kde's kdm mainainer can be a bit... um... stubborn, but I'm certain
> his heart is in the right place.  I'll do what I can to push, pull, nudge
> things in the right direction.

Cool, I think all parties involved would be grateful.



From caillon at redhat.com  Wed Oct 31 15:46:49 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 16:46:49 +0100
Subject: KDE logout options with F8
In-Reply-To: <47286BCE.2070208@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>	<4728673A.9050502@redhat.com>
	<47286BCE.2070208@fedoraproject.org>
Message-ID: <4728A369.9060507@redhat.com>

Rahul Sundaram wrote:
> Christopher Aillon wrote:
>> GDM is getting a massive face lift to be more generic.  The original 
>> intent was to get KDE on board as well such that all you'd do is swap 
>> toolkits and use the same backend.  We've been trying to convince KDM 
>> upstream to participate but I've heard there's been pushback because 
>> of something dumb like we need to be bug for bug compatible with the 
>> existing KDM, which is just not going to happen.
> 
> It would be fantastic if the backend was more neutral like you said 

Agreed, which might be why I brought it up.

> since there are people who might want to run any display manager with 
> any desktop environment. Meanwhile, throwing around accusations instead 
> of looking at what KDE maintainers as well as users want in Fedora is 
> counter productive. Just a while back I was accused of having an agenda 
> against KDE [1]. Now I get accused of having an agenda towards KDE [2]. 
> I guess, the next one to follow would be XFCE [3]. Others would accuse 
> Red Hat of crippling KDE and the routine will continue.  Next time, 
> don't wonder why.

Which has what exactly to do with my post?  This is not the first time 
you've included seemingly random points in replies to people in this 
thread.  You've confused various community members, which is counter 
productive.  It could also be a contributing factor to the hostility. 
Being a former board member, if you have any issues that need conflict 
resolution, you should know of better places to direct them to than 
mailing list flame wars.



From caillon at redhat.com  Wed Oct 31 15:55:37 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 16:55:37 +0100
Subject: KDE logout options with F8
In-Reply-To: <4727F17D.2090305@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org>
Message-ID: <4728A579.4040901@redhat.com>

Rahul Sundaram wrote:
> Matthias Clasen wrote:
>> On Wed, 2007-10-31 at 08:31 +0530, Rahul Sundaram wrote:
>>> It is a regression compared to the KDE spin.
>>>
>>
>> Thats a creative use of the term regression. 
> 
> Maybe it is. Not a native speaker.

If you are going to play the non-native speaker card, you should then be 
acutely aware that several people vehemently disagreeing with you could 
be precisely because of communication issues, and you might decide to 
curb the hostility and try a different argument instead of pushing the 
same one over again.



From sundaram at fedoraproject.org  Wed Oct 31 15:59:34 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 21:29:34 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728A369.9060507@redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>	<4728673A.9050502@redhat.com>	<47286BCE.2070208@fedoraproject.org>
	<4728A369.9060507@redhat.com>
Message-ID: <4728A666.20107@fedoraproject.org>

Christopher Aillon wrote:
> 
>> since there are people who might want to run any display manager with 
>> any desktop environment. Meanwhile, throwing around accusations 
>> instead of looking at what KDE maintainers as well as users want in 
>> Fedora is counter productive. Just a while back I was accused of 
>> having an agenda against KDE [1]. Now I get accused of having an 
>> agenda towards KDE [2]. I guess, the next one to follow would be XFCE 
>> [3]. Others would accuse Red Hat of crippling KDE and the routine will 
>> continue.  Next time, don't wonder why.
> 
> Which has what exactly to do with my post?  This is not the first time 
> you've included seemingly random points in replies to people in this 
> thread. 

Feel free to point out what you consider "random" points. I think I have 
only discussed related things.

  You've confused various community members, which is counter
> productive.  It could also be a contributing factor to the hostility. 

I don't see which community members I confused. My point is that there 
should be a common understanding that putting GDM as default for KDE 
users is not merely about naming. It is about functionality and 
integration that we are lacking due to our choice of defaults. It might 
indeed be the case that the KDM maintainer is not being co-operative but 
the lack of integration continues to affect our end users and we are 
getting blamed for that. What are we going to do about it if anything? 
Is there any distribution besides Fedora continues to have GDM as 
default for KDE (in the DVD image) despite KDE maintainers not wanting that?

> Being a former board member, if you have any issues that need conflict 
> resolution, you should know of better places to direct them to than 
> mailing list flame wars.

If you are suggesting private mails, my experience has been that they 
often go unanswered even after reminders.

Rahul



From sundaram at fedoraproject.org  Wed Oct 31 15:59:40 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 21:29:40 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728A579.4040901@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com>
Message-ID: <4728A66C.8070103@fedoraproject.org>

Christopher Aillon wrote:
> Rahul Sundaram wrote:
>> Matthias Clasen wrote:
>>> On Wed, 2007-10-31 at 08:31 +0530, Rahul Sundaram wrote:
>>>> It is a regression compared to the KDE spin.
>>>>
>>>
>>> Thats a creative use of the term regression. 
>>
>> Maybe it is. Not a native speaker.
> 
> If you are going to play the non-native speaker card, you should then be 
> acutely aware that several people vehemently disagreeing with you could 
> be precisely because of communication issues, and you might decide to 
> curb the hostility and try a different argument instead of pushing the 
> same one over again.

My arguments have remained purely technical so far and please do point 
out where I have expressed any hostility. It seems the other way around 
to me.

Rahul



From vikigoyal at gmail.com  Wed Oct 31 16:19:59 2007
From: vikigoyal at gmail.com (Vikram Goyal)
Date: Wed, 31 Oct 2007 21:49:59 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031113007.08137c1c@redhat.com>
References: <20071031113007.08137c1c@redhat.com>
Message-ID: <20071031161959.GA6778@holycow.viki.com>

On Wed, Oct 31, 2007 at 11:30:07AM -0400, Jesse Keating wrote:
> On Wed, 31 Oct 2007 20:52:30 +0530
> Vikram Goyal <vikigoyal at gmail.com> wrote:
> 
> > By the way I turned on kdm just now after reading the magical words in
> > one of the previous reply and found two selinux denied avcs and filed
> > the bug. The avcs it shows could have been fixed but since people
> > could not use kdm, they never came to filing bugs.
> 
> What is the bug number, and as stated in this thread there are plenty
> of people using kdm.
> 

https://bugzilla.redhat.com/show_bug.cgi?id=360301

-- 
vikram...
         ||||||||
         ||||||||
^^'''''^^||root||^^^'''''''^^
        // \\   ))
       //(( \\// \\
      // /\\ ||   \\
     || / )) ((    \\
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
		-- Wm. Shakespeare, "A Midsummer Night's Dream"
-- 
~|~
 =



From caillon at redhat.com  Wed Oct 31 16:34:12 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 17:34:12 +0100
Subject: KDE logout options with F8
In-Reply-To: <4728A666.20107@fedoraproject.org>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>	<4728673A.9050502@redhat.com>	<47286BCE.2070208@fedoraproject.org>	<4728A369.9060507@redhat.com>
	<4728A666.20107@fedoraproject.org>
Message-ID: <4728AE84.1080905@redhat.com>

Rahul Sundaram wrote:
> Christopher Aillon wrote:
>>
>>> since there are people who might want to run any display manager with 
>>> any desktop environment. Meanwhile, throwing around accusations 
>>> instead of looking at what KDE maintainers as well as users want in 
>>> Fedora is counter productive. Just a while back I was accused of 
>>> having an agenda against KDE [1]. Now I get accused of having an 
>>> agenda towards KDE [2]. I guess, the next one to follow would be XFCE 
>>> [3]. Others would accuse Red Hat of crippling KDE and the routine 
>>> will continue.  Next time, don't wonder why.
>>
>> Which has what exactly to do with my post?  This is not the first time 
>> you've included seemingly random points in replies to people in this 
>> thread. 
> 
> Feel free to point out what you consider "random" points. I think I have 
> only discussed related things.

What does the above have to do with my specific post?  Because I was not 
accusing you of anything.



From caillon at redhat.com  Wed Oct 31 16:44:20 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 17:44:20 +0100
Subject: KDE logout options with F8
In-Reply-To: <4728A66C.8070103@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>	<4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org>
Message-ID: <4728B0E4.2050209@redhat.com>

Rahul Sundaram wrote:
> My arguments have remained purely technical so far and please do point 
> out where I have expressed any hostility. It seems the other way around 
> to me.

I'm seeing it expressed in both directions, though you might not be 
aware of it.  For instance, complaining to me about how other people 
suck and are accusing you of having various agendas is a form of 
hostility toward the other people, and when you brought it up in the 
direct mail to me which had no relation to my post, I'm reading it as:

"This idea seems great, but stop accusing me of stuff.  Others were too. 
  If we suck, it's no wonder why".  This immediately puts me on the 
defensive as I'm wondering what I said to provoke this reaction from you.

Again, you are a former Fedora Board member.  Please find better places 
to express your dissatisfaction(s).  In other words, knock it off (not 
just you).  I'm tired of the bickering, and this is detracting from the 
main point I was making:

We are looking to have a more neutral backend.  This is good for both 
KDE and GNOME.



From cebbert at redhat.com  Wed Oct 31 16:49:28 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Wed, 31 Oct 2007 12:49:28 -0400
Subject: KDE logout options with F8
In-Reply-To: <20071030230707.13c5662b@redhat.com>
References: <20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<20071031022813.GA15904@nostromo.devel.redhat.com>	<4727ECB6.1080002@fedoraproject.org>
	<20071030230707.13c5662b@redhat.com>
Message-ID: <4728B218.5020803@redhat.com>

On 10/30/2007 11:07 PM, Jesse Keating wrote:
> On Wed, 31 Oct 2007 08:17:18 +0530
> Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> So the question is, is there any way at all to get KDM by default
>> when users select KDE during installation or is there none?
> 
> Sure, in release notes for KDE you tell them to uncheck gdm. 

Shouldn't unchecking Gnome automatically uncheck gdm???



From sundaram at fedoraproject.org  Wed Oct 31 16:48:45 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 22:18:45 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728AE84.1080905@redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<1193794397.11243.1.camel@localhost.localdomain>	<4727DD39.5070900@fedoraproject.org>	<4728673A.9050502@redhat.com>	<47286BCE.2070208@fedoraproject.org>	<4728A369.9060507@redhat.com>	<4728A666.20107@fedoraproject.org>
	<4728AE84.1080905@redhat.com>
Message-ID: <4728B1ED.2060509@fedoraproject.org>

Christopher Aillon wrote:
> Rahul Sundaram wrote:
>> Christopher Aillon wrote:
>>>
>>>> since there are people who might want to run any display manager 
>>>> with any desktop environment. Meanwhile, throwing around accusations 
>>>> instead of looking at what KDE maintainers as well as users want in 
>>>> Fedora is counter productive. Just a while back I was accused of 
>>>> having an agenda against KDE [1]. Now I get accused of having an 
>>>> agenda towards KDE [2]. I guess, the next one to follow would be 
>>>> XFCE [3]. Others would accuse Red Hat of crippling KDE and the 
>>>> routine will continue.  Next time, don't wonder why.
>>>
>>> Which has what exactly to do with my post?  This is not the first 
>>> time you've included seemingly random points in replies to people in 
>>> this thread. 
>>
>> Feel free to point out what you consider "random" points. I think I 
>> have only discussed related things.
> 
> What does the above have to do with my specific post?  Because I was not 
> accusing you of anything.

It is not specific to your post as such but it is related to the entire 
thread and I am explaining my perspective on why I consider this important.

Rahul



From triad at df.lth.se  Wed Oct 31 16:52:35 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 31 Oct 2007 17:52:35 +0100 (CET)
Subject: Doxygen and multilib
Message-ID: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>

OK so I have that problem where Doxygen generates links as hashes 
including something like a time stamp, so the -devel packages end up 
causing multilib conflicts.

Is there some silver bullet to actually SOLVE this?

I saw that Hans solved this by tar.gz:ing up the docs and add as separate 
source and then suppress compile-time building of the docs, replacing with 
pre-generated contents.

Myself I simply deleted the docs for now.

I sort of believe Doxygen should be fixed to do something more 
predictable, atleast on request.

Any ideas?

Linus



From sundaram at fedoraproject.org  Wed Oct 31 16:55:08 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 22:25:08 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728B0E4.2050209@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com>
Message-ID: <4728B36C.4060403@fedoraproject.org>

Christopher Aillon wrote:
> Rahul Sundaram wrote:
>> My arguments have remained purely technical so far and please do point 
>> out where I have expressed any hostility. It seems the other way 
>> around to me.
> 
> I'm seeing it expressed in both directions, though you might not be 
> aware of it.  For instance, complaining to me about how other people 
> suck and are accusing you of having various agendas is a form of 
> hostility toward the other people, and when you brought it up in the 
> direct mail to me which had no relation to my post, I'm reading it as:
> 
> "This idea seems great, but stop accusing me of stuff.  Others were too. 
>  If we suck, it's no wonder why".  This immediately puts me on the 
> defensive as I'm wondering what I said to provoke this reaction from you.

I am sorry you took it that way. Reading the entire thread would make it 
clear where I am coming from. I wasn't complaining to you btw. Just 
explaining my perspective.

> Again, you are a former Fedora Board member.  Please find better places 
> to express your dissatisfaction(s).  In other words, knock it off (not 
> just you).  I'm tired of the bickering, and this is detracting from the 
> main point I was making:
> 
> We are looking to have a more neutral backend.  This is good for both 
> KDE and GNOME.

This is good for the long term if it works out well. Meanwhile can we 
please make it so that if the user unselects GNOME and selects KDE 
explicitly in Fedora DVD image, the user gets KDM by default? I think 
this is a very reasonable request to make. Please consider it.

Rahul



From sandeen at redhat.com  Wed Oct 31 17:03:49 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 31 Oct 2007 12:03:49 -0500
Subject: Doxygen and multilib
In-Reply-To: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
Message-ID: <4728B575.40300@redhat.com>

Linus Walleij wrote:
> OK so I have that problem where Doxygen generates links as hashes 
> including something like a time stamp, so the -devel packages end up 
> causing multilib conflicts.
> 
> Is there some silver bullet to actually SOLVE this?
> 
> I saw that Hans solved this by tar.gz:ing up the docs and add as separate 
> source and then suppress compile-time building of the docs, replacing with 
> pre-generated contents.
> 
> Myself I simply deleted the docs for now.
> 
> I sort of believe Doxygen should be fixed to do something more 
> predictable, atleast on request.

I'd like to see that too - I took a quick look at how it generates the
hashes, and couldn't find it.  :)  But if it could be seeded with some
predictable thing based on what it's parsing, maybe it could be made
consistent?

-Eric

> Any ideas?
> 
> Linus
> 



From chris.stone at gmail.com  Wed Oct 31 17:09:54 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 31 Oct 2007 10:09:54 -0700
Subject: Doxygen and multilib
In-Reply-To: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
Message-ID: <d9c612bf0710311009j50e45251jbb845ec2e2a6e082@mail.gmail.com>

On 10/31/07, Linus Walleij <triad at df.lth.se> wrote:
> OK so I have that problem where Doxygen generates links as hashes
> including something like a time stamp, so the -devel packages end up
> causing multilib conflicts.
>
> Is there some silver bullet to actually SOLVE this?
>
> I saw that Hans solved this by tar.gz:ing up the docs and add as separate
> source and then suppress compile-time building of the docs, replacing with
> pre-generated contents.
>
> Myself I simply deleted the docs for now.
>
> I sort of believe Doxygen should be fixed to do something more
> predictable, atleast on request.
>
> Any ideas?

I created a bug this morning.

https://bugzilla.redhat.com/show_bug.cgi?id=360131



From bkonrath at redhat.com  Wed Oct 31 17:17:46 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Wed, 31 Oct 2007 13:17:46 -0400
Subject: eclipse-egit orphaned
In-Reply-To: <20071031153137.GB20269@redhat.com>
References: <1193771127.8105.2.camel@localhost.localdomain>
	<47278652.1060805@redhat.com>  <20071031153137.GB20269@redhat.com>
Message-ID: <1193851066.4959.3.camel@localhost.localdomain>


On Wed, 2007-10-31 at 11:31 -0400, Andrew Overholt wrote:
> * Anthony Green <green at redhat.com> [2007-10-30 15:30]:
> > Ben Konrath wrote:
> >> Hi, I just orphaned the eclipse-egit package. Anybody interested is more
> >> than welcome to pick it up.
> >
> > I just installed it yesterday to try it out.  Are there any inherent 
> > problems with this package?
> 
> Ben was telling me last week that it's still very much in development.
> There aren't a whole lot of GUI operations but one can import from a
> command line-checked out repository.  I really don't know much about it,
> though.

Yeah, that's about right. The biggest feature I think it's missing is
the ability to directly import from a git repo. Without this feature,
it's awkward to get started with projects hosted with git.

As far as the packaging goes, it's a fairly straight forward Eclipse
package. The only reason I orphaned it is because I'm going to have
limited access to the internet for the next 6 months and won't have time
to keep it updated.

Cheers, Ben



From mark.bidewell at alumni.clemson.edu  Wed Oct 31 17:21:01 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 31 Oct 2007 13:21:01 -0400
Subject: IcedTea Plugin not working on F8 x86_64
Message-ID: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>

The IcedTea java plugin for firefox does not seem to load on F8.  I manually
added the link in /usr/lib/mozilla/plugins but to no avail.  I notice the
plugin directory is amd64.  I am on an Intel chip.  Could this be a problem?

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/6adda646/attachment.htm>

From aph at redhat.com  Wed Oct 31 17:24:10 2007
From: aph at redhat.com (Andrew Haley)
Date: Wed, 31 Oct 2007 17:24:10 +0000
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
Message-ID: <18216.47674.929662.188785@zebedee.pink>

Mark Bidewell writes:

 > The IcedTea java plugin for firefox does not seem to load on F8.  I
 > manually added the link in /usr/lib/mozilla/plugins but to no
 > avail.  I notice the plugin directory is amd64.  I am on an Intel
 > chip.  Could this be a problem?

No, but the 64 / 32 bit difference could be.  Are you using a 32-bit
IcedTea ?  A 32-bit Mozilla ?  A 32-bit OS ?

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From jkeating at redhat.com  Wed Oct 31 17:38:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 13:38:35 -0400
Subject: KDE logout options with F8
In-Reply-To: <4728B36C.4060403@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
Message-ID: <20071031133835.0408f40c@redhat.com>

On Wed, 31 Oct 2007 22:25:08 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> This is good for the long term if it works out well. Meanwhile can we 
> please make it so that if the user unselects GNOME and selects KDE 
> explicitly in Fedora DVD image, the user gets KDM by default? I think 
> this is a very reasonable request to make. Please consider it.

Too late for Fedora 8.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/05e8bae0/attachment.sig>

From jkeating at redhat.com  Wed Oct 31 17:39:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 13:39:12 -0400
Subject: KDE logout options with F8
In-Reply-To: <4728B218.5020803@redhat.com>
References: <20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<20071031022813.GA15904@nostromo.devel.redhat.com>
	<4727ECB6.1080002@fedoraproject.org>
	<20071030230707.13c5662b@redhat.com> <4728B218.5020803@redhat.com>
Message-ID: <20071031133912.2bd11b11@redhat.com>

On Wed, 31 Oct 2007 12:49:28 -0400
Chuck Ebbert <cebbert at redhat.com> wrote:

> Shouldn't unchecking Gnome automatically uncheck gdm???

gdm isn't in the Gnome group, it's in Base-x, for reasons Bill has
posted.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/cea834b8/attachment.sig>

From pertusus at free.fr  Wed Oct 31 17:40:17 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 31 Oct 2007 18:40:17 +0100
Subject: Doxygen and multilib
In-Reply-To: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
Message-ID: <20071031174017.GB5156@free.fr>

On Wed, Oct 31, 2007 at 05:52:35PM +0100, Linus Walleij wrote:
> OK so I have that problem where Doxygen generates links as hashes including 
> something like a time stamp, so the -devel packages end up causing multilib 
> conflicts.
>
> Is there some silver bullet to actually SOLVE this?
>
> Myself I simply deleted the docs for now.

It should only be fixed for F-9, plenty of time.

> I sort of believe Doxygen should be fixed to do something more predictable, 
> atleast on request.

I filled some time ago:
https://bugzilla.redhat.com/show_bug.cgi?id=349361

--
Pat



From rdieter at math.unl.edu  Wed Oct 31 17:41:27 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 31 Oct 2007 12:41:27 -0500
Subject: IcedTea Plugin not working on F8 x86_64
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
Message-ID: <fgaeoa$u8o$1@ger.gmane.org>

Mark Bidewell wrote:

> The IcedTea java plugin for firefox does not seem to load on F8. 

Confirmed.

$ rpm -q firefox java-1.7.0-icedtea-plugin
firefox-2.0.0.8-2.fc8.x86_64
java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8.x86_64

symlinking
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so 
to
/usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
did the trick tho.

-- Rex



From jspaleta at gmail.com  Wed Oct 31 17:49:12 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 31 Oct 2007 09:49:12 -0800
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <fgaeoa$u8o$1@ger.gmane.org>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
Message-ID: <604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>

On 10/31/07, Rex Dieter <rdieter at math.unl.edu> wrote:
> symlinking
> /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so
> to
> /usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
> did the trick tho.

Was the symlink going to an outdated location or was it just missing?

-jef



From lsof at nodata.co.uk  Wed Oct 31 17:51:45 2007
From: lsof at nodata.co.uk (nodata)
Date: Wed, 31 Oct 2007 18:51:45 +0100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193791440.2818.2.camel@localhost.localdomain>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<1193791440.2818.2.camel@localhost.localdomain>
Message-ID: <1193853105.2703.4.camel@sb-home>


Am Mittwoch, den 31.10.2007, 11:44 +1100 schrieb Rodd Clarkson:
> On Tue, 2007-10-30 at 18:47 -0500, King InuYasha wrote:
> > I have had this problem since Fedora Core 4. Ever since GCJ and OOo
> > 2.0 were included in Fedora, this specific issue has cropped on my
> > computers all the time. The strange thing is that only OpenDocument
> > files are considered Java Archives. None of the other archive-based
> > formats supported by OOo have this issue as far as I can tell. 
> 
> Try this.
> 
> Right click a .odt file on the desktop (or in nautilus) and select
> properties.
> 
> Select the Open With tab and see what's in there.
> 
> I have:
> 
> [ ] Archive Manager
> [*] Word Processor

I have Archive Manager, and Java.

> 
> The Word Processor option is marked as the default.
> 
> I suspect you might have a third option and that this is marked as the
> default.  You should be able to remove this third option (since it's
> pointless)

If I manually add /usr/bin/oowriter, and select it, nautilus still tries
to open the file with Java (I still get the warning message).

> 
> R.
> 
> 
> -- 
> "It's a fine line between denial and faith.
>  It's much better on my side"
> 



From lsof at nodata.co.uk  Wed Oct 31 17:54:09 2007
From: lsof at nodata.co.uk (nodata)
Date: Wed, 31 Oct 2007 18:54:09 +0100
Subject: OOo .odt files - open with Java by default
In-Reply-To: <1193819205.31627.63.camel@Jehannum>
References: <1193772994.6165.22.camel@sb-home>
	<1193787436.31627.60.camel@Jehannum>
	<645d17210710301624x2aa02fffq4796d5895a53b1c5@mail.gmail.com>
	<8278b1b0710301647k6013b7e3kc3b0e0b56c284cd2@mail.gmail.com>
	<645d17210710301744k68b3017eg97b30345c9a37eaa@mail.gmail.com>
	<8278b1b0710302048j38202b28x7e56e3179640be30@mail.gmail.com>
	<1193819205.31627.63.camel@Jehannum>
Message-ID: <1193853249.2703.8.camel@sb-home>

Am Mittwoch, den 31.10.2007, 08:26 +0000 schrieb Caolan McNamara:
> On Tue, 2007-10-30 at 22:48 -0500, King InuYasha wrote:
> > I never install Sun Java. These problems crop up in a default Fedora
> > install for me.
> 
> Where as I have never ever ever seen it. Do you get the same error
> message of "if you open this file, the file might present a security
> risk to your system"
> 
> C.
> 

Yes. A long message.



From mark.bidewell at alumni.clemson.edu  Wed Oct 31 17:57:16 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 31 Oct 2007 13:57:16 -0400
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
Message-ID: <bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>

I think the issue is that the link is in the wrong location or the firefox
search path is incorrect.  the link was created in
/usr/lib64/mozilla/plugins not /usr/lib/firefox-2.0.0.8/plugins.  Oddly
however totem seems to load and that is in /usr/lib64/mozilla/plugins.

On 10/31/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> On 10/31/07, Rex Dieter <rdieter at math.unl.edu> wrote:
> > symlinking
> > /usr/lib/jvm/java-
> 1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so
> > to
> > /usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
> > did the trick tho.
>
> Was the symlink going to an outdated location or was it just missing?
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/ccc3cc41/attachment.htm>

From caillon at redhat.com  Wed Oct 31 17:59:32 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 31 Oct 2007 18:59:32 +0100
Subject: KDE logout options with F8
In-Reply-To: <4728B36C.4060403@fedoraproject.org>
References: <loom.20071030T224723-163@post.gmane.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>	<4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
Message-ID: <4728C284.4050305@redhat.com>

Rahul Sundaram wrote:
> I wasn't complaining to you btw. Just 
> explaining my perspective.

Which you'd already done elsewhere in the thread.  Several times.  No 
need to bring it up again, is all.  It's like you were looking for 
someone to get back into the flame war with.


>> We are looking to have a more neutral backend.  This is good for both 
>> KDE and GNOME.
> 
> This is good for the long term if it works out well. 

If your first reaction had been to ask for more information instead of 
add complaints, I might have mentioned that the plan is to have this for 
F9 (I think so at least, someone can correct me if I'm wrong?).  Not 
sure if that counts as long term...

> Meanwhile can we 
> please make it so that if the user unselects GNOME and selects KDE 
> explicitly in Fedora DVD image, the user gets KDM by default? I think 
> this is a very reasonable request to make. Please consider it.

It is a reasonable request.  Can you accept reasonable answers?  Notting 
and jkeating have already replied with technical analysis explaining why 
it is not possible.  If you have more knowledge than they do about the 
crazy way anaconda and comps works, and can refute their knowledge, 
please do on technical terms.  Note: "I, on behalf of the KDE SIG, think 
we should be able to do this" is not technical.

Besides, we already know it's not going to happen for F8.  And F9 we 
could in theory have a better all around solution....



From sundaram at fedoraproject.org  Wed Oct 31 18:00:45 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 23:30:45 +0530
Subject: KDE logout options with F8
In-Reply-To: <20071031133835.0408f40c@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com>	<4728B36C.4060403@fedoraproject.org>
	<20071031133835.0408f40c@redhat.com>
Message-ID: <4728C2CD.5020206@fedoraproject.org>

Jesse Keating wrote:
> On Wed, 31 Oct 2007 22:25:08 +0530
> Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> This is good for the long term if it works out well. Meanwhile can we 
>> please make it so that if the user unselects GNOME and selects KDE 
>> explicitly in Fedora DVD image, the user gets KDM by default? I think 
>> this is a very reasonable request to make. Please consider it.
> 
> Too late for Fedora 8.

Right. Like I said earlier in this thread, I wasn't talking about this 
release but the next one.

Rahul



From jspaleta at gmail.com  Wed Oct 31 18:05:54 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 31 Oct 2007 10:05:54 -0800
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
Message-ID: <604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>

On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> I think the issue is that the link is in the wrong location or the firefox
> search path is incorrect.  the link was created in
> /usr/lib64/mozilla/plugins
yeah that sounds like a firefox issue.

looking at /usr/bin/firefox script on my F7 install.
sorry for the line breakage on the script logic.
the relevant script logic seems to be,

if [ "$MOZ_PLUGIN_PATH" ]
then
  MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:
      $MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
else
  MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
fi
export MOZ_PLUGIN_PATH

where MOZ_LIB_DIR is ealier defined as:

MOZ_ARCH=$(uname -m)
case $MOZ_ARCH in
        x86_64 | ia64 | s390 )
                MOZ_LIB_DIR="/usr/lib64"
                SECONDARY_LIB_DIR="/usr/lib"
                ;;
        * )
                MOZ_LIB_DIR="/usr/lib"
                SECONDARY_LIB_DIR="/usr/lib64"
                ;;
esac


Is this directory calculation logic screwing up?

-jef



From myfedora at richip.dhs.org  Wed Oct 31 18:13:31 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 31 Oct 2007 12:13:31 -0600
Subject: KDE logout options with F8
In-Reply-To: <4728C284.4050305@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.4050305@redhat.com>
Message-ID: <1193854411.12145.4.camel@localhost6.localdomain6>

On Wed, 2007-10-31 at 18:59 +0100, Christopher Aillon wrote:
> It is a reasonable request.  Can you accept reasonable answers?  Notting 
> and jkeating have already replied with technical analysis explaining why 
> it is not possible.  If you have more knowledge than they do about the 
> crazy way anaconda and comps works, and can refute their knowledge, 
> please do on technical terms.  Note: "I, on behalf of the KDE SIG, think 
> we should be able to do this" is not technical.

I'd like to make a request to the KDE-SIG folks to please review this
thread, specifically looking for Notting's and jkeating's technical
analysis for why it can't be done and put it on the KDE-SIG wiki for
future review? As much as I'd like to figure out what can and can't be
done, I don't want to go through that whole thread (I just automatically
deleted mail with the Subject title).

Personally, I like and use Gnome and have no intention of using KDE, but
I believe that Fedora should be about giving people the choice to do
what they want and that Fedora's inclination in a split-decision should
only show in the choice of defaults and not what is and isn't allowed.
--

Richi Plana



From mark.bidewell at alumni.clemson.edu  Wed Oct 31 18:18:08 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 31 Oct 2007 14:18:08 -0400
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
Message-ID: <bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>

I wind up with a MOZ_PLUGIN_PATH path of:

/usr/lib64/mozilla/plugins-wrapped:/usr/lib64/firefox-
2.0.0.8/plugins-wrapped

/usr/lib64/firefox-2.0.0.8/plugins-wrapped doesn't exist so
/usr/lib64/firefox-2.0.0.8/plugins must be hardcoded.

The F8 logic is:
##
## Make sure that we set the plugin path
##
if [ "$MOZ_PLUGIN_PATH" ]
then

MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR
else

MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR
fi
export MOZ_PLUGIN_PATH

MOZ_LIB_DIR being defined as in F7.


Mark Bidewell

On 10/31/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > I think the issue is that the link is in the wrong location or the
> firefox
> > search path is incorrect.  the link was created in
> > /usr/lib64/mozilla/plugins
> yeah that sounds like a firefox issue.
>
> looking at /usr/bin/firefox script on my F7 install.
> sorry for the line breakage on the script logic.
> the relevant script logic seems to be,
>
> if [ "$MOZ_PLUGIN_PATH" ]
> then
>   MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:
>       $MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
> else
>   MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
> fi
> export MOZ_PLUGIN_PATH
>
> where MOZ_LIB_DIR is ealier defined as:
>
> MOZ_ARCH=$(uname -m)
> case $MOZ_ARCH in
>         x86_64 | ia64 | s390 )
>                 MOZ_LIB_DIR="/usr/lib64"
>                 SECONDARY_LIB_DIR="/usr/lib"
>                 ;;
>         * )
>                 MOZ_LIB_DIR="/usr/lib"
>                 SECONDARY_LIB_DIR="/usr/lib64"
>                 ;;
> esac
>
>
> Is this directory calculation logic screwing up?
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/58a96580/attachment.htm>

From sundaram at fedoraproject.org  Wed Oct 31 18:15:38 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 31 Oct 2007 23:45:38 +0530
Subject: KDE logout options with F8
In-Reply-To: <4728C284.4050305@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>	<4728B0E4.2050209@redhat.com>	<4728B36C.4060403@fedoraproject.org>
	<4728C284.4050305@redhat.com>
Message-ID: <4728C64A.9080602@fedoraproject.org>

Christopher Aillon wrote:
> Rahul Sundaram wrote:
>> I wasn't complaining to you btw. Just explaining my perspective.
> 
> Which you'd already done elsewhere in the thread.  Several times.  No 
> need to bring it up again, is all.  It's like you were looking for 
> someone to get back into the flame war with.

I have no such motivations or hidden agendas. Period. When I am accused 
I am merely forced to ask why, defend myself and explain the details. If 
anyone still thinks  so, please explain to me why offlist and let's 
stick to the relevant discussion here.

> If your first reaction had been to ask for more information instead of 
> add complaints, I might have mentioned that the plan is to have this for 
> F9 (I think so at least, someone can correct me if I'm wrong?).  Not 
> sure if that counts as long term...

If the plan is to have this for Fedora 9, that information could have 
neutered this thread long back. No one said that so far.

> It is a reasonable request.  Can you accept reasonable answers?  Notting 
> and jkeating have already replied with technical analysis explaining why 
> it is not possible.  If you have more knowledge than they do about the 
> crazy way anaconda and comps works, and can refute their knowledge, 
> please do on technical terms.  Note: "I, on behalf of the KDE SIG, think 
> we should be able to do this" is not technical.

I personally requested this and not on the behalf of the KDE SIG but KDE 
SIG themselves have said they wanted this as has been pointed earlier in 
the thread and I have already replied in detail on what could be done 
earlier and there has more information posted from others on how to work 
this out technically. In case, it was not clear, move GDM to the GNOME 
group. XDM should be in the Xorg group. If anyone installs just the Xorg 
group, it is a corner case and we don't have to worry about them getting 
  XDM and TWM. Yes, both are ugly, lack functionality etc but power 
users doing such things can afford to deal with this. It brings in 
better functionality and integration for both GNOME and KDE users which 
is the large majority of desktop users.

> Besides, we already know it's not going to happen for F8.  And F9 we 
> could in theory have a better all around solution....

Let's see.

Rahul



From jspaleta at gmail.com  Wed Oct 31 18:24:46 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 31 Oct 2007 10:24:46 -0800
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
	<bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
Message-ID: <604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>

On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> MOZ_LIB_DIR being defined as in F7.
So its the new $MOZ_PLUGIN_DIR definition that is causing the problem here.

Is -wrapped something 64bit specific? Or is plugins-wrapped always
going to be available on all arches?  I wonder if there are any other
plugin packages which actually get burned by the change in plugin
path.

-jef



From myfedora at richip.dhs.org  Wed Oct 31 18:44:48 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 31 Oct 2007 12:44:48 -0600
Subject: NFS Update and SELinux
Message-ID: <1193856288.12145.9.camel@localhost6.localdomain6>

Hi,

On F7, the latest nfs-utils update (1:1.1.0-4.fc7.x86_64) seems to be
resulting in a lot of SELinux denials (accesses to /dev/usbmon?).

Not knowing what to do next, I thought I'd ask at fedora-devel. Is there
something I should do that I'm not (ie. rebooting, restarting some
daemon, restorecon)? Is this a bug in nfs-utils?
selinux-policy-targeted? Is this some malicious software update?

I could use a little help in troubleshooting.
--

Richi Plana



From mark.bidewell at alumni.clemson.edu  Wed Oct 31 18:47:10 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 31 Oct 2007 14:47:10 -0400
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
	<bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
	<604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
Message-ID: <bfdeacfa0710311147p2db5a745ja23c115ec41480@mail.gmail.com>

I'm just guessing but it would seem logical that plugins-wrapped contains 32
to 64 bit wrappers.

On 10/31/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > MOZ_LIB_DIR being defined as in F7.
> So its the new $MOZ_PLUGIN_DIR definition that is causing the problem
> here.
>
> Is -wrapped something 64bit specific? Or is plugins-wrapped always
> going to be available on all arches?  I wonder if there are any other
> plugin packages which actually get burned by the change in plugin
> path.
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/39bda99d/attachment.htm>

From kevin.kofler at chello.at  Wed Oct 31 18:49:55 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 31 Oct 2007 18:49:55 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<4727E818.8020202@fedoraproject.org>	<1193797979.11243.11.camel@localhost.localdomain>	<4727EBED.4020909@fedoraproject.org>	<1193799384.11243.21.camel@localhost.localdomain>	<4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	
	<4727F17D.2090305@fedoraproject.org>	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>	<4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!
	5@redhat.com>
Message-ID: <loom.20071031T182928-261@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> If your first reaction had been to ask for more information instead of 
> add complaints, I might have mentioned that the plan is to have this for 
> F9 (I think so at least, someone can correct me if I'm wrong?).  Not 
> sure if that counts as long term...

Even if somebody implements a KDE frontend for the GDM backend, that won't make 
KDM go away. There's no way KDM is going away for KDE 4.0 which realistically 
will be what F9 will be shipping. (And of course, it's even less likely that 
said thing would happen in 3.5. Chances that KDE 4.1 will be anywhere near 
ready at F9 release are essentially nil, 4.1 might quite possibly not even make 
F10.)

> It is a reasonable request.  Can you accept reasonable answers?  Notting 
> and jkeating have already replied with technical analysis explaining why 
> it is not possible.

I have suggested at least 2 technical solutions, none of which needs any 
changes to Anaconda:
1. revert the default login manager in Base X to XDM. As much as you 
(plural "you") hate that, it's the most logical solution and some other people 
in this thread are defending it too.
2. change the fallback logic to pick KDM over GDM. As I said, I think we can 
easily put KDM in a subpackage so it doesn't accidentally get installed by a 
dependency on kdebase, kde-redhat used to do that in FC6 times.

There's another one, which is even less invasive (and doesn't change the 
behavior for the neither-GNOME-nor-KDE case as 1. nor for the 
both-GNOME-and-KDE case as 2., but really only affects KDE-but-not-GNOME which 
is what needs fixing), but has to be implemented as a specialized Anaconda 
hack. Pseudocode:
if (! upgrade && KDE selected && ! GNOME selected)
  echo 'DISPLAYMANAGER="KDE"' >/mnt/sysimage/etc/sysconfig/desktop

> Besides, we already know it's not going to happen for F8.  And F9 we 
> could in theory have a better all around solution....

"better" is subjective. If upstream KDE isn't going to drop KDM or recommend 
against it, IMHO that fact shouldn't be ignored.

        Kevin Kofler



From jkeating at redhat.com  Wed Oct 31 18:59:33 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 31 Oct 2007 14:59:33 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071031T182928-261@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!
	5@redhat.com> <loom.20071031T182928-261@post.gmane.org>
Message-ID: <20071031145933.18929ef2@redhat.com>

On Wed, 31 Oct 2007 18:49:55 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> I have suggested at least 2 technical solutions, none of which needs
> any changes to Anaconda:
> 1. revert the default login manager in Base X to XDM. As much as you 
> (plural "you") hate that, it's the most logical solution and some
> other people in this thread are defending it too.
> 2. change the fallback logic to pick KDM over GDM. As I said, I think
> we can easily put KDM in a subpackage so it doesn't accidentally get
> installed by a dependency on kdebase, kde-redhat used to do that in
> FC6 times.

Both of these changes take time to do, and time to recompose trees to
make the release out of, and likely would lead to a slip of the Fedora
8 release.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/f919f55c/attachment.sig>

From notting at redhat.com  Wed Oct 31 19:21:32 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 31 Oct 2007 15:21:32 -0400
Subject: KDE logout options with F8
In-Reply-To: <47280CB7.5030400@lex.hider.name>
References: <1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
	<47280CB7.5030400@lex.hider.name>
Message-ID: <20071031192132.GB27461@nostromo.devel.redhat.com>

lexual (floss at lex.hider.name) said: 
> Kubuntu guys may have a patch?
> https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/64695
>
> Do you have link to KDE bug, because I couldn't find any gdm mentions in 
> kde bugzilla.

http://bugs.kde.org/show_bug.cgi?id=149045

Bill



From notting at redhat.com  Wed Oct 31 19:25:43 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 31 Oct 2007 15:25:43 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071031T044300-453@post.gmane.org>
References: <1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<20071031023210.GB15904@nostromo.devel.redhat.com>
	<4727E9C1.6010906@fedoraproject.org>
	<20071031024944.GA22292@nostromo.devel.redhat.com>
	<4727EECD.2080808@fedoraproject.org>
	<20071031030743.GA23453@nostromo.devel.redhat.com>
	<4727F1B3.80700@fedoraproject.org>
	<20071031031301.GA23887@nostromo.devel.redhat.com>
	<loom.20071031T044300-453@post.gmane.org>
Message-ID: <20071031192543.GC27461@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> > - You're interested in pushing a different agenda
> 
> The "agenda" he is "pushing" is the position of several KDE SIG members and the 
> closest thing to an official KDE SIG position you'll get unless you want us to 
> hold a vote.

Right. All I was saying is that I was interested in solving the bug being
referenced; I don't think it was unfair to say that Rahul was advocating
something else.

>From a practical standpoint, I don't see how this is easily fixable. On a
broader scale, the combination of choosing KDE + multimedia, or KDE + office,
isn't going to get you the same package set as the KDE livecd either, and
that really can't be fixed in the comps file.

Shipping xdm as a default anywhere doesn't make sense because of the large amounts of
functionality you lose (including being able to actually pick different sessions,
whether they be KDE, GNOME, XFCE, fluxbox, etc.). So, I would say that GDM should
remain the default in base-X. In the case where the user installs just KDE, they
can just check off gdm under X, and the right thing should happen.

Bill



From tibbs at math.uh.edu  Wed Oct 31 19:53:31 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 31 Oct 2007 14:53:31 -0500
Subject: Summary of the 2007-10-30 Packaging Committee meeting
Message-ID: <ufa3avrysas.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the packaging committee meeting which
occurred on 2007-10-30 are online:

http://fedoraproject.org/wiki/Packaging/Minutes
http://fedoraproject.org/wiki/Packaging/Minutes20071030

Executive summary:

No new guidelines this week.

Issues pending FESCO ratification:

* Standardizing the set of virtual provides for various servers:
  http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
  * Accepted (5 - 0)
  * Voting for: spot rdieter abadger1999 tibbs f13
  * There is still tweaking to be done, and because this will require
    changes to several packages, FPC is asking that this be driven via
    the feature process for F-9.

* Specifying the location for FORTRAN 90 .mod files:
   http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
  * Accepted (5 - 0)
  * Voting for: spot rdieter f13 abadger1999 tibbs

Misc business:
 * FPC discussed the acceptability of metapackages.  The opinions of
   FESCo and other interested parties are welcomed here.

 - J<



From notting at redhat.com  Wed Oct 31 19:54:47 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 31 Oct 2007 15:54:47 -0400
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
	<bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
	<604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
Message-ID: <20071031195447.GD27461@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > MOZ_LIB_DIR being defined as in F7.
> So its the new $MOZ_PLUGIN_DIR definition that is causing the problem here.
> 
> Is -wrapped something 64bit specific? Or is plugins-wrapped always
> going to be available on all arches?  I wonder if there are any other
> plugin packages which actually get burned by the change in plugin
> path.

plugins-wrapped is searched if nspluginwrapper is installed. I suspect
running 'mozilla-plugin-config -i -f' (as root) would fix the original
issue.

Bill



From notting at redhat.com  Wed Oct 31 20:00:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 31 Oct 2007 16:00:15 -0400
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <ufa3avrysas.fsf@epithumia.math.uh.edu>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
Message-ID: <20071031200015.GF27461@nostromo.devel.redhat.com>

Jason L Tibbitts III (tibbs at math.uh.edu) said: 
> * Standardizing the set of virtual provides for various servers:
>   http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
>   * Accepted (5 - 0)
>   * Voting for: spot rdieter abadger1999 tibbs f13
>   * There is still tweaking to be done, and because this will require
>     changes to several packages, FPC is asking that this be driven via
>     the feature process for F-9.

Changing these concerns me - what about not-built-in-Fedora packages that
have the old dependencies?

Bill



From nando at ccrma.Stanford.EDU  Wed Oct 31 20:02:28 2007
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Wed, 31 Oct 2007 13:02:28 -0700
Subject: linux1394 and f8
In-Reply-To: <4728951F.6080007@hhs.nl>
References: <47288307.7060306@nostar.net>
	<5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
	<1193840839.14742.18.camel@localhost.localdomain>
	<4728951F.6080007@hhs.nl>
Message-ID: <1193860948.11912.12.camel@cmn3.stanford.edu>

On Wed, 2007-10-31 at 15:45 +0100, Hans de Goede wrote:
> Will Woods wrote:
> > On Wed, 2007-10-31 at 13:46 +0000, Peter Robinson wrote:
> >>> I am running 7.92, and I see that the new firewire stack is in place.
> >>> There is a page at the linux1394 wiki that suggests that kernel
> >>> packagers build the old stack into the kernel for the time being:
> >>>
> >>> http://wiki.linux1394.org/JujuMigration
> >>>
> >>> Any chance of this happenign for Fedora 8?
> > 
> > Short answer: No. We've been using the Juju stack since F7 and we're not
> > moving back, 'cuz Cutting Edge is what we're all about. But see below. 
> > 
> >> Right below where it says the best advise is to use the old drivers it
> >> also says :
> >>
> >> Building the new drivers is only for advanced users (who for example
> >> want the better speed of firewire-sbp2 relative to sbp2, on the
> >> hardware on which the new drivers already work) - and for distributors
> >> who know what is required in userspace to make use of the new drivers
> >> (i.e. a patched libraw1394, a libdc1394 prerelease, adapted scripts
> >> and config files etc.).
> >>
> >> I suspect "distributors who know what is required in userspace" covers
> >> Fedora and hence the required patches are probably all there.
> > 
> > Right. Kristian H?gsberg is the primary author of the Juju stack - he's
> > a Red Hat employee and Fedora contributor. He got all the Juju bits into
> > F7 - the "new firewire stack" has been in place since then.
> > 
> > So nothing's really new for firewire in F8. The only noticeable changes
> > since F7 are some bugfixes, and some changes relating to dvgrab,
> > libraw1394 and isochronous devices (basically cameras and other
> > audio/video devices). 
> > 
> > Iso devices should work everywhere *except* machines with OHCI 1.0
> > controllers. Otherwise you get this message in dmesg:
> > 
> > firewire_ohci: Added fw-ohci device 0000:03:03.0, OHCI version 1.0
> > firewire_ohci:     Isochronous I/O is not yet implemented for OHCI 1.0
> > chips.
> > firewire_ohci:     Cameras, audio devices etc. won't work on this
> > controller with this driver version.
> > 
> > Unfortunately, these turn out to be more common than previously thought.
> > But people are actively working on this problem - see this bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=Juju_OHCI_1.0
> > 
> > It's possible this will be fixed in an F8 update. It's quite likely to
> > be fixed for Fedora 9. If that's not soon enough, I'm told there's some
> > third-party repositories out there that package up the older stack.
> 
> Correct, most notably planet ccrma (AFAIK)

Yup. The Planet CCRMA realtime kernels had to revert to the old stack
(and as a result I have to track and supercede libraw1394 releases from
Fedora - not good). Non functioning firewire audio interfaces are a bit
of a problem if you do audio. 

-- Fernando




From pertusus at free.fr  Wed Oct 31 20:20:38 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 31 Oct 2007 21:20:38 +0100
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <20071031200015.GF27461@nostromo.devel.redhat.com>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
	<20071031200015.GF27461@nostromo.devel.redhat.com>
Message-ID: <20071031202038.GA23272@free.fr>

On Wed, Oct 31, 2007 at 04:00:15PM -0400, Bill Nottingham wrote:
> Jason L Tibbitts III (tibbs at math.uh.edu) said: 
> > * Standardizing the set of virtual provides for various servers:
> >   http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
> >   * Accepted (5 - 0)
> >   * Voting for: spot rdieter abadger1999 tibbs f13
> >   * There is still tweaking to be done, and because this will require
> >     changes to several packages, FPC is asking that this be driven via
> >     the feature process for F-9.

I am not sure that it is needed. My plan would be to propose patches for
the package spec files to have them Provides server(smtp) and when it is
ready for all, provide patches for the dependent packages. The Provides
is already removed from ssmtp, so this only makes 4+4 packages to
modify, that seems to me not to require to set up a features page.

I would like to have it done way before F-9, and even before the alpha.

I am not violently against going through the features process, but I
don't think that this is needed here.

> Changing these concerns me - what about not-built-in-Fedora packages that
> have the old dependencies?

My proposal is to keep the old dependencies as Provides as long as we
want backward compatibility (at least in F-9), but don't add more, and 
also set all the Requires according to the proposal.

--
Pat



From buildsys at fedoraproject.org  Wed Oct 31 20:39:46 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Wed, 31 Oct 2007 16:39:46 -0400 (EDT)
Subject: Package EVR problems in Fedora 2007-10-31
Message-ID: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8

andreas bierfert AT lowlatency de:
    rxvt-unicode
      F7-updates > F8 (0:8.4-1.fc7 > 0:8.3-1.fc8)
    
    wine
      F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)
    
    wine-docs
      F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)
    
aportal AT univ-montp2 fr:
    gputils
      FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)
      FE6 > F8 (0:0.13.5-1.fc6 > 0:0.13.4-4.fc8)
    
    kbackup
      FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
      FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)
    
    pikloops
      FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)
    
bjohnson AT symetrix com:
    gscan2pdf
      FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)
      FE6 > F8 (0:0.9.17-2.fc6 > 0:0.9.16-1.fc8)
    
    libsieve
      FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
      FE6 > F8 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
    
    perl-PDF-API2
      FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)
      FE6 > F8 (0:0.65-1.fc6 > 0:0.62-2.fc8)
    
cgoorah AT yahoo com au:
    kdmtheme
      FE6 > F8 (0:1.2.1-1.fc6 > 0:1.1.3-2.fc8)
      F7-updates > F8 (0:1.2.1-1.fc7 > 0:1.1.3-2.fc8)
    
    piklab
      FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
      FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)
    
    toped
      F7-updates > F8 (0:0.8.6-1.fc7 > 0:0.8.5-2.fc8)
    
    xcircuit
      FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
      F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)
    
chris stone AT gmail com:
    cksfv
      FE6 > F8 (0:1.3.12-2.fc6 > 0:1.3.12-1.fc8)
      F7-updates > F8 (0:1.3.12-2.fc7 > 0:1.3.12-1.fc8)
    
    poker-network
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)
    
    poker2d
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)
    
cweyl AT alumni drew edu:
    Zim
      FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
      F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
esandeen AT redhat com:
    xfsprogs
      FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)
    
foolish AT guezz net:
    gtk-recordmydesktop
      F7-updates > F8 (0:0.3.6-1.fc7.1 > 0:0.3.4-1.fc8.1)
    
    gtranslator
      F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)
    
    recordmydesktop
      F7-updates > F8 (0:0.3.6-1.fc7 > 0:0.3.4-1.fc8)
    
frank-buettner AT gmx net:
    ctapi-cyberjack
      FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
      F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)
    
gauret AT free fr:
    basket
      F7-updates > F8 (0:1.0.2-3.fc7 > 0:1.0.2-2.fc8)
    
gecko-maint AT redhat com:
    seamonkey
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)
    
gemi AT bluewin ch:
    q
      F7-updates > F8 (0:7.8-1.fc7 > 0:7.6-2.fc7)
    
    yap
      F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
i AT stingr net:
    weechat
      F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
jkeating AT redhat com:
    mock
      F7-updates > F8 (0:0.8.4-2.fc7 > 0:0.7.6-1.fc8)
    
john AT ncphotography com:
    bugzilla
      FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
      FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
lemenkov AT gmail com:
    flashrom
      FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)
      FE6 > F8 (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc8)
    
    fuse-python
      FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
      F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)
    
lxtnow AT gmail com:
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
    wammu
      FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
      F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)
    
mfleming+rpm AT enlartenment com:
    mcabber
      FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)
      FE6 > F8 (0:0.9.4-1.fc6 > 0:0.9.3-6.fc8)
    
    mlmmj
      FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)
    
michel sylvan AT gmail com:
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)
    
    nagios-plugins
      FE6 > F7-updates (0:1.4.8-9.fc6 > 0:1.4.8-4.fc7)
      FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)
    
    phpMyAdmin
      FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)
      F7-updates > F8 (0:2.11.1.2-1.fc7 > 0:2.11.0-1.fc8)
    
    python-meld3
      FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
      FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
    
    smolt
      FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
      FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)
    
mtasaka AT ioa s u-tokyo ac jp:
    kazehakase
      FE6 > F8 (0:0.5.0-1.fc6 > 0:0.4.9-2.svn3312.fc8)
      F7-updates > F8 (0:0.5.0-1.fc7 > 0:0.4.9-2.svn3312.fc8)
    
    mirage
      FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
      F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
ondrejj AT salstar sk:
    climm
      FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
      F7-updates > F8 (0:0.6.1-1.fc7 > 0:0.6-2.fc8)
    
packages AT amiga-hardware com:
    kdetv
      FE6 > F8 (0:0.8.9-7.fc6 > 0:0.8.9-6.fc8)
      F7-updates > F8 (0:0.8.9-7.fc7 > 0:0.8.9-6.fc8)
    
    SILLY
      FE6 > F8 (0:0.1.0-4.fc6 > 0:0.1.0-3.fc8)
      F7-updates > F8 (0:0.1.0-4.fc7 > 0:0.1.0-3.fc8)
    
pingoufc4 AT yahoo fr:
    rkward
      FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
      FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)
    
rc040203 AT freenet de:
    perl-File-NCopy
      F7-updates > F8 (0:0.35-3.fc7 > 0:0.34-6.fc8)
    
rcritten AT redhat com:
    mod_nss
      FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
      F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)
    
rmeggins AT redhat com:
    adminutil
      FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)
    
    mozldap
      FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
      F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
roland AT redhat com:
    monotone
      FE6 > F7 (0:0.37-2.fc6 > 0:0.35-3.fc7)
      FE6 > F8 (0:0.37-2.fc6 > 0:0.36-2.fc8)
    
s adam AT diffingo com:
    fwfstab
      FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
      F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
tagoh AT redhat com:
    anthy
      F7-updates > F8 (0:9100d-1.fc7 > 0:9100b-1.fc8)
    
    ruby
      F7-updates > F8 (0:1.8.6.111-1.fc7 > 0:1.8.6.110-2.fc8)
    
----------------------------------------------------------------------

adminutil: rmeggins AT redhat com
  FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)

anthy: tagoh AT redhat com
  F7-updates > F8 (0:9100d-1.fc7 > 0:9100b-1.fc8)

basket: gauret AT free fr
  F7-updates > F8 (0:1.0.2-3.fc7 > 0:1.0.2-2.fc8)

bugzilla: john AT ncphotography com
  FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
  FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)

cksfv: chris stone AT gmail com
  FE6 > F8 (0:1.3.12-2.fc6 > 0:1.3.12-1.fc8)
  F7-updates > F8 (0:1.3.12-2.fc7 > 0:1.3.12-1.fc8)

climm: ondrejj AT salstar sk
  FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
  F7-updates > F8 (0:0.6.1-1.fc7 > 0:0.6-2.fc8)

ctapi-cyberjack: frank-buettner AT gmx net
  FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
  F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

flashrom: lemenkov AT gmail com
  FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)
  FE6 > F8 (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc8)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

fuse-python: lemenkov AT gmail com
  FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
  F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)

fwfstab: s adam AT diffingo com
  FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
  F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)

gputils: aportal AT univ-montp2 fr
  FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)
  FE6 > F8 (0:0.13.5-1.fc6 > 0:0.13.4-4.fc8)

gscan2pdf: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)
  FE6 > F8 (0:0.9.17-2.fc6 > 0:0.9.16-1.fc8)

gtk-recordmydesktop: foolish AT guezz net
  F7-updates > F8 (0:0.3.6-1.fc7.1 > 0:0.3.4-1.fc8.1)

gtranslator: foolish AT guezz net
  F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

kazehakase: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.5.0-1.fc6 > 0:0.4.9-2.svn3312.fc8)
  F7-updates > F8 (0:0.5.0-1.fc7 > 0:0.4.9-2.svn3312.fc8)

kbackup: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
  FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)

kdetv: packages AT amiga-hardware com
  FE6 > F8 (0:0.8.9-7.fc6 > 0:0.8.9-6.fc8)
  F7-updates > F8 (0:0.8.9-7.fc7 > 0:0.8.9-6.fc8)

kdmtheme: cgoorah AT yahoo com au
  FE6 > F8 (0:1.2.1-1.fc6 > 0:1.1.3-2.fc8)
  F7-updates > F8 (0:1.2.1-1.fc7 > 0:1.1.3-2.fc8)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libsieve: bjohnson AT symetrix com
  FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
  FE6 > F8 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mcabber: mfleming+rpm AT enlartenment com
  FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)
  FE6 > F8 (0:0.9.4-1.fc6 > 0:0.9.3-6.fc8)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

mirage: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
  F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)

mlmmj: mfleming+rpm AT enlartenment com
  FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)

mock: jkeating AT redhat com
  F7-updates > F8 (0:0.8.4-2.fc7 > 0:0.7.6-1.fc8)

mod_nss: rcritten AT redhat com
  FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
  F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)

monotone: roland AT redhat com
  FE6 > F7 (0:0.37-2.fc6 > 0:0.35-3.fc7)
  FE6 > F8 (0:0.37-2.fc6 > 0:0.36-2.fc8)

mozldap: rmeggins AT redhat com
  FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
  F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)

nagios-plugins: mmcgrath AT redhat com
  FE6 > F7-updates (0:1.4.8-9.fc6 > 0:1.4.8-4.fc7)
  FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

perl-File-NCopy: rc040203 AT freenet de
  F7-updates > F8 (0:0.35-3.fc7 > 0:0.34-6.fc8)

perl-PDF-API2: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)
  FE6 > F8 (0:0.65-1.fc6 > 0:0.62-2.fc8)

phpMyAdmin: mmcgrath AT redhat com
  FE6 > F8 (0:2.11.1.2-1.fc6 > 0:2.11.0-1.fc8)
  F7-updates > F8 (0:2.11.1.2-1.fc7 > 0:2.11.0-1.fc8)

piklab: cgoorah AT yahoo com au
  FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
  FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)

poker-network: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)

poker2d: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-meld3: mmcgrath AT redhat com
  FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
  FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

q: gemi AT bluewin ch
  F7-updates > F8 (0:7.8-1.fc7 > 0:7.6-2.fc7)

recordmydesktop: foolish AT guezz net
  F7-updates > F8 (0:0.3.6-1.fc7 > 0:0.3.4-1.fc8)

rkward: pingoufc4 AT yahoo fr
  FE6 > F7-updates (0:0.4.8-2.fc6 > 0:0.4.7-4.fc7)
  FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)

ruby: tagoh AT redhat com
  F7-updates > F8 (0:1.8.6.111-1.fc7 > 0:1.8.6.110-2.fc8)

rxvt-unicode: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:8.4-1.fc7 > 0:8.3-1.fc8)

seamonkey: gecko-maint AT redhat com
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)

SILLY: packages AT amiga-hardware com
  FE6 > F8 (0:0.1.0-4.fc6 > 0:0.1.0-3.fc8)
  F7-updates > F8 (0:0.1.0-4.fc7 > 0:0.1.0-3.fc8)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
  FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

toped: cgoorah AT yahoo com au
  F7-updates > F8 (0:0.8.6-1.fc7 > 0:0.8.5-2.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

wammu: lxtnow AT gmail com
  FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
  F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)

weechat: i AT stingr net
  F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)

wine: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)

wine-docs: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)

xcircuit: cgoorah AT yahoo com au
  FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
  F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)

xfsprogs: esandeen AT redhat com
  FC6-updates > F7-updates (0:2.9.3-1.fc6 > 0:2.8.21-1.fc7)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

yap: gemi AT bluewin ch
  F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)

Zim: cweyl AT alumni drew edu
  FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
  F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From a.badger at gmail.com  Wed Oct 31 20:52:59 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 31 Oct 2007 13:52:59 -0700
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <20071031200015.GF27461@nostromo.devel.redhat.com>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
	<20071031200015.GF27461@nostromo.devel.redhat.com>
Message-ID: <4728EB2B.7070102@gmail.com>

Bill Nottingham wrote:
> Jason L Tibbitts III (tibbs at math.uh.edu) said: 
>> * Standardizing the set of virtual provides for various servers:
>>   http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
>>   * Accepted (5 - 0)
>>   * Voting for: spot rdieter abadger1999 tibbs f13
>>   * There is still tweaking to be done, and because this will require
>>     changes to several packages, FPC is asking that this be driven via
>>     the feature process for F-9.
> 
> Changing these concerns me - what about not-built-in-Fedora packages that
> have the old dependencies?
> 

Should we change this:
'''
In my opinion (PatriceDumas) the choice to remove the smtpdaemon virtual 
provides in Provides or leave it for backward compatibility should be 
left to the maintainer. All the Requires should be changed, however.
'''
to be more definite?  Maybe:

'''
When you implement the new Provides, please leave the old ones so that 
third party packages that have grown to depend on them can continue to 
function.  The Requires for all Fedora packages should be changed to use 
the new provides by F-9, however.
'''

-Toshio



From ville.skytta at iki.fi  Wed Oct 31 20:55:58 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 31 Oct 2007 22:55:58 +0200
Subject: Rebuild sysprof-kmod for final kernel
In-Reply-To: <1193830981.9762.4.camel@localhost.localdomain>
References: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>
	<1193830981.9762.4.camel@localhost.localdomain>
Message-ID: <200710312255.58489.ville.skytta@iki.fi>

On Wednesday 31 October 2007, Lubomir Kundrak wrote:
> Hi,
>
> On Wed, 2007-10-31 at 11:07 +0100, Gianluca Sforna wrote:
> > I tried to rebuild sysprof-kmod for the f8 release, but it failed with:
> >
> > Checking for unpackaged file(s): /usr/lib/rpm/check-files
> > /var/tmp/sysprof-kmod-1.0.8-1.2.6.23.1_41.fc8-root-kojibuilder
> > error: Installed (but unpackaged) file(s) found:
> >    /lib/modules/2.6.23.1-41.fc8/modules.alias
> >    /lib/modules/2.6.23.1-41.fc8/modules.ccwmap
> >    /lib/modules/2.6.23.1-41.fc8/modules.dep
> >    /lib/modules/2.6.23.1-41.fc8/modules.ieee1394map
> >    /lib/modules/2.6.23.1-41.fc8/modules.inputmap
> >    /lib/modules/2.6.23.1-41.fc8/modules.isapnpmap
> >    /lib/modules/2.6.23.1-41.fc8/modules.ofmap
> >    /lib/modules/2.6.23.1-41.fc8/modules.pcimap
> >    /lib/modules/2.6.23.1-41.fc8/modules.seriomap
> >    /lib/modules/2.6.23.1-41.fc8/modules.symbols
> >    /lib/modules/2.6.23.1-41.fc8/modules.usbmap
> >
> > These was not created before, so I'm not sure if they have to be
> > packaged, removed, ghosted or...
>
> I'd remove them, possibly with %exclude. It is the responsibility of
> scriptlets added by kmodtool to calculate the module dependencies, these
> files are unusable anyways.

They are generated because kernel-devel packages in F-8 include System.map, 
see Makefile in the source tree for details.  I chose to explicitly disable 
depmod during build (which is what generates those files) in em8300-kmod, I 
think that's a cleaner approach, and matches what actually happens in earlier 
distros.

http://cvs.fedora.redhat.com/viewcvs/rpms/em8300-kmod/F-8/em8300-kmod.spec?r1=1.42&r2=1.43&makepatch=1&diff_format=h



From pertusus at free.fr  Wed Oct 31 21:06:07 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 31 Oct 2007 22:06:07 +0100
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <4728EB2B.7070102@gmail.com>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
	<20071031200015.GF27461@nostromo.devel.redhat.com>
	<4728EB2B.7070102@gmail.com>
Message-ID: <20071031210606.GC23272@free.fr>

On Wed, Oct 31, 2007 at 01:52:59PM -0700, Toshio Kuratomi wrote:
> to be more definite?  Maybe:
>
> '''
> When you implement the new Provides, please leave the old ones so that 
> third party packages that have grown to depend on them can continue to 
> function.  The Requires for all Fedora packages should be changed to use 
> the new provides by F-9, however.
> '''

Very nice.

--
Pat



From ville.skytta at iki.fi  Wed Oct 31 21:07:35 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 31 Oct 2007 23:07:35 +0200
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <4728EB2B.7070102@gmail.com>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
	<20071031200015.GF27461@nostromo.devel.redhat.com>
	<4728EB2B.7070102@gmail.com>
Message-ID: <200710312307.35851.ville.skytta@iki.fi>

On Wednesday 31 October 2007, Toshio Kuratomi wrote:
> '''
> When you implement the new Provides, please leave the old ones so that
> third party packages that have grown to depend on them can continue to
> function.  The Requires for all Fedora packages should be changed to use
> the new provides by F-9, however.
> '''

I think using the same backwards compatibility recommendations as in naming 
guidelines' renaming/replacing existing packages section would work fine.

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d



From mschwendt.tmp0701.nospam at arcor.de  Wed Oct 31 21:13:55 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 31 Oct 2007 22:13:55 +0100
Subject: rpms/postgis/FC-6 postgis.spec,1.7,1.8
In-Reply-To: <200710292258.l9TMwTxx005376@cvs-int.fedora.redhat.com>
References: <200710292258.l9TMwTxx005376@cvs-int.fedora.redhat.com>
Message-ID: <20071031221355.b3d276bc.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 29 Oct 2007 18:58:29 -0400, Devrim G?ND?Z (devrim) wrote:

> Author: devrim
> 
> Update of /cvs/extras/rpms/postgis/FC-6

> +++ postgis.spec	29 Oct 2007 22:57:51 -0000	1.8
> @@ -1,6 +1,6 @@
> -%{!?javabuild:%define	javabuild 1}
> +%{!?javabuild:%define	javabuild 0}

This is a sub-package switch, which must not be (ab)used to toggle
sub-packages on and off randomly. If there's nothing in the guidelines
already, it would make sense to enhance them.

Once you've built and published a sub-package, you need to obsolete it
when you want to publish an update where the sub-package is not built
anymore. Here "Obsoletes: postgis-jdbc < 1.3.1".



From buildsys at fedoraproject.org  Wed Oct 31 21:21:11 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Wed, 31 Oct 2007 17:21:11 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-10-31
Message-ID: <20071031212111.669F215212F@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 14

    dbmail-2.2.7-1.fc6
    gnome-libs-1.4.2-7.fc6
NEW gt5-1.4.0-4.fc6 : A diff-capable 'du-browser'
    mailgraph-1.14-1.fc6
    monotone-0.37-3.fc6
    ntfs-3g-1.1030-1.fc6
NEW perl-DBI-Dumper-2.01-3.fc6 : Dump data from a DBI datasource to file
    perl-DBIx-DBSchema-0.35-1.fc6
    perl-Image-ExifTool-7.00-1.fc6
    perl-Set-IntSpan-1.13-1.fc6
    phpMyAdmin-2.11.2-1.fc6
    physfs-1.0.1-7.fc6
    queuegraph-1.1-2.fc6
    udunits-1.12.4-12.fc6


Changes in Fedora Extras 6: 


dbmail-2.2.7-1.fc6
------------------
* Wed Oct 31 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.7-1
- 2.2.7-1
- removed unused thread references patch
- removed unused hup patch
- removed unused gmime segv patch
- license clarification
- dbmail: Initscript Review (bz #246901)

* Tue Aug 28 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 2.2.5-7
- Rebuild for selinux ppc32 issue.

* Tue Jul 03 2007 Bernard Johnson <bjohnson at symetrix.com> 2.2.5-6
- patch to fix SEGV in dbmail-imapd

gnome-libs-1.4.2-7.fc6
----------------------
* Mon Oct 29 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-7
- Fix buffer overflow in popthelp (#354911)

* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-6
- Clarify licensing (db 1.85 is BSD with advertising, and many objects link
  to it)
- Don't manually install files in %install that aren't going to be packaged
- Preserve timestamps of files copied directly from source to installed package
- Encode ChangeLog as UTF-8
- Fix multiarch conflicts in %{_bindir}/gnome-config,
  %{_bindir}/libart-config, and
  %{_includedir}/gnome-1.0/libart_lgpl/art_config.h (#341321)
- Add patch to help configure find umode_t and hence avoid ppc64 build failure
- Use xdg-open in preference to htmlview for Fedora 7 onwards

* Fri Mar 09 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-5
- Fix GnomeDateEdit time format regression (#230186)

* Tue Feb 13 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-4
- Fix multilib conflict in /etc/mime-magic.dat (#228361)

gt5-1.4.0-4.fc6
---------------
* Sat Oct 27 2007 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.4.0-4
- applied suggestions by Mamoru Tasaka (all below)
- removed a chown patch by a direct use of an 'install' command
- removed INSTALL from a documentation set
- added using "text-www-browser" virtial Provides for F-8+

mailgraph-1.14-1.fc6
--------------------
* Tue Oct 30 2007 Bernard Johnson <bjohnson at symetrix.com> - 1.14-1
- v 1.14
- fix broken URLs (bz #251280)
- selinux policy fu (bz #243302)
- Mailgraph needs AddHandler cgi-script .cgi (bz #289021)
- Make initscript LSB compliant (bz #246977)

monotone-0.37-3.fc6
-------------------
* Sat Oct 27 2007 Roland McGrath <roland at redhat.com> - 0.37-3
- Updated for 0.37 release.
- Prevent destroying old passphrase file with 'service monotone genkey'.
- Put LSB standard comments in monotone.init for monotone-server subpackage.

ntfs-3g-1.1030-1.fc6
--------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1030-1
- bump to 1.1030

perl-DBI-Dumper-2.01-3.fc6
--------------------------
* Mon Oct 29 2007 Chris Weyl <cweyl at alumni.drew.edu> 2.01-3
- bump

* Sun Oct 14 2007 Chris Weyl <cweyl at alumni.drew.edu> 2.01-2
- add licensing text

perl-DBIx-DBSchema-0.35-1.fc6
-----------------------------
* Wed Oct 31 2007 Ralf Cors?pius <rc040203 at freenet.de> - 0.35-1
- Upstream update.

* Thu Sep 06 2007 Ralf Cors?pius <rc040203 at freenet.de> - 0.34-1
- Upstream update.
- Update license tag.

perl-Image-ExifTool-7.00-1.fc6
------------------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 7.00-1
- 7.00

* Sun Aug 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 6.95-1
- 6.95
- license tag fix

perl-Set-IntSpan-1.13-1.fc6
---------------------------
* Tue Oct 30 2007 Ralf Cors?pius <rc040203 at freenet.de>  - 1.13.1
- Upstream update.

phpMyAdmin-2.11.2-1.fc6
-----------------------
* Mon Oct 29 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.2-1
* upstream released new version

physfs-1.0.1-7.fc6
------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.0.1-7
- fix multilib conficts

* Sun Aug 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.0.1-6
- fix license tag, rebuild for BuildID

queuegraph-1.1-2.fc6
--------------------
* Tue Oct 30 2007 Bernard Johnson <bjohnson at symetrix.com> - 1.1-2
- new tarball - no version numbers updated
- fixed up patches to match new tarball
- removed repotag
- Queuegraph needs AddHandler cgi-script .cgi (bz #289031)
- queuegraph is denied by selinux (bz #247435)

udunits-1.12.4-12.fc6
---------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-12
- multilib enable

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-11.3
- add BR: perl(ExtUtils::MakeMaker)

* Mon Aug 27 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-11.2
- rebuild for BuildID

* Mon Aug 06 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.12.4-11.1
- fix license (MIT)



From devrim at CommandPrompt.com  Wed Oct 31 21:22:18 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Wed, 31 Oct 2007 14:22:18 -0700
Subject: rpms/postgis/FC-6 postgis.spec,1.7,1.8
In-Reply-To: <20071031221355.b3d276bc.mschwendt.tmp0701.nospam@arcor.de>
References: <200710292258.l9TMwTxx005376@cvs-int.fedora.redhat.com>
	<20071031221355.b3d276bc.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1193865738.10273.37.camel@laptop.gunduz.org>

Hi,

On Wed, 2007-10-31 at 22:13 +0100, Michael Schwendt wrote:
> Once you've built and published a sub-package, you need to obsolete it
> when you want to publish an update where the sub-package is not built
> anymore. Here "Obsoletes: postgis-jdbc < 1.3.1". 

Oops, sorry :( Just committed that fix to CVS, and will re-tag the
packages.

Regards,
-- 
Devrim G?ND?Z
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.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/20071031/844368c0/attachment.sig>

From roland at redhat.com  Wed Oct 31 21:28:50 2007
From: roland at redhat.com (Roland McGrath)
Date: Wed, 31 Oct 2007 14:28:50 -0700 (PDT)
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: buildsys@fedoraproject.org's message of  Wednesday,
	31 October 2007 16:39:46 -0400
	<20071031203946.4CFF015212F@buildsys.fedoraproject.org>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
Message-ID: <20071031212850.E09144D04AE@magilla.localdomain>

Can this robot be taught to take into account updates pending in bodhi but
not yet pushed?  i.e. either suppress complaints in those cases, or cite
rel-eng rather than the maintainer as the party who need to take action.


Thanks,
Roland



From mark.bidewell at alumni.clemson.edu  Wed Oct 31 21:31:38 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 31 Oct 2007 17:31:38 -0400
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <20071031195447.GD27461@nostromo.devel.redhat.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
	<bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
	<604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
	<20071031195447.GD27461@nostromo.devel.redhat.com>
Message-ID: <bfdeacfa0710311431i688e5731x5e0719b64b19663@mail.gmail.com>

That did seem to correct the problem

On 10/31/07, Bill Nottingham <notting at redhat.com> wrote:
>
> Jeff Spaleta (jspaleta at gmail.com) said:
> > On 10/31/07, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > > MOZ_LIB_DIR being defined as in F7.
> > So its the new $MOZ_PLUGIN_DIR definition that is causing the problem
> here.
> >
> > Is -wrapped something 64bit specific? Or is plugins-wrapped always
> > going to be available on all arches?  I wonder if there are any other
> > plugin packages which actually get burned by the change in plugin
> > path.
>
> plugins-wrapped is searched if nspluginwrapper is installed. I suspect
> running 'mozilla-plugin-config -i -f' (as root) would fix the original
> issue.
>
> Bill
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071031/9975d27a/attachment.htm>

From pertusus at free.fr  Wed Oct 31 21:32:41 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 31 Oct 2007 22:32:41 +0100
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <200710312307.35851.ville.skytta@iki.fi>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
	<20071031200015.GF27461@nostromo.devel.redhat.com>
	<4728EB2B.7070102@gmail.com>
	<200710312307.35851.ville.skytta@iki.fi>
Message-ID: <20071031213241.GD23272@free.fr>

On Wed, Oct 31, 2007 at 11:07:35PM +0200, Ville Skytt? wrote:
> On Wednesday 31 October 2007, Toshio Kuratomi wrote:
> > '''
> > When you implement the new Provides, please leave the old ones so that
> > third party packages that have grown to depend on them can continue to
> > function.  The Requires for all Fedora packages should be changed to use
> > the new provides by F-9, however.
> > '''
> 
> I think using the same backwards compatibility recommendations as in naming 
> guidelines' renaming/replacing existing packages section would work fine.
> 
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d

I think that it is a bit different here. And while we can say don't
remove it before F-9, I think that the virtual provides can be left in
by packagers if the want to. In my opinion virtual provides should
be more backward compatible than package names. So maybe something along:

'''
When you implement the new Provides, please leave the old ones so that
third party packages that have grown to depend on them can continue to
function, at least for F-9. After F-9 keeping or removing the provides
is left to the packager. The Requires for all Fedora packages should
be changed to use the new provides by F-9, however.
'''

--
Pat



From zaitcev at redhat.com  Wed Oct 31 21:47:06 2007
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 31 Oct 2007 14:47:06 -0700
Subject: linux1394 and f8
In-Reply-To: <1193840839.14742.18.camel@localhost.localdomain>
References: <47288307.7060306@nostar.net>
	<5256d0b0710310646i63264f94r86a8fd7c0bd6b854@mail.gmail.com>
	<1193840839.14742.18.camel@localhost.localdomain>
Message-ID: <20071031144706.f4e95b2e.zaitcev@redhat.com>

On Wed, 31 Oct 2007 10:27:19 -0400, Will Woods <wwoods at redhat.com> wrote:

> Right. Kristian H?gsberg is the primary author of the Juju stack - he's
> a Red Hat employee and Fedora contributor. He got all the Juju bits into
> F7 - the "new firewire stack" has been in place since then.

BTW, I think Kristian has passed Juju to Jay Fenlason.

-- Pete



From devrim at CommandPrompt.com  Wed Oct 31 22:04:59 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Wed, 31 Oct 2007 15:04:59 -0700
Subject: rpms/postgis/FC-6 postgis.spec,1.7,1.8
In-Reply-To: <1193865738.10273.37.camel@laptop.gunduz.org>
References: <200710292258.l9TMwTxx005376@cvs-int.fedora.redhat.com>
	<20071031221355.b3d276bc.mschwendt.tmp0701.nospam@arcor.de>
	<1193865738.10273.37.camel@laptop.gunduz.org>
Message-ID: <1193868299.10273.41.camel@laptop.gunduz.org>

Hi,

On Wed, 2007-10-31 at 14:22 -0700, Devrim G?ND?Z wrote:
> Oops, sorry :( Just committed that fix to CVS, and will re-tag the
> packages.

FWIW, please don't push this package to stable. Upstream *just* sent a
fix and I want to try that.

Regards,
-- 
Devrim G?ND?Z
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.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/20071031/edc6b1e8/attachment.sig>

From pertusus at free.fr  Wed Oct 31 22:09:26 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 31 Oct 2007 23:09:26 +0100
Subject: Summary of the 2007-10-30 Packaging Committee meeting
In-Reply-To: <ufa3avrysas.fsf@epithumia.math.uh.edu>
References: <ufa3avrysas.fsf@epithumia.math.uh.edu>
Message-ID: <20071031220926.GE23272@free.fr>

On Wed, Oct 31, 2007 at 02:53:31PM -0500, Jason L Tibbitts III wrote:
> Meeting minutes and full logs of the packaging committee meeting which
> occurred on 2007-10-30 are online:
> 
> http://fedoraproject.org/wiki/Packaging/Minutes
> http://fedoraproject.org/wiki/Packaging/Minutes20071030
> 
> Executive summary:
> 
> No new guidelines this week.
> 
> Issues pending FESCO ratification:
> 
> * Standardizing the set of virtual provides for various servers:
>   http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
>   * Accepted (5 - 0)
>   * Voting for: spot rdieter abadger1999 tibbs f13
>   * There is still tweaking to be done, and because this will require
>     changes to several packages, FPC is asking that this be driven via
>     the feature process for F-9.

I have remove the ssmtp references, since it is obsolete, and I have
changed Misc into Plan at the bottom of the page, taking into account
Toshio and Ville comments:

http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides

--
Pat



From pbrobinson at gmail.com  Wed Oct 31 23:09:48 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 31 Oct 2007 23:09:48 +0000
Subject: IcedTea Plugin not working on F8 x86_64
In-Reply-To: <20071031195447.GD27461@nostromo.devel.redhat.com>
References: <bfdeacfa0710311021nf7e9db1l93743b0104cb8fbe@mail.gmail.com>
	<fgaeoa$u8o$1@ger.gmane.org>
	<604aa7910710311049x73645401qc3634231f86d2b94@mail.gmail.com>
	<bfdeacfa0710311057n5884941sd09124560619eb9f@mail.gmail.com>
	<604aa7910710311105k1c8e102dlba3d76bc704655e7@mail.gmail.com>
	<bfdeacfa0710311118s435ab4f6m3c33b65eca2d2be1@mail.gmail.com>
	<604aa7910710311124m707a4d5dt2ba697c535652227@mail.gmail.com>
	<20071031195447.GD27461@nostromo.devel.redhat.com>
Message-ID: <5256d0b0710311609ta4275cdv8f3bdcee1f53bd@mail.gmail.com>

> > > MOZ_LIB_DIR being defined as in F7.
> > So its the new $MOZ_PLUGIN_DIR definition that is causing the problem here.
> >
> > Is -wrapped something 64bit specific? Or is plugins-wrapped always
> > going to be available on all arches?  I wonder if there are any other
> > plugin packages which actually get burned by the change in plugin
> > path.
>
> plugins-wrapped is searched if nspluginwrapper is installed. I suspect
> running 'mozilla-plugin-config -i -f' (as root) would fix the original
> issue.

I was having problems with the java (and swfdec-mozilla too) not
working on x86_64 (yes all 64 bit packages).

For the java if I went to about:plugins it was listed. If I went to
www.java.com it and selected the detect option it detected version
1.7.0 so that looked OK, but a couple of java sites I use on occasion
would come back with errors saying java wasn't installed.

For swfdec (yes I know its not part of Fedora) it wouldn't even detect
it in about:plugins.

I tried the above and got the following:

[root at euuklonw7300b1n ~]# mozilla-plugin-config -i -f
*** NSPlugin Viewer  *** ERROR: libxpcom.so: cannot open shared object
file: No such file or directory
[root at euuklonw7300b1n ~]# ldconfig -v | grep libxp
[root at euuklonw7300b1n ~]#

A rpm gave me
[root at euuklonw7300b1n ~]# rpm -ql firefox| grep libxpcom
/usr/lib64/firefox-2.0.0.8/components/libxpcom_compat_c.so
/usr/lib64/firefox-2.0.0.8/libxpcom.so
/usr/lib64/firefox-2.0.0.8/libxpcom_compat.so
/usr/lib64/firefox-2.0.0.8/libxpcom_core.so
[root at euuklonw7300b1n ~]#

So I added a /etc/ld.so.conf.d/firefox.conf file with
/usr/lib64/firefox-2.0.0.8/ in it. Ran a ldconfig and restarted
firefox and it all started working.

So I'm not sure if there's suppose to be links for libxpcom.so or
something else or whether the plugins have issues. Let me know if you
want more details.

Peter



From mmcgrath at redhat.com  Sun Oct 14 22:43:46 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sun, 14 Oct 2007 22:43:46 -0000
Subject: intermittent fedora web service outages
In-Reply-To: <20071014051221.GA5135@crow.myhome.westell.com>
References: <20071014051221.GA5135@crow.myhome.westell.com>
Message-ID: <471299DA.6000107@redhat.com>

Luke Macken wrote:
> Mike is in the process of tracking down some issues with our database at
> the moment, so there may be some intermittent outages with some of our
> web services, including:
>
>     - bodhi
>     - koji
>     - pkgdb
>     - mirrormanager
>     - accounts system
>   

FYI All, this should be fixed now.  Those interested in the details 
(mostly postgresql stuff) please refer to ticket:

https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/190

    -Mike